В отрасли разработки ПО уже давно является обыденным, что разработчики и инженеры по обеспечению качества (QA) находятся в постоянном конфликте. Мы настолько привычно воспринимаем такое положение вещей, что многие организации считают, что так и должно быть. Они верят, что конфликт интересов двух сторон весьма выгоден, поскольку QA-инженеры, с одной стороны, требуют от разработчиков хорошего качества разрабатываемого кода, а разработчики, с другой стороны, оказывают встречное давление на QA-инженеров, чтобы те не препятствовали скорейшему выпуску продукта, опутывая их многочисленными тестами.
Эрик Фогг (Erik Fogg) на страницах портала DevOps.com рассуждает о том, какими средствами можно прекратить “непримиримое противостояние” двух сторон.
Разработчики заинтересованы в том, чтобы создавать и отправлять в продуктив как можно больше кода. К этому их подталкивают ключевые показатели эффективности, которые в большинстве своём завязаны на скорость: время выхода на рынок, длительность спринта и т.п.
А теперь давайте посмотрим на мотивацию инженеров по контролю качества. Думаете, что самой важной целью для QA-инженеров является обеспечение качества, которое находится в противоречии со скорейшим временем вывода продукта на рынок (поскольку на обеспечение гарантий качества кода требует много времени и ресурсов)? На самом деле, главный интерес команд инженеров QA в том, чтобы на них не возложили вину за неудачу с продуктом.
Причина, по которой минимизация возможных обвинений является приоритетной задачей для QA-инженеров, заключается в том, что в области контроля качества существует общее мнение, что ошибки всегда будут поступать в продуктивную среду, несмотря ни на что. Продукт, вероятность отсутствия ошибок в котором стремится к 100%, будет готовиться к выпуску в свет годами, а не неделями, и поэтому будет экономически нежизнеспособным. QA-инженеры отдают себе отчёт в том, что проблемы будут в любом случае, с ними так или иначе придётся иметь дело. Поэтому задача сводится к тому, чтобы продемонстрировать, что сделано было всё возможное, чтобы предотвратить эти проблемы. Отсюда желание написать как можно больше тестов, чтобы свести к минимуму количество не найденных ошибок, которые можно было обнаружить. Но поскольку невозможно написать бесконечное количество тестов, QA-инженеры должны определить приоритеты областей тестирования.
И здесь команда контроля качества не имеет никакой вводной информации, с помощью которой можно было бы расставить приоритеты. По сути, это игра в угадывание. Да, она может быть интеллектуальной, основываться на опыте и знаниях, предположениях, но не на чётком понимании, что же действительно нужно клиентам. Ваша стратегия контроля качества превращается в вечный спор между разработчиками и инженерами по QA. Разные организации разрешают этот спор по-разному. Есть компании, где вообще не проводится сквозное тестирование разрабатываемого продукта. Такие компании ориентированы на скорость выпуска кода. В других команиях, наоборот, проводится огромное число тестов. Порой, требуется два дня, чтобы запустить регрессионный цикл. В первом примере, где извечный спор выиграли разработчики, компании принимают на себя значительную долю риска при развёртывании. Там же, где QA-инженеры перетянули одеяло на себя, компании не желают расставаться с чувством безопасности, которое дают им тысячи тестов, жертвуя скоростью.
Организации тратят немало ресурсов впустую, сжигая их в междуусобной борьбе функциональных колодцев – в том числе, между разработкой и контролем качества. Это довольно распространённая управленческая проблема. Кажется, что нет конца и края этому противостоянию. Однако, можно представить себе такое будущее, в котором и разработка, и контроль качества живут в гармонии. Путь к урегулированию этого конфликта – переориентировать мотивы и цели обеих сторон. Очевидно, что два отдела, работающие вместе для достижения общей цели, будут работать лучше, чем два отдела, у которых есть разнонаправленные интересы. Такое выравнивание требует наличия подхода, стандарта, согласно которому мы определяем, какие тесты важны, а какие – нет. Стандарт должен базироваться на объективных вещах, а не на мнениях.
При определении приоритетов того, что нужно тестировать, необходимо понимать, что является наиболее важным для пользователей. Не мнения и оценки, а объективное знание требований пользователей. И вместо того, чтобы заставлять инженеров из отдела контроля качества угадывать, что же важно для пользователей, а что нет, почему бы просто не дать возможность пользователям сказать об этом?
Машинное обучение открыло возможность привнести объективность в тестирование. Анализируя реальное поведение пользователей разрабатываемого вами приложения, продукта, вы можете расставлять приоритеты и ориентировать ваш набор тестов на то, что действительно важно для пользователей. Вы объективно будете знать, что тестировать, основываясь на реальном поведении пользователей, вы будете находить больше багов, вы будете обнаруживать их гораздо раньше, с меньшим количеством тестов, чем если бы вы придумывали их сами, основываясь на своих оценках. Качество вашего кода значительно улучшится без необходимости создавать ненужные тесты, которые засоряют отчётность в JIRA и конвейеры развертывания. Выигрывают обе стороны!
Использование такого подхода приводит к тектоническим сдвигам и в тестировании новых функций. Разрабатывая их, мы пока не понимаем, что именно важно для пользователей, потому что не знаем, как они собираются их использовать. А как тогда их протестировать? В ближайшем будущем технологии машинного обучения и автономного тестирования смогут решить эту проблему просто за счёт использования накопленного опыта. Хотя мы и называем многие вещи “новыми”, но по-настоящему новые вещи редко появляются в мире. Особенно это касается пользовательских интерфейсов. Интерфейсы должны быть похожи на другие интерфейсы. Они должны быть интуитивно понятны для любых пользователей. Они должны быть уже достаточно знакомы и привычны, чтобы использовать их без необходимости их переобучения и привыкания.
Технологии машинного обучения и автономного тестирования могут легко сравнивать новые функции с наборами функций, которые ранее уже использовались в других приложениях. Когда наборы данных похожи, например, UI, страницы входа, страницы оформления заказа и т.п., вы можете достоверно предположить, как люди будут их использовать, и использовать эти данные для создания новых тестов. Новые тесты не будут идеальными, но они будут намного более точными, чем те, что создавались QA-инженерами на основе их лучших догадок и озарений.
Представьте себе будущее, в котором ваши пользователи постоянно выдают обратную связь о том, что необходимо протестировать, а накопленный опыт тысяч других приложений, которые имеют схожую функциональность, доступен для анализа. Этот массовый коллективный опыт, который раньше невозможно было создать, теперь может использоваться для оценки того, как должны выглядеть ваши наборы тестов. Собственно, противостояние между разработчиками и QA-инженерами на этом должно закончиться, потому что стратегия тестирования будет выровнена между ними, и не будет оснований для каких-либо споров о том, что нужно тестировать, а что нет.
Теперь у вас есть единая команда, обладающая объективным, основанным на конкретных данных, балансом между скоростью разработки и временем, затрачиваемым на тестирование, гораздо большая уверенность в том, что разработка может быстро выпускать код, обеспечивая при этом должное качество. Обе стороны могут мирно сосуществовать и, наконец, работать как одна команда с единой миссией.
