Как не переборщить с контролем качества?

Старинный вопрос, наряду с непрекращающейся войной между инженерами ПО и QA-инженерами, где идёт вечная борьба между теми, у кого горят глаза и теми, кто обеспечивает практическую часть.

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

Важно понимать, что относительно разработки ПО, QA-инженеры не стремятся усложнить вам жизнь и часто с радостью помогают устранить недостатки…ну, в большинстве.

Инженер ПО также не ленится проверять все потенциальные пути, по которым может или не может пойти пользователь. При построении ПО, вполне естественно представлять только то, как что-либо должно использоваться.

Как и во многом другом, важен баланс. Важно сбалансировать требования QA с возможностями разработки и стандартами архитектуры. Дело в том, что чрезмерное увлечение тестированием продукта и «обеспечением качества» может привести к застою продукта и далекой от идеала скорости разработки.

Помню, как в самом начале карьеры, мой, на тот момент, CEO, поведал мне о важности выпуска первой версии. Хоть я и согласился с этим убеждением, мне потребовалось время, чтобы обдумать реальную пользу и суть данного совета.

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

Я попался на удочку двух моих самых нелюбимых практик в современной разработке ПО.

• Разработка через исполнение
• Ошибка нирваны

Разработка через руководителя

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

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

Как не прийти к такому финалу? Создайте минимальную версию вашего продукта и отправьте её. Предоставьте MVP (продукт с минимальным функционалом) или любую другую солидную аббревиатуру, которая подразумевает минимальную презентацию продукта на первых этапах.

После того, как вы это сделаете, начинайте работать над получением обратной связи, используйте аналитику, отзывы клиентов, пользовательское тестирование и любой другой инструмент, который вам подходит. Главное, собирайте ДАННЫЕ.

«Если у нас есть данные, то смотрим на них. Если всё, что у нас есть – мнение, то остановимся на моём». — Джим Барксдейл, бывший CEO компании Netscape

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

Ошибка нирваны

Ошибка нирваны (также известное, как ошибка идеального решения) чаще всего встречается с цитатой «лучшее – враг хорошего» — Вольтер.

В разработке ПО, проявляется в том, что перед выпуском продукта, инженеры часами напролёт выискивают баги, считая, что продукт всё еще не идеален.

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

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

Данные об использовании

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

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

Заходит в бар QA-инженер. Заказывает пиво. Заказывает 0 пива. Заказывает 99999999999 пива. Заказывает ящерицу. Заказывает -1 пиво. Заказывает абвлдрлвды.

Заходит первый реальный клиент и спрашивает, где уборная. Бар полыхает огнём, убивая всех.

Более того, если вы затормозите время выхода продукта на рынок, а затем получите данные уже после запуска «идеального» продукта, будет уже поздно что-то исправлять. Сбор этих данных на раннем этапе дает возможность изменить план-график по разработке ПО. Либо в случае потенциальных багов, эти данные помогут инженеру ПО сначала работать над наиболее насущными проблемами. Те проблемы, с которыми сталкивается большинство вашей пользовательской базы, должны решаться гораздо раньше, чем какая-нибудь надоедливая, трудно воспроизводимая ошибка, затрагивающая одного пользователя.

Защитное проектирование

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

• У подъемника (лифта) есть тормоза, установленные подальше от тормозных колодок под натяжением тросов, благодаря чему, в случае обрыва троса немедленно срабатывают тормоза и подъемник не падает.
• Во многих бортовых радиоэлектронных системах используются резервные системы для одновременного выполнения одних и тех же вычислений, что позволяет выявить наличие неисправности в датчиках, системах или ПО.
• Системы контроля за переключением светофоров отслеживают неисправности или несостыковки в сигналах, чтобы вместо опасных несовпадающих сигналов, отображать сигнал ошибки.

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

Конечно, это не значит, что кто-то хочет, чтобы его ПО давало сбой. Никому это не нужно. И никто намеренно не создаёт заранее провальный код. По крайней, мере, в трезвом состоянии. Нам важно знать, есть ли сбой в коде, насколько он значителен и распространён, чтобы понимать, насколько быстро и точно можно решить этот вопрос.

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

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

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

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

Ошибайтесь быстро. Ошибайтесь часто. Исправляйте быстрее.

Оригинал статьи: https://medium.com/@ashdavies/how-much-qa-is-too-much-qa-c5a25c9b9bcb