Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье хочу вольно порассуждать о схожести моделей когнитивной деятельности в тестировании ПО и расследовании уголовных дел. Мне кажется, у этих сфер много общего — например, оба процесса представляют из себя исследование результатов неправильного поведения, причин и следствий такого поведения и документирование результатов.
Год назад я получил оффер на должность QA Manual Engineer в inDriver. Но до этого я семь лет расследовал уголовные дела в разных подразделениях правоохранительных органов. За время службы я работал со значительным спектром преступлений: от тяжких против жизни и здоровья до экономических межрегионального характера. На последнем месте работы моя должность звучала так: «Старший следователь СЧ по РОПД СУ МВД по РС (Я)». Если опустить два первых слова, выглядит как ребус.
Сейчас я занимаюсь организацией регрессионного тестирования, написанием мобильных UI-автотестов, а также многим другим, что связано с ускорением доставки новых фич пользователям без потери в качестве продукта.
Начинаем расследование
Как расследование уголовного дела начинается с осмотра места происшествия, так и баг-репорт начинается с описания окружения, в котором был обнаружен дефект. Так мы получаем какие-то безусловные данные. А на их основе, применяя дедукцию, знания об окружающем мире или о продукте, можно сузить область исследования, начать планировать дальнейшие действия и строить гипотезы.
Составляем план действий
Когда мы получаем исходные данные, возникает ситуация информационного разнообразия. Теперь важно составить план действий. Время является нашим главным ресурсом. Вряд ли проверка всех значений от -2147483648 до 2147483647 в поле ввода имени — хорошая идея, чтобы найти дефект. Следователь также не имеет возможности допросить всех жителей города или отправить всю домашнюю утварь на молекулярно-генетическую экспертизу.
Для решения этой проблемы QA применяет техники тест-дизайна — граничные значения, классы эквивалентности, pairwise. Следователь же применяет тактические приемы и комбинации, позволяющие спланировать свои дальнейшие действия максимально эффективно.
Выдвигаем первые гипотезы
Предположим, нам поступило сообщение об убийстве о краше в нашем приложении. Исходя из опыта следователя я знаю, что почти в 90% случаев убийцы тем или иным образом связаны с жертвой (мужья, жены, родственники, друзья, соседи). Так и в приложении — мы руководствуемся знаниями о продукте: скажем, достаем сниффер, проверяем исходящие запросы и получаемые ответы. Пока ничего интересного — у всех членов семьи алиби, а в ответе с сервера «200». Похоже, тут все в порядке.
Также мы знаем, что психически здоровый человек не пойдет на убийство, не имея на то причин. Исходя из этого мы от неограниченного круга лиц можем перейти к тем, с кем у потерпевшего были финансовые, рабочие или иные связи. Так и в приложении мы можем выяснить версию, с которой начинает воспроизводиться дефект, и построить гипотезы о том, какие изменения кода могли повлечь его появление.
Снимаем логи
Далее мы пытаемся установить все события, предшествовавшие преступлению, чтобы обнаружить какие-нибудь следы:
Смотрим записи видеокамер.
Опрашиваем соседей: слышали ли они звуки борьбы, видели ли подозрительных лиц.
Устанавливаем, с кем созванивался потерпевший незадолго до совершения преступления.
В случае с дефектом мы также собираем следы:
Снимаем логи в Android Studio или XCode.
Проверяем логи сервера.
В ходе этого обнаруживаем, что незадолго до совершения преступления в квартиру вошел NullPointerException мужчина. Соседи опознали его как ранее осужденного местного хулигана, который регулярно выпивал и держал в страхе весь дом.
Проверяем показания на месте
Предположим, после предъявления доказательств мужчина сознается в совершении преступления. Но расследование на этом не заканчивается. Мы должны убедиться, что именно он совершил данное преступление, а признание вины вызвано раскаянием, а не страхом испортить настроение следователя.
Для этого проводится «проверка показаний на месте», в ходе которой обвиняемый досконально воспроизводит детали преступления и рассказывает об обстоятельствах, которые не могут быть известны непричастному к совершению преступления лицу. Так, найдя стабильный сценарий воспроизведения дефекта, мы убедились, что нашли именно того, кого искали.
Законченное уголовное дело = баг-репорт
Установив все обстоятельства преступления, следователь не занимается устранением этого дефекта. Он оформляет полученные сведения в материалы уголовного дела, составляет обвинительное заключение и передает их в суд. Решение о мере наказания, способе устранения дефекта, либо о признании бага невиновной фичей принимается уже за пределами процесса тестирования.
Устанавливаем причины преступления
С целью профилактики совершения в будущем похожих преступлений, следователь обязан установить обстоятельства, которые поспособствовали его совершению и принять меры. Например, разобраться, почему никто ранее не реагировал на сообщения о хулигане или почему принятые в отношении него меры не помогли предотвратить преступление.
Также и в случае с тестированием — при обнаружении бага на проде не помешает установить факторы, способствовавшие этому:
Недостаточное тестовое покрытие.
Мердж без тестов.
Плохая постановка задачи.
Недоработанные требования.
Непроверенные QA-специалистом corner-кейсы.
Небольшое количество времени, выделенное на тестирование и разработку.
Низкая квалификация команды разработки.
Часто меняющиеся требования.
Заключение
Очевидно, профессии следователя и тестировщика отличаются друг от друга. Даже при наличии схожих моментов, различий все же значительно больше. Но если у вас по какой-либо причине появилось желание кардинально сменить ремесло, то вы можете найти подходящие курсы у нашего партнера это возможно. Даже в абсолютно чуждой сфере можно найти деятельность со схожим майндсетом — и тогда добиться поставленной цели будет немного проще.
