Комментарии 16
А что делать, если фичи типовые, дока написана за пол дня, а до 1 задачи на тест еще день-два? ☺️
— ревью аналитики/прототипов. Бывает так, что маленький вопрос, нюанс от тестировщика ломает к чертям всё, что было придумано и надо придумывать что-то новое;
— составление кейсов для тестов. Не важно, кто пишет тесты, какие-то тесты всё-равно должны/будут написаны разработчиком. Набор хороших сценариев для функциональных тестов, переданный разработчику, серьёзно уменьшает количество переоткрытий задачи по результатам тестирования;
— планирование тестирования интеграций. Если у нас фича такая, что задевает несколько модулей (которые могут разрабатываться разными командами), надо договориться с другими сторонами об объемах интеграционного тестирования (разделить ответственность за контракты и использование контрактов);
— карты/чеклисты/тестпланы (кому что нравится) — для каких-то сложных фич, где сложно всё учесть и уместить в голове.
Проблема в желании вогнать в границы спринта работу на принципиально разных стадиях, устроив команде микроводопад со всеми его недостатками. В начале спринта BA рискуют не успеть наделать задач, а QA в конце - недотестировать.
Сдвиньте декомпозицию и анализ сторей на полспринта до начала нового, а тестирование с релизом на полспринта после - и не будет ни у кого ни каких простоев.
У разработчиков в начале спринта появится время на багфикс и возможность знакомиться новыми задачами, собирая PoC на уровне happy path и обратную связь. QA в это время тестируют результаты предыдущей итерации, и готовят отчёты к релизу. Во второй половине - дев команда доводит код до продакшн состояния, реализуя сценарии отработки сбоев, покрывая юнит тестами. QA вместе с PO и TL прорабатывают сценарии и тесткейсы на следующий спринт.
Проблема зиждется на скрам-методологии, которая декларирует необходимость выпуска готовой протестированной фичи в конце спринта. Все пытаются в это прокрустово ложе поместиться, но я ни разу не видел, чтобы у кого-то это получилось.
Скорее в части ее трактовок. Почему-то некоторые считают, дескать раз спринты по 2 недели, то в таком скрам-роддоме теперь нужно и детей вынашивать за это же время, а не 9 месяцев как обычно. В результате начинают выдавать если и живых, то сильно недоношенных.
Нет, чтобы релизить каждые 2 недели детей вам нужно не это. А нужен буфер из почти (без двух недель) готовой работы.
Просто разбейте работу на двухнедельные этапы и определите критерии качества в конце каждого из них, чтобы можно было оценить завершенность. Если все в пределах нормы - идете дальше. Если заметите, что-то не так, вы можете скорректировать или прервать и взяться за другое. В этом и состоит гибкость если сравнивать с классическим водопадом.
А вы правы: уже начал писать коммент с возражением, но решил еще раз прочитать Скарм Гайд ) И действительно: там нигде не сказано, что ВСЕ задачи, взятые в спринт, должны быть выполнены. Там сказано лишь, что результатом спринита должен быть один или несколько инкрементов -- задач соответствующим критериям готовности.
То есть никакого запрета на то, чтобы брать в спринт задачи, которые будут готовы лишь в следующем спринте Скрам Гайд не накладывает.
В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
Как выше отметили — самое лучшее, это либо дотестировать функционал с прошлых спринтов, либо провести ревью аналитики / дизайна.
Есть вероятность, что другие действия пойдут во вред. Так как пропистаь на уровне прототипов тест-кейсы скорее всего получится только очевидные. Что и так делается быстро. Неочевидные либо будут с высокой долей предположения и часть работы пойдет в стол.
Могут быть исключения, если у вас на проекте сработанная команда, долгий горизонт планирования и все предсказуемо.
Не использовать скрам.
Прям все так идеально, а по факту тестировщики вступают в работу в основном, когда тикеты уже готовы для тестирования в спринте. Что "будем делать" настолько сырое, что можно создать лишь базовые проверки, которые в последствии нужно будет апдейтить, потому что недалеко от ready for testing в тикете появляются новые дополнения.
Как же сложно сформулировано. Создать матрицу трассировки, кого чего трассировки:)
полезная статья, спасибо.
Полезная статья, на моем опыте задачи есть всегда, даже успела выгореть.
Что делать, если в начале спринта у тестировщика нет задач?