OVA

Почему я пропустил эту ошибку?

Потому что я искал другие ошибки. Тысячи их. А когда в продукте очень много ошибок почему-то очень много времени уходит на его тестирование. Сильно меньше чем когда в продукте мало ошибок. Сильно страдает эффективность тестирования как такового. TDD, CI, Code Review (не отмазки типа "я посмотрел, вроде ок"), Testability, раннее вовлечение пользователей в работу над продуктом, отличные логи, отличный мониторинг работы продукта, никаких головняков с установками и переконфигурацией, хорошие инструменты для тестирования - это может помочь улучшить качество поставляемого на тестирование продукта, но не спасет. Чтобы лучше находить баги, чтобы их было проще диагностировать и чинить - Testability.

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

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

Пропуск ошибок это зачастую не проблема отдела тестирования. Просто очень сложно построить качественный продукт, когда нет хорошей культуры качества. Когда каждый член команды работающей над продуктом не делает все возможное чтобы сделать качественный продукт. Часто это системная проблема. Программист знал что где-то могут быть проблемы, но не посчитал нужным сообщить. Или он написал код, достаточно сложный для того чтобы при последующих изменениях в нем никто не мог понять где же оно рухнет. Или код простой, но этот простой код внутри выстраивается в такие сложные цепочки взаимодействия, что ряд изменений (обычных последнее время) надо делать долго и аккуратно, внося его всюду. И в итоге что-то забывается и код не работает. Это возникает потому что программист нерадивый или потому что над ним сидит менеджер который по самые уши напортачил с планированием или наобещал ге-то с три короба и теперь заставляет команду работать в очень сжатые сроки воспитывая парадигму вида "после нас хоть потоп". Или менеджер жрет время команды на бесполезную активность вроде отчетов которые ему на самом деле не нужны (или он не объяснил команде просто и доступно зачем они нужны и тем самым деморализует ее). Или дурацкие митинги. Или менеджер игнорирует жалобы команды разработки просто говоря что-то вроде "keep going that way"? Или тестировщики занимаются не эффективным тестированием? Может они не видят под носом шаблонов в ошибках? Не могут их хорошо диагностировать и не представляют что как работает и зачем оно нужно коду/проекту/бизнесу? Или они заняты игрой в бюрократию и пишут тонны бесполезной тестовой документации вместо того чтобы тестировать? Или это просто плохие тестировщики которые умеют только жмакать на случайные кнопочки и бить кувалдой по монитору? Или эти тестировщики просто проверили что все что написано в ТЗ продукт делает и успокоились?




Это не спора ради, это я так, дополнить)