Что делает тестировщик? Пример.

Тестирование занимает один из самых важных этапов при разработке программного обеспечения. От качества тестирования зависит каким программный продукт будет реализован, понравится ли он пользователям, насколько исправно он будет работать, насколько удобен будет интерфейс. Для наглядного примера разберем детально работу тестировщика, чтоб был понятен спектр его задач.

В этой статье мы разберем что делает тестировщик на протяжении рабочего проекта на примере и с какими задачами может сталкиваться.

Больше примеров разбираем на наших занятиях в IT Testing School. И, если вы поймете, что тестирование - профессия именно для вас, то рекомендуем записаться на наш курс "Тестировщик с нуля", где мы детально изучаем все инструменты для работы, раскладываем по полочкам все ваши вопросы, даем только необходимые знания без воды и делаем из вас профессионалов своего дела.
Первый шаг к тестированию - анализ требований.

Прежде чем приступить к самому этапу тестирования, специалист ознакамливается с техническими требованиями к ПО, которые ставит в задачу заказчик и составляет требования к тестированию, в котором указаны:
  • функционал, который подлежит тестированию (наименование всех функций сайта таких, как меню, пользовательские формы (обратная связь, чаты и другие), ссылки, дизайн и другое);
  • методы тестирования функций и типы проверок;
  • среда тестирования (какие гаджеты, операционные системы, браузеры подлежат тестированию);
  • рациональность автотестов для ПО.

Далее план тестирования (документ, который описывает весь объем подлежащий тестированию) составляется старшим менеджером по тестированию (Team Lead QA), он также распределяет бюджет на тестирование, составляет графики тестирования, распределяет роли между младшим персоналом (когда в команде каждый тестировщик выполняет только определенные проверки: тестирование безопасности, тестирование юзабилити, функциональное тестирование и другие).

Сценарии тестирования.

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

Сценарии тестирования делают исходя из пользовательского функционала, то есть этот тип документа является поверхностным и не требует специализированных знаний. Наглядным примером пункта из сценария тестирования будет: "Протестировать форму регистрации на сайте для ____ девайсов, ____ операционных систем, ____ браузеров."

Чек-листы и тест-кейсы проверок.

Если сценарии тестирования - это обобщенный план всех проверок, то тест-кейсы или чек-листы содержат очень подробное описание тестов для каждого функционального элемента в ПО. Для той же формы входа в аккаунт может быть более десяти назначенных чек-листов, например:

  1. Проверить пользовательские поля на ввод нестандартных символов (; / : " * & и другие).
  2. Проверить отсутствие ввода доменной формы в строке адреса электронной почты.
  3. Проверить выполнение входа без регистрации.
  4. Проверить вывод информации об ошибках при введении неправильных данных в формы.
  5. Проверить заполнение только обязательных форм для регистрации.
  6. Проверить чек-боксы (например, форма "запомнить меня" при регистрации и воспроизведение при авторизации, другие).
  7. Проверить орфографии в форме авторизации.
  8. Тестирование совместимости разных разрешений для девайсов, ОС, браузеров.
  9. Проверить функциональности смены языка.
  10. Проверить быструю авторизацию через Google/Facebook/ Telegram и другие.
В данном чек-листе будет значительно больше проверок. Они составляются для каждого элемента, подлежащего под тестирование. Документ с тест-кейсами или чек-листами вносится в Testrail или TestLink для удобства работы с проверками. В некоторых компаниях тест-кейсы хранят в Confluence или в Гугл-таблицах (что мы не очень рекомендуем делать).

Рекомендуется тест-кейсы начинать составлять как можно раньше, это помогает глубже разобраться в будущем функционале и понять как он работает.

После проводится первичное тестирование. Программный продукт могут проверять на баги частично, по мере создания кода отдельных функциональных частей разработчиками. Каждая ошибка документируется и вносится на рабочую доску в Jira (Sprint), ей присваиваются статус и она проходит жизненный цикл до закрытия.
Составление документации по исходу тестирования.

Составление качественной тестовой документации очень важно для работы QA-инженера. Для того, чтобы все дефекты устранялись быстро и качественно, тестировщик должен детально описать шаги, которые привели к появлению ошибки системы, расхождение между требованием и реализованной функциональностью и внести их в баг-репорт. По возможности, желательно приложить к отчету скрины всех шагов и самого дефекта. Так же можно записать короткое видео с ошибкой или приложить логи.

Каждому багу назначается приоритет, уровень серьезности и ответственный за его исправление. Приоритет отвечает за первоочередность исправления, его назначает обычно проджект менеджер. Серьезность же отвечает за критичность последствий при появлении данной ошибки.

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

Важной составляющей отчетности для Team Lead QA также является сбор метрик тестирования и их анализ. Некоторыми из метрик измеряется эффективность как тестировщиков, так и команды проекта в целом. Обсуждение метрик выносится на митинги и рассматривается для улучшения качества работы.

Выше перечислено, что делает тестировщик на примере и его основные обязанности на проекте. В некоторых моментах мы упомянули работу Team Lead QA, поскольку не во всех командах он может присутствовать. Если же вы попадаете на проект, где являетесь единственным тестировщиком, то данный функционал также будет являться вашим. Не стоит этого бояться, поскольку у вас не будет ментора, который будет вам помогать и корректировать всю работу на начальном этапе.

Для Junior QA достаточно знаний, данных на курсе "Тестировщик с нуля", чтоб выполнять свой спектр работы. От него не будут требовать безупречной работы на первых порах. Но рекомендуем сознательно относиться к качеству своей работы, то есть всегда работать над своими ошибками. Важно понимать, что после каждого спринта следует проводить ретроспективу и анализировать свою работу, чтоб в подальшем все ошибки сводить к минимуму.

Теперь вы можете понять насколько проста профессия тестирования ПО и почему она остается самой желанной сейчас на рынке труда. На нашем курсе тестирования с нуля мы изучаем больше инструментов, которые использует QA в работе, учимся составлять всю документацию и анализировать качество программного обеспечения. Стань одним из множества наших выпускников, которые работают в самой стабильной сфере и получают зарплату в долларах.

По всем вопросам свяжитесь с нами любым удобным способом: