Это важная деталь :) QA не помогают, QA -инженер часть developers в скраме. И все команда developers отвечает за качество, сроки, выполнение критериев приемки. Процесс очень индивидуален в каждой команде. Процесс который ты описал тоже имеет место на жизнь, но лично мы так делаем редко. Пункт 3 обычно избыточен, двойная работа, тесты потом все равно выгрузятся (у нас :) ). Я бы описал примерно такой процесс: 1. На спринт ставится задача сделать продуктовый инкремент какой-то (спринт-гоал) 2. developers при планировании разбирают, как им задачу выполнить. Как будут использовать инкремент, ну туже самую форму, вероятно, разбивают на подзадачи. Вместе обдумывают что и каким способом будет протестировано (тут наш QA активно помогает). 3. То, что было решено покрыть автотестами - разработчики пишут сами, QA ревьюит. При каком-то событии (тут неважно, мерж в мастер, создание ПР или что-то еще) - тесты из кода в выгружаются в TMS 4. Когда все готово - инкремент проходит приемочное и/или исследовательское тестирование. Те тесткейсы, что при планировании были предусмотрены как ручные проверяются как раз тут. Все ручное - ручным способом попадает в TMS. 5. Задача выполнена, когда все пункты Definition of done выполнены: критерии приемки удовлетворены, не менее 70% кода покрыто тестами, задача в проде и т.п.
Я также еще раз хочу отметить важную вещь, которая у тебя в пункте 5 "В процессе работы разработчики обязаны покрыть тестами все тесткейсы". Если разработчик, написал код, который потом сложно протестировать, ему больно и он страдает. Важно не жертвовать качеством автотестов, потому что тут разработка эволюционирует и начинает писать так, чтобы было легче протестировать :) Обычно это означает лучшую, менее связанную архитектуру, разбитую на компоненты. От этого выигрывают все, в том числе сами разработчики.
Привет, спасибо за вопрос, он довольно интересный. На самом деле процессы - это достаточно холиварная тема. Тут нужно понимать, а для чего все делается, какой профит компания с этого получит. Допустим, мы, как владельцы продукта хотим получить высокое качество продукта. В идеале - измеримое, чтобы мы могли понимать где и как у нас обстоят дела, где-то нас все устраивает, а где-то нужно чуть больше. Мы приходим в команду и спрашиваем - а что у нас с качеством? Кто нам ответит на вопрос? QA или тимлид разрабов? В твоем случае, получается, что разрабы какие-то тесткейсы написали, но они не знают как тестировать и QA не знает, а что они вообще хотели протестировать. Если ответственный за качество QA, то почему он не может ставить требования разработке?
Одно из решений этой ситуации - это скрам подход. По скраму нету отдельной сущности QA. Там есть dev-team, владелец продукта, скрам-мастер и стейкхолдеры (заинтересованная сторона). И скрам постулирует, что в дев-команде все могут делать все, там нету деления на какие-то специальности, т.е. дев-команда вся целиком отвечает за качество, каждый ее участник, в этом вся суть. Если у нас, например, 3 бэка и 1 QA, это 4 участника дев-команды. И, для обеспечения качества, QA максимально шарит свою экспертизу внутри команды на всех этапах разработки.
Давай пример. Вот надо сделать форму на странице, которая складывает два числа, это цель спринта. На этапе планирования, когда мы пишем критерии приемки, подключается QA и своей экспертизой сразу расписывает какие тесткейсы на каком уровне будут протестированы. Те тесткейсы, что будут автоматизированы (юниты на сложение, интеграционные на получение запроса от формы и е2е на полный тест формы) - пишут разработчики, QA помогает им и принимает тесткейсы на код-ревью. Те тесткейсы, что не будут автоматизированны (лучше их минимизировать) - руками тестирует сам QA инженер. Чтобы понимать, что вообще протестировано, на каком этапе, тесткейсы заносятся в ТМС. Ручные руками, автоматизированные - как выберете, у нас разметка и парсинг из кода. Это очень облегчает регрессионное тестирование в будущем. И в таком случае, практически любой участник команды сможет показать кусочек тестовой модели которая относится к этой форме. Качество уже можно начинать измерять.
Что делает QA инженер все оставшееся время? Кроме помощи разработчикам в планировании, ревью, мануальном тестировании есть еще много работ, на которые раньше нехватало времени, например, разбор багов, инцидентов, нагрузочное тестирование, мутационное, проработки регламентов выкладки и тому подобное, тут список бесконечен.
Это важная деталь :) QA не помогают, QA -инженер часть developers в скраме. И все команда developers отвечает за качество, сроки, выполнение критериев приемки.
Процесс очень индивидуален в каждой команде. Процесс который ты описал тоже имеет место на жизнь, но лично мы так делаем редко. Пункт 3 обычно избыточен, двойная работа, тесты потом все равно выгрузятся (у нас :) ).
Я бы описал примерно такой процесс:
1. На спринт ставится задача сделать продуктовый инкремент какой-то (спринт-гоал)
2. developers при планировании разбирают, как им задачу выполнить. Как будут использовать инкремент, ну туже самую форму, вероятно, разбивают на подзадачи. Вместе обдумывают что и каким способом будет протестировано (тут наш QA активно помогает).
3. То, что было решено покрыть автотестами - разработчики пишут сами, QA ревьюит. При каком-то событии (тут неважно, мерж в мастер, создание ПР или что-то еще) - тесты из кода в выгружаются в TMS
4. Когда все готово - инкремент проходит приемочное и/или исследовательское тестирование. Те тесткейсы, что при планировании были предусмотрены как ручные проверяются как раз тут. Все ручное - ручным способом попадает в TMS.
5. Задача выполнена, когда все пункты Definition of done выполнены: критерии приемки удовлетворены, не менее 70% кода покрыто тестами, задача в проде и т.п.
Я также еще раз хочу отметить важную вещь, которая у тебя в пункте 5 "В процессе работы разработчики обязаны покрыть тестами все тесткейсы". Если разработчик, написал код, который потом сложно протестировать, ему больно и он страдает. Важно не жертвовать качеством автотестов, потому что тут разработка эволюционирует и начинает писать так, чтобы было легче протестировать :) Обычно это означает лучшую, менее связанную архитектуру, разбитую на компоненты. От этого выигрывают все, в том числе сами разработчики.
Привет, спасибо за вопрос, он довольно интересный.
На самом деле процессы - это достаточно холиварная тема. Тут нужно понимать, а для чего все делается, какой профит компания с этого получит. Допустим, мы, как владельцы продукта хотим получить высокое качество продукта. В идеале - измеримое, чтобы мы могли понимать где и как у нас обстоят дела, где-то нас все устраивает, а где-то нужно чуть больше. Мы приходим в команду и спрашиваем - а что у нас с качеством? Кто нам ответит на вопрос? QA или тимлид разрабов? В твоем случае, получается, что разрабы какие-то тесткейсы написали, но они не знают как тестировать и QA не знает, а что они вообще хотели протестировать. Если ответственный за качество QA, то почему он не может ставить требования разработке?
Одно из решений этой ситуации - это скрам подход. По скраму нету отдельной сущности QA. Там есть dev-team, владелец продукта, скрам-мастер и стейкхолдеры (заинтересованная сторона). И скрам постулирует, что в дев-команде все могут делать все, там нету деления на какие-то специальности, т.е. дев-команда вся целиком отвечает за качество, каждый ее участник, в этом вся суть. Если у нас, например, 3 бэка и 1 QA, это 4 участника дев-команды. И, для обеспечения качества, QA максимально шарит свою экспертизу внутри команды на всех этапах разработки.
Давай пример. Вот надо сделать форму на странице, которая складывает два числа, это цель спринта.
На этапе планирования, когда мы пишем критерии приемки, подключается QA и своей экспертизой сразу расписывает какие тесткейсы на каком уровне будут протестированы.
Те тесткейсы, что будут автоматизированы (юниты на сложение, интеграционные на получение запроса от формы и е2е на полный тест формы) - пишут разработчики, QA помогает им и принимает тесткейсы на код-ревью.
Те тесткейсы, что не будут автоматизированны (лучше их минимизировать) - руками тестирует сам QA инженер.
Чтобы понимать, что вообще протестировано, на каком этапе, тесткейсы заносятся в ТМС. Ручные руками, автоматизированные - как выберете, у нас разметка и парсинг из кода. Это очень облегчает регрессионное тестирование в будущем. И в таком случае, практически любой участник команды сможет показать кусочек тестовой модели которая относится к этой форме. Качество уже можно начинать измерять.
Что делает QA инженер все оставшееся время? Кроме помощи разработчикам в планировании, ревью, мануальном тестировании есть еще много работ, на которые раньше нехватало времени, например, разбор багов, инцидентов, нагрузочное тестирование, мутационное, проработки регламентов выкладки и тому подобное, тут список бесконечен.