Баланс между
качеством и дедлайном

Десять вредных советов

Если ты давно мечтаешь, чтобы тестировщиков не воспринимали всерьёз, баги не воспроизводились, а релизы превращались в цирк - эта статья для тебя.
Лови 10 вредных советов, следуя которым ты гарантированно угробишь тестовую документацию (и нервы команды).

вредный баг

1. Никогда ничего не записывай - ты же всё помнишь!

Подумаешь, вчера проверял 8 сценариев в 5 браузерах. У тебя же отличная память. Да и зачем другим знать, что ты уже протестировал? Пусть каждый раз догадываются сами.

2. Тест-план - это для слабаков

Хочешь настоящего экстрима? Начни тестирование без целей, объёма и расписания. Пусть проект живёт своей жизнью, а ты просто проверяй "на глаз".

3. Тест-кейсы - это скучно, проверяй как душа пожелает

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

4. Пиши баг-репорты в стиле “ничего не работает”

Упоминание шагов воспроизведения, окружения и логов - это для зануд. Пусть разработчик сам догадается, в чём проблема и где она воспроизводится. Это же квест!

5. Чек-листы - для тех, кто не доверяет своей интуиции

Ты же профессионал. Проверил пару вещей - и достаточно. Зачем тебе список, по которому можно случайно проверить всё, что нужно?

6. Никаких отчётов! Пусть команда узнаёт о результатах тестирования из слухов

Они же сами поймут, что всё работает. Или не работает. Ну а если баги ушли в прод - это повод встряхнуться!

7. Названия тестов? Да пусть будут "Test1", "Test2", "123"

Главное - чтобы ты сам понимал. Ну или когда-нибудь вспомнил. А ещё лучше - пусть каждый новый тестировщик начинает с чистого листа.

8. Не обновляй документацию - пусть живёт прошлым

Если требования поменялись, оставь тест-кейсы как есть. Это же история проекта, её нельзя переписывать!

9. Забудь про трассировку требований

Связь между тестами и требованиями? А зачем? Это только мешает свободному творчеству. Логика - враг хаоса.

10. Вся документация - в голове (или в устных обсуждениях в курилке)

Настоящий мастер - тот, кто не нуждается в документации.
А если завтра тебя собьёт автобус… Ну, не тебе же потом разбираться.

Что будет, если всё это соблюдать?

  • Никто не знает, что протестировано
  • Баги постоянно воспроизводятся «только у клиента»
  • Новым тестировщикам проще всё выкинуть и начать заново
  • Разработчики тебя ненавидят
  • А ты сам не понимаешь, что проверял две недели назад

А если серьёзно?

Хорошая тестовая документация - это не бюрократия. Это инструмент выживания в сложном проекте. Она помогает:

  • Делать тестирование прозрачным
  • Экономить время и нервы
  • Делать знания доступными для команды
  • Снижать хаос и уровень боли на релизах

Хочешь быть уважаемым и полезным QA-инженером? Забудь эти вредные советы.
А лучше - распечатай, повесь у монитора и делай наоборот.