«Плавающие» дефекты

На любом проекте время от времени появляются дефекты, которые воспроизводятся не на постоянной основе – их ещё часто называют трудновоспроизводимыми или «плавающими». Однако, несмотря на то, что вероятность появления таких дефектов после поставки значительно ниже 100%, ущерб наносимый ими даже единожды, может иметь серьёзнейшие последствия. Чтобы минимизировать количество «плавающих» дефектов можно использовать следующие методы:

1. Добавление/изменение подходов к воспроизведению (и тестированию в целом)

- фокусировка на интуитивно выявленных критических местах

- привлечение помощи сторонних (возможно с другого проекта) тестировщиков для более (exploratory) или менее (ad-hoc) глубокого тестирования

2. «Bug bash» мероприятия

- суть в задействований как можно большего числа "глаз" на приложении с целью выявления дефектов. Большой плюс в привлечении для тестирования не тестировщиков - поскольку это помогает получить разносторонний взгляд на тестируемую систему. В данном случае алгоритм может быть следующим: тестировщик высказывает свои соображения по поводу того, где может находится дефект, остальные (тестировщики, привлечённые с других проектов, а также все остальные члены комады) тестируют систему, параллельно обсуждая вслух возможные варианты воспроизведения (по принципу «что если...») - получается своего рода брэйнсторминг.

3. Парное тестирование (тестировщик + тестировщик или тестировщик + разработчик)

Суть в том, что два тестировщика (или тестировщиу с разработчиком) в паре работают над некой функциональностью за одной машиной. Парное тестирование имеет ряд плюсов:

- в разы снижается риск того, что часть функциональности будет пропущена или недостаточно тщательно протестирована

- общение, возникающее во время парного тестирования, способствует обоюдному расширению знаний о проекте и обмен опытом в целом

- помимо повышения качества тестирования, увеличивается и его скорость

Латаем дыры в тестовом покрытии

На большинстве проектов, на которых мне довелось работать использовались тест кейсы. Однако не смотря на прогон полного набора тестов, багам всё-таки удётся проскакивать в лайф. Источников этих «утечек» довольно много, однако по большому счёту их можно отнести к одной из следующих групп:

1. Ошибка при выполнении теста

Причина: Ошибки могут быть всевозможными - непосредственно в шагах, в настройках "железа", в настройках софта... и причины этих ошибок также могут быть весьма разнообразными.

Что делать: Писать конкретные, достаточно(на усмотрение) детализированные и недвусмысленные шаги и ожидаемые результаты, чтобы с тест кейсоми смог работать тестирвщик со средним знанием тестируемой системы. В написании по-настоящему хорошего теста огромную помощь может оказать разработчик той функциональности, тест к которой вы пишете. Ревизия теста разработчиком добавит в кейс шаги направленные на "узкие" места.

2. Неактуальный тест кейс

Причина: Тест кейс писался на ранних этапах разработки, когда ещё не совсем ясны детали; фунциональность проапдейтили, а тест нет; тестировщик недопонял фичу и написал тест с соответствии с ошибочной точкой зрения;...

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

3. Отсутствует тест кейс

Причина: Если на написание тестов и выделяют время, то его, как правило, недостаточно для детального покрытия фич тестами. Поэтому не стоит удивлсяться случаю, когда на проскочивший баг не найдётся тест кейса, который мог бы его выявить.

Что делать: Разобраться детально в проблеме и создать тест кейс, покрывающий найденный баг плюс небольшую смежную область - так называемый work-around.

4. Ошибка в спеке

Причина: В моём понятии - спека - это, конечно, большая роскошь. Однкако, уж коль она есть, то и ошибки в ней, наверняка, присутствуют. Поэтому, если писать тест кейсы просто по спеке, то есть большой риск, что в них ещё до первого прогона будут содержаться ошибки.

Что делать: Читая спеку тестировщик должен всё ставить под сомнение - это поможет выявить ряд дефектов системы на раннем этапе и не допустить написания ошибочных тест кейсов.

5. Некорректный баг репорт

Причина: Такой баг был занесён в баг-трэккер, но "прошёл мимо" разработчиков - виной тому неверное выставление приоритета, версии, компонента, платформы и т.д. и т.п.

Что делать: Придерживаться установленных в компании/на проекте правил написания отчётов о дефектах. А если возникает ситуация в которой тестировщик сомневается к какому компоненту отнести тот или иной дефект, то не зазорно обратится к разработчикам или тех лиду.

Пишем отчёты о дефектах

В большинсве проектов используют те или иные багтрэкинговые сисемы. Это может быть кастомный (например, на базе SharePoint), бесплатный (например, Bugzilla) или платный (например, JIRA) продукт. Однако вне зависимости от выбора такой системы, шаблон, по которому пишутся отчёты о найденных дефектах будет очень похож. Конечно же очень важно выставлять багу правильный приоритет, версию ПО, ответственного разработчика и т.п., но я бы хотел обратить внимание на три поля, информация в которых повлияет на понимание дефекта, его восприятие и потребует от тестировщика некоторых усилий и определённых знаний тестируемой системы.

1. Summary
Резюме бага, оно же саммари (summary) - это лицо бага, это та самая "одёжка", по которой встречают. Очень многое зависит от того, насколько удачно сформулировано саммари. В идеале, прочтя саммари, разработчик должен на 80% понять суть проблемы.
Советую учесть следующие моменты при написании саммари для дефекта:
а) указание платформы (например, test или prod), если на проекте используется несколько платформ
б) указание компонента (например, аdmin, reports, upload и т.п.), если последующее описание может подойти нескольким компонентам
в) указание браузера (например, IE7), если ошибочное поведение наблюдается специфически под определённым браузером
г) указание частоты воспроизведение (например, occasionally или 4 of 10 times), если воспроизводится не на постоянной основе
д) использование терминологии, использующейся в тестируемой системе (например, не photos, а images или не scroll bar, а slider)

2. Description
Описание шагов (description) - по сути самое важное во всём отчёте, поскольку от того, как тестировщик сумеет объяснить суть бага и шаги к его воспроизведению, зависит его (бага) дальнейшая судьба. Слишком кратко - высока вероятность того, что баг вернётся к тестировщику для уточнения. Слишком детально - разработчик скорее всего отложит такой баг на потом, поскольку его даже читать лень, не говоря уже о качественном фиксе. Осюда вывод, что для того, чтобы избежать временных потерь, надо искать оптимальный размер описания.
Лично я, при написании баг репорта, советую выбрать довольно высокую степень детализации шагов, однако, по возможности, группировать несколько простых действий в один шаг.
Помните, что хорошо описанная проблема - проблема наполовину решённая.

3. Attachment
Правилом хорошего тона в данном случае будет добавление к описанию бага визуального подтверждения. Более распространённым видом такой визуализации является снимок экрана, он же скриншот (screenshot), однако с нынешним выбором ПО нет никакой проблемы прикрепить и заархивированное видео. Многие разработчики оценят такого рода апгрейд - ведь, как говорится, "лучше один раз увидеть, чем сто раз услышать два раза прочитать"

Задача тестировщика состоит не только в том, чтобы найти баг, но и в том, чтобы найденный баг был исправлен.
Помните, что если ваш баг вернулся к вам со статусом не Resolved, то скорее всего в этом виноваты вы.


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