Взгляд изнутри на оптимизацию процесса QA
Поговорка стара как мир, вечная война между программистами и тестировщиками, борьба между мечтателями и теми, кто воплощает их мечты.
Мир QA - нестандартный, интересный, поразительный, и, порой, нервный. Допустим, группа людей пытается решить проблему. Все участвуют в поиске решения, пробуя разные подходы. Все, кроме одного!
Он сидит молча, наблюдает, анализирует решения в своей голове, указывая на риски и недостатки в каждом решении и, следовательно, отбрасывает все лишнее. Он следит за тем, чтобы решение было правильным, гибким и устойчивым. Он ведёт отчёт по стоимости и качеству. Он - инженер по контролю качества!
Тестирование ПО не ограничивается тестированием функций приложения и составлением длинных контрольных списков. Всё это лишь подмножество того, что мы называем проектированием QA.
Это целый комплекс задач, таких, как анализ потенциальных рисков на этапе до разработки, анализ требований и недочётов, тестирование приложения с точки зрения разных персонажей, анализ критериев приемлемости и тестирование приложения на них.
Обеспечение качества — сложная задача. Выделим несколько практик, которым должна следовать команда, чтобы в итоге получить высококачественный продукт:
Тестирование — это не просто проверка работы разработчиков
Ваша работа как QA-инженера заключается не только в тестировании кода разработчиков, но и в обеспечении качества каждой операции, будь то разработка функций, взаимодействие с клиентами, определение требований, проектирование каркасов, построение архитектуры, управление гибкой доской и т. д. QAявляется неотъемлемой части жизненного цикла разработки ПО на всех этапах.
Таким образом можно выявить сбои в процессе на более ранних этапах. Подобная концепция тестирования функций и выявления проблем ранее в SDLC называется восходящим тестированием. «Восходящее тестирование» — одна из лучших практик SQA.
Гарантия качества по общекомандному подходу
Суть общекомандного подхода заключается в том, что каждый несет ответственность за обеспечение качества. Каждый член команды должен осознавать важность и ценность своей роли и своей работы. Таким образом, за неудачи будет нести ответственность вся команда, а успех станет коллективной заслугой!
Ретроспективное мышление
Попутное выявление улучшений и постоянный анализ, «что мы можем сделать лучше», — это основа. Но что, если вместо ожидания откровений, члены команды будут применять ретроспективное мышление.
Ретроспективное мышление предполагает постоянную и предварительную обратную связь. Это постоянный анализ, как лучше поступить в данный период времени, вместо постоянных сожалений "лучше было сделать иначе". Это и есть «мышлением в ретроспективе». Члены команды могут встречаться один на один, делиться отзывами о продукте и процессе.
Общение, общение и ещё раз общение
Риски, проблемы и ошибки — это не постоянные понятия, а, скорее, временные переменные. Время является важным фактором качества продукта, поскольку стоимость ошибки, обнаруженной в ходе эксплуатации, будет выше, чем в ходе разработки. Общение играет важную роль. Все члены команды должны свободно и открыто обсуждать все возникшие и возможные проблемы.
Исследовательское тестирование
Исследовательское тестирование — это тип динамического тестирования, позволяющий команде определить все возможные сценарии тестирования, изучая работу приложения. Таким образом, команда способна определять планы тестирования на протяжении всего жизненного цикла разработки ПО.
Будучи тестировщиком-исследователем, вы будете делать выводы о сценариях тестирования и проблемах их исполнения. Исследовательский подход — одна из лучших практик, позволяющая лучше понять и изучить продукт.
Равноправное тестирование — поиск неизвестных в юзабилити
Команда, работающая над ПО в течение многих месяцев, может не найти проблем в юзабилити приложения, поскольку они к нему привыкли. Им сложно понять, с какими проблемами и трудностями может столкнуться новый пользователь. Для этого на работу приложения и его функции необходимо оценить свежим взглядом, без предвзятости. Таким образом можно определить, насколько удобен функционал и понятно юзабилити.
Эффект пестицида, тестовое покрытие и разработка через тестирование
Тестовое покрытие — сложная метрика. Это количественное измерение, которое описывает, сколько тестовых наборов из идентифицированных тестовых наборов применено. Может быть 100% тестовое покрытие, но оно не гарантирует качество продукта, потому что сосредоточено на покрытии идентифицированных скриптов.
Это может вызвать эффект пестицида. Вместо повторяющихся циклов тестирования команда должна искать новые сценарии. Этот подход позволяет нестандартно мыслить и выявлять новые проблемы.
Agile-тестирование
В идеале, проводить тестирование необходимо с зарождения проекта, будь то взаимодействие с клиентом, составление требований, написание историй и т.д. Доказано, что эта концепция очень эффективная. Agile-специалисты тестируют продукт, а также процесс с первого дня, становясь частью каждого этапа.
Управление Бэклогом продукта
Незавершенные работы без надлежащего управления могут спровоцировать беспорядок. Неприоритетные проблемы будут накапливаться, если их не решать по мере поступления. Несмотря на то, что управление невыполненными задачами является обязанностью менеджера проекта, ответственность за ошибки/улучшения лежит на специалисте по обеспечению качества.
Лучший способ очистить бэклог — составить список проблем и представить их на собрании команды.
Заключение
Да, знаю, текста МНОГО!!! У инженеров QA немало работы (причём всегда!)
Хотя его роль однозначна, порой, в некоторых проектах его роль недооценена, соответственно, пренебрегается качество приложения.
Качество должно оставаться приоритетом с самого начала. В команде должен быть человек, настроенный на создание качественной продукции!
В заключение, чтобы все усилия QA "окупились", команда должна понимать ценность и важность тестирования на каждом этапе и помнить, что качество — это приоритет всей команды!