Распространённый сценарий: вы только что выпустили новую версию своего продукта и что-то пошло не так. То, что ваша команда должна была заметить во время тестирования. И вот после решения проблемы вы задаетесь вопросом: “Что можно сделать, чтобы впредь избежать таких ситуаций?” Ясно, что единого для всех волшебного решения нету.
Но вы должны быть уверены в своих инструментах, чтобы в любое время иметь возможность протестировать продукт и быстрее исправить ошибки.
Ошибка, которую часто допускают, заключается в том, что продукт тестируют только тогда, когда планируют публикацию новой версии. Для сложных программных продуктов это в корне неверно. Вы должны быть уверены, что даже текущие версии работают без сбоев.
Есть ряд инструментов / процессов, которые помогают достичь этой цели:
Автоматические предупреждения
Если один из ключевых показателей эффективности, которые мы определили как важные для оценки состояния работоспособности наших приложений, находится выше / ниже определенного порога, команда автоматически получает предупреждение через различные каналы (Slack, email и т. д.).
Ежедневные проверки работоспособности
Команда QA проводит набор стандартных тестов, чтобы приложения работали, как ожидалось, ежедневно. Эти наборы включают анализ использования памяти, использования ЦП и прочее.
Предварительные версии ОС
С точки зрения разработчиков, мы знаем, что новая версия операционной системы может внести изменения в работу нашего продукта. Вот почему стоит запускать тесты на любой версии ОС. При этом мы не только предварительно поймаем баг до получения программы клиентом, но также убедимся, что производительность приложений не меняется в разных версиях одной и той же операционной системы.
TDD / BDD / автоматизация
Часто люди обсуждают (иногда яростно) TDD и BDD: некоторые говорят, что TDD - это то, что нужно реализовывать в первую очередь; другие считают, что BDD - единственное, чему стоит уделять внимание.
Мы же считаем, что эти инструменты дополняют друг друга, и если ваша команда сможет правильно их использовать, то они окажутся неоценимыми.
Когда тестировщики вручную тестируют то, для чего можно было применить автоматизацию, это неправильно. Они тратят колоссальное количество времени на то, что может сделать машина. Ручное тестирование может быть сосредоточено на конкретных областях, оно позволяет тестировщикам находить больше дефектов и в полной мере использовать свои навыки.
Функциональное и нефункциональное тестирование
Не будем вдаваться в подробности, почему нужно заботиться о функциональном и нефункциональном тестировании. Оба вида невероятно важны, и ни один продукт не должен считаться готовым к выпуску, если он не был протестирован в одной из этих двух областей. Эти два теста должны иметь одинаковое значение в вашей стратегии тестирования. Тогда все заинтересованные стороны останутся довольны.
Одной из лучших практик является то, чтобы команда QA активно участвовала в обсуждении дизайна, архитектуры и реализации: они смогут выделить любые основные недостатки, прежде чем кто-либо будет тратить время на создание кода. Это, в свою очередь, сократит цикл разработки и поможет ускорить релиз.
Приоритет ошибок
Если приложение падает, цель - исправить проблему как можно скорее, но иногда это невозможно сделать сразу; поэтому всегда стоит оценивать степень серьезности проблемы, проверяя, как много клиентов / устройств пострадали от сбоя. Аналогично, если ошибка не приводит к сбою приложения, мы проверяем данные об использовании: появляется ли ошибка в области, которая часто используется нашим клиентом или же наоборот. И в зависимости от этого мы выставляем приоритеты.
После релиза имеет смысл запустите проверку работоспособности приложений, используя производственные учетные записи, чтобы знать, что ваши клиенты получили то, что ожидали и приложения не дают сбой на множестве поддерживаемых устройствах. Вы также должны убедиться, что сторонние системы, которые взаимодействуют с приложениями, правильно интегрированы.
Эти аспекты, а также желание тестировщиков развивать новые навыки и участвовать во многих этапах процесса разработки помогут избежать многих проблем как в самом процессе тестирования, так и после выпуска продукта.
21 июня/2018
