Почему мы пропускаем ошибки?

Автор: Наталья Руколь

Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?







Читать дальше

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

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

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

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

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




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

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

Подписываюсь под каждым словом ;)

Только при этом важно понимать, что условия, в которых мы работаем - это факторы, влияющие на наш процесс, их важно учитывать и ИСХОДЯ ИЗ НИХ стремиться к максимуму. Естественно, что эти условия являются для того самого максимума ограничивающими - но иногда не так уж и сильно, как нам кажется.

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

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

Если это возможно - то да. Если это не возможно, или по крайней мере не сразу - эффективнее подстраиваться под текущий процесс, и уже выполняя СВОЮ работу на отлично, стараться улучшить работу проекта в целом.

Но это естественно ИМХО :)

А сообщать о потенциальных и очень даже актуальных проблемах и дефектах на проекте разве не наша работа?

А сообщать о потенциальных и очень даже актуальных проблемах и дефектах на проекте разве не наша работа?

Наша, конечно наша. Просто одного сообщения, как показывает практика, обычно недостаточно :) А пока запущена капательная на мозг функция, с регулярным анализом рисков, предложениями, ROI и прочей бронетехникой, которая может наконец-то убедить другие группы в необходимости дехаотизировать их работу, нам всё так же нужно работать над своей :) То есть то, что у всех вокруг всё плохо, это очень веский повод пинать и улучшать всё вокруг - но отнюдь не веский повод факапить свои собственные задачи и снижать требования к себе.

Но как мне кажется, то, что мы сейчас обсуждаем - это религия и жизненая позиция. То есть называть какой-то подход "правильным" лично я не рискну, просто рассказываю о своём подходе. При этом ни капельки не претендую на его "правильность"! :)

Собственные задачи факапить не надо, конечно же. С другой стороны плохой процесс как правило приводит к тому что возникают задачи из категории "а давайте погреем воздух". Т.е. бессмысленные по своей сути задачи, которые, в итоге, ничем хорошим не закончатся. Например плохая автоматизация, которая обычно аукается сильно в минус по ROI хорошо если через годик-два, а все остальное время работает в ноль или в легкий плюс (причем зачастую просто потому что большая часть тестировщиков перестала заниматься ерундой). Но это тренд а с ним бороться трудно, тем более что за такую магию многие готовы платить.

А чтобы отбрыкиваться от таких задач надо обладать опытом/знаниями, которых зачастую нет, потому как за свои 2-3-5 лет в тестировании многие просто не видели никогда в какой адочек это все может превратиться или не осознавали что за адочек творится вокруг.

С условиями фишка такая -- вы сообщили о "дефекте в условиях", и ждёте, пока его исправят.
Но пока не исправили -- работать-то всё равно надо. Поэтому приходится искать воркэраунды.

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

)))))
Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого



Молитва немецкого богослова Карла Фридриха Этингера (1702—1782).

В справочниках цитат и изречений англосаксонских стран, где эта молитва очень популярна (как указывают многие мемуаристы, она висела над рабочим столом президента США Джона Кеннеди), ее приписывают американскому теологу Рейнхольду Нибуру (1892—1971). С 1940 г. она используется обществом «Анонимные алкоголики», что также способствовало ее популярности.

С условиями фишка такая -- вы сообщили о "дефекте в условиях", и ждёте, пока его исправят.
Но пока не исправили -- работать-то всё равно надо. Поэтому приходится искать воркэраунды.

Почему ждем? Мы же решения не принимаем, так что ждать тоже смысла нет. Наша работа предоставлять информацию о рисках и проблемах. И в этом плане memory leak это точно такая же проблема и точно такой же риск как и изъяны в рабочем процессе. Проблемы с Testability могут жрать не меньше времени чем регулярно падающая установка продукта. Про игнорирование постоянно повторяющихся шаблонов дефектов и проблем порождаемых многочисленными заплатками на них я вовсе молчу. И как правило никто не будет счастлив если я заберусь в код и начну себе хуки там делать для тестирования или просто сяду и перепишу (хотя мне так уже приходилось делать я все еще не вижу в этом ничего хорошего). И я не иду править код который приводит к утечкам памяти. Точно так же не пойду делать за менеджера/аналитика/архитектора/кого-то-еще-с-красивым-названием-должности его работу.

Мы можем тестировать быстрее, но...
Мы можем тестировать более эффективно, но...
Мы можем сообщать более качественную информацию о дефектах, но...

Если все заинтересованные лица в курсе и их это устраивает, то вопросы "почему вы пропустили этот баг?" по меньшей мере странные. Если не в курсе - надо им помогать.