Ну не знаю, очень зависит от размера и уровня команды

да не, просто 2 дня на требования как-то дофига - если конечно задачи не для следующей после текущей итерации

т.е. типа выглядит как : 2 дня сидим и непонятно чем занимаемся пока тестировщики с аналитиками нам требования подготовят

нет, почему: вручную по всем страницам тоже можно пройтись

Около 1000 страниц) не думаю)

git diff ?

Спасибо, попробую разобраться

Мы хотим решить проблему процессов, т.е. чтобы в разработку своевременно уходили проверенные тестировщиком требования, и что бы в любой момент любой участник команды мог узнать, в какой стадии находится та или иная задача (можно ли брать ее в разработку)

Я думаю проблема, всё таки, звучит скорее как "Мы хотим избавиться от того, что разработчику приходят требования низкого качества". Если вам нужно гарантировать, что любая задача пришедшая в разработку прошла ревью требований - просто добавляете соответствующий статус в свой воркфлоу. "Сбор требования" -> "Ревью требований" -> "Бэклог спринта", условно.

Около 1000 страниц) не думаю)

всего 1-2 дня работы )) если ничем больше не заниматься )) если разовая процедура - лучше ручками; если есть риск регрессии в будущем - то да, АТ это решение

всего 1-2 дня работы )) если ничем больше не заниматься )) если разовая процедура - лучше ручками; если есть риск регрессии в будущем - то да, АТ это решение

А почему лучше ручками, учитывая что автотест в данном случае будет быстрее и эффективнее?

да не, просто 2 дня на требования как-то дофига - если конечно задачи не для следующей после текущей итерации

А может эти 2 дня - это суббота и воскресенье?)))

Как у нас было. Аналитик засылает фичи в релиз. Фича (хорошо описанная) попадает на тестировщика. Он знакомится и задает вопросы аналитику. Потом два дня идет planning game, на котором каждый тестер (15 человек в команде было) делает презентацию своей фичи и примерный список тест-кейсов. Остальные тестеры внимательно слушают и вносят замечания. Потом пишутся автотесты по фиче.

Спасибо. Думаю, что подобную схему можно успешно адаптировать и для работы небольшой команды. Только возникает вопрос: если тестер один на проекте, то кто тогда будет слушать его презентацию и вносить замечания?

Спасибо. Думаю, что подобную схему можно успешно адаптировать и для работы небольшой команды. Только возникает вопрос: если тестер один на проекте, то кто тогда будет слушать его презентацию и вносить замечания?

аналитики )

А почему лучше ручками, учитывая что автотест в данном случае будет быстрее и эффективнее?

Раз вопрос Как - значит АТ инфраструктуры у них нет, значит нужно будет разбираться с инструментом и потом писать и отлаживать под него скрипт. А это больше 2ух дней.

Довольно много допущений в одном предложении.

согласен )) но мы не знаем контекста и можем предлагать всякое - а человек уже сам выберет )

Раз вопрос Как - значит АТ инфраструктуры у них нет, значит нужно будет разбираться с инструментом и потом писать и отлаживать под него скрипт. А это больше 2ух дней.

А нафига там инфраструктура для одиночного прогона? Набрасываем скрипт (Через регулярки или прямым сравнением), запускаем. Может даже селениум не нужен будет...

Запускаем, идем пить кофе

А нафига там инфраструктура для одиночного прогона? Набрасываем скрипт (Через регулярки или прямым сравнением), запускаем. Может даже селениум не нужен будет...

дак у вас тоже допущение, что человек знает "Как набросать скрипт?" - "какой инструмент применить?" - "как этот инструмент работает?" по моему более вероятно что человек этого не умеет, чем то, что он это умеет

дак у вас тоже допущение, что человек знает "Как набросать скрипт?" - "какой инструмент применить?" - "как этот инструмент работает?" по моему более вероятно что человек этого не умеет, чем то, что он это умеет

Хм... логично... Но это как обычно, я со своей колокольни посмотрел...

Но с подобной задачи началось мое изучение питона... Если я помню, меньше дня ушло на скрипт...

При нулевых знаниях...

Я думаю проблема, всё таки, звучит скорее как "Мы хотим избавиться от того, что разработчику приходят требования низкого качества". Если вам нужно гарантировать, что любая задача пришедшая в разработку прошла ревью требований - просто добавляете соответствующий статус в свой воркфлоу. "Сбор требования" -> "Ревью требований" -> "Бэклог спринта", условно.

Спасибо. Так же еще стоит вопрос оперативности. Команда в лице РП заинтересована в максимально быстром прохождении данного этапа, потому что зачастую задачи добавляются в спринт в последний момент

да я вообще-то тоже: Нужно писать корректно: Если у вас есть опыт автоматизации - то написать скрипт. Если нет опыта и разовая операция - то руками Если нет опыта и разовая операция которая "терпит" - изучить Если нет опыта и операция многоразовая - изучить

Если нет опыта и разовая операция - то руками Если нет опыта и операция многоразовая - изучить + есть деньги -> аутсорс, как вариант

Спасибо. Так же еще стоит вопрос оперативности. Команда в лице РП заинтересована в максимально быстром прохождении данного этапа, потому что зачастую задачи добавляются в спринт в последний момент

Это проще решать по средством понимания приоритетов в команде и коммуникациями. Канбан доска, приоритеты задач на ней, соотв. каждый тестировщик будет видеть, что задача с приоритетом N ждет ревью требований. Если его текущие задачи менее приоритетны - берет её.

Мне кажется все попытки форсить эти задачи насильно, а не из осознания приоритетов, принесут больше вреда чем пользы.

Это проще решать по средством понимания приоритетов в команде и коммуникациями. Канбан доска, приоритеты задач на ней, соотв. каждый тестировщик будет видеть, что задача с приоритетом N ждет ревью требований. Если его текущие задачи менее приоритетны - берет её.

Спасибо

Отдельный совет: старайтесь распределять нагрузку тестировщиков внутри спринта, т.к. понятно, что пик нагрузки приходится на конец спринта разработки (наибольшее количество жирных задач уходят в тестирование) - следовательно первую часть спринта можно в большей степени посвятить анализу требований, в т.ч. и на следующие спринты (если есть что ревьюить).

Ну и отдельный холивар: достаточно ли для качественных требований того, что их ревьюят тестировщики. Это сильно ситуативно и зависит от процессов в компании, команды и вообще того, как люди привыкли работать. На мой практике было эффективнее участвовать в разборе требований всей команде (дизайнеры, разработчики, тестировщики, PO\PM). Это тратит много времени команде, но если есть проблемы с полнотой и понятностью требований - позволяет разработчикам лучше понимать, что от них хотят получить, что бы даже в условиях неполных требований (а они почти всегда таковые) принимать правильные решения.

Новосибирских, томских, иркутских, красноярских, и даже кемеровских тестировщиков, приглашаю в чатик QA Сибирь https://t.me/qa_siberia

Что за дискриминация?

по географическому признаку же

а как будет осуществляться фильтрация?

вобщем грамотный перелив)

Что за дискриминация?

Да, заходи, чего уж. Прописку пока не спрашиваем. Будешь смотреть вакансии и недоумевать, а почему зп в два раза ниже рынка.

вжух

Всем привет. Какую книгу можете посоветовать для обучения программированию на python для новичка? (и ещё, какую книгу могли бы посоветовать по компьютерным сетям?)

Всем привет. Какую книгу можете посоветовать для обучения программированию на python для новичка? (и ещё, какую книгу могли бы посоветовать по компьютерным сетям?)

по питону Лутц.

по питону Лутц.

я так понимаю, пятое издание ещё не переведено на русский язык?

ну если есть знания языка, можно и не ждать перевода. Но есть не очень древнее 4е издание.

2011 вроде

да, есть такое

а отличия существенные?

а отличия существенные?

не скажу. я по 4му учусь. 5е издание еще не смотрела

Лутц вообще классно базу дает, что главное. А различие между версиями можно и на python.org посмотреть)

Лутц вообще классно базу дает, что главное. А различие между версиями можно и на python.org посмотреть)

Это если ты его хотя бы до середины осилишь. Я лично таких людей не знаю, кто смог. Но все советуют :) такое себе, если знаешь английский - книжек и курсов по питону очень много, начинать с Лутца - это путь для мазохистов )

По опыту, вот этот курс нормально заходил даже тем, кто никогда не сталкивался с программированием https://www.codecademy.com/learn/learn-python Но нужен английский

Кодакадеми -> Дейв Томас \ Питер Купер. Это если для старта.

Если чуть выше novice уровня, то Ruby Cookbook.

кстати, а в каких случаях используется руби для автоматизации?

appium

selenium - если речь о web и ui

rspec любят некоторые

selenium - если речь о web и ui

Я думаю человека интересовал вопрос почему используется именно руби, а не что-нибудь другое.

Я думаю человека интересовал вопрос почему используется именно руби, а не что-нибудь другое.

интересный подтекст ))) я такого не уловил в вопросе ))

Это, вообще, вполне логичный подтекст, если прочитать вопрос.

но наверное бы тогда вопрос звучил бы - "Чем руби для Такой-То-Ситуации лучше чем Такой-то-язык ?"

или "чем руби лучше тогда-то ? "

но наверное бы тогда вопрос звучил бы - "Чем руби для Такой-То-Ситуации лучше чем Такой-то-язык ?"

Вопрос звучал так: в каких случаях для автоматизации используют руби?