понедельник, 7 июля 2014 г.

Диагностировать проблемы никогда не рано!

В книжке "Закон малинового варенья" я прочитала еще одну интересную историю. Позволю себе ее кратко перефразировать, сжатая версия в моем исполнении:

Как-то приехал я в одну компанию и предложил такой способ поиска проблемного продукта: на пробковой доске записываем названия всех проектов, потом берем первую жалобу, читаем. Видим в ней название проекта, к которому она относится и втыкаем в пробковую доску кнопку около названия этого проекта. И так идем по всем жалобам = в результате получаем наглядную картину мира (похоже на багтрекер, не правда ли?)



И очень мне помогала эта методика, применял ее везде (как тот самый молоток). Пока однажды не приехал в компанию и не увидел там... Доску для жалоб! Я был смущен, но решил поинтересоваться, указав на нее "Что, проблемы с качеством ПО?", а Заказчик удивленно на меня посмотрел и сказал "Нет, у нас лучшая система по качеству на рынке, а почему вы спрашиваете?".

И немного потом уже я осознал, что наличие "доски жалоб", места для хранения, анализа и диагностики проблем, указывает не на то, что проблемы есть, а на то, что их быстро отлавливают и решают. В итоге проблемы есть как раз у тех, кто не ведет никакой статистики, полагая, что все и так хорошо.

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

У нас есть система, в которой все хорошо Smile :)

"Доска жалоб" присутствует давно в виде JIRA, в ней всегда можно проконтролировать, на каком из подпроектов больше всего задач с разными типами. Где наиболее активные пользователи, которые задают много вопросов? На что они жалуются чаще всего? Что неудобно? В каком компоненте системы больше всего ошибок? И т.д. и т.п., я думаю, с системой баг-трекенга все знакомы и вы ждете от меня чего-то еще... И мне есть что сказать! Wink ;)

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

Тем не менее, регрессия находит очень мало ошибок. Волшебный мир, где пони, радуга и все такое Smile :)

Хотя для некоторых это не пони с радугой, а просто светлое будущее!


Но... Система сложная (по внутренней логике), а с каждым релизом фич становится все больше и больше...


Далее следует регрессионная спираль смерти!
Как она проявилась у нас, с таким современным подходом?

Вначале все было хорошо. Конечно, не спорю, иногда находятся баги в PROD, но, к счастью, очень редко + оперативно хотфиксятся. Но само состояние системы (а в нашем случае - базы) не поддается сомнению. Ведь в базе созданы всяко-разные уникальные индексы, чтобы предотвратить неконсистентности, которые система не сможет обработать.

Именно эта уверенность нас и подвела.

Как-то раз у одного из Заказчиков возникла проблема, обновление карточки упало с ошибкой. Стали разбираться - а разбираться пришлось долго, собирать логи, делать селекты из Базы... С грехом пополам разобрались, нашли верхушку айсберга, исправили "проблему".

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

В итоге в ходе ретроспективного анализа мы пришли к выводу, что "баги есть всегда" и пора бы с этим смириться. Но зачем заставлять Заказчика каждый раз страдать? Да и ответственный за Заказчика QA каждый раз тратит много времени на диагностику проблемы.

Так появилась утилита диагностики. Собственно говоря, как раз сейчас на сайте http://software-testing.ru/ идет активное обсуждение, зачем тестировщики вообще программируют и пока лидирует ответ "по мелочеве, чтобы облегчить себе жизнь".

Утилита была как раз такой мини-программой, которая позволяла указать на входе "собери мне то, то и то" и выдать на выходе zip-архивчик, который позволит QA разобраться в проблеме быстрее.

ЖИТЬ СТАЛО ГОРАЗДО ПРОЩЕ!

Это я говорю сейчас, спустя год, как она у нас появилась Smile :) Оглядываюсь назад и не понимаю, как мы жили без нее раньше?

Итак, даже в идеальном мире нашлись проблемы, которые были вначале незаметны, потом стали раздражать, а потом превратились в #жизньболь, что внезапно привело к оптимизации! Еще раз поражаюсь необычайно глубокой мысли ребят из Google "если у вас есть нехватка ресурсов - это хорошо!".

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

Вау, все хорошо? Как бы не так...

Как я уже писала выше, наша самонадеянность нас и погубила. Когда видишь код не в первый раз и даже не в двадцатый, глаз замыливается. Смотришь на новые фичи, ошибочно полагая, что все базовое давно и прочно проверено и проблем там быть не может (иначе они бы давно всплыли).

И вот опять ошибка. С помощью утилиты диагностики определить причину было очень легко, но вот поверить в нее намного сложнее. Ведь она шла в разрез с установкой "ну уж ТАМ то проблем быть не может". Решение "пофиксить баг" тут не пройдет, надо копать глубже, искать его корни, а главное - поразмыслить, если это выстрелило у одного Заказчика, не случится ли это снова у  другого?

Для проверки этой теории были написаны скрипты-чекеры на поиск неконсистентностей в базе. Причем не только того случая, который выстрелил, но и всех окололежащих, несмотря на громкие возмущения разработчиков "нет, ТАК точно быть не может!".

Таким образом, мы стали искать проблемы там, где их нет. И это дало свои результаты! Конечно, большинство чекеров выстрелило впустую у большинства Заказчиков. Некоторые скрипты оказались неправильно написаны и дали ложное срабатывание. А некоторые указали на проблемы, которые уже есть и удивительно, как еще ничего из-за них не сломалось.

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

Подведем небольшие итоги:

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

Но не останавливайтесь на этом! Если проблем нет, ищите их! Даже там, где их и быть не может. И пусть ваши чекеры сработают вхолостую, но "нулевой" результат - тоже результат! Вы будете спать спокойно, точно зная, что у ваших Заказчиков все хорошо.

И не потому, что вы все проверили на своих тестовых стендах, а потому, что вы все проверили на реальных стендах. Вы искали и ничего не нашли. А если вдруг у Заказчика возникнет хотя бы намек на проблему, вы узнаете об этом первым, все найдете, устраните и снова будете спать спокойно Smile :)

Таким образом, нет предела совершенству! В том числе и в обеспечении качества! Это мне напоминает уже другую книгу, Экстремальный тайм-менеджмент. Там молодой человек оценил свои навыки как n % от 100, допустим, он сейчас на уровне в 20% от идеала. Далее он поставил себе цели, как достичь идеала и расписал, что нужно делать для достижения этих целей.

Достигнув цели, однако, он не сказал "ну все, я совершенен". нет (ну, может, он бы и сказал, но верный друг направил его по пути истины). Он сказал "ок, то, что было 100% 3 месяца назад, теперь лишь 15-20% от идеала. Так что вперед, разрабатываем новый план по достижению следующей ступеньки!".

Нет предела совершенству, тестируйте, диагностируйте, анализируйте... И никогда не забывайте, что на продакшен лучше перебдеть, чем недобдеть! Wink ;)

Комментариев нет:

Отправить комментарий