На большинстве проектов, на которых мне довелось работать использовались тест кейсы. Однако не смотря на прогон полного набора тестов, багам всё-таки удётся проскакивать в лайф. Источников этих «утечек» довольно много, однако по большому счёту их можно отнести к одной из следующих групп:
Причина: Ошибки могут быть всевозможными - непосредственно в шагах, в настройках "железа", в настройках софта... и причины этих ошибок также могут быть весьма разнообразными.
Что делать: Писать конкретные, достаточно(на усмотрение) детализированные и недвусмысленные шаги и ожидаемые результаты, чтобы с тест кейсоми смог работать тестирвщик со средним знанием тестируемой системы. В написании по-настоящему хорошего теста огромную помощь может оказать разработчик той функциональности, тест к которой вы пишете. Ревизия теста разработчиком добавит в кейс шаги направленные на "узкие" места.
2. Неактуальный тест кейс
Причина: Тест кейс писался на ранних этапах разработки, когда ещё не совсем ясны детали; фунциональность проапдейтили, а тест нет; тестировщик недопонял фичу и написал тест с соответствии с ошибочной точкой зрения;...
Что делать: Регулярно проводить ревизию тест кейсов, причём опять же желательно, совместно в разработчиком, отвечающим за конкретную функциональность.
3. Отсутствует тест кейс
Причина: Если на написание тестов и выделяют время, то его, как правило, недостаточно для детального покрытия фич тестами. Поэтому не стоит удивлсяться случаю, когда на проскочивший баг не найдётся тест кейса, который мог бы его выявить.
Что делать: Разобраться детально в проблеме и создать тест кейс, покрывающий найденный баг плюс небольшую смежную область - так называемый work-around.
4. Ошибка в спеке
Причина: В моём понятии - спека - это, конечно, большая роскошь. Однкако, уж коль она есть, то и ошибки в ней, наверняка, присутствуют. Поэтому, если писать тест кейсы просто по спеке, то есть большой риск, что в них ещё до первого прогона будут содержаться ошибки.
Что делать: Читая спеку тестировщик должен всё ставить под сомнение - это поможет выявить ряд дефектов системы на раннем этапе и не допустить написания ошибочных тест кейсов.
5. Некорректный баг репорт
Причина: Такой баг был занесён в баг-трэккер, но "прошёл мимо" разработчиков - виной тому неверное выставление приоритета, версии, компонента, платформы и т.д. и т.п.
Что делать: Придерживаться установленных в компании/на проекте правил написания отчётов о дефектах. А если возникает ситуация в которой тестировщик сомневается к какому компоненту отнести тот или иной дефект, то не зазорно обратится к разработчикам или тех лиду.
Комментариев нет:
Отправить комментарий