Компромисс 2: Важно не количество ошибок, а их качество

А вы когда-нибудь дрючили продукт с целью обнаружения как можно большего количества ошибок? И вашему начальнику нравилось, что вы находите столько много ошибок?

А что было потом? Какой процент этих ошибок был исправлен? Стоило ли тратить время на их поиск? Вы же, наверняка, придумывали всякие экзотические сценарии или какие-нибудь абсолютно невероятные входные данные или условия, отвлекаясь от главной своей цели - предоставить актуальную информацию о состоянии продукта. Я практически уверен, что в конце такого тестирования у вас было ощущение, что вы ещё не всё протестировали и продукт ещё не готов к выпуску. Давайте посмотрим на некоторые утверждения:
- Время не резиновое
- Всех ошибок не найти
- Конечному пользователю все равно, как много вы нашли других не интересных ему проблем, если есть хотя бы одна, которая ему мешает.
- Количество обнаруженных дефектов не повышает качество продукта
- Придумайте ещё что-нибудь сами :)
А теперь делайте выводы. У меня нет готового рецепта на все случаи, а есть только вопрос: как повысить свою эффективность в конкретных условиях? Поскольку условия бывают разные, то и рецепты могут быть совершенно противоположными.

Компромисс 1: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

Поскольку я, по жизни, не очень люблю компромиссы и всякого рода универсальные решения типа плащ-кроватка, они мне бросаются в глаза. И, стоит отметить, в тестировании таких компромиссов хватает, о чем и хочется открыть очередную серию заметок. Кстати, я ещё обожаю Компромиссы Сергея Довлатова.

Итак, компромисс первый: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

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

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