Стрихар Павел
Аналитик
Процесс разработки невозможно представить без тестирования. Никто не отменял человеческий фактор - все мы люди, склонные к ошибкам, поэтому необходимо на постоянной основе проверять и корректировать функционирование ПО. Безусловно, баги необходимо выявлять до того, как они попадают в продакшн, ведь все мы хотим обеспечивать надежную и высокопроизводительную работу продукта. Каким же есть способы тестирования программного обеспечения?
Тестирование делится на ручное и автоматизированное. Ручное тестирование - это процесс, в котором контроль качества осуществляется тестировщиком, т.е. реальным человеком - он выполняет подготовленные тест-кейсы шаг за шагом. Цель ручного тестирования - выявить ошибки и неполадки с функциями до того, как программное приложение начнет работать.
В автоматизированном тестировании, напротив, контроль качества осуществляется программно, т.е. используются тесты, скрипты и инструменты, подготовленные специалистами для автоматизации тестирования.
Как вы могли заметить, ключевая разница между ручным и автоматизированным тестированием заключается в непосредственном исполнителе. Давайте попробуем выяснить, какой метод лучше применять в том или ином случае.
На практике основными преимуществами ручного тестирования являются:
- может быть протестирован весь функционал приложения. Фактически добиться полного покрытия всего функционала тестами практически невозможно, в то время как ручные тесты позволяют охватывать даже самые редкие флоу;
- более низкая стоимость относительно автоматизированного тестирования;
- требуется меньше времени - к тестированию можно приступать сразу после реализации функционала;
- проверка удобства пользовательского интерфейса. Иногда бывает крайне полезно получить фидбек, так как в данном случае тестировщика можно рассматривать в качестве потенциального пользователя.
Ключевыми недостатками ручного тестирования являются:
- человеческий фактор. К сожалению, нужно быть всегда готовым к тому, что некоторые баги могут остаться незамеченными;
- увеличение необходимого времени по мере расширения функциональна;
- в случае выявления ошибок повторное тестирование после их исправления может занимать много времени.
Самым большим преимуществом ручного тестирования по сравнению с автоматизированным является возможность обработки сложных и детализированных тестовых сценариев. Основными преимуществами автоматизированного тестирования являются:
- после написания тестов под сценарии сам процесс тестирования занимает мало времени;
- уменьшается количество логических ошибок за счет минимизации человеческого фактора;
- можно применять нагрузочное тестирование для моделирования большого количества единовременных пользователей.
К ключевым недостаткам можно отнести:
- высокая стоимость. Необходимо нанимать соответствующих специалистов и использовать инструменты автоматизированного тестирования;
- отсутствие UX/UI-тестирования (это не то же самое, что скриншотные тесты);
- есть кейсы, под которые написание автотестов затруднительно или невозможно;
- необходима постоянная актуализация, достичь которую можно лишь процессными изменениями и замедлением разработки.
Таким образом, несмотря на все преимущества, автоматическое тестирование не может полностью заменить ручное. Давайте более подробно рассмотрим этапы ручного тестирования.
При правильном планировании разработки тестировщик приступает к работе на самых ранних этапах. Такая концепция называется shift-left testing. После того, как от заказчика получены и согласованы необходимые требования, QA-специалисты могут приступать к их проверке. Как правило, работа на данном этапе происходит в тандеме с аналитиками, ведь задачей тестировщика является моделирование будущего приложения или новой части функционала. Тестировщику необходимо получить и обработать все требования - если в уже реализованное приложение добавляется новый функционал, крайне важно разобраться в том, как новый функционал будет взаимодействовать с уже существующим.
После обработки требований следует этап проектирования. В большинстве случаев QA-специалист на основе подготовленного дизайн-макета понимает то, как будет реализовано перемещение пользователя между экранами, уделяя особое внимание тому, как будут валидироваться все необходимые поля, а также какое поведение может быть у той или иной функция при взаимодействии с пользователем. Своей работой тестировщик еще раз проверяет насколько корректно был подготовлен макет, не упущены ли мелкие детали, проблемы с которыми могут стать серьезным препятствием при реализации задуманного.
После этого тестировщики начинают написание тест-кейсов. Тест-кейсы представляют собой детализированное описание входных данных, а также условий, ожидаемых результатов и непосредственно процедуры тестирования. Каждый кейс должен определять один конкретный сценарий - то, как должна функционировать отдельно взятая часть функционала. На первых этапах их детализация может быть недостаточно глубокой, однако чем более грамотно подготовлены тест-кейсы, тем лучше будет результат на выходе. В большинстве проектов в первую очередь тестами покрываются ключевые флоу приложения, что заметно уменьшает вероятность возникновения багов у пользователей. Редко используемые части функционала тестируются вручную.
Первым шагом тестирования как мы уже описано выше это написание тест-кейсов или же тест-дизайна всего приложения. Далее когда разработчик выполнил задачу у QA инженера появляется возможность проверить ее по заранее подготовленным сценариям.
На примере работы корзины в интернет-магазине тестирование фичи представляет собой оценку того, можно ли вообще добавить в нее товар и перейти к оформлению заказа, без уточнения того, есть ли товар на остатке или проверки корректности обработки дополнительных полей. Если технически товар добавляется, то далее мы можем переходить к более глубокому тестированию данного функционала.
Следующий этапом является проведение регрессионного тестирования. Регресс представляет собой выполнение большого массива заранее подготовленных тестов, покрывающий большую часть или весь функционал приложения. Иногда при добавлении нового функционала разработчики могут тем или иным образом сломать уже реализованную логику, однако явно они этого не заметят. Ключевым преимуществом регрессионного тестирования является то, что оно позволяет выявить дефекты там, где, казалось бы, ничего не менялось. С другой стороны, регресс может занимать много времени, ведь при добавлении даже незначительных изменений QA-специалистам необходимо проверять большое количество сопряженных флоу. Регресс в свою очередь также проводиться по заранее подготовленным тест кейсам, которые включены в пулл регресионных тестов.
Последним шагом является смоук тестирование. Его особенностью является то тестирование приложения QA-специалистами ограничивается проверкой основного функционала (флоу) приложения, на продакшен сборке. Обычно при релизе, приложение катиться на 1-10% пользователей чтобы в случае возникновения критической проблемы с ней не столкнулись все пользователи. Проверяется весь основной функционал, аналогично регрессу по заранее приготовленным тест кейсам из пулла смоук тестов. В случае нахождения критической проблемы релиз откатывается и исправляется, а в случае успеха приложение раскатывается на оставшуюся часть пользователей.
В этой статье мы рассмотрели то, как проводится ручное тестирование, а также выяснили, почему его нельзя полностью заменить автоматизированным. Статья носит скорее обзорный характер, основных процессов связанных с тестированием. Но самое главное - когда мы самостоятельно и своими руками тестируем продукт, мы встаем на место пользователя, для которого он создавался.