Тестирование — необязательный этап разработки? Зачем подключать QA к планированию? И неужели люди правда выпускают продукты с дефектами?
Меня зовут Наталья Мурашова, я Senior QA Engineer, тренер по теории, процессам и автоматизации тестирования. Сегодня разберём, что такое тестирование, зачем оно нужно, и как работают тестировщики у нас в СИБУР Диджитал.
Вы же просто ловите баги?
Успех реализации ПО зависит от качества продукта. А качество — это не только отсутствие багов, но и довольные заказчики и пользователи. Всем хочется выпустить продукт, который отлично работает и радует всех стейкхолдеров. Но от ошибок не застрахованы даже самые компетентные команды.
Задача тестировщика в этой ситуации не ограничивается поиском дефектов в готовом коде. Quality Assurance нужен на всех стадиях разработки, чтобы обеспечить качество продукта, прогнозировать и устранять ошибки как можно раньше. И вот почему.
Чем позже обнаружен дефект, тем дольше и дороже его исправлять. Допустим, мы отловили баг на этапе системного тестирования. Но этот баг может не относиться к коду — он может быть дефектом требований, архитектуры или дизайна. Соответственно, чтобы его исправить, мы возвращаемся к тому этапу, на котором он возник. А потом проходим жизненный цикл заново. Причём на каждом этапе будем по новой тестировать, чтобы убедиться, что починка бага не поломала другие части системы
Из этого следует, что лучший способ пощадить бюджет заказчика — отловить баги на этапе планирования.
А как тестировать, когда продукт ещё не разработан?
Если коротко, то на этапе планирования тестируем требования к продукту — то есть вычитываем документацию. Почему это именно работа тестировщика?
Документ с требованиями — это тоже продукт, и он тоже требует «тестирования». На этапе планирования QA-специалист выполняет роль редактора, который читает документацию и задаёт душные вопросы. Объясним на примере.
Допустим, аналитик указал в требованиях, что поле для ввода email-адреса в форме регистрации на форуме должно быть на 20 символов. Задача QA-специалиста в этом случае — задаться вопросами:
Разве большинство реальных адресов вписываются в этот лимит?
Что будет с пользователем, у которого email-адрес содержит 22 символа?
Если он не сможет зарегистрироваться, мы понесём убытки?
Если мы понесём убытки, то насколько они критичны?
Ответив на эти вопросы, тестировщик вместе с аналитиками принимает решение. Например, выясняет, что риски от потери пользователей с отвратительно длинными адресами некритичны и лимит можно оставить. Или наоборот, приходит к выводу, что это дискриминация и надо увеличить лимит до 30 символов.
Можно ли выпустить продукт с дефектом?
Каждый дефект — это риск для пользователей и бизнеса. Поэтому перед релизом мы оцениваем влияние этого дефекта на продукт, как в случае с email-адресами. И если мы понимаем, что стоимость этого риска меньше, чем стоимость исправления прямо сейчас, то да, продукт с дефектом выпустить можно.
Один из примеров — дефекты интерфейса, найденные в последний момент. Если дефект некритичен, а времени на исправление и ретест нет, то мы исправляем его в следующем релизе. Это могут быть, например, грамматические ошибки в UI-тексте, перегруженные результаты поиска или карточка товара, которая открывается в отдельном окне браузера.
Как работает QA в СИБУР Диджитал
Тестировщики в СИБУР Диджитал не просто проверяют готовый код, а контролируют качество продуктов для производства и помогают с их внедрением и развитием. А продукты бывают разные — от интернета вещей до визуализации контроля на производстве. Поэтому QA-специалисты ещё и вникают в весь процесс и контекст их использования, чтобы скорректировать тестирование.
Например, недавно мы внедрили машиночитаемые доверенности в документооборот между нами и контрагентами. Процесс задействует различные системы и внутри компании, и вовне, так что приходится использовать различные интеграции. Также программам для электронного документооборота нужно нагрузочное тестирование, чтобы проверить, выдержит ли софт наплыв документов в определённые даты. По итогам тестирования приложение оптимизируется для повышения скорости обработки документов и пропускной способности.
А объекты с подключенными датчиками измерения температуры, давления и чего угодно ещё не протестировать, не разобравшись в самих датчиках — какими они бывают, как в них фиксируется параметр, как часто они отправляют информацию и как она отображается на дашборде.
Над этим в СИБУР Диджитал работают 36 штатных и внештатных специалистов по тестированию — от стажёров до Senior QA. Они проводят тесты на всех этапах разработки — вручную и автоматически, через интерфейс пользователя и на смартфонах, включая заводские взрывозащищённые смартфоны.
Вот как выглядит процесс тестирования на разных этапах:
Планирование. Читаем и проверяем документацию. Допустим, разработчики собираются вводить новую фичу в уже готовое и работающее приложение. Не сломает ли она всю логику приложения? Соответствует ли она функции продукта в целом? Однозначно ли понимают новую фичу все участники команды разработки? На этом же этапе планируем процесс тестирования и разбиваем его на задачи.
Разработка. На этом этапе пишем сценарии тестирования и чеклисты проверки функционала, проверяем отдельные части продукта и трекаем баги.
Тестирование. К этому моменту все фичи спринта реализованы и отданы QA. На этом этапе делаем ретест исправлений, проводим регрессионное тестирование, чтобы убедиться, что ничего не сломалось, и формируем отчёт.
Релиз. Если продукт находится на поддержке — передаем артефакты разработки и тестирования команде поддержки. Затем команда поддержки разворачивает релизную версию в продуктовом контуре.
Наш стэк
Напоследок расскажем о том, какие инструменты мы используем в работе:
Allure TestOps — для разработки и хранения сценариев, планов и отчётов по тестированию. Эта платформа интегрирована с GitLab — системой хранения и контроля версий кода, которой пользуется вся компания. В ней же настроен конвейер автотестов по расписанию, по коммиту или вручную. Так что все результаты пайплайнов тоже попадают в Allure TestOps.
Автотесты пишем на Kotlin — этот язык лёгок для обучения, лаконичен и совместим с Java.
Selenium WebDriver используем для автоматизации ручных сценариев тестирования. Этот инструмент имитирует работу пользователя с браузером — заполнение форм, переходы по ссылкам, нажатия кнопок и др. Такой же инструмент есть и для имитации действий пользователя в смартфоне — Appium.
Junit и Gradle используем для структуризации тестов и сборки.
Если хотите узнать больше о том, как у нас устроено тестирование — пишите вопросы в комментах, и мы с радостью придём к вам с ответами :) До новых встреч!