В идеале процесс тестирования начинается с изучения документации, стеков и требований, которые передают аналитики и другие причастные люди. Но вот незадача: даже если требования переданы, то не факт, что они соответствуют ожиданиям тестировщика.
В практике «С первого раза» были следующие случаи:
☛ Описание требований было неполным, потому что кто-то не учел важные детали. Человеческий фактор, так сказать.
☛ Описание требований было некорректным. Действительно, зачем менять первоначальные требования – они и так хорошо разработаны!
☛ Требований нет и в помине. Ну, тут хочется просто помолчать…
Каждый из нас сталкивался с такими проблемами и, я уверена, великолепно справлялся. Однако тестирование сильно затягивалось. Пока разберешься что к чему… Тестировать фичу приходится несколько раз: сначала по тому, что есть, потом с большим желанием высказать свою «любовь» другим командам на проекте.
Как мы справляемся с такими проблемами?
☛ Спрошу у всех
Сначала нужно определить основную цель проекта и узнать, каким постановщики видят итоговый функционал. Ну, побудем немного аналитиками – пособираем информацию из разных источников... Тут нам помогут разработчики и аналитики. Также никто не запрещает задавать вопросы постановщикам.
Спрашиваем и уточняем до момента, когда у нас появится четкая картина. Собираем крупицы информации в план и документируем его. Если фичи не очень большие, нам хватает тест-кейсов. Мы адаптируем кейсы под свои проекты и делаем их удобными для работы.
После составления документации мы согласовываем ее с разработчиками и постановщиками. Кому, если не им, знать, что должно получиться в итоге и чего категорически нельзя допустить до боя?
Правильно составленный кейс – залог успешного тестирования. Его основная цель – учесть все возможные варианты тестов, иначе работа сведется к банальному прокликиванию кнопочек мышкой и вводу нескольких значений.
☛ Посмотрю сам
Если нет доступа к коду или квалификации у сотрудника, подключаем имеющийся опыт и начинаем тестировать. Анализируем интерфейс и производим мыслимые и немыслимые проверки. Тест-кейсы и чек-листы создаются и выполняются в процессе самого тестирования. В итоге останется проанализировать и оценить полученный кейс. Во время выполнения тестов все должно быть учтено и проведено. Данный метод можно назвать «исследовательским черным ящиком».
Если мы имеем возможность заглянуть в святая-святых разработчиков – исходный код, то так и делаем. Главное, чтобы тестировщик понимал исходный код и знал используемый язык программирования. С этим проблем нет? Тогда смело пишите документацию на основе знания кода, тестируйте логику программы, смотрите внутреннюю структуру и, соответственно, проверяйте корректность ввода и вывода! Метод «исследовательского белого ящика» позволяет выявить слабые места в условиях и решениях с помощью разработанных проверок. Мы тестируем как с помощью инструментов (JMeter, Postman, Swagger), так и вручную.
Если фича имеет визуальную составляющую, то мы совмещаем приятное с полезным – воздействуем на функционал и интерфейс, создаем определенные сценарии и проверяем, что программа корректно реагирует на наши действия, т.е. прибегаем к методу «исследовательского серого ящика».
☛ Верну обратно
Если необходимых требований нет, вы можете вернуть задачу и указать на отсутствие компонентов, без которых невозможно полноценное тестирование, потому что разработка и ведение требований выходит за рамки вашей работы. Важную роль играет механизм обратной связи. Не молчите о проблемах!
Главное понимать, что возврат на этап подготовки требований может сорвать срок сдачи проекта или проект в целом. Согласитесь, успешное завершение проекта – это общая цель.
Поделитесь, какие решения Вы используете в своей практике?
Спек - самое важное в работе тестировщика. Будет спек - будет результат. А так, без нормального ТЗ и результат ХЗ :)
Мы слишком лояльны к разрабам, надо донести, что искать иголку в стоге сена мы не будем.
Самый лучший ответ разработчика по задаче: - "А я не знаю, что должно быть в конечном результате задачи"
Требования, это отдельная боль тестировщиков)
Из разряда: иди туда, не знаю куда и найди то, не зная что......