В этой статье изложен опыт компании Infoshell по тестированию приложений. Речь пойдёт о тестировании в спринте и в проектной работе, предрелизном тестировании и других вопросах.
В первый день спринта (выделенного на одну функцию или часть продукта периода) необходимо создать тест-кейсы и автотесты. Или отредактировать их, если текущий спринт не первый в цепочке.
Тест-кейс — это документация тестировщика. Это список действий, который нужно совершить, чтобы достичь поставленной цели. Он включает в себя, в среднем, 5 пунктов:
Положительный — фактический результат равен ожидаемому. Отрицательный — если не равен и была найдена какая-то ошибка. «Тест блокирован» — невозможность выполнения шагов. Это означает ошибку, которую необходимо найти и указать в результате.
По желанию в текст-кейс можно добавлять другие пункты. Например, историю редактирования, в которой нужно указывать, кем и когда этот кейс был изменён, что было убрано или добавлено.
При этом в тест-кейсе не должно быть нечётких формулировок, лишних деталей и описаний, умалчиваний или неточностей в описании шагов и результата. Ещё одно важное условие — каждый кейс должен быть независим от остальных. Держите это в голове, так как тест-кейсы и автотесты пишутся на каждую функцию, и начать связывать их автоматически очень легко.
Автотест — код, который пишет разработчик для проверки работоспособности приложения. Позволяет не только сэкономить время на поиск и исправления багов, но и увидеть конкретную строчку кода с ошибкой.
Тест-кейсы и автотесты нужны для того, чтобы проверить, как продукт будет вести себя при разных действиях пользователя: ожидаемых и неожиданных, логичных и нелогичных, правильных и неправильных.
Также полезно Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться.
В большинстве случаев это тестирование проводится вручную. Этапа три, они идут по порядку:
Дымовое тестирование. Цель — проверить базовую функциональность приложения. Продумайте поведение пользователя, затем начните тестировать приложение. Сделайте позитивный тест и выполните целевое действие. Пусть это будет подписка на email-рассылку.
После него начните тест негативный: попытайтесь «обмануть» программу, кликайте на разные кнопки, иконки, изображения и отслеживайте, как она реагирует на ваши действия. Продукт не должен открывать никаких лишних окон, картинок. Он также не должен давать никакой информации при нажатии «в пустоту».
Если всё прошло хорошо, переходите к следующему этапу. Если хотя бы в одном из этих тестов вы нашли ошибку, приложение нужно отправить на доработку с описанием обнаруженных багов в баг-репорте. Назначьте задачу на исправление и ждите устранения ошибки, после чего повторите дымовое тестирование.
Необходимо для того, чтобы проверить, исправили ли разработчики найденные баги. Ещё одна цель регрессионного тестирования — отслеживание того, как внесённые изменения повлияли на работу других частей приложения и его поведение в целом.
Сэм Канер, профессор программной инженерии Технологического института, директор Образовательного и исследовательского центра тестирования программного обеспечения Флориды, выделяет три основных типа этого теста:
Полное тестирование по тест-кейсам. На третьем этапе тестировщик проверяет все функции, которые описаны в его тест-кейсах. Когда результат по каждому из них будет положительным, тестирование можно считать оконченным.
В проектной работе применяют преимущественно регрессионное тестирование. Это обусловлено тем, что тест в данном случае проводят на заключительных этапах. Предположим, запланировано четыре спринта. Тогда тестировщик включается после третьего.
Особое внимание при тестах в проектной работе стоит уделить тестированию взаимодействия. Это функциональный тест, который проверяет способность продукта взаимодействовать с компонентами или системами: от одного и больше. Оно включает в себя тестирование совместимости и интеграционное тестирование.
Тестирование совместимости — нефункциональный тест, цель которого — проверить, корректно ли работает приложение в определённом окружении. Это может быть аппаратная платформа, различные ОС, браузеры и расширения.
Интеграционное тестирование — фаза теста ПО, где отдельные модули программы объединяют и тестируют в группе. Интеграционное тестирование можно автоматизировать с помощью систем непрерывной интеграции (например, Jenkins, TeamCity, Travis CI, Gitlab CI, Circle CI, GoCD или другие).
Это особенный, наиболее важный спринт и тестирование. Перед релизом продукт необходимо «прогнать» ещё раз, чтобы убедиться в отсутствии багов (по крайней мере, больших) наверняка.
Сначала нужно провести регрессионное тестирование. В идеале процесс разработки должен быть построен так, чтобы для теста перед релизом оставались только мелкие функции, баги которых не требуют много времени для устранения. Также важно учитывать, чтобы возможные исправления не могли повлиять на другие части продукта и его поведение в принципе. Ведь исправлять всё перед релизом попросту некогда.
Если процесс был спланирован правильно, регрессионное тестирование ограничится проверкой случайных изменений в коде с прошлого спринта. Если нет — случиться может всё, что угодно. Но вероятность того, что вы спокойно завершите работу над приложением в срок, крайне мала.
После регрессионного начинайте тестирование внедрённых багфиксов (исправленных ошибок). Сейчас тестировщик должен проверить, есть ли какие-то негативные последствия от исправления багов, найденных с помощью регрессионного теста, или нет. А также были ли эти ошибки вообще исправлены разработчиками.
Затем идёт тестирование интеграции патча (код, который добавили разработчики для устранения ошибок). Фактически, это тест результата двух предыдущих этапов. Тестировщик пытается понять, не вредит ли патч приложению, и насколько хорошо он «встал» в систему. Помимо патчей на данном этапе проверяют все дополнения, которые были внесены в проект за последнее время. Для этого используются юнит-тесты.
Юнит-тест — автотест для небольшой части кода, которая отвечает за конкретную функцию приложения. Юнит-тесты подают значения. Тест считается пройденным, если программа обрабатывает их верно — так, как было задумано тестировщиком. Если реакция приложения не совпадает с запланированной, тест считается не пройденным. Но разработчики понимают, в какой части кода находится ошибка, и исправляют её.
Это не вся польза юнит-тестов. Они могут очень помочь в борьбе с багами после обновлений. Ведь возвращение к старому коду требует много времени на разбор и сравнение его с новым, а юнит-тест покажет область проблемы сразу.
Последний этап — это финальное тестирование продукта. Оно включает в себя проверку всех функций приложения с учётом спецификации или бэклога, которую команда согласовала с заказчиком.
Начните изучать разработку с бесплатного курса «Основы современной вёрстки». Вы научитесь создавать статические веб-страницы, стилизовать элементы, использовать редакторы кода с полезными расширениями. В конце курса вы опубликуете свой первый сайт на GitHub Pages.
Это тестирования, которые происходят после релиза продукта. Они нужны только в том случае, когда заказчик попросит добавить новый функционал или договорится с компанией о дальнейшем обслуживании приложения и исправлении новых багов.
Во время тестирования на поддержке нужно проверять сборку: основной функционал после обновлений. Когда тестировщик обнаружит баг, он должен описать его. Дальнейшая работа над проблемой будет происходить по принципу тестирования во время спринта.
Важно придерживаться единообразия стандартов, так как это залог стабильной работы отдела тестировщиков. Мы используем описанные выше методики и принципы, чтобы оптимизировать все процессы, экономить время и силы сотрудников, упрощать разработку и не позволять багам проникать в пост-релиз.
Для удобства можно использовать в работе чек-лист.
Статью подготовил Дмитрий Котенко, генеральный директор Infoshell. Мнение администрации «Хекслета» может не совпадать с мнением автора.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях