Недавно на работе опять столкнулась с задачей внедрения автоматизации на проект, которую мне следовало спланировать, как QA эксперту.
И снова я увидела непонимание менеджментом роли авто-тестировщиков.
Эта тема уже набила мне оскомину, поэтому я решила кратко её осветить, т.к. знаю, что на меня подписано много IT-специалистов, для которых это будет очень актуально.
Итак, давайте не забывать, что авто-тестировщики - это, в первую очередь, ТЕСТИРОВЩИКИ.
В принципе, на этом можно и закончить.
Как-то так у меня в жизни складывалось, что в какой бы компании и команде я не работала, на роли автотестеров всегда брали людей, «которые умеют писать код и работать с пайплайнами».
В связи с этим на в команду часто брали бывших или несостоявшихся разработчиков или новичков, которые только научились на каких-либо курсах неплохо писать код.
Да, человек может покрывать кодом мануальный тест-кейс. Для этого ему не обязательно знать основы тестирования - он просто шаг за шагом описывает каждое действие куском кода, не вдумываясь в смысл самого кейса.
Но если ваша система немного сложнее, чем калькулятор, то для корректной работы с ней необходимо разбираться, иначе можно очень неприятно встрять.
В работе любого специалиста всегда имеет место быть человеческий фактор, а при создании автоматизированного тест-кейса риск того, что он вреда нанесёт больше, чем пользы, обратно пропорционален знанию автора системы и скиллов мануального тестировщика.
Самый плохой случай выглядит так:
Автоматизатор покрыл кодом один тест-кейс, особо не вдумываясь в него и не анализируя. Другой такой же автоматизатор его проревьюил и одобрил. Залили в общий пайплайн. Стали гонять на необходимом окружении. Через какое-то время (неделя, месяц, полгода) ВНЕЗАПНО вскрылась куча багов, которые копились ни одну итерацию, потому что автотест отрабатывал некорректно.
Печально, дорого, больно.
Какие же важные плюсы есть у автотестера с хорошим бэкграундом мануальщика:
1. Он просто понимает смысл тест-кейса, который нужно автоматизировать. Понимает, какие шаги можно сократить/объединить, увеличивая эффективность автотеста и снижая затраты на его поддержание.
2. Автотестеры могут делать хорошее ревью автотестов друг друга без привлечения мануальных тестировщиков (чтобы проверять корректность именно смысловой отработки).
3. Покрывая тест-кейс кодом, автоматизатор сам проводит ревью мануального кейса и может уже на этом этапе выявить какие-то недочёты и попросить автора их исправить, пока это ещё не слишком дорого. Это может ещё и сэкономить время на ревью мануальных кейсов, в зависимости от того, как в проекте поставлен этот процесс.
4. При резком скачкообразном увеличении нагрузки на команду мануальщиков можно «перекидывать» автотестеров им на помощь, как команду быстрого реагирования, т.к. изначально в приоритете всё-таки проверка корректной работы функционала, а не создание библиотеки автотестов, что тоже, безусловно, важно.
5. Хороший скилловый автотестер может писать хроошие автотесты сразу с нуля, не беря за основу мануальный кейс. Бывают ситуации на проекте, когда такой скилл категорически важен.
Всё это тест-лидам и ПМам на заметку, когда будете набирать команду автотестеров. Если есть ресуры покопаться на рынке труда и повыбирать, то обызательно обращать внимание на мануальный опыт работы тестировщика. Он должен знать основы тестирования, уметь работать с техниками тест-дизайна, уметь грамотно составлять артефакты тестирования и т.д.
Что можно сделать для повышения качества синергии автотестера и системы?
Когда я работала в Quantori, я была тест-лидом самого крупного и стабильного проекта. Тогда нами с ПМом было введено правило: каждый новый автотестер в команде сначала полностью знакомится с проектом/продуктом (1 месяц), потом какое-то время работает мануальщиком (2-4 спринта) и только потом полноценно переходит в команду автоматизации.
Да, это было дорого. Но, учитывая обширность и сложность нашей системы, это было необходимо.
Трудно подсчитать скольких проблем нам удалось таким образом избежать, пропуская баги на прод.
В общем-то, на этом, пожалуй, всё.
Ещё раз повторю свой тезис: «Авто-тестировщик в первую очередь тестировщик» - и забывать об этом может быть крайне рискованно для проекта.
