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