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

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

Сообщество тестировщиков все еще живет каскадной моделью внутри новых agile-проектов. Торопясь внедрить Agile в любой проект или организацию, мы всегда упускаем из виду важный аспект — инженеров-тестировщиков.

Опасное предположение

При внедрении agile-разработки может возникнуть неправильное представление, что тестировщик не нужен, поскольку разработчик должен создавать работоспособный и качественный код, но на практике это невозможно.

Будем честны: усилия, затрачиваемые на тестирование багов и ошибок, а также на их детальное изучение в большинстве случаев не входят в скорость команды (team velocity) в Scrum. Оба этих аспекта, напрямую влияющие на качество продукта, часто остаются незамеченными, когда речь заходит о бэклоге спринта, оценке усилий и скорости команды.

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

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

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

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

Использование методологии Agile срывает работу не только сообщества разработчиков, но и индустрии в целом, так как разработчики располагают намного более совершенными инструментами, чем тестировщики.

Зачем нужно тестировать

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

  • Чтобы убедиться, что продукт делает то, что должен.
  • Если продукт работает, когда его использует один человек, он должен точно так же работать, когда его используют сотни людей.
  • Есть множество различных устройств, браузеров и операционных систем, и программное обеспечение должно быть совместимо со всеми этими средами.
  • Тестирования ПО связано с рентабельностью инвестиций (ROI) компании. Поскольку его отсутствие требует от компании трудозатрат на исправление ошибок, не обнаруженных на этапе тестирования. Это также может привести к недовольству клиентов, что в конечном итоге повлияет на ваши продажи.

Виды тестирования программного обеспечения

Существует множество методов тестирования ПО, давайте кратко рассмотрим наиболее распространенные из них.

Тестирование методом черного ящика

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

Тестирование методом белого ящика

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

Тестирование методом серого ящика

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

Agile-тестирование

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

Ad-hoc тестирование

Это метод тестирования без какого-либо планирования и документации.э

Жизненный цикл тестирования программного обеспечения

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

Анализ требований

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

Планирование тестов

После того, как вы составите общее представление о том, что нужно тестировать, — планируйте тесты.

Разработка тестов

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

Настройка тестовой среды

Вы настраиваете тестовую среду (сервер/клиент/сеть и т. д.) с целью имитации среды конечного пользователя.

Выполнение тестирования

Вы выполняете свои тестовые примеры/сценарии в тестовой среде, чтобы проверить ПО на ошибки.

Отчет о тестах

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

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

Зачем автоматизировать тестирование ПО

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

Что нужно знать об автоматизации тестирования

  • Автоматизация тестирования требует навыков программирования и знания системы.
  • В сообществе тестировщиков все чаще делают так: начинают с ручного тестирования и постепенно переходят к автоматизированному.
  • Создавайте и запускайте скрипты с помощью инструментов автоматизации для экономии времени.
  • Используйте GUI-автоматизацию тестирования там, где это возможно.
  • Хотя мутационное тестирование и не требует знаний в написании кода или скриптов, помните, что поддержка тестовых примеров затрудняется, если ПО постоянно изменяется.
  • Стратегия автоматизации является самой важной частью автоматизации.
  • Автоматизация должна быть структурированной. Определитесь, что вы хотите тестировать и как вы собираетесь это делать.
  • Не автоматизируйте тестирование тех частей GUI, которые расширяются при каждом релизе.
  • Используйте комбинированное автоматизированное тестирование для проверки интерфейса, скриптов, данных и проверки ввода-вывода.
  • Если вы планируете автоматизировать тестирование какой-либо части приложения, убедитесь, что вы настроили автоматизацию и интеграцию в правильном месте.

Преимущества автоматизации

Это экономичнее

Строго говоря, автоматизированное тестирование — это единовременная трата, избавляющая вас от регулярных расходов.

Это быстрее

Автоматизированные тесты выполняются намного быстрее, чем ручные.

Это надежнее

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

Это снижает риски

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

Пользовательское тестирование (UAT)

UAT (User Acceptance Testing) — это заключительное тестирование, выполняемое после функционального, системного и регрессионного тестирования. UAT-тестирование проводится для того, чтобы убедиться, что ПО соответствует бизнес-требованиям. UAT, альфа и бета — это разные типы приемочного тестирования. Они проводятся конечными пользователями, которые знакомы с бизнес-требованиями ПО.

Заключение

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

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

Учтите, что автоматизировать абсолютно все или, наоборот, использовать только ручное тестирование — глупо и неэффективно. Постарайтесь найти баланс.

Перевод статьи: Types of Software Testing and Automation