<style>.lazy{display:none}</style>Три полезные практики QA в производственной среде

Три полезные практики QA в производственной среде

Многие организации используют методы и средства QA (Quality Assurance) для повышения качества своих продуктов, полагая, что в перспективе эти действия приведут к снижению затрат и росту рентабельности. Согласно последнему отчету World Quality Report, применение контроля качества к производственным процессам все чаще рассматривается как ключ к достижению бизнес-результатов.

Контроль качества в производственной среде – это набор новых методов DevOps, которые направлены на развитие четкого понимания того, какие проблемы на самом деле возникают в процессе производства продукта. Эти методы дополняют (а в некоторых случаях и отменяют) традиционные методы QA.

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

БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"

Предупреждайте о неожиданных сценариях

Каждая команда разработчиков беспокоится о непредвиденных обстоятельствах. Вдруг данные из этой системы окажутся не такими, как мы ожидаем? Что, если это значение равно null? Что произойдет, если пользователи нажмут на это до того, как нажмут на то? Такая неопределенность является естественной частью процесса разработки ПО, учитывая непредсказуемость поведения реальных пользователей, сетей, устройств и других систем. Проблема заключается в том, что эта неопределенность стоит денег.

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

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

if (theData.importantValue !== expectedValue) {
   logger.error(‘Important data had an unexpected value: ’ + theData.importantValue);
}

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

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

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

Ведите журнал аудита

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

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

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

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

[{
   invoiceId: ‘123’,
   time: ‘2017-05-12T10:00:35.123Z’,
   type: ‘loaded’,
   details: { userId: ‘780’, amount: 1000 }
},
{
   invoiceId: ‘123’,
   time: ‘2017-05-13T11:00:35.123Z’,
   type: ‘approval_request_sent’,
   details: { userId: ‘44’, emailAddress: ‘sue@example.com’ }
},
{
   invoiceId: ‘123’,
   time: ‘2017-05-13T11:00:35.123Z’,
   type: ‘approved’,
   details: { userId: ‘77’, amendments: { amount: 445 } }
},
{
   invoiceId: ‘123’,
   time: ‘2017-05-13T15:00:35.123Z’,
   type: ‘scheduled’,
   details: { userId: ‘645’, expectedPaymentDate: ‘2017-05-15T00:00:00.000Z’, p    aymentBatchId: 991 }
}]

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

Представьте себе, если бы журнал аудита выглядел следующим образом:

[{
   invoiceId: ‘123’,
   time: ‘2017-05-12T10:00:35.123Z’,
   type: ‘loaded’,
   details: { userId: ‘780’, amount: ‘1000’ }
}

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

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

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

Тратьте меньше времени на бесполезные тесты

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

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

В целом, такой подход позволяет тратить меньше времени на тесты, которые не представляют ценности, и повышает осведомленность команды о том, что как в действительно проходит производственный процесс.

Создайте свою систему безопасности

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

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

Перевод статьи Rouan Wilsenach «3 production QA practices that will save your business money».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *