Почему тестирование - это не просто

Главная проблема

На дворе 2022 год, корабли бороздят просторы большого блокчейна - а в ИТ индустрии все еще процветают мифы о том, что:

"Тестирование - это просто!"

"Тестирование - самый простой способ войти в айти!"

"Сидишь клацаешь кнопки и получаешь свои килобаксы!".

Сегодня я постараюсь развенчать эти мифы и рассказать подробнее о том, что в реальности делает (или может делать) тест инженер.

Спойлер - это не только тестирование.

Что такое "идеальный тест инженер"?

Понятие "идеального" тест инженера у каждого свое. Мало того - еще и зависит от конкретного проекта, стека технологий, бизнеса, компании.

Со стороны любого разработчика и менеджера, тестер - это такой "суслик", который как-то там "дергает АПИ запросы", возможно время от времени находит баги. Находит ошибки - супер! Эффективность и полезность доказана. Не находит - значит плохо работает (или у вас "идеальный код без ошибок").

Что же в реальности делает (или может делать) "идеальный тест инженер в вакууме"?

Сферы деятельности тест инженера я поделил условно на четыре группы:

Business
Technology
Leading
Testing

Business

инженер разбирается в бизнес домене: знает терминологию, бизнес флоу. Знает даже какие экономические уязвимости могут случиться с продуктом;
инженер ведет разговор с бизнесом на языке рисков: что будет или не будет если не починить этот баг, какой импакт может быть и на какое количество пользователей. В любой технической деятельности инженер в первую очередь думает о пользе для бизнеса. (И даже, о ужас, может согласиться, что баг можно фиксить не срочно);
инженер мастерски знает все метрики, которые важны бизнесу: DAU, MAU и прочее;
инженер постоянно общается с саппортом и реальными пользователями - и знает их боль. На основе этой информации, он понимает, какие части приложения более рисковые и какие нужно тестировать тщательнее;
инженер разбирается и следит за всякого рода *ilities: usability, scalability, maintainability, etc. И по крайней мере, задает команде вопросы о них;

Technology

инженер обладает хорошими знаниями по архитектуре систем в целом, и системе, которые тестирует - в частности. Это позволяет вести предметные разговоры с архитекторами о возможных проблемах (на этапе дизайна компонентов). Инженер может разобрать любую систему на составные части и проанализировать их отдельно и всю систему целиком;
инженер умеет читать код в ПРах и находить там потенциальные проблемы в бизнес логике. Познаний в языке программирования у него достаточно и для автотестов, и для написания фича кода (с фича кодом может чуть похуже). А еще - для мелкого скриптинга рутинных задачек. Кроме всего прочего, он умеет прикручивать code coverage инструменты и настраивать рулы для любого проекта;
инженер разбирается во огромном множестве поинтов интеграции с внешними и внутренними системами и API;
инженер знает как встроить любые виды тестов в CICD процессы в практически любом инструменте будь то Jenkins, Teamcity, Github Actions и прочее;

Leading

в некоторых случаях тест инженер "играет роль" скрам мастера - ведет церемонии, следит за беклогом, фасилитирует ретроспективы;
инженер коучит и менторит тестировщиков и других инженеров по вопросам тестирования и качества;
инженер всегда в курсе всех чейнджей и следит за релизами (играет роль релиз менеджера в некоторых случаях);
инженер внедряет новые инструменты и подходы в процессы в команде (и компании);
инженер определяет процессы тестирования и следит, чтобы это все работало и приносило пользу;

Testing

инженер знает и умеет пользоваться разными инструментами для тестирования - от утилит командной строки, до настройки инстансов в клауде и прочих Postman'ов;
инженер проводит исследовательское тестирование на разных уровнях и использует все модные и не модные техники тестирования и тест дизайна;
инженер умеет мастерски коммуницировать: у него построено credibility с каждым участником команды. С девелопером он говорит на языке код и паттернов, с менеджером - на языке рисков и бизнес импакта, с тестировщиками - на языке покрытия, с архитекторами - на UML и метрик :)
и конечно же инженер может строить с нуля (или хотя бы прекрасно использовать готовые) фреймворки для автоматизации: знает как писать автотесты, чинить их, анализировать и ускорять;

Где же прячется идеал?

Идеального тест инженера, похоже, не существует в природе. Если его и найдешь - то он стоит очень много денег (и, возможно, уже читает свои курсы или дает консультации). В реальной жизни приходится выбирать и смещаться в один из кругов. Или грамотно миксовать их между собой.

Как видно из рисунка, тестирование и тест инжиниринг (и обеспечение качества) - это далеко не простое занятие. Оно обьединяет множество аспектов бизнеса и технологий.

Миф о "простом тестировании" возникает от того, что девелоперы и другие инженеры работают в основном с тестировщиками, которые умеют только лишь тестировать (и то - только в теории и по книжке). Поэтому и складывается впечатление, что этим может заниматься любой человек.

Дальше - все зависит от глубины и ширины знаний конкретного человека и как он применяет эти знания для проверки гипотез.

К тому же, если у тест инженера нет credibility (доверия) в команде - его всегда будут воспринимать "несерьезно". (Может не напрямую, но в "курилках"). Но вопрос доверия важен не только для тестировщика, а и для любого нового члена команды. И доверие можно прокачивать каждый день в совместной работе.

А вы тоже думаете, что тестирование - это просто?