В книжке "Закон малинового варенья" я прочитала еще одну интересную историю. Позволю себе ее кратко перефразировать, сжатая версия в моем исполнении:
Как-то приехал я в одну компанию и предложил такой способ поиска проблемного продукта: на пробковой доске записываем названия всех проектов, потом берем первую жалобу, читаем. Видим в ней название проекта, к которому она относится и втыкаем в пробковую доску кнопку около названия этого проекта. И так идем по всем жалобам = в результате получаем наглядную картину мира (похоже на багтрекер, не правда ли?)
И очень мне помогала эта методика, применял ее везде (как тот самый молоток). Пока однажды не приехал в компанию и не увидел там... Доску для жалоб! Я был смущен, но решил поинтересоваться, указав на нее "Что, проблемы с качеством ПО?", а Заказчик удивленно на меня посмотрел и сказал "Нет, у нас лучшая система по качеству на рынке, а почему вы спрашиваете?".
И немного потом уже я осознал, что наличие "доски жалоб", места для хранения, анализа и диагностики проблем, указывает не на то, что проблемы есть, а на то, что их быстро отлавливают и решают. В итоге проблемы есть как раз у тех, кто не ведет никакой статистики, полагая, что все и так хорошо.
История заставила меня задуматься и вспомнить пример из собственной практики, за которым не надо далеко ходить...
У нас есть система, в которой все хорошо
"Доска жалоб" присутствует давно в виде JIRA, в ней всегда можно проконтролировать, на каком из подпроектов больше всего задач с разными типами. Где наиболее активные пользователи, которые задают много вопросов? На что они жалуются чаще всего? Что неудобно? В каком компоненте системы больше всего ошибок? И т.д. и т.п., я думаю, с системой баг-трекенга все знакомы и вы ждете от меня чего-то еще... И мне есть что сказать!
На все фичи пишутся автотесты, поэтому при проверке задачи ручному тестированию уделяется мало внимания. Оно помогает лишь поисследовать, подкинуть новых идей для автотестов "а если сделать еще вот так?" ну и просто проверить интеграционно. А то, сами знаете, как бывает - все тесты проходят, приложение падает. А почему? А потому что тесты пишутся на моках и не всегда могут словить ошибку.
Тем не менее, регрессия находит очень мало ошибок. Волшебный мир, где пони, радуга и все такое
Хотя для некоторых это не пони с радугой, а просто светлое будущее!
Но... Система сложная (по внутренней логике), а с каждым релизом фич становится все больше и больше...
Далее следует регрессионная спираль смерти!
Как она проявилась у нас, с таким современным подходом?
Вначале все было хорошо. Конечно, не спорю, иногда находятся баги в PROD, но, к счастью, очень редко + оперативно хотфиксятся. Но само состояние системы (а в нашем случае - базы) не поддается сомнению. Ведь в базе созданы всяко-разные уникальные индексы, чтобы предотвратить неконсистентности, которые система не сможет обработать.
Именно эта уверенность нас и подвела.
Как-то раз у одного из Заказчиков возникла проблема, обновление карточки упало с ошибкой. Стали разбираться - а разбираться пришлось долго, собирать логи, делать селекты из Базы... С грехом пополам разобрались, нашли верхушку айсберга, исправили "проблему".
Прошло какое-то время, БАХ, опять ошибка. Опять долгий анализ, который или стоит нам много денег на выезд к Заказчику, чтобы посмотреть самим все данные или приходится мучить администратора на стороне Заказчика, рассказывая, что где откопать и нам переслать.
В итоге в ходе ретроспективного анализа мы пришли к выводу, что "баги есть всегда" и пора бы с этим смириться. Но зачем заставлять Заказчика каждый раз страдать? Да и ответственный за Заказчика QA каждый раз тратит много времени на диагностику проблемы.
Так появилась
утилита диагностики. Собственно говоря, как раз сейчас на сайте
http://software-testing.ru/ идет активное обсуждение,
зачем тестировщики вообще программируют и пока лидирует ответ "по мелочеве, чтобы облегчить себе жизнь".
Утилита была как раз такой мини-программой, которая позволяла указать на входе "собери мне то, то и то" и выдать на выходе zip-архивчик, который позволит QA разобраться в проблеме быстрее.
ЖИТЬ СТАЛО ГОРАЗДО ПРОЩЕ!
Это я говорю сейчас, спустя год, как она у нас появилась
Оглядываюсь назад и не понимаю, как мы жили без нее раньше?
Итак, даже в идеальном мире нашлись проблемы, которые были вначале незаметны, потом стали раздражать, а потом превратились в #жизньболь, что внезапно
привело к оптимизации! Еще раз поражаюсь необычайно глубокой мысли ребят из Google "если у вас есть нехватка ресурсов - это хорошо!".
Так вот, мы усовершенствовались и если раньше все было хорошо, то стало вообще зашибись. Ошибки у нас, если и возникают, то очень сложные и хитрые (легкие отлавливаются еще на этапе коммитов по задаче). А теперь их стало легко диагностировать, появился накопленный опыт по временному обходу проблем, быстрому решению и анализу "а как сделать так, чтобы это не повторялось"...
Вау, все хорошо? Как бы не так...
Как я уже писала выше, наша самонадеянность нас и погубила. Когда видишь код не в первый раз и даже не в двадцатый, глаз замыливается. Смотришь на новые фичи, ошибочно полагая, что все базовое давно и прочно проверено и проблем там быть не может (иначе они бы давно всплыли).
И вот опять ошибка. С помощью утилиты диагностики определить причину было очень легко, но вот поверить в нее намного сложнее. Ведь она шла в разрез с установкой "ну уж ТАМ то проблем быть не может". Решение "пофиксить баг" тут не пройдет, надо копать глубже, искать его корни, а главное - поразмыслить, если это выстрелило у одного Заказчика, не случится ли это снова у другого?
Для проверки этой теории были написаны скрипты-чекеры на поиск неконсистентностей в базе. Причем не только того случая, который выстрелил, но и всех окололежащих, несмотря на громкие возмущения разработчиков "нет, ТАК точно быть не может!".
Таким образом, мы стали искать проблемы
там, где их нет. И это дало свои результаты! Конечно, большинство чекеров выстрелило впустую у большинства Заказчиков. Некоторые скрипты оказались неправильно написаны и дали ложное срабатывание. А некоторые указали на проблемы, которые уже есть и удивительно, как еще ничего из-за них не сломалось.
Теперь, когда возникает какая-то проблема, мы сразу рассматриваем ее с точки зрения "как это может проявиться у других Заказчиков, как это найти и как поправить". Ну и, конечно же, стандартный ретроспективный анализ "как сделать, чтобы такое в принципе больше не повторялось".
Подведем небольшие итоги:
Система баг-трекинга нужна! Это первый шаг на пути к идеальному миру и такому же ПО. Собирая жалобы пользователей и анализируя их, вы можете сократить количество ошибок в дальнейшем.
Но не останавливайтесь на этом! Если проблем нет, ищите их! Даже там, где их и быть не может. И пусть ваши чекеры сработают вхолостую, но "нулевой" результат - тоже результат! Вы будете спать спокойно, точно зная, что у ваших Заказчиков все хорошо.
И не потому, что вы все проверили на своих тестовых стендах, а потому, что вы все проверили
на реальных стендах. Вы искали и ничего не нашли. А если вдруг у Заказчика возникнет хотя бы намек на проблему, вы узнаете об этом первым, все найдете, устраните и снова будете спать спокойно
Таким образом, нет предела совершенству! В том числе и в обеспечении качества! Это мне напоминает уже другую книгу,
Экстремальный тайм-менеджмент. Там молодой человек оценил свои навыки как n % от 100, допустим, он сейчас на уровне в 20% от идеала. Далее он поставил себе цели, как достичь идеала и расписал, что нужно делать для достижения этих целей.
Достигнув цели, однако, он не сказал "ну все, я совершенен". нет (ну, может, он бы и сказал, но верный друг направил его по пути истины). Он сказал "ок, то, что было 100% 3 месяца назад, теперь лишь 15-20% от идеала. Так что вперед, разрабатываем новый план по достижению следующей ступеньки!".
Нет предела совершенству, тестируйте, диагностируйте, анализируйте... И никогда не забывайте, что на продакшен лучше перебдеть, чем недобдеть!
Приходится сидеть в двух чатах, так как в скайпе все студенты... Это все грустно и печально, Но! С другой стороны, это повод освежить рубрику «панбагон», ведь в этой 
