Мышление QA: От поиска багов к обеспечению качества

Фундамент профессии: отличие мышления тестировщика от восприятия обычного пользователя

Добро пожаловать в курс «Мышление QA». Если вы читаете эти строки, значит, вы решили заглянуть за кулисы IT-индустрии и освоить профессию, которая является последним бастионом между программным кодом и конечным пользователем.

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

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

Иллюзия идеального мира: Взгляд пользователя

Чтобы понять тестировщика, сначала нужно понять того, для кого мы работаем — пользователя.

Обычный пользователь — это оптимист. Когда он открывает приложение для заказа такси или сайт интернет-магазина, у него есть конкретная цель: уехать домой или купить кроссовки. Его мышление направлено на успешный сценарий.

В профессиональной среде это называется Happy Path (Счастливый путь). Это сценарий использования продукта, при котором всё идет по плану:

* Пользователь вводит верные данные. * Интернет работает стабильно. * На банковской карте есть деньги. * Сервер отвечает мгновенно.

Пользователь подсознательно «помогает» программе работать. Он не будет вводить в поле «Возраст» иероглифы или отрицательные числа. Он хочет, чтобы программа работала, и игнорирует мелкие недочеты, пока они не блокируют его основную цель.

> Если программа работает, пользователь считает, что она сделана качественно. Если программа ломается, пользователь испытывает разочарование и злость.

Инженерный скептицизм: Взгляд тестировщика

Тестировщик — это профессиональный пессимист с инженерным подходом. Там, где пользователь видит красивый фасад здания, тестировщик видит несущие конструкции, проводку и потенциальные места протечек.

Мышление QA строится на вопросе: «А что, если?..»

В отличие от пользователя, чья цель — достичь результата, цель тестировщика — исследовать поведение системы в условиях неопределенности и стресса. Мы не верим, что всё пойдет по плану. Мы знаем, что план обязательно нарушится.

!Сравнение «Happy Path» пользователя и исследовательского подхода тестировщика.

Ключевые отличия восприятия

Рассмотрим фундаментальные различия в таблице:

| Характеристика | Обычный пользователь | QA-инженер | | :--- | :--- | :--- | | Доверие | Доверяет системе по умолчанию | Подвергает сомнению каждый элемент | | Цель | Получить результат (купить, отправить) | Получить информацию о качестве | | Действия | Стандартные, предсказуемые | Нестандартные, граничные, хаотичные | | Реакция на ошибку | Паника, раздражение, уход | Интерес, анализ, документирование | | Фокус внимания | Центр экрана, основные кнопки | Края, скрытые меню, логика работы |

Практический пример: Форма авторизации

Давайте разберем простейший пример — форму входа на сайт, состоящую из полей «Логин», «Пароль» и кнопки «Войти».

Что делает пользователь?

Вводит свой email.

Вводит свой пароль.

Нажимает «Войти».

Если он вошел — всё отлично. Если забыл пароль — нажимает «Восстановить».

Что делает тестировщик?

В голове QA-инженера мгновенно формируется список проверок, выходящих далеко за рамки обычного использования. Вот лишь малая часть вопросов, которые задает себе тестировщик:

Граничные значения: А что, если пароль состоит из 1 символа? А если из 5000 символов?

Типы данных: Что будет, если в поле email ввести только цифры? Или спецсимволы (#, $, %)? Или эмодзи?

Пустота: Что произойдет, если нажать «Войти», оставив поля пустыми?

Безопасность: Можно ли вставить в поле вредоносный код (SQL-инъекция или XSS)?

Среда: Что будет, если нажать кнопку «Войти» и в этот момент отключить интернет?

Интерфейс: Удобно ли нажимать кнопку с мобильного телефона? Видно ли текст ошибки дальтоникам?

!Визуализация того, как тестировщик видит скрытую сложность простой формы входа.

Не просто «ломать»: Созидание через разрушение

Существует опасный миф, что работа тестировщика — это деструктивная деятельность. Якобы мы получаем удовольствие от того, что ломаем чужой труд. Это в корне неверно.

Тестирование — это созидательный процесс.

Представьте, что вы строите мост. Чтобы убедиться, что он выдержит поток машин, вы сначала нагружаете его бетонными блоками, превышающими вес обычного транспорта. Вы «пытаетесь сломать» мост не для того, чтобы его разрушить, а для того, чтобы убедиться в его надежности.

Мышление QA направлено на предотвращение рисков. Мы ищем баги (ошибки) сейчас, чтобы они не нашлись потом, когда продуктом будут пользоваться миллионы людей. Найденный баг — это не повод для злорадства над разработчиком, а спасенная репутация компании и нервы пользователей.

Эмпатия как профессиональный инструмент

Парадоксально, но чтобы стать хорошим тестировщиком, нужно уметь переключать тумблер в голове обратно в режим «Пользователь».

Технически безупречный продукт может быть абсолютно неудобным. Если кнопка работает идеально, но она серого цвета на сером фоне и находится в углу, где её никто не видит — это баг. Но это баг не кода, а баг пользовательского опыта (UX — User Experience).

Мышление QA включает в себя эмпатию. Вы — адвокат пользователя внутри команды разработки. Разработчики часто забывают о том, как обычные люди взаимодействуют с техникой, потому что сами являются продвинутыми пользователями. Ваша задача — напомнить команде:

* «А поймет ли бабушка, куда здесь нажимать?» * «А что, если у пользователя медленный мобильный интернет в метро?» * «Не слишком ли много шагов нужно сделать для простой покупки?»

Эффект пестицида и замыливание глаза

В теории тестирования есть понятие «Парадокс пестицида». Если вы каждый раз обрабатываете поле одним и тем же ядом, вредители вырабатывают иммунитет. Точно так же, если вы проверяете программу по одному и тому же сценарию, вы перестаете находить новые баги.

Мышление тестировщика требует постоянной гибкости. Вы не можете позволить себе привыкнуть к продукту так же, как к нему привыкает пользователь. Вы должны каждый день смотреть на приложение так, будто видите его впервые.

Для этого QA-инженеры используют различные техники тест-дизайна (о которых мы поговорим в следующих статьях), но главное оружие — это любопытство. Желание заглянуть туда, куда «не просят», и нажать то, что «не нужно».

Заключение

Переход от мышления пользователя к мышлению QA — это необратимый процесс. Начав замечать несовершенства в программном обеспечении, вы уже не сможете это «развидеть». Вы начнете замечать баги в лифтах, в микроволновках, в расписании автобусов.

Но именно это изменение восприятия делает вас профессионалом.

Краткое резюме урока:

Пользователь идет по «Счастливому пути» (Happy Path), тестировщик исследует отклонения и границы.

Пользователь хочет результат, тестировщик ищет информацию о качестве.

Тестирование — это не разрушение, а проверка надежности.

Хороший QA совмещает технический скептицизм с эмпатией к конечному пользователю.

В следующей статье мы углубимся в то, что такое «качество» на самом деле, и почему отсутствие багов не гарантирует успех продукта.

Анализ требований и декомпозиция: предотвращение ошибок на этапе проектирования

В предыдущей статье мы разобрали, как переключить тумблер в голове из режима «Пользователь» в режим «QA-инженер». Мы научились сомневаться, искать граничные значения и смотреть на продукт сквозь призму скептицизма.

Теперь пришло время применить этот навык на практике. Но не спешите открывать программу и искать баги в коде. Самые опасные и дорогие ошибки рождаются задолго до того, как разработчик напишет первую строчку кода. Они рождаются в требованиях.

В этой статье мы научимся читать документацию так, как это делают профессионалы, и узнаем, как предотвратить катастрофу, просто задав правильный вопрос вовремя.

Цена ошибки: Почему важно читать документы

Представьте, что вы строите дом. Архитектор нарисовал план, где забыл указать дверь в ванную комнату.

* Сценарий А: Вы заметили это на этапе просмотра чертежа. Цена исправления: 5 минут работы ластиком и карандашом. Стоимость: 0 рублей. * Сценарий Б: Вы заметили это, когда строители уже возвели стены и положили плитку. Цена исправления: Снос стены, вывоз мусора, покупка новых материалов, оплата труда рабочих. Стоимость: десятки тысяч рублей и недели задержки.

В разработке программного обеспечения (ПО) действует тот же принцип. Это называется «Стоимость исправления дефекта».

!График, демонстрирующий экспоненциальный рост стоимости ошибки по мере продвижения по этапам разработки.

Тестирование требований (или статическое тестирование) — это процесс проверки документации до начала разработки. Ваша задача — найти логические дыры, противоречия и недосказанности, пока они существуют только на бумаге.

Что такое требование?

Новички часто думают, что требования — это огромный документ на 500 страниц с печатью, написанный сухим юридическим языком (Техническое Задание или ТЗ). В реальности IT-мира требования могут выглядеть как:

* Задача (тикет) в системе управления проектами (Jira, Trello). * Макет дизайна в Figma. Сообщение от заказчика в мессенджере: «Хочу, чтобы кнопка была красной и мигала»*. * Устная договоренность на митинге.

Требование — это любое описание того, как система должна вести себя, выглядеть или какие функции выполнять.

Критерии качественных требований

Как понять, что требование плохое? Хороший тестировщик работает как редактор-зануда. Он проверяет требования на соответствие нескольким ключевым критериям. В индустрии часто используют мнемонику INVEST или SMART, но мы упростим их до самых важных для QA характеристик:

1. Полнота (Completeness)

Описаны ли все сценарии?

> Плохое требование: «Пользователь может загрузить аватарку».

Здесь возникает миллион вопросов: * Какого формата (JPG, PNG, GIF)? * Какого максимального размера (5 Мб, 1 Гб)? * Что будет, если загрузить текстовый файл вместо картинки? * Можно ли загрузить квадратную или прямоугольную картинку?

> Хорошее требование: «Пользователь может загрузить аватарку в формате JPG или PNG, размером не более 5 Мб. Если файл превышает размер, система выдает ошибку: "Файл слишком большой"».

2. Недвусмысленность (Unambiguity)

Требование должно трактоваться всеми участниками команды одинаково. Избегайте субъективных прилагательных.

Слова-паразиты в требованиях: * «Быстро» * «Красиво» * «Удобно» * «Интуитивно понятно» * «В ближайшее время»

Для разработчика «быстро» — это 100 миллисекунд. Для заказчика — 2 секунды. Когда продукт выйдет, возникнет конфликт.

> Исправление: Заменяйте эмоции на цифры. Не «сайт должен работать быстро», а «время загрузки главной страницы не должно превышать 1.5 секунды при 4G соединении».

3. Непротиворечивость (Consistency)

Требования не должны конфликтовать друг с другом.

Стр. 5:* «Кнопка "Купить" доступна только авторизованным пользователям». Стр. 12:* «Гость может совершить быструю покупку без регистрации».

Это классический пример противоречия. Разработчик сделает как ему удобнее, а тестировщик потом заведет баг. Задача QA — заметить это несоответствие при чтении.

4. Тестируемость (Testability)

Можете ли вы придумать проверку, которая однозначно скажет: требование выполнено или нет?

Если требование звучит как «Система должна нравиться пользователям», его невозможно протестировать объективно. Как вы измерите «нравится»?

Декомпозиция: Искусство разделять и властвовать

Часто требования приходят в виде больших, абстрактных задач. Например: «Сделать форму регистрации».

Чтобы качественно протестировать (и разработать) такую задачу, её нужно декомпозировать — разбить на мельчайшие составляющие. Это похоже на разборку механизма на шестеренки.

Декомпозиция помогает:

Увидеть скрытую сложность.

Не пропустить важные проверки.

Точнее оценить время на тестирование.

[VISUALIZATION: Схема декомпозиции объекта

Негативное тестирование и граничные значения: искусство ломать систему правильно

В первых статьях нашего курса мы говорили о том, как мыслит тестировщик, и как важно предотвращать ошибки еще на этапе требований. Мы выяснили, что пользователи — это оптимисты, которые идут по «Счастливому пути» (Happy Path). Но что происходит, когда пользователь сворачивает с протоптанной дорожки? Или, что еще хуже, когда он делает это намеренно?

Сегодня мы переходим к самой захватывающей части профессии — негативному тестированию и техникам тест-дизайна, которые превращают хаотичное «тыканье» кнопок в точную инженерную науку.

Позитивное и Негативное тестирование: Две стороны одной медали

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

Позитивное тестирование

Это проверка того, что система делает то, что должна делать. Мы вводим корректные данные и ожидаем успешный результат.

* Пример: В поле «Возраст» вводим «25». Система принимает значение. * Цель: Убедиться, что основной функционал работает.

Негативное тестирование

Это проверка того, что система не делает того, чего не должна делать, и корректно обрабатывает невалидные (неверные) данные. Мы намеренно вводим ошибки, чтобы посмотреть, устоит ли программа.

* Пример: В поле «Возраст» вводим «-5» или «двадцать». Система должна показать понятное сообщение об ошибке и не «упасть». * Цель: Проверить устойчивость (стабильность) и безопасность системы.

!Иллюстрация различий между проверкой нормальной работы и проверкой на устойчивость к ошибкам.

> Негативное тестирование — это не просто попытка сломать. Это попытка доказать, что систему сломать нельзя.

Проблема бесконечности

Представьте, что вам нужно протестировать поле ввода, которое принимает числа от 1 до 100.

Если вы будете проверять каждое число (1, 2, 3... 99, 100), вы потратите уйму времени. А если диапазон от 1 до 1 000 000? Проверить всё физически невозможно.

Здесь нам на помощь приходят техники тест-дизайна. Это математические методы, которые позволяют сократить количество тестов с миллиона до нескольких штук, не потеряв при этом в качестве проверки. Две самые главные техники — это Классы эквивалентности и Граничные значения.

Техника №1: Классы эквивалентности (Equivalence Partitioning)

Идея этой техники гениально проста: если система одинаково обрабатывает набор значений, нет смысла проверять их все. Достаточно проверить одно значение из группы.

Давайте вернемся к нашему примеру: поле ввода возраста для покупки алкоголя (от 18 до 100 лет).

Мы можем разбить все возможные числа на группы (классы):

Валидный класс (Разрешено): Числа от 18 до 100. Если система принимает число 25, она с вероятностью 99.9% примет и число 46, и 88. Нам достаточно одного теста из этого диапазона.

Невалидный класс (Слишком мало): Числа от 0 до 17. Если система блокирует 5 лет, она заблокирует и 10.

Невалидный класс (Слишком много): Числа больше 100 (допустим, 101 и выше).

Невалидный класс (Отрицательные): Числа меньше 0.

Вместо перебора всех чисел мы выбрали по одному представителю из каждого класса. Например: 25, 10, 150, -5. Всего 4 теста вместо бесконечности!

!Визуализация метода классов эквивалентности.

Техника №2: Анализ граничных значений (Boundary Value Analysis)

Классы эквивалентности — это мощно, но у них есть слабое место. Ошибки в коде чаще всего скапливаются не в середине диапазонов, а на их границах.

Разработчики — тоже люди. Когда программист пишет условие, он может легко ошибиться в знаке неравенства.

Рассмотрим простейшее математическое условие на языке программирования:

Где — это возраст пользователя, а символ означает «строго больше».

Если разработчик написал так, то человек, которому исполнилось ровно 18 лет, не сможет пройти проверку, потому что 18 не больше 18. Правильный код должен был быть (больше или равно).

Именно такие ошибки ловит техника Граничных значений.

Правило границ

Для каждой границы мы должны проверить три значения:

Саму границу.

Значение сразу перед границей (-1).

Значение сразу после границы (+1).

Вернемся к примеру с возрастом (от 18 до 100).

Граница 18 (Нижняя): * 17 (Граничное - 1): Ожидаем отказ. * 18 (Граница): Ожидаем успех. * 19 (Граничное + 1): Ожидаем успех.

Граница 100 (Верхняя): * 99 (Граничное - 1): Ожидаем успех. * 100 (Граница): Ожидаем успех. * 101 (Граничное + 1): Ожидаем отказ.

Таким образом, мы прицельно бьем в самые уязвимые места логики программы.

Комбинируем техники: Полный набор проверок

В реальной работе QA-инженер использует обе техники одновременно. Давайте разберем реальный кейс.

Задача: Протестировать поле для ввода промокода. Требование: Промокод должен состоять от 5 до 10 символов.

Как мы будем это тестировать?

Шаг 1. Определяем классы эквивалентности (по длине)

* Валидный: Длина от 5 до 10 символов. * Невалидный (мало): Длина от 0 до 4. * Невалидный (много): Длина 11 и более.

Шаг 2. Определяем границы

Нас интересуют стыки между классами: 5 и 10.

Шаг 3. Формируем список тестов (Чек-лист)

| Значение (длина) | Тип проверки | Ожидаемый результат | Пояснение | | :--- | :--- | :--- | :--- | | 4 символа | Негативный (Граница - 1) | Ошибка | Проверка нижней границы (снаружи) | | 5 символов | Позитивный (Граница) | Успех | Проверка нижней границы (внутри) | | 7 символов | Позитивный (Класс) | Успех | Проверка середины диапазона (не обязательно, но полезно) | | 10 символов | Позитивный (Граница) | Успех | Проверка верхней границы (внутри) | | 11 символов | Негативный (Граница + 1) | Ошибка | Проверка верхней границы (снаружи) |

Всего 5 проверок гарантируют нам почти 100% уверенность в том, что валидация длины работает корректно.

Типичные ошибки новичков

1. Эффект «Золотого молотка»

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

> Совет: Всегда оценивайте риски. Если поле критичное (например, банковский перевод) — тестируйте жестко. Если это поле «Комментарий к заказу пиццы» — достаточно базовых проверок.

2. Забытая пустота

Очень часто тестировщики забывают проверить пустое значение. Что будет, если просто нажать кнопку, ничего не вводя? Это отдельный, очень важный класс эквивалентности.

3. Тестирование ради тестирования

Не нужно проверять значения 6, 7, 8, 9 в примере выше. Они все принадлежат одному классу. Если работает 7, то 8 тоже будет работать. Лишние тесты — это потерянное время компании.

Заключение

Искусство тестирования заключается не в том, чтобы сделать как можно больше тестов, а в том, чтобы сделать необходимый минимум тестов, который найдет максимум ошибок.

Классы эквивалентности и граничные значения — это ваш скальпель. С их помощью вы отсекаете лишнее и вскрываете проблемы там, где они прячутся чаще всего.

В следующей статье мы отойдем от полей ввода и поговорим о том, как тестировать логику переходов и состояний системы, когда у нас есть сложные сценарии взаимодействия.

Краткое резюме:

Позитивное тестирование проверяет, что система работает. Негативное — что она не ломается от ошибок.

Классы эквивалентности позволяют группировать данные и не проверять всё подряд.

Граничные значения — это места стыка классов, где чаще всего живут баги.

Проверяйте границы: само значение, значение «до» и значение «после».

Жизненный цикл дефекта: как грамотно локализовать и описать проблему

В предыдущей статье мы вооружились техниками тест-дизайна — классами эквивалентности и граничными значениями. Теперь вы умеете находить уязвимые места в системе и, скорее всего, уже обнаружили свой первый баг. Поздравляем! Но найти ошибку — это только половина дела.

Представьте, что вы свидетель преступления. Если вы прибежите в полицию и закричите: «Там что-то случилось!», это никому не поможет. Вам нужно четко описать: кто, где, когда и что именно сделал.

В работе QA-инженера этот «протокол» называется Баг-репорт (Bug Report). От того, насколько грамотно вы его составите, зависит, как быстро разработчик исправит ошибку и исправит ли её вообще.

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

Локализация: Работа детектива

Новички часто совершают одну и ту же ошибку: увидев баг, они сразу бегут заводить задачу в баг-трекер (систему отслеживания ошибок, например, Jira). Профессионал же сначала делает шаг назад и начинает расследование. Этот процесс называется локализацией дефекта.

Локализация — это процесс сужения области поиска причины ошибки. Ваша цель — найти минимальный набор шагов, который гарантированно приводит к воспроизведению бага.

Принцип «Бритвы Оккама» в тестировании

Допустим, вы тестируете интернет-магазин. Вы зашли на главную, открыли каталог, отфильтровали товары по цене, зашли в карточку товара, почитали отзывы, добавили товар в корзину, перешли к оплате, нажали «Оплатить» — и сайт упал с ошибкой 500.

Если вы опишете все эти шаги разработчику, он потратит час, чтобы повторить ваш путь. Но, возможно, ошибка возникает просто при нажатии кнопки «Оплатить», независимо от фильтров и отзывов.

Как локализовать проблему:

Отсекайте лишнее. Попробуйте воспроизвести баг без фильтрации. Воспроизводится? Отлично, значит фильтры ни при чем. Попробуйте без чтения отзывов.

Изолируйте переменные. Проблема в конкретном товаре или в любом? Проблема в браузере Chrome или в Firefox тоже?

Найдите минимальный путь. Идеальный баг-репорт содержит 3–5 шагов, а не 20.

> Хорошо локализованный баг — это сэкономленные часы работы всей команды.

Анатомия идеального баг-репорта

Баг-репорт — это технический документ. Он должен быть сухим, четким и однозначным. Давайте разберем его структуру на атомы.

1. Заголовок (Summary)

Это самое важное поле. Разработчик часто читает только его. Заголовок должен отвечать на три вопроса: Что? Где? Когда?

* ~~Плохо:~~ Кнопка не работает. * ~~Плохо:~~ Ошибка при заказе. * Хорошо: Ошибка 404 при нажатии кнопки «Оплатить» в корзине авторизованного пользователя.

2. Описание и Шаги воспроизведения (Steps to Reproduce)

Инструкция, по которой любой человек (даже тот, кто не знает проект) сможет увидеть баг.

Открыть сайт example.com.

Авторизоваться под тестовым пользователем.

Добавить товар «Ноутбук» в корзину.

Нажать кнопку «Оплатить».

3. Фактический и Ожидаемый результат

Это сердце конфликта. Вы должны четко показать разницу между реальностью и требованиями.

* Фактический результат (Actual Result): Появилось сообщение «Server Error 500», оплата не прошла. * Ожидаемый результат (Expected Result): Происходит переход на страницу подтверждения заказа, списываются средства.

> Без «Ожидаемого результата» это не баг, а просто наблюдение. Вы должны обосновать, почему считаете поведение системы ошибочным, ссылаясь на требования или здравый смысл.

4. Окружение (Environment)

Баг может появляться только на iPhone 14 или только в браузере Safari. Всегда указывайте: * Версию приложения. * Операционную систему. * Браузер и его версию. * Разрешение экрана (если баг визуальный).

5. Приоритет и Серьезность (Priority & Severity)

Эти два понятия часто путают, но разница между ними фундаментальна.

* Серьезность (Severity) — это техническая степень влияния бага на систему. Насколько сильно сломано? Blocker:* Система не работает вообще (сайт не открывается). Critical:* Не работает ключевая функция (нельзя купить товар). Major:* Функция работает с ошибками, но есть обходной путь. Minor:* Мелкие неудобства, опечатки, съехавшая верстка.

* Приоритет (Priority) — это бизнес-важность. Как быстро нужно чинить? High:* Чинить немедленно. Medium:* Чинить в порядке очереди. Low:* Можно починить, когда будет время.

!Матрица соотношения Серьезности и Приоритета с примерами ситуаций.

Парадокс: Опечатка в названии компании на главной странице имеет Low Severity (сайт работает, кнопки нажимаются), но High Priority (репутационные риски огромны). А падение системы при генерации годового отчета 31 января имеет High Severity, но если сейчас июль — Low Priority.

Жизненный цикл дефекта (Bug Life Cycle)

Баг не просто лежит в базе данных, он «живет». Он меняет свои статусы, переходя от специалиста к специалисту. Этот путь называется жизненным циклом.

Рассмотрим классическую схему:

New (Новый): Вы нашли баг и завели его в систему.

Open (Открыт): Тимлид или менеджер подтвердил, что это действительно баг, и его нужно чинить.

In Progress (В работе): Разработчик начал исправлять ошибку.

Fixed / Resolved (Исправлено): Разработчик внес правки в код и утверждает, что починил баг.

Внимание! На этом этапе работа не заканчивается. Начинается самое интересное.

Verified (Проверено): QA-инженер берет исправленную версию и проверяет, действительно ли баг исчез.

* Если баг исчез — статус Closed (Закрыт). * Если баг остался — статус Reopened (Переоткрыт), и он возвращается к разработчику.

!Схема циркуляции задачи между тестировщиком и разработчиком.

Альтернативные концовки

Не все баги доживают до исправления. Иногда они умирают раньше:

* Rejected (Отклонен): Разработчик считает, что это не баг, а «фича» (feature). Или вы неправильно поняли требования. * Duplicate (Дубликат): Такой баг уже кто-то завел до вас. * Won't Fix (Не будем чинить): Баг признан, но его исправление слишком дорогое или рискованное, а влияние на пользователей минимально. Например, сайт некорректно отображается в браузере Internet Explorer 6.

Культура общения в баг-репорте

Помните, что баг-репорт — это не жалоба на разработчика. Не используйте эмоциональную окраску.

* ~~Плохо:~~ «Криворукий код, опять ничего не работает!» * ~~Плохо:~~ «Срочно почините!!!» * Хорошо: «Функция экспорта в PDF вызывает падение приложения».

Ваша задача — не обвинить, а проинформировать. Вы и разработчик — в одной лодке, и у вас одна цель: качественный продукт.

Заключение

Умение писать качественные баг-репорты — это визитная карточка QA-инженера. Хороший отчет снимает вопросы, плохой — порождает новые.

Краткое резюме урока:

Сначала локализуйте проблему (найдите минимальные шаги), потом пишите отчет.

Заголовок должен отвечать на вопросы: Что? Где? Когда?

Всегда указывайте Ожидаемый результат, чтобы доказать, что это ошибка.

Различайте Серьезность (техническое влияние) и Приоритет (бизнес-срочность).

Жизненный цикл бага заканчивается не когда разработчик сказал «готово», а когда вы это проверили.

В следующей статье мы поговорим о видах тестирования, которые выходят за рамки простого нажатия кнопок: регрессионное, смоук-тестирование и санитарное тестирование.

Психология тестирования: конструктивная коммуникация с разработчиками и защита качества

В предыдущей статье мы детально разобрали жизненный цикл дефекта и научились писать идеальные баг-репорты. Казалось бы, дело сделано: ошибка найдена, задокументирована и отправлена в разработку. Но в реальности именно на этом этапе часто начинаются самые большие сложности.

Тестирование — это не работа с документами или кодом. Это, в первую очередь, работа с людьми. Даже самый профессиональный отчет об ошибке может быть проигнорирован, если между тестировщиком и разработчиком выстроена стена непонимания.

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

Синдром гонца с плохими новостями

Исторически сложилось так, что отношения между разработкой (Dev) и тестированием (QA) часто носят напряженный характер. Чтобы изменить это, нужно понять психологическую подоплеку конфликта.

Разработчик — это созидатель. Он тратит часы и дни, выстраивая сложную логическую структуру, решая нетривиальные задачи. Его код — это его творение.

Тестировщик в глазах разработчика часто выглядит как разрушитель или критик. Вы приходите и говорите: «Твоя работа сделана плохо. Здесь ошибка, и здесь тоже». Никто не любит, когда ему указывают на ошибки, особенно публично (в баг-трекере).

!Иллюстрация перехода от конфронтации к сотрудничеству между QA и Dev.

Эффект когнитивного диссонанса

Когда разработчик пишет код, он держит в голове «Счастливый путь» (Happy Path). Он уверен, что логика верна. Когда вы приносите баг, в его сознании возникает конфликт: «Я хороший специалист, но мой код не работает».

Первая защитная реакция психики — отрицание. Отсюда рождаются знаменитые фразы: * «У меня всё работает». * «Это не баг, это фича». * «Пользователь никогда так не сделает».

Ваша задача как профессионала — обойти эти защитные механизмы и перевести диалог в конструктивное русло.

Принципы конструктивной коммуникации

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

1. Атакуйте проблему, а не личность

Это самое важное правило. Никогда не переходите на личности. Ошибка в коде не делает человека плохим программистом.

Сравните две фразы:

* Деструктивно: «Ты опять сломал авторизацию! В твоем коде ошибка». * Конструктивно: «В последней сборке авторизация работает некорректно. При вводе верного пароля система выдает ошибку».

В первом случае вы обвиняете («Ты сломал»). Во втором — констатируете факт о системе («Авторизация работает некорректно»). Используйте безличные конструкции. Не «ты допустил ошибку», а «была обнаружена ошибка».

2. Оперируйте фактами, а не эмоциями

Разработчики — люди с техническим складом ума. Они верят логам, скриншотам и цифрам, а не вашим ощущениям.

Если вы скажете: «Сайт как-то медленно грузится, это ужасно», разработчик, скорее всего, проигнорирует это.

Если вы скажете: «Время загрузки главной страницы увеличилось с 1.5 секунд до 5.2 секунд после последнего коммита. Вот график из инструментов разработчика», — это аргумент, с которым невозможно спорить.

3. Не будьте роботом

Не превращайтесь в генератор баг-репортов. Если разработчик сделал сложную фичу, и она работает хорошо — скажите ему об этом!

> «Привет! Протестировал новый модуль оплаты. Очень круто, что ты предусмотрел обработку редких валют, я даже не смог это сломать. Нашел только пару мелких багов в верстке, сейчас заведу тикеты».

Позитивное подкрепление творит чудеса. Если вы приходите к человеку не только с проблемами, но и с хорошими словами, ваше взаимодействие станет намного продуктивнее.

Работа с возражениями: «У меня всё работает»

Фраза «Works on my machine» (Работает на моей машине) — это классика IT-юмора и боль тестировщиков.

Почему так происходит? Среда разработки (локальный компьютер программиста) часто отличается от тестовой среды. У разработчика могут быть установлены специфические библиотеки, другие настройки базы данных или просто более мощное «железо».

Алгоритм действий QA:

Не спорьте. Примите тот факт, что у него действительно всё работает.

Проверьте окружение. Убедитесь, что вы тестируете ту же версию сборки, о которой идет речь.

Очистите кэш. Часто проблема кроется в старых данных, сохранившихся в браузере.

Предоставьте доказательства. Запишите видео с экрана. Видео — лучший аргумент против «у меня всё работает».

Предложите посмотреть вместе. «Давай я подойду (или созвонимся), и я покажу, как я это делаю». Часто в процессе совместного просмотра выясняется, что разработчик нажимал Enter, а вы кликали мышкой по кнопке, и именно в этом разница.

Битва за требования: «Это не баг, это фича»

Иногда разработчик признает поведение системы, но отказывается признавать его ошибкой.

QA: «Кнопка