Раннее тестирование экономит время и деньги. Приведем несколько примеров.

В мае 2015 пользователи IPhone обнаружили баг в системе, при котором определенная последовательность символов Unicode, отправленная в виде текста другому пользователю IPhone, приводила к сбою в работе аппарата. Шутники по всему миру в течение нескольких недель «выключали» телефоны своих приятелей, пока разработчики не выявили проблему и не выкатили обновление операционной системы, которое исправило возникающую ошибку.

Менее веселый случай произошел в первые недели после запуска долгожданного 5 терминала аэропорта Хитроу в 2008 году, который открывала сама королева Елизавета. Из-за сбоя в работе ПО, отвечающего за обработку багажа, было отменено более 500 рейсов и около 42 000 единиц багажа не последовали за своими владельцами в место назначения. По оценкам сбои в работе терминала обошлись в 16 млн фунтов стерлингов. 

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

QA или, буквально, обеспечение качества (англ. Quality Assurance) – комплекс мер нацеленный на предотвращение проблем в программном обеспечении или сервисе для достижения максимально возможного качества продукта и клиентского опыта.

Мы решили чуть глубже копнуть эту тему и попросили руководителя отдела тестирования Oprosso, Дениса Василенкова, рассказать о том, как правильно организовать процесс QA, чтобы после не было мучительно больно.

8 критериев организации процессов в области QA

1. Формирование целей и областей тестирования

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

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

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

2. Укомплектованная команда

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

Рекомендуемое соотношение разработчиков к тестировщикам – 2 к 1.

3. Налаженная внутренняя коммуникация

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

Основные принципы:

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

4. Подходящая методология тестирования

Методология тестирования позволяет определить подходы к выполнению задач по тестированию ПО. Для наших целей подошла каскадная модель или модель водопада (англ. Waterfall), в которой все этапы QA идут один за другим и появляются только один раз за условный проект: 

• Анализ требований совместно с командой разработки – понимание, что будет или не будет работать;
• Процесс планирования тестирования – как и что команда будет проверять;
• Реализация продукта, функции или компонента;
• Процесс тестирования – проверка на ошибки и соответствие заявленным требованиям, если нет, то отправка на доработку;
• Интеграция и передача в эксплуатацию.
  

Каждая фаза длится до тех пор, пока его результат не будет удовлетворительным. «Потому что нужно делать нормально на том этапе, на котором мы находимся», – подвел итог Денис.

5. Документирование процесса

Документирование процесса – действие, которое нельзя игнорировать, если вы не хотите терять во времени, качестве и стоимости тестирования продукта.

Основные документы:

• Тест-кейсы – это некий сценарий тестирования, в котором указан набор входных данных и условий с указанным желаемым результатом. Например, тест-кейс проверки авторизации при вводе валидных данных. Расписываются шаги, что тестировщик должен сделать, вставить, чтобы получить конечный результат, если все ок, то идем дальше, если нет, отправляем на доработку;
• Чек-листы – в Oprosso используются реже, это список того, что нужно проверить;
• Протоколы тестирования – подробное описание проведенных тестов, в которых отмечены время, успешность, дополнительная информация по контексту теста и обнаружению как-либо необычных явлений;
• Матрица покрытия требования – это двумерная таблица, в которой сопоставляются требования к продукту и подготовленные тест-кейсы. Из нее видно, какие требования и по какому сценарию будут проверяться;
• Стратегия тестирования – документ, в котором описан общий подход к тестированию, объекты тестирования, критерии, необходимые методики;
• Внутренняя база знания – инструкции, кейсы и прочая полезная для сотрудников информация.
  
  

6. Управление рисками 

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

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

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

7. Инструменты и среда тестирования

Инструменты – то, что облегчает процесс работы тестировщика, позволяет качественно тестировать и доносить информацию до команды разработки, сюда входят:

• Инструменты для баг-треккинга;
• Инструменты для снятия скриншотов и логов;
• Инструменты автоматизации.
  

Среда тестирования – это специально сконфигурированное окружение, в котором проводятся запланированные мероприятия по проверке продукта на ошибки и соответствие требованиям в различных условиях. Использование различных ее конфигураций позволяет добиться точности, достоверности и эффективности в тестировании. Часто среды разделяют на среду разработки (dev), тестирования (test) и производственную (prod).

8. Постоянное улучшение 

Тестирование – это творчество. QA-инженер должен проявлять изрядный уровень креативности и постоянно обновлять подходы к тестированию, чтобы постараться отработать не только ожидаемые манипуляции с сервисом, но и что-то что не было в изначальной задумке создателей. Например, в игре Red Dead Redemption был выявлен следующий баг – если в определенной локации забиться в угол между стеной и сейфом и попрыгать, то его катапультирует в небо. 

В Oprosso, в рамках этого критерия, в отделе постоянно проводят ретроспективные встречи, чтобы отмечать, что в процессе работы прошло хорошо, а что требует улучшений и каких. Также команда на регулярной основе проводит встречи для обмена знаний – делятся свежими технологиями, кейсами, инструментами.

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

Если говорить, о необходимых soft-навыках для тестировщика, то для того, чтобы «ломать» систему максимально тщательно, пока это не сделали пользователи необходимы любознательность, гибкость ума и умение кидать себе новые вызовы.

Заключение

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