Что пишут в блогах

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Организационные пороки QA/тестирования
04.02.2021 00:00

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

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

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

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

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

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

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