Все мы с ними знакомы. Читали в комментариях на Хабре. Видели на Ютубе. Или слышали от друзей, «настоящих» айтишников.
Стереотипы о тестировании неизбежны – как впрочем почти о любой профессии. Часто они генерируются извне, представителями других специальностей. Ведь не-тестировщики могут не понимать многих внутренних процессов или интерпретировать их неверно.
Сегодня посмотрим на самые популярные заблуждения и попытаемся понять, что с ними не так.
1. Тестировщики занимаются только поиском ошибок
На самом деле ⬇️
На любом проекте QA-инженеры могут выполнять целый ряд задач, не связанных с багами. Ведь «обеспечение качества» принимает разный вид в зависимости от особенностей продукта.
Это может быть оценка рисков и управление ими: понять, где у продукта есть «узкие места», потенциально ведущие к ошибкам, и сообщить разработчикам. Или провести общую критическую оценку ПО – с точки зрения архитектуры и удобства конечного пользователя.
Часто именно тестировщики составляют документацию. Ведь при подготовке к тестированию нужно собрать разносторонние требования, которые предъявляют к продукту все команды сразу – от бизнес-аналитика до дизайнера. В конечном итоге именно QA-инженер знает, как всё должно работать – с точки зрения и SEO, и логики бэкенда.
В некоторых случаях тестировщики занимаются автоматизацией тестов – и это тоже отдельное большое направление работы.
Наконец, QA-команда может делиться с коллегами лучшими практиками: например, внедрять ранее тестирование или whole team quality approach — подход, при котором в обеспечение качества вовлекается вся команда, а не только тестировщики.
2. При разработке о тестировании думают в последнюю очередь
На самом деле ⬇️
Один из принципов тестирования гласит: чем позднее обнаружен баг, тем дороже его исправление.
Поэтому набирает популярность концепция shift-left testing, при которой тестирование начинается как можно раньше в цикле разработки. Это позволяет предотвращать часть багов, а не только находить их и исправлять в готовом продукте. Ведь фикс после релиза может обойтись в десятки раз дороже, чем до него – учитываем не только оплату рабочего времени dev-команды, но и репутационные потери бизнеса.
3. Кто угодно может заниматься тестированием ПО, технические знания для этого не нужны
На самом деле ⬇️
Строго говоря, кто угодно может стать QA-инженером. Но далеко не в том смысле, что человек с улицы может протестировать что угодно, сделать полезные выводы и дать ценные комментарии.
На QA-инженера в любом случае придется учиться. С одной стороны, нужно освоить навык тестирования как таковой – уметь составлять тестовые сценарии, применять техники тест-дизайна и знать общие принципы QA. Но главное – любой, даже начинающий ручной тестировщик должен базово понимать, как работает Интернет. Поэтому не обойтись без технических знаний: понимания архитектуры современных сайтов и приложений, знаний HTML-кода, структуры URL, состава HTTP-запросов и ответов.
Да, уровень hard skills у автотестера в финтехе и ручного тестировщика маленького мобильного приложения разный — но базовые знания нужны всем.
И без определенного набора софт-скиллов тоже никуда. Тестировщики должны быть внимательными, гибкими, дотошными, но при этом общительными — ведь им приходится взаимодействовать со всей командой, от одних получать требования, другим указывать на ошибки. Аналитические способности тоже станут большим плюсом.
Всему этому можно и нужно учиться – например, в нашей школе :)
4. Протестированный продукт не содержит багов
На самом деле ⬇️
Еще один QA-принцип – тестирование показывает наличие багов, а не их отсутствие. И после релиза продукта обязательно обнаружатся баги: в лучшем случае их найдут штатные тестировщики, менее благоприятный вариант – пользователи сообщат о них через техподдержку.
Избежать критических ошибок поможет грамотное планирование. Если на проекте закладывается время на тестирование, а QA-инженеры и разработчики работают в тесной связи друг с другом, шансов, что блокер попадет на прод, немного.
5. Автотесты лучше ручного тестирования
На самом деле ⬇️
Туда же можно отнести стереотип, что «разработка лучше тестирования». Некоторые думают, что создание кода – будь то программирование или написание автотестов – обязательно «лучше», чем проверка функционала вручную. Это сравнение само по себе некорректное – просто у кого-то есть склонности и интерес к одной работе, а у кого-то – к другой.
Поэтому не совсем верно сравнивать ручное и автоматизированное тестирование – это разные специализации. Нередко они сосуществуют на одном проекте, просто решают различные задачи, и каждый вид тестирования по-своему приносит пользу. Полезно автоматизировать регресс на крупной интернет-платформе, которая функционирует уже много лет. И напротив, нет смысла внедрять автоматизацию и отказываться от ручного тестирования, например, при работе с голосовыми помощниками или в небольшом стартапе.
В своей работе QA-инженеры могут совмещать ручное тестирование с автоматизацией, а могут посвятить себя чему-то одному – зависит от текущих потребностей на проекте и культуры тестирования в компании.
6. Тестировщики полностью ответственны за качество продукта
На самом деле ⬇️
Начнем с главного: за качество продукта отвечает вся команда.
Тестировщик может быть сеньором с 10-летним опытом за плечами и выполнять свою работу безупречно. Но если продукт изначально задуман, построен и разработан неверно, никакое тестирование на финальном этапе не сделает его по-настоящему качественным.
Если бизнес-аналитик и product owner исходили из неверных представлений о потребностях пользователей, архитектор не продумал пользовательский флоу должным образом, а разработчик написал код, игнорируя лучшие практики – тестировщик бессилен. Поэтому вспоминаем о whole team quality approach из пункта 1 и рассказываем о нем коллегам :)
7. Тестирование — это слишком дорого и долго
На самом деле ⬇️
На многих проектах нет профессиональных тестировщиков именно из-за этого стереотипа. Тестированием занимаются сами разработчики, проджект-менеджеры и даже саппорт – если у них остается минутка после выполнения основных задач. Чаще минутки, конечно, не находится.
При правильном планировании и распределении ресурсов тестирование не занимает больше времени, чем разработка. И да, любой специалист стоит денег, но качественный продукт сможет привлечь к продукту больше пользователей и в целом повысит доверие к бизнесу.
8. Обеспечение качества — это забота тестировщиков и никого больше
На самом деле ⬇️
Чем-то перекликается со стереотипов о полной ответственности тестировщиков за результат разработки.
Конечно, задачи по тестированию поручаются в первую очередь QA-отделу: продумывать и писать тестовую документацию, проводить проверки, составлять баг-репорты и сообщать остальной команде, насколько ПО готово к релизу.
Но чтобы продукт был действительно качественным, необходимо участие всей команды. Например, бизнес-аналитик и product owner помогут с тестированием требований, разработчики проведут юнит-тесты и подготовят тестовый стенд для QA-инженеров, а техподдержка сообщит после релиза о проблемах и пожеланиях пользователей.
9. Напиши хороший тест-сьют однажды — и этого будет достаточно, чтобы тестировать ПО
На самом деле ⬇️
Мы бы хотели, чтобы всё было так просто :)
Но любую тестовую среду нужно регулярно обслуживать: автотесты требуют поддержания кода, а ручные тестировщики должны периодически обновлять свои тест-кейсы и тестовые данные. Иначе проявится так называемый эффект пестицида, при котором одни и те же проверки с использованием одинаковых данных не позволяют заметить ошибки в других частях ПО или проверить другие кейсы. Как следствие – общее качество тестирования снижается.
10. Тестировать нужно только новые фичи
На самом деле ⬇️
Любая строчка кода, которую добавляет разработчик, может аффектить другие части этого кода. О каких-то взаимосвязях команда может даже не догадываться, поскольку они появляются, например, из-за особенностей библиотек и фреймворков.
Поэтому важно регулярно проводить регресс и санити-тестирование, чтобы убедиться, что весь продукт работает исправно.
11. Тестировщики занимаются тем, что ломают ПО
На самом деле ⬇️
Тестировщики не ломают ПО — они развеивают иллюзию того, что ПО работает :)
Но если говорить серьезно, цель тестировщика – не «сломать» плод чужих трудов и ни в коем не ткнуть разработчика носом в его ошибки. QA-инженеры и программисты делают одно дело, их цель – донести до релиза качественный продукт, который принесет потребителям пользу, а бизнесу – доход.
Тестирование среди прочего призвано выявить уязвимости ПО до того, как с ними столкнутся пользователи (и из-за этого уйдут к конкурентам). Так что если продукт «ломается» во время теста – значит он был заведомо создан с погрешностями, которые можно и нужно исправлять.
Заключение
Надеемся убедили вас, что всё перечисленное – неверно полностью или отчасти :)
А если остались вопросы о профессии, загляните в наш Журнал или задайте нам их [тут]
