Когда дело доходит до достижения успеха, как у крупных футбольных клубов, так и у успешных компаний, ключевую роль играет гармоничное сочетание различных факторов. Это включает в себя найм талантливых и мотивированных специалистов, стратегическое управление, инновационный подход и высокое качество продуктов. Это относится и к ИТ-командам и качеству их продуктов.
Менеджеры всегда стремятся к достижению высокого качества продукта. Они требуют от нас нулевого уровня ошибок в производственном процессе и автоматизации всех тестовых примеров. Также часто возникает задача вовлечения всех специалистов по контролю качества в автоматизацию процесса.
Эти запросы знакомы большинству ИТ-специалистов, и мы часто сталкиваемся с подобными требованиями на работе. Однако реальность такова, что, когда дело доходит до практики, часто все обстоит по-другому. Действительно ли все менеджеры отдают приоритет качеству?
Устанавливают ли они прозрачную коммуникацию с клиентами, заинтересованными сторонами и спонсорами, чтобы добиваться повышения качества работы своих команд? Это не всегда так. В данной статье мы сфокусируемся на ключевых проблемах контроля качества и рассмотрим способы оптимизации в области тестирования.
Процесс тестирования и обеспечение качества тестов
В любой среде разработки программного обеспечения кастомизация играет важную роль для адаптации к конкретным потребностям проекта и команды, работающей над ним. Если, например, у вас есть надежная команда, которая проводит тщательное локальное тестирование, это значительно упрощает работу специалистов по обеспечению качества (QA) и повышает общее качество продукта. Возможность поддержки пользовательских приемочных тестов (UAT) и промышленной эксплуатации становится более простой, поскольку можно настроить окружение в соответствии с требованиями и процедурами вашей команды.
Когда у вас нет сильной команды, возникают сложности. В таких случаях применение проактивных методов контроля качества становится важным. Специалисты по контролю качества должны принимать активное участие, поднимать вопросы крайних случаев, занимать активную позицию и не ограничиваться только обнаружением ошибок. Эффективное коммуницирование играет решающую роль, и предпочтение следует отдавать ясному и конкретному письменному общению. Команда должна видеть в инженере по контролю качества гаранта качества, который обеспечивает, что ничто не попадет в основную ветку разработки без тщательного тестирования для обеспечения качества. Только так можно гарантировать, что продукт соответствует высоким стандартам и требованиям.
Другим важным аспектом является создание и анализ тестовых примеров. Содействие созданию атмосферы сотрудничества между старшими и младшими сотрудниками имеет неоценимое значение. Младшие специалисты по контролю качества могут приобрести знания, выходящие за рамки тестирования, научившись писать тестовые примеры и анализировать сложные сценарии.
По нашему мнению, партнерство «старший-младший» может быть более эффективным, чем отношения «старший-старший», особенно в проектах ручного тестирования. Младшие члены команды могут сосредоточиться на своем сегменте работы, в то время как старшие специалисты по контролю качества могут посвятить свой опыт более широкой картине.
Такой подход позволяет специалистам по контролю качества не тратить время на более мелкие задачи, например, связанные с пользовательским интерфейсом, переводом или незначительными изменениями.
Роль автоматизации тестирования в обеспечении качества тестов
В современных компаниях, основанных на разработчиках, наблюдается новая тенденция — «автоматизация каждого тестового примера». Тем не менее, среди специалистов по контролю качества продолжается обсуждение того, является ли автоматизация всего процесса инструментом поддержки или основным инструментом.
Мы все еще придерживаемся мнения, что автоматизация тестирования является неотъемлемой поддержкой процесса обеспечения качества. Она помогает повысить эффективность, ускорить тестирование и обеспечить надежность продукта, но не заменяет важность тщательного ручного тестирования и экспертного подхода.
Автоматизация может быть полезной и эффективной, но необходимо учитывать, сколько времени будет затрачено на запуск каждого тестового примера и на автоматизацию каждого перехода, текста кнопки и комбинации шагов. Также важно учесть, сколько времени QAs потратят на саму автоматизацию и как будет осуществляться обслуживание пакета автоматизации. Поэтому, несмотря на то, что мечтать о полной автоматизации хорошо, необходимо реально оценить, насколько это будет соответствовать потребностям.
Набор тестов автоматизации должен обладать достаточной интеллектуальностью для охвата основных шаблонов, интеграции с другими системами или третьими сторонами, а также для выявления повторяющихся проблем. Основной фокус должен быть на тех проблемах, которые возникают снова и снова. Однако, если у отдела контроля качества есть достаточные ресурсы и время для разработки и модификации автоматизированных тестов, то можно рассмотреть возможность расширения набора тестов. Важно понимать, что работа с умом всегда эффективнее, чем просто усердно трудиться.
Обучение новых сотрудников отдела контроля качества тестирования
Для ускорения процесса адаптации сотрудников отдела контроля качества можно вовлечь их в реальные проблемы. Это можно осуществить путем создания ошибок, тестирования функций, анализа истории пользователей и автоматизации тестовых примеров, всегда под настоящим наставничеством.
Когда новые участники команды работают в тесном взаимодействии с опытными коллегами, которые делятся своими знаниями и выделяют ключевые моменты, время, необходимое для адаптации, сокращается.
Кроме того, столкнувшись с разнообразием проблем и их решений, сотрудники получают лучшее понимание проекта и глубже вникает в его особенности.
Выявление осложнений перед запусками при тестировании обеспечения качества
Отдел контроля качества должен обладать способностью предвидеть осложнения в цикле тестирования, подобно шестому чувству. Это значит, что команда должна быть готова и проактивно реагировать на причины, которые могут вызывать возникновение проблем. Некоторые из основных причин заключаются в следующем:
- Зависимости (недостаток или несоответствие зависимостей между компонентами или модулями программного обеспечения может затруднить или замедлить процесс тестирования).
- Взад-вперед во время тестирования (недостаточное планирование порядка выполнения тестовых сценариев или непредусмотренные обратные связи между различными этапами тестирования могут создать проблемы и привести к задержкам).
- Нерешенные открытые вопросы в процессе разработки.
- Неоптимизированный план выполнения теста.
- Недостаточно хорошо продуманные процессы в течение жизненного цикла разработки программного обеспечения.
- Масштабирование в процессе разработки без поддержки руководителей команд или scrum-мастеров.
Подходы прикладной команды L1-L2-L3, поддерживаемые при тестировании для обеспечения качества
Еще одной проблемой является группа производственной поддержки. Команды производственной поддержки поддерживают непосредственный контакт с пользователями приложений, бизнесом, владельцами систем и даже высшим руководством.
Эти группы часто сталкиваются с повторяющейся работой, которую выполняет команда L1, занимающаяся сортировкой и разрешением проблем. Однако большинство членов команды L1 недостаточно обучены передовым практикам и не обладают достаточными навыками для эффективного управления ситуациями, когда количество инцидентов растет. Это может стать причиной задержек в решении проблем и снижения качества обслуживания. Примеры:
- Несоответствие инцидента минимальным критериям для включения в заявку L2: Если команда L1 не соблюдает установленные минимальные критерии инцидента, могут возникнуть задержки в передаче проблемы команде L2, что затрудняет быстрое разрешение проблемы.
- Отсутствие воспроизведения в среде с низкой сложностью для команд L1: Если команда L1 не имеет доступа к среде с низкой сложностью для воспроизведения инцидента, они могут столкнуться с проблемами в изучении и решении проблемы, что может привести к задержкам в обслуживании.
- Недостаточное понимание приложения командой L1: Если команда L1 не полностью понимает работу приложения и его компоненты, они могут столкнуться с затруднениями в идентификации и решении проблемы, что влечет задержки в обслуживании пользователей.
- Отсутствие специальной документации для команд L1: Если команда L1 не получает достаточную документацию или не имеет доступа к правильной информации для ответа пользователям, они более вероятно будут сталкиваться с затруднениями в решении проблемы, что может привести к задержкам в обслуживании и эскалации бизнеса.
Команда L1 всегда нуждается в поддержке со стороны L2. Эти команды необходимы друг с другом для решения проблем. Одной из самых важных обязанностей команд L2 является обучение членов команды L1 созданию четких отчетов об ошибках. Что значит создать четкий отчет об ошибке?
- Информативность для L2: при отправке запроса командам L2, отчет должен содержать всю необходимую информацию, чтобы специалисты могли осознать и разобраться в проблеме.
- Расширение возможностей системы: команды L2 должны быть осведомлены о доступных возможностях подключенной системы для устранения инцидентов. Это позволит им применять соответствующие инструменты и процессы для решения проблем, вместо закрытия заявок «по плану».
- Организация команд L1 и L2: в случае возникновения вопросов P1, команды L2 должны быть способны выстраивать работу команд L1 и L2 для эффективного решения проблемы в разных системах.
- Улучшение процесса: команды L2 должны работать над разработкой улучшений, направленных на сокращение количества зарегистрированных инцидентов с «пользователей» до уровня L1 и далее с L1 до L2. Это позволит снизить нагрузку на команды поддержки и повысить качество обслуживания.
Команды L2 должны поддерживать хорошую связь с командами L3 или группами разработчиков продуктов, в которых разрабатываются новые функции. Этому есть несколько причин:
- Для обсуждения вопросов, связанных с новыми функциями и изменениями, командам службы поддержки L2 могут возникать некоторые вопросы.
- Сотрудничество между командами L2 и L3 или разработчиками является критически важным для решения проблем класса P1 или проблем, имеющих высокую степень важности.
- Заметки о выходе новых версий или демонстрационные встречи обычно вызывают множество вопросов у команд L2 и L1, и поэтому эти вопросы должны быть переданы разработчикам продукта для учета в дальнейшей работе.
В каждой команде и в каждом конкретном случае может быть разный подход к тестированию и обеспечению качества. Важно обеспечить эффективную коммуникацию и четкую настройку процесса, учитывая индивидуальные потребности команды, проекта и бизнеса. Все идеи и подходы должны быть разработаны и адаптированы в рамках гибкого процесса, применимого к конкретному контексту тестирования и обеспечения качества.
