Как тестировщику работать на проектах с неидеальными требованиями?

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

В практике «С первого раза» были следующие случаи:

☛ Описание требований было неполным, потому что кто-то не учел важные детали. Человеческий фактор, так сказать.

☛ Описание требований было некорректным. Действительно, зачем менять первоначальные требования – они и так хорошо разработаны!

☛ Требований нет и в помине. Ну, тут хочется просто помолчать…

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

☛ Спрошу у всех

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

Спрашиваем и уточняем до момента, когда у нас появится четкая картина. Собираем крупицы информации в план и документируем его. Если фичи не очень большие, нам хватает тест-кейсов. Мы адаптируем кейсы под свои проекты и делаем их удобными для работы.

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

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

☛ Посмотрю сам

Если нет доступа к коду или квалификации у сотрудника, подключаем имеющийся опыт и начинаем тестировать. Анализируем интерфейс и производим мыслимые и немыслимые проверки. Тест-кейсы и чек-листы создаются и выполняются в процессе самого тестирования. В итоге останется проанализировать и оценить полученный кейс. Во время выполнения тестов все должно быть учтено и проведено. Данный метод можно назвать «исследовательским черным ящиком».

Если мы имеем возможность заглянуть в святая-святых разработчиков – исходный код, то так и делаем. Главное, чтобы тестировщик понимал исходный код и знал используемый язык программирования. С этим проблем нет? Тогда смело пишите документацию на основе знания кода, тестируйте логику программы, смотрите внутреннюю структуру и, соответственно, проверяйте корректность ввода и вывода! Метод «исследовательского белого ящика» позволяет выявить слабые места в условиях и решениях с помощью разработанных проверок. Мы тестируем как с помощью инструментов (JMeter, Postman, Swagger), так и вручную.

Если фича имеет визуальную составляющую, то мы совмещаем приятное с полезным – воздействуем на функционал и интерфейс, создаем определенные сценарии и проверяем, что программа корректно реагирует на наши действия, т.е. прибегаем к методу «исследовательского серого ящика».

☛ Верну обратно

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

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

Поделитесь, какие решения Вы используете в своей практике?

#QA #работавкоманде #тестирование #техническоезадание #тз