Как проходит тестирование ПО

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

• Планирование
• Анализ поставленных требований
• Дизайн и, собственно сама разработка проекта
• Имплементация кода и получение конечного продукта
• Тестирование
• Оценка
• Релиз
• Обеспечение поддержки

Этап тестирования – обязательный этап жизненного цикла ПО. Это очень важный процесс работы над проектом, на котором определяется что сделано правильно и хорошо, а что – нет. В интернете можно встретить определение термина «тестирование» как процесс поиска ошибок. На самом деле это утверждение верно лишь частично. Одна из аксиом software development гласит о том, что найти все баги невозможно. И, если в результате подробного тестирования не было выявлено ни одной ошибки, это еще не означает, что их нет.

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

Понятие качества – вещь субъективная. Однако, в каждом проекте у нас есть какое-то ожидание результата. С начала работы над продуктом, product owner, который придумал некую идею, имеет некоторый набор представлений о том, как должен выглядеть конечный проект. Он прописал требования, с ним поработали аналитики, составили для разработчиков списки requirements. Задача тестировщика – убедиться, что качество продукта соответствует ожиданиям заказчика. Не субъективным ожиданиям самого тестировщика, не ожиданиям проектного менеджера, а ожиданиям того, кто является первоначальным автором идеи.

Что такое User Acceptance Testing (Приемочное тестирование)?

Давайте немного разберемся как организовано тестирование ПО в общем. В процессе тестирования различают две области. За первую на позиции QC (Quality Control) отвечает test engineer – после тестов он выполняет верификацию на предмет исправленных ошибок (например, поплыла верстка, не работают кнопки, некорректно обрабатываются ссылки и т.д.). За вторую область ответственен QA (Quality Assurance) – он обеспечивает качество выходного продукта на приемлемом уровне. Он включается в работу еще на стадии анализа и архитектуры. Полагаясь на свой опыт и чутье, он уже на ранних стадиях предлагает внести правки в документацию и что-то изменить в списке требований, что минимизирует риски ухудшения качества продукта. Также он предвидит узкие места в архитектуре и подготавливает такой набор тестов, которые уже в начале работы над продуктом позволит выявить дефекты. QA в значительной мере экономит расходы на весь процесс разработки, поскольку исправление недочетов, пропущенных на начальном этапе, впоследствии очень накладно и серьезно сказывается на смете всего проекта. 

К слову, подбирая кандидата на работу, HR обычно не делает различий и называет должность тестировщика как попало –  QA-аналитик, QA-инженер и пр. Тут следует понимать, что должность определяет заказчик аутсорсинговой услуги, который хочет получить сотрудника с как можно более широким спектром скилов. Но работа Quality Assurance по сравнению с Quality Control гораздо более объемна сложна, в первом случае специалист просто выполняет тесты и составляет баг-репорты, во втором – человек должен выстроить и обеспечить контроль качество всего проекта. 

Международной квалификационной комиссией по тестированию программного обеспечения ISTQB различают следующие уровни тестирования:

• Модульное тестирование. Ответственность за юнит-тесты обычно лежит в основном за самих девелоперах, компетенция которых позволяет ориентироваться в коде. Предположим, ваш проект – интернет-магазин, состоящий из большого числа веб-приложений и отдельных модулей (блок регистрации, модуль авторизации, поиск, фильтры поиска и пр). Тестирование на уровне отдельно взятой опции – это и есть модульное тестирование. Unit-тесты выполняются на уровне кода. Например, если в калькуляторе выполнить проверку сложения и в окне видим «5» это еще не свидетельствует, что функция Sum(a,b) работает некорректно. Возможно, ошибка кроется в другом месте и калькулятор высвечивать пять что бы мы не вводили. Поэтому тестами мы проверяем работу только этой функции условием if Sum(2, 2) = 4 then...

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

Цели и преимущества приемного тестирования

На первый взгляд приемное тестирование на последнем уровне может показаться избыточным. Если ориентироваться на заказчика, то он наверняка уже не раз «щупал» сырой (ну, или и не очень сырой) продукт, оставлял свои комментарии по поводу его работы. Однако, здесь следует различать «проверку» и «тестирование». Уровень приемного тестирования предназначен не для того, чтобы выявить ошибки, а чтобы оценить, насколько продукт готов к продакшн и соответствует бизнес-требованиям заказчика. UAT – это не функциональное тестирование, оно не выявляет сбои в работе, а дает оценку продукту в общем, выявляя насколько он удобен и пригоден для использования.

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

Документы, необходимые для приемного тестирования

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

Приемное тестирование требует несколько рабочих документов:

• План приемных испытаний – то есть список проводимых тестов. Он составляется еще на этап разработки при формировании архитектуры проекта
• Формат UAT – описание с требованиями тестирования – предмет тестирования и сценарии тестирования, с учетом требований
• Реестр комментариев к процессу тестирования
• Протокол UAT

Существуют разные подходы к приемному тестированию. Чек-лист с наиболее частыми формами проверки проекта выглядят следующим образом:

1. Альфа-бета тестирование – задействование группы реальных пользователей.
2. Контрактное тестирование – проверка соответствия продукта ТЗ.
3. Операционное тестирование – вариант тестирования, при котором анализируются процессы, необходимые для функционирования продукта. Это могут быть, например, системы защиты, различные сервисы для резервного копирования и восстановления информации и др.
4. Законодательное тестирование – определяет насколько программный продукт соответствует действующему законодательству. Особое внимание уделяется в том случае, если проект имеет отношение к финансовой деятельности или сфере здравоохранения.

Инструменты UAT, примеры тестирования

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

Прежде всего это FitNesse tool, написанный на Java, который предназначен для автоматизации процесса тестирования. Он поставляется в виде единственного исполняемого jar файла, который включает вики движок, встроенный веб-сервер, тестовый движок и прочие ресурсы. FitNesse позволяет пользователям разрабатываемой системы осуществлять ввод данных в специальном формате (понятном для не-программистов). На основе этого ввода автоматически генерируются тесты, которые  исполняются системой, с последующим возвратом результатов. 

Watir: другой инструментарий для приемочного тестирования на основе браузера. Это – библиотека языка Ruby, которая позволяет создавать свои сценарии тестирования веб-приложений.

Скрипт для тестирования может выглядеть, например, вот так:

# Пример небольшого скрипта для проверки последовательности действий 

 require 'watir'                          # подключаем инструмент Watir

 testing _site = 'http://www.some_adress.com'      # определяем переменную

 ie = Watir::IE.new                       # запускаем веб-обозреватель Internet Explorer

 ie.goto(testing _site)                   # переходим по ссылке

 ie.text_field(:name, "search").set("Picasso") # в текстовое поле с именем "search" помещаем слово "Picasso"

 ie.button(:name, "Knopka").click           # нажимает на кнопку с именем "Knopka"

 if ie.text.include?("Programming Ruby")  # описание условия теста

   puts "Test Passed. Found the test string: 'Programming Ruby'." # заключение по успешному прохождению

 else

   puts "Test Failed! Could not find: 'Programming Ruby'" # тест не пройден

 end

 

Заключение

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