Home

Автор: Санжит Хохар (SunjeetKhokhar)
Оригинал статьи
Перевод: Ольга Алифанова

По моему опыту, пороки QA и тестирования, как и пороки кода, попадают под четыре больших категории первопричин:

1. Апатия – игнорирование тестирования как функции/ремесла.
2. Гонор – слепые пятна, вызванные талантом или позицией, которые ведут к ошибкам в принятии решений.
3. Невежество – никто не показал, как сделать лучше, или же членам команды не хватает определенного (тестировщицкого) образа мышления.
4. Беспомощность – когнитивное истощение из-за постоянной борьбы с незрелыми практиками разработки или организационной дисфункцией.

Я составил список из цитат и виданных мною "пороков", с которыми я столкнулся в своей карьере тестировщика – включая те, которым поддавался сам!

Дополняйте в комментариях, спасибо заранее.

Уверен, что что-то уже известно как стереотип, но, может, что-то покажется вам новеньким (и, следовательно, от этого стоит держаться подальше).

• Пользователи не будут использовать это "так".
• Ты слишком рано начинаешь тестировать.
• (последствие) Ты тестируешь слишком поздно.
• Зачем тебе присутствовать на дизайн-сессии?
• Зачем тебе присутствовать на код-ревью?
• Зачем тебе присутствовать на сессии сбора требований?
• Попробуй-ка, сломай это!
• (последствие) На это еще ни один пользователь не жаловался!
• Смотри (показывая на IDE), оно работает.
• Попробуй сейчас. (стук по клавиатуре) Попробуй сейчас (стук по клавиатуре) ………… Попробуй сейчас (стук по клавиатуре).
• Оно что, сломалось?
• Когда оно работало в последний раз?
• Я ничего не менял?
• Откуда я знаю, что поменялось?
• Как я тебе скажу, какие тесты писать, это твоя работа.
• Это большое изменение, но мы были вынуждены внести его за один присест!
• Как посмотреть ошибки бэкэнда?
• Что означает "Неизвестное исключение, обратитесь к системному администратору"?
• Откуда я знаю, связаны ли все эти ошибки?
• Это регулярно происходит, но я не могу воспроизвести это по желанию.
• Окей, понятия не имею, что еще сломано.
• Это всегдааааа ломается.
• Мы всегда должны брать три дня на то, чтобы повторно протестировать все на свете.
• Я "ручной" тестировщик.
• (последствие) Я "автоматизатор".
• Каждый разработчик должен иметь большой опыт автоматизации тестирования.
• (последствие) Мам, смотри, тестировщики не нужны!
• (последствие последствия) {этот подход/технология} заменит тестировщиков
• Нет, НЕ ПЫТАЙСЯ менять этот конфигурационный файл.
• (последствие) Зачем тебе доступ к процессу поставки ПО?
• В этом релизе оно станет быстрее.
• Протестируй это, пока я документирую дизайн.
• (последствие) Задокументирую, если время будет.
• Я зарефакторю это в один прием.
• Это вообще никогда не входило в задачу.
• Почему у нас всего 157 кейсов на проект?
• (последствие) 100% тестов прошли!
• (последствие последствия) Было 100%, но сейчас прошло 87%
• (последствие последствия последствия) Если мы упадем ниже 75%, мы не можем релизиться.
• Это окружение только для разработки.
• (последствие) На проде будет "иначе".
• "Пока не волнуйся за интеграцию" (команда 1) ………………….. (2 недели после релиза) ……Команда 2: "Никто не сказал нам об этих изменениях".
• Виновата наверняка база данных.
• (последствие) Виноваты наверняка разрешения.
• (последствие последствия) Должно быть, это известная проблема.
• Это мои автотесты, они никому не нужны в контроле версий.
• (последствие) Код тестов – это не "код прода".
• (последствие последствия) Наша команда поставляет только код приложения.
• Так и выглядит
• (последствие) Так и выглядит тестирование в Agile.
• (последствие последствия) Так и выглядит тестирование в (вставьте новую модную методологию).
• Потому что это Docker!
• (последствие) Потому что это (какая-то новая технология)!