Тестирование продукта — одна из самых важных составляющих процесса разработки в ИТ. Во время тестирования происходит проверка соответствия между реальным и ожидаемым поведением программы. ПО проходит верификацию, то есть оценку, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Также производится валидация — проверка соответствия ПО ожиданиям и потребностям пользователя, требованиям к системе.

За счёт тестирования можно снизить стоимость продукта, потому что баги будут обнаружены до того, как компания потратит много времени и ресурсов на разработку. Кроме того, тестирование косвенно влияет на лояльность потребителей к компании и продукту, так как любой обнаруженный дефект негативно сказывается на доверии пользователей.

Помимо поиска ошибок, работа тестировщиков зачастую заключается в поиске вариантов использования ПО, которые не были предусмотрены при разработке, и в оценке UX-дизайна — они пробуют использовать программу так, как будет это делать пользователь. 

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

Автотестирование — оптимизация в больших масштабах

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

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

Собственно, автотест — это скрипт, имитирующий поведение пользователя при эксплуатации программного продукта. Он действительно помогает сократить время на проверки, повысить скорость разработки и уменьшить вероятность человеческой ошибки. Но имеет и свои ограничения. 

Вот какие выгоды приносит автоматизированное тестирование: 

  • позволяет имитировать действия большого количества пользователей;

  • увеличивает скорость тестирования по сравнению с ручной проверкой;

  • уменьшает потребность в QA‑специалистах для тестирования регрессов/релизов;

  • осуществляет более точную проверку функционала, снижает роль человеческого фактора;

  • позволяет запустить тестирование в ночное время, когда нагрузка на сервер меньше;

  • автоматически формирует информативный и понятный отчет о тестировании.

Разумеется, есть и издержки, это: 

  • время разработки автотестов;

  • необходимость поддержки уже написанных тестов;

  • стоимость разработки;

  • ограниченность применения — автотесты не смогут выявить дефекты за пределами обозначенных тестировщиком границ.

Кроме того, автоматизаторы — востребованная и оттого даже дефицитная специальность на рынке. Их поиск и найм требует ресурсов — как временных, так и финансовых.

Такая комбинация плюсов и минусов приводит к очевидному выводу: в одних случаях автотесты — идеальное решение оптимизации, а в других — лишняя трата ресурсов. 

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

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

Что должен уметь автотестировщик?

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

Hard skills — более специфичная тема. Любой автотестировщик должен:

  • понимать принципы объектно-ориентированного программирования;

  • иметь опыт работы в тестировании или разработке ПО;

  • уметь использовать тестовые фреймворки;

  • уметь работать с тестовыми данными;

  • знать системы контроля версий (Git);

  • иметь опыт работы с базами данных;

  • автоматизировать составление отчётов;

  • знать основы теории тестирования (Foundation Level ISTQB, SQL);

  • иметь опыт тест-дизайна сложных систем;

  • уметь работать в сопутствующих инструментах (Postman, Fidler, Allure, TestIT, Wireshark).

Что касается языка программирования, для автотестирования чаще всего используются C#, Python, Java, Kotlin. У всех них есть свои плюсы и своя сфера применимости, но лидирует на рынке Java — благодаря надежности и масштабируемости его активно используют в бэкенд-разработке, а кросс-платформенность позволяет писать на нем приложения для большинства современных платформ.

Если говорить непосредственно о Java, у него есть большой массив библиотек и фреймворков, относящихся к работе автотестировщика, которые тоже следует освоить, например:

  • Cucumber — для описания тестовых сценариев в читабельном виде;

  • JUnit — для модульного тестирования;

  • Selenium — для тестирования графических веб-интерфейсов.

Как видно из массива требуемых навыков, обучение на автотестировщика — задача не из простых. Но нет ничего невозможного!

7 человек экономят сотни часов: как мы помогли клиенту переобучить ручных тестировщиков в автоматизаторов Java

Зачем клиенту понадобилось переобучение?

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

Стало очевидно, что процессы нуждаются в модернизации и структурной перестройке. 

При этом поиск на рынке автоматизаторов не был оптимальным решением — эти специалисты дефицитны, и к тому же после найма потребовалось бы адаптировать новичков не только к компании, но и к самим продуктам. При этом в штате клиента уже были сотни ручных тестировщиков, которые лучше всех знают свой продукт. Так что наиболее эффективным выходом в данном случае было переобучить часть из них в автоматизаторов на Java. 

Подготовка

Мы провели входное тестирование, чтобы выбрать амбициозных и мотивированных тестировщиков, способных стать автотестерами.

Отбор происходил по 3 критериям:

  • тест;

  • беседа — проверка мотивации;

  • отзыв руководителя — чтобы убедиться, что сотрудник действительно может получать задачи по автоматизации и обучение пройдет не зря.

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

При создании курса мы опирались на требования и список всех технологических сервисов, используемых для создания и работы ПО (проще говоря — техстек) заказчика. Также мы проводили детальные кастдевы с руководителями и инженерами компании, чтобы точнее понять их запросы. Работа с руководителями позволила заранее подготовить реальные задачи по автоматизации для выпускников. Такие, которые они будут выполнять в своих командах после выпуска.

Процесс обучения

Курс был гибридным и сочетал предзаписанную теорию с тестовыми заданиями, практическими задачами с самопроверкой и синхронными встречами с экспертами. Почти полгода менторы из Т1 Цифровой Академии и практикующие эксперты по автотестированию Холдинга индивидуально работали с участниками группы, проводили ревью и консультации при выполнении учебного проекта. 

Обучающиеся изучили инструментарий тестирования на базе Java-технологий, научились автоматизировать процессы проверки программных модулей, веб-сервисов и веб-интерфейсов, освоили JUnit. Также они практиковались в тестировании веб-сервисов с использованием RestAssured и применении WebDriver для обеспечения качества веб-интерфейсов, познакомились с инструментами отчетов Allure и TestIt.

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

Чтобы облегчить обучающимся погружение, мы приняли решение ввести параллельные процессы: участники курса проходили темы по Java и в то же время правили чужие тесты, со временем начиная писать собственные.

Результаты

По итогам программы автоматизаторами стали 7 человек — они вернулись в свои команды и перехватили те блоки задач, что были связаны с повторяющимися рутинными тестами. Через год после старта проекта вовлечение ручных тестировщиков уменьшилось на 70%, и теперь каждую отгрузку экономия времени достигает 800 человеко-часов.

А еще переобучение вышло на 25% дешевле, чем поиск и найм специалистов с аналогичными навыками на рынке.

Комментарии (1)


  1. Litovsky83
    02.12.2023 04:20
    +2

    Добрый день !

    1) почему именно Java? Сравнивали с другими языками? Какие плюсы?

    2) какие сложности были в процессе обучения ? Хватило ли времени на обучение?

    3) какого уровня специалисты вышли (джун, мидл)? Как они развивались дальше? Появился ли у них опытный тимлид?

    4) что стало с их зп?