На недавней конференции SQA Days в Санкт-Петербурге произошёл один инцидент, который поначалу остался незамеченным. Я не нашёлся сразу, что ответить, лишь улыбнулся в ответ. Но какое-то зерно сомнения проронилось в мой мозг и проросло лишь через несколько дней.

В общем,

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

Вы находите не те ошибки.

Я лишь улыбнулся.

Лишь позже я понял, что именно здесь в корне неправильное.

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

Что такое Quality Assurance

Это чертовски важный момент. Это, чёрт побери, все QA-инженеры должны знать как отче наш.

QA расшифровывается как “Quality Assurance”, то есть - “уверенность в качестве”. Наша первоочерёдная задача не найти все баги. Наша первоочерёдная задача - обеспечить, чтобы оно работало.

Например

Если мы делаем интернет-магазин для продажи телевизоров, задача QA в первую очередь - убедиться, что пользователь может найти телевизор, нажать “Купить” и заплатить деньги. Это - в первую очередь.

То, что при этом баннер съехал, кнопка “Распечатать PDF” открывается в новом окне, кнопка “login” пропадает через раз - это, конечно, ошибки, но они уже второстепенные. Если они есть, будет хреново, конечно, но бизнес будет продолжать работать. А вот если кнопка “Купить” не кликается - пиши пропало, бизнес встал. Это большая разница!

Ну и совсем уж третьесортные “ошибки” - это когда пользователь вбивает в поле “логин” тысячу символов и получает бяку. Да ни один нормальный пользователь никогда так не сделает! А если кто-то и сделает, то пусть и получает свою бяку. Ибо нефиг!

Я не говорю, что все эти второсортные и третьесортные ошибки не надо искать и исправлять. Надо. Но только после того, как вы убедились, что бизнес работает.

Отсюда главный вывод:

1. Ваш первый тест - “зелёный путь”. То есть типичный случай, который приносит прибыль:
   Найти телек - “Купить” - заплатить. Неважно, пишите ли вы автоматические тесты или тестируете вручную. Первый тест - зелёный путь.

   С ним есть одна маленькая проблемка. Это самый скучный тест. Это гарантированный способ находить меньше всех багов в отделе. Это гарантированный способ создать у начальства впечатление, что вы нифига полезного не делаете. Но именно это - первоочерёдная задача QA.

2. Все эти дебильные тесты про “1000 символов в поле логин” - делать надо, только если всё остальное хорошо. И реально больше некуда девать свободное время. То есть практически никогда. Но именно их тестировщики фигачат в каждом релизе в диких количествах, генерируя тонны никому-не-нужных, не приносящих пользы баг-репортов. Эти баг-репорты сжирают ваши ресурсы и отвлекают внимание от по-настоящему серьёзных проблем, которые проскальзывают незамеченными.

Зато это отличный способ находить по 50 багов в релиз и стать лучшим работником месяца. Это называется “локальная оптимизация”, и это лучшее изобретение дьявола.

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

Поэтому я говорю:

Мы не ищем баги

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

In testo veritas!

09.12.14