Построить процесс тестирования в командах разработки, в которых тестирования не было в принципе- это не простая, но типичная задача для нашей реальности. Есть много гибких амбициозных молодых команд разработчиков, которые работают над серьезными проектами, пишут Юнит-тесты и сами тестируют свой продукт. Но через некоторое время, приходит осознание, что для тестирования следует нанять человека и получить ему эти область. Человека нанимают, но что с ним делать дальше- большой вопрос. В этой статье я хочу поделиться нашим опытом, как мы строили процесс тестирования именно в таких командах. Самое интересное, задача заключалась не только в том, что построить процесс, но и изменить/создать заново отношение команды к тестированию в принципе.

Строим процесс. Начало

Какие были у нас входных данные. Это требования от руководителя команд:

• Проводил мануальное тестирование и заносил баги. Сценарии тестирования заносил в TFS.
• Дописывал unit-тесты по кейсам, которые не были покрыты разработчиками
• Проверял code-coverage, выносил задачи разработчикам
• Писал тесты интерфейса
• Писал нагрузочные тесты, проводил нагрузочное тестирование
• Давал рекомендации руководителю команды по готовности к релизу
• KPI тестера будет формироваться из найденных багов на продакшене

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

К каким выводам мы пришли

1. 1. Нельзя строить процесс тестирования, не влияя на процесс разработки продукта в команде, а это не всегда и не всем нравится и как следствие, не факт, что что-то будет изменено.
   2. До сих пор к тестировщикам и тестированию некоторые продуктовые команды относятся с некоторым пренебрежением. Если ты не пишешь продуктовый код- тебе не место в нашей команде.
   3. Необходимо документировать все сделанные шаги, все договоренности, сделать общий доступ к такой информации.
   4. Стараться формализовать видимый положительный результат каждого этапа улучшения процесса.
   5. Невозможно взять готовый сценарий улучшения/построения процесса и внедрить его, все необходимо изменять и адаптировать динамически к текущим реалиям (постоянно).
   6. Запрашиваем обратную связь, корректируем разработанную стратегию.
   7. И самое главное, необходимо работать с теми, кто действительно этого хочет.

Это будет интересно:

как мы Канбан строим в трех частях:  Часть 1, Часть 2, Часть 3