Начинающий тестировщик порой не задумывается, зачем предназначается то или иное программное обеспечение и как конкретно оно будет использоваться клиентами в будущем. У большинства на первое место выходит соответствие техническому заданию, которое порой может слишком сильно отличаться от действительности.
Иногда постановщик задачи (клиент или менеджер проекта) может иметь недостаточно знаний, времени и желания вникать в бизнес-процессы. И тогда возможна ситуация, что на тестах ПО работает корректно, а при поступлении в широкое использование отображается масса багов и дефектов.
Далее постараемся разобраться, что необходимо брать в расчет начинающему тестировщику, чтобы процесс проверки ПО был полезным для конечного пользователя.
Совет №1 – Доверяй, но всегда проверяй
Начинающие QA порой реализуют на практике лучшие методики тестирования, которые идеально сочетаются с правильным продуктом. Бывает так, что они не обращают внимание на поведение ПО, когда в качестве исходных данных поступает некорректная информация. А это первым делом и происходит, когда продукт начинает работать в реальной среде.
Просчитать абсолютно все сценарии использования ПО невозможно, но работать в данном направлении необходимо.Совет №2 – Станьте на место пользователя
Еще одна сложность может возникать именно с пользователями программы. Любой потенциальный пользователь, даже смотря на детализированную инструкцию по использованию ПО, всегда может нажать на комбинацию кнопок или ввести такие данные, которые могут вывести из строя алгоритм, если он не содержит даже банальной «защиты от дурака».
Это не так уж сложно для QA-инженера, вообразить себя на месте потенциального пользователя. Ведь они (пользователи) тоже люди и могут совершать ошибки. Если есть время, стоит уделить внимание разнообразным наборам комбинаций, а также попробовать вводить некорректные данные.
Совет №3 – Никогда не откладывайте на потом
Тестировщики могут сами себе создавать дополнительные проблемы во время работы над быстро исполнимой задачей, когда несознательно забывают выполнить тесты того или иного функционала. Например, при проверке работы навигации забыть протестировать корректность работы блока «хлебных крошек».
Подобные вещи не выглядят глобальными на фоне остальных задач. QA может сопровождать ощущение того, что их проверку можно отложить на будущее. И самое критическое здесь – тот факт, что «потом» может попросту не наступить из-за нехватки времени или смены приоритетов в работе.
Совет №4 – Спокойствие и максимальная выдержка
Порой каждый из нас попадает в такие ситуации, когда рабочего времени критически мало. Спешка при тестировании обязательно приводит к тому, что на выходе программное обеспечение получается «сырое» и некоторые его системные действия могут выполняться некорректно.
А если продукт большой и содержит сложную логику, то вам как проверяющему придется потратить массу времени на тестирование одного и того же функционала несколько раз. Без трезвой оценки своих возможностей и спокойствия в реализации своих обязанностей что-то успеть у вас точно не получится.
Оставить комментарий