Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье хочу вольно порассуждать о схожести моделей когнитивной деятельности в тестировании ПО и расследовании уголовных дел. Мне кажется, у этих сфер много общего — например, оба процесса представляют из себя исследование результатов неправильного поведения, причин и следствий такого поведения и документирование результатов.

Год назад я получил оффер на должность QA Manual Engineer в inDriver. Но до этого я семь лет расследовал уголовные дела в разных подразделениях правоохранительных органов. За время службы я работал со значительным спектром преступлений: от тяжких против жизни и здоровья до экономических межрегионального характера. На последнем месте работы моя должность звучала так: «Старший следователь СЧ по РОПД СУ МВД по РС (Я)». Если опустить два первых слова, выглядит как ребус.

Сейчас я занимаюсь организацией регрессионного тестирования, написанием мобильных UI-автотестов, а также многим другим, что связано с ускорением доставки новых фич пользователям без потери в качестве продукта.

Начинаем расследование

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

Составляем план действий

Когда мы получаем исходные данные, возникает ситуация информационного разнообразия. Теперь важно составить план действий. Время является нашим главным ресурсом. Вряд ли проверка всех значений от -2147483648 до 2147483647 в поле ввода имени — хорошая идея, чтобы найти дефект. Следователь также не имеет возможности допросить всех жителей города или отправить всю домашнюю утварь на молекулярно-генетическую экспертизу.

Для решения этой проблемы QA применяет техники тест-дизайна — граничные значения, классы эквивалентности, pairwise. Следователь же применяет тактические приемы и комбинации, позволяющие спланировать свои дальнейшие действия максимально эффективно.

Выдвигаем первые гипотезы

Предположим, нам поступило сообщение об убийстве о краше в нашем приложении. Исходя из опыта следователя я знаю, что почти в 90% случаев убийцы тем или иным образом связаны с жертвой (мужья, жены, родственники, друзья, соседи). Так и в приложении — мы руководствуемся знаниями о продукте: скажем, достаем сниффер, проверяем исходящие запросы и получаемые ответы. Пока ничего интересного — у всех членов семьи алиби, а в ответе с сервера «200». Похоже, тут все в порядке.

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

Снимаем логи

Далее мы пытаемся установить все события, предшествовавшие преступлению, чтобы обнаружить какие-нибудь следы:

• Смотрим записи видеокамер.

• Опрашиваем соседей: слышали ли они звуки борьбы, видели ли подозрительных лиц.

• Устанавливаем, с кем созванивался потерпевший незадолго до совершения преступления.

В случае с дефектом мы также собираем следы:

• Снимаем логи в Android Studio или XCode.

• Проверяем логи сервера.

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

Проверяем показания на месте

Предположим, после предъявления доказательств мужчина сознается в совершении преступления. Но расследование на этом не заканчивается. Мы должны убедиться, что именно он совершил данное преступление, а признание вины вызвано раскаянием, а не страхом испортить настроение следователя.

Для этого проводится «проверка показаний на месте», в ходе которой обвиняемый досконально воспроизводит детали преступления и рассказывает об обстоятельствах, которые не могут быть известны непричастному к совершению преступления лицу. Так, найдя стабильный сценарий воспроизведения дефекта, мы убедились, что нашли именно того, кого искали.

Законченное уголовное дело = баг-репорт

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

Устанавливаем причины преступления

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

Также и в случае с тестированием — при обнаружении бага на проде не помешает установить факторы, способствовавшие этому:

• Недостаточное тестовое покрытие.

• Мердж без тестов.

• Плохая постановка задачи.

• Недоработанные требования.

• Непроверенные QA-специалистом corner-кейсы.

• Небольшое количество времени, выделенное на тестирование и разработку.

• Низкая квалификация команды разработки.

• Часто меняющиеся требования.

Заключение

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