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

На любом проекте время от времени появляются дефекты, которые воспроизводятся не на постоянной основе – их ещё часто называют трудновоспроизводимыми или «плавающими». Однако, несмотря на то, что вероятность появления таких дефектов после поставки значительно ниже 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. Если вы не уверены в том, насколько хорошо вы справляетесь с перечисленными тремя пунктами - не стесняйтесь и спросите у тех, кому приходится непосредственно с этой информацией работать - вашу команду разработчиков

Огранизация команды тестирования

Успешность работы команды тестирования (QA team) во многом зависит от её лидера (QA lead). Неоспоримо, что большую роль играет профессиональный и личностный уровень членов команды, однако не стоит недооценивать и то, насколько успешной её может сделать хороший QA Lead (в дальнейшем - лидер).
Я попробовал сформулировать несколько принципов, которые должен использовать лидер в своей работе.

1. Team spirit
Лидер - часть команды. И подчинённые должны это видеть. В противном случае они просто потеряют желание работать в такой команде и приносить пользу проекту.
Многие лидеры забывают, что ступив на чуть более высокую ступень и получив приставку Lead к должности, они по прежнему остаются QA.

2. QA Lead – tester…
Лидер и сам должен тестировать. Это не значит, что он обязан тратить всё своё время на тестирование. Однако следует уделять задачам тестирования хотя бы некоторую часть (в зависимости от размера команды) времени.

3. Writing Test Cases
Лидеру не стоит оставлять написание тестов исключительно подчинённым. В противном случае члены команды могут посчитать написание тестов менее важной задачей, что приведёт к ухудшению тестового покрытия в качестенном и количественном выражении. В добавок к этому, регулярное написание тестов позволит чётко представлять состояние базы тестов на проекте.

4. Learn Together
Лидер должен избегать тенденции к исследованию новой функциональности первым. Члены команды должны видеть, что их лидер изучает функциональности и учится вместе с ними наровне.

5. Everybody makes mistakes
Лидер должен обличать свои ошибки. Ошибки делают все. Это потребует некоторой смелости, поскольку никто не любит выглядеть неподобающим образом и не каждый осмелится на такое.

6. No Monopoly on Ideas
Лидер просто обязан избегать "монополизации" идей. Он должен иногда давать право членам команды брать инициативу на себя. Также в отдельных случаях необходимо поощрять принятие решений (конечно если компетенции членов команды позволяют принимать решения).

7. Trusted team
Лидер должен создать команду, на которую он сможет полностью положиться. Да, лидер должен быть осторожен, но не настолько, чтобы не вовлекать своих подчинённых в решение сложных задач. Лидер должен таким образом организовать взаимодействие с подчинёнными, что они почувстуют свою значимость - факт, что они делают свой вклад в проект.

8. Input Appreciation
Лидер должен поощрять не только выдающиеся результаты, но и просто хорошую работу. Даже простого упоминания на собрании хватит, чтобы члены команды почувствовали себя значимыми. Лидер должен ставить членам команды цели и вознаграждать за их достижение.
9. Proactivity is Welcomed
Лидер должен приветсвовать проактивность. Проактивность должна вести к расширенным полномочиям.


10. No Knowledge Ownership
Лидер должен избегать "приватизирования знаний". Каждый член команды должен знать большую часть функциональности системы (насколько это позволяет размер проекта - в идеале 100%). Также каждый член команды должен хорошо ориентироваться во всей базе тестов - принцип тот же.