Как сократить ручное тестирование и можно ли без него обойтись
С развитием технологий мир меняется. Все больше функций и процессов автоматизируются, все менее востребован ручной труд. И это применимо не только к рабочим специальностям, но и к самой IT-индустрии. Manual QA как отдельная специализация может со временем уйти в историю.
Вокруг тестирования ходит очень много разговоров, но на практике крайне мало команд качественно покрывают тестами свой код. В статье я расскажу о том, как мы в Railsware трансформировали привычный процесс ручного тестирования в набор подходов к разработке.
Мы говорим только о собственном примере, но он является достаточно показательным, так как в портфолио компании присутствуют продукты и платформы различных размеров и сложностей для разнообразных индустрий.
Разработка с ручным тестированием
До 2011 года наша команда работала по весьма привычному алгоритму разработки программного обеспечения, ему же следует большинство аутсорсинговых фирм на сегодняшний день.
Проджект-менеджеры готовили задачи инженерам, те, в свою очередь, поскорее писали код, не особо заботясь о качестве, и отдавали разработанную фичу на тестирование. QA обычно находил множество багов и нестыковок, отправлял фичу на доработку. И этот цикл повторялся по нескольку раз. Причем зачастую, поправив баги в одном месте, инженеры порождали новые в других местах.
Тогда ходило много разговоров о юнит и интеграционном тестировании, но на практике не так много команд (включая нас) применяли эти подходы. Если за тебя баги будут искать другие люди, писать тесты — уже не твоя головная боль.
Я не утверждаю, что во всех проектах, где есть отдельные QA команды, не пишутся тесты, но такое совпадение можно заметить достаточно часто.
Трансформация подходов к тестированию продуктов
В процессе перехода Railsware к модели software consultancy, о которой мы писали ранее, нам необходимо было значительно повысить качество создаваемых продуктов и, соответственно, квалификацию команды. Ведь без этих составляющих выйти на новый виток развития компании не представлялось возможным. Как часть процесса трансформации, был усовершенствован и наш подход к тестированию.
Мы изучали успешные примеры на рынке и экспериментальным путем выявили для себя несколько ключевых подходов и техник, которые используем и сегодня:
- Юнит-тесты и интеграционные тесты — неотъемлемая часть кода. Абсолютно все инженеры на всех проектах обязаны сопровождать фичи автоматическими тестами.
- Непрерывная интеграция (Continuous Integration) — система, при которой автоматические тесты прогоняются при любом изменении кода. На рынке существует множество решений для такого рода автоматизации, вот некоторые из них: Jenkins, Circleci, Travis CI.
- Обязательное использование валидаторов качества кода, таких как Rubocop, ESLint.
- Pull Request Policy. Любой код, который попадает в основную ветку проекта (master branch), должен быть проверен и утвержден одним или более участником, но не самим разработчиком.
- Парное программирование — техника разработки, которая предполагает совместную одновременную работу двух инженеров над одним кодом.
При дисциплинированном применении перечисленных подходов, технический долг в вашем проекте существенно сократится. Следовательно, сократится и количество багов в системе.
Значит ли это, что мы полностью исключили мануальное тестирование?
С внедрением подходов, описанных выше, загрузка мануальных тестировщиков на проектах существенно сокращалась. Для full-time загрузки тестировщиков привлекали part-time сразу на несколько проектов (если говорить о небольших и средних продуктах). Но эта модель оказалась неэффективной: QA не погружался полностью в контекст тестируемого продукта, не был в курсе всех принимаемых решений. Такая вовлеченность приносила больше проблем, чем пользы. Потому мы покрыли функцию мануального тестирования с помощью еще одного подхода, который позаимствовали у наших голландских коллег по проекту Philips Directlife (у них на тот момент уже не было собственных QAs).
TestFest — это сессия мануального тестирования, которая проводится перед большими релизами. В ней участвуют инженеры, продакт-менеджеры, иногда UI/UX дизайнеры, команда со стороны клиента. Об этом подходе мы напишем отдельную статью, но если коротко, то на несколько часов вся команда становится мануальными тестировщиками.
Результат TestFest — список багов, каждый из которых получает свой приоритет и добавляется в общий скоуп.
Применение данного подхода естественным образом убрало какую либо потребность в отдельном человеке на позиции manual QA.
Выводы
Railsware постепенно ушла от необходимости иметь отдельного manual QA в команде.
В процессе трансформации бизнес-модели мы, в первую очередь, стремились повысить качество кода. За счет применения новых подходов к разработке количество багов значительно уменьшилось, как и объем работ для тестировщиков. Part-time загрузка QA не позволяла им полноценно погружаться в контекст продукта, что сказывалось на результатах работы. В итоге, роль мануал QA была полностью исключена из организационной структуры, а функция тестирования распределена между участниками команды.
Разработчики, в свою очередь, смогли значительно улучшить качество создаваемого кода за счет изменений подходов к разработке. Это повысило их квалификацию, и, как результат, качество создаваемых продуктов.
В таком формате мы разрабатываем продукты (как небольшие, так и достаточно крупные платформы) вот уже 7 лет. Очевидно, что в продуктах есть баги. Но если сравнить качество продуктов Railsware до и после трансформации QA — последние выигрывают со значительным отрывом.
Мы не отрицаем, что существуют очень специфические и сложные продукты, которые не мануальным способом без специально выделенных людей протестировать сложно. Но в остальных случаях мануальное тестирование продуктов может быть заменено набором подходов к разработке, что приведет к уменьшению технического долга и повышению качества продукта в целом.
