5.2. Bug Report
Bug Report (отчет о дефекте, баг, баг-репорт) – это документ, который содержит информацию о найденном в программном обеспечении дефекте. Цель баг-репорта –предоставление любым заинтересованным лицам всей необходимой информации для идентификации, последующего воспроизведения и исправления обнаруженной ошибки.
Баг-репорт тоже является одним из наиболее часто встречающихся видов документации. Обычно его составляет QA инженер в ходе проведения проверок. Тем не менее баг-репорт может также завести любой другой участник проекта: руководитель, разработчики, аналитики, поддержка. Также баг-репорт могут предоставлять пользователи. В случае Альфа или Бета–тестирования баг-репорт может быть приближен к тому, который составляет QA инженер. В некоторых ситуациях его генерирует система автоматически – тогда он скорее всего имеет описание не в такой “человеческой” форме.
Баг-репорт обладает критериями, по которым можно определить его качество. Чем качественней документ, тем меньше вероятности недопонимания между членами команды и риска неправильной приоритезации.
Атрибуты качества баг-репорта:
– Точность – описание баг-репорта должно быть понятным, конкретно указывать на проблему, без разночтений показывать ошибку.
– Полнота – описание должно содержать все условия, при которых возникает ошибка, а также объяснять ее последствия.
– Воспроизводимость – указанные предусловия, шаги и другая информация должна быть достаточной для того, чтобы любой участник команды, не обращаясь к создателю документа, смог воспроизвести описанный дефект.
– Приоритезированность – баг-репорт содержит оценку серьезности дефекта и его приоритета для исправления.
– Краткость – в нём не должно быть информации, не относящейся к описанному дефекту.
Хорошим тоном будет приложить к баг-репорту все логи работы приложения, которые только можно. Также полезно указать баг-репорты, ошибки в которых кажутся похожими или связанными с дефектом, который вы обнаружили.
Структура баг-репорта:
– Идентификатор (ID) – уникальный номер дефекта, который обычно выставляется автоматически.
– Название – краткое описание проблемы.
– Статус – указывает на текущее состояние обнаруженного дефекта, например, открыт, в работе, исправлен, отменен. QA инженер чаще всего открывает и закрывает баг–репорты.
– Приоритет – обозначает срочность взятия дефекта в работу для исправления. Его может указать QA инженер или любой другой участник команды, отвечающий за приоритезацию работы над дефектами.
– Критичность – оценка влияния дефекта на работоспособность системы.
– Окружение – описание окружения, в котором был обнаружен дефект, например операционная система, браузер, версия тестируемого программного обеспечения.
– Описание – полное описание проблемы, включает точные шаги для воспроизведения, ожидаемый и фактический результаты поведения системы.
– Вложения – дополнительная информация, способная помочь быстрее исправить дефект, например скриншоты, видео, логи ошибок.
– Дата и время создания дефекта.
– Автор – тот, кто создал баг-репорт.
Пример баг-репорта
На практике баг-репорты полезны не только тем, что помогают понять, в чем причина возникших ошибок, но и тем, что они также являются частью процесса разработки программного обеспечения. Это значит, что информация в них позволяет обнаруживать проблемы в процессах лично вашей работы, работы команды или проекта. Найденные проблемы можно обратить в точки роста, которые усовершенствуют существующие процессы или повысят навыки людей в команде. Поэтому важно, чтобы ваши баг-репорты как документация были всесторонне качественными.
5.3. Test Plan
Test Plan (тест-план) – это документ, в котором описан весь объем работ по тестированию. Он состоит из следующих частей:
– Описание объекта тестирования. Этот раздел дает общее представление о продукте или компоненте, которому предстоит пройти тестирование. Здесь указываются функции, модули или аспекты системы, подлежащие тестированию, а также любые версии или конфигурации, которые необходимо учесть.
– Стратегия проведения тестирования – описание подхода к тестированию, включая его типы, которые планируют проводить, а также методологии и техники, которые будут использовать. Стратегия также должна учитывать приоритеты тестирования, основываясь на важности функций, рисках, объеме и сложности работы.
– Расписание проведения тестирования. Здесь определены временные рамки тестирования, включая начало и окончание каждого его цикла, а также ключевые даты, к которым должны быть достигнуты конкретные цели. Это помогает координировать усилия команды и обеспечивать соблюдение сроков.
– Критерии начала и окончания тестирования. Критерии начала определяют условия, которые должны быть выполнены, прежде чем начнется тестирование. Например, завершение разработки, наличие тестовой среды в готовом для работы состоянии. Критерии окончания описывают, когда тестирование может считаться завершенным, например, когда все критические ошибки исправлены или когда достигнуты определенные цели.
– Необходимое оборудование. В этом разделе перечислены все аппаратные и программные ресурсы, необходимые для тестирования, включая тестовые серверы, клиентские машины, мобильные устройства, специализированное оборудование, а также версии операционных систем браузеров и другого программного обеспечения.
– Особые знания сотрудников. Указание любых специализированных навыков или знаний, необходимых членам команды тестирования для выполнения плана тестирования. Это может быть опыт работы с определенными технологиями, программными продуктами или методологиями тестирования.
– Оценка возможных рисков и варианты решения при их возникновении. В этом разделе оцениваются потенциальные риски для проекта, такие как задержки в разработке, нехватка ресурсов или оборудования, а также риски, связанные с качеством самого продукта. Для каждого риска предлагаются стратегии минимизации или планы действий на случай его реализации.
– Дополнительная информация, необходимая для осуществления плана тестирования. Раздел может включать ссылки на внешние ресурсы, стандарты, руководства, шаблоны документации, инструкции по доступу к инструментам или системам, используемым в тестировании, а также любую другую информацию, которая может быть полезна для успешного выполнения плана тестирования.
Тест-план – основополагающий элемент процесса тестирования, поскольку он обеспечивает всеобъемлющую основу для тестирования на всех этапах разработки продукта. Оформлением документа обычно занимается QA Lead, Head of QA или наиболее опытный QA инженер.
Качественно разработанный тест-план обеспечивает четкую и организованную структуру для всего процесса тестирования, помогая удостовериться, что все аспекты продукта тщательно проверят, а результаты тестирования будут соответствовать ожиданиям всех заинтересованных сторон.
На практике тест-планы не всегда создают как большой всеобъемлющий документ. Он нередко вообще отсутствует при тестировании приложений. Однако это не означает, что документ не нужен в принципе, а только говорит о процессах и потребностях на проекте.
Нежелание использовать тест-план в некоторых командах связано, во–первых, с тем, что текущий тренд в разработке программного обеспечения – это создавать небольшие обновления, которые проще тестировать. К тому же нередко команды разработки довольно маленькие: в них состоят 1–3 QA инженера. Из–за небольшого масштаба опытный QA вполне может держать этот план в голове и следовать ему.
Во–вторых, это связано с низким запросом на качество выпускаемого продукта. То есть, компании и команды не всегда хорошо понимают, для чего тратить время на такой документ, и как его эффективно использовать, не в полной мере осознают его ценность. Отсутствие тест-плана для задач среднего и большого размера может оказаться критичным.
Отсутствие тест-плана даже при регулярном тестировании больших задач не обязательно означает, что команда то и дело будет выпускать некачественный продукт. И все же большие компании с огромной прибылью предпочитают снижать риски. Ведь тест-планы это в первую очередь про снижение рисков как некачественного тестирования, так и сторонних факторов. При этом большие компании тоже нередко ведут разработку, выполняя небольшие задачи. Отсюда появилась гибкость тест-планов. Если вы столкнетесь с ними, то увидите, что в разных компаниях они имеют очень разную детализацию и размер. Из этой вариативности можно выделить два типа тест-планов:
– Release Test Plan (тест-план релиза) – план, который применяют ко всему большому релизу приложения. Он как раз похож на описанный выше и будет включать большинство пунктов с подробным описанием. Такой документ особенно полезен, когда необходимо синхронизировать работу множества отдельных команд, выпускающих единый релиз. Этот документ не описывает подробности того, как будет тестироваться каждая отдельная фича, а только указывать их список.
– Feature Test Plan (тест-план фичи) – план, который применяют для любой доработки приложения. Этот документ структурно похож на тест-план релиза, но он концентрируется и подстраивается только под конкретные потребности доработки, его размер сокращен только до самого важного.
Пример простого тест-плана релиза:
5.4. Test Report
Test Report (тест-репорт, отчет о тестировании) – это документ, в котором подводят итоги тестирования после его завершения. Он предоставляет собой всесторонний обзор проведенных тестов, их результатов и выводов по качеству тестируемого продукта. Отчет о тестировании играет ключевую роль в оценке готовности продукта к выпуску и помогает заинтересованным сторонам принимать решения.
Тест-репорт, как и тест-план, не всегда выглядит как большой документ со всевозможными подробностями. Это может быть довольно короткий отчет, подчеркивающий самое важное для сторон, заинтересованных в документе.
Тест-репорт состоит из таких разделов:
– Общая информация – здесь указывают название проекта/продукта, даты начала и окончания цикла тестирования, имя и должность лица, ответственного за подготовку отчета.
– Цели тестирования – краткое описание целей, которые были поставлены перед командой тестирования.
– Объект тестирования – описание функций, модулей или компонентов продукта, которые проходили тестирование.
– Тестовое окружение – детальное описание аппаратного и программного обеспечения, использованного в процессе тестирования.
– Обзор тестирования – краткое изложение подходов и методик, применяемых в тестировании.
– Объем тестирования – перечень основных участков функционала продукта, которые были проверены.
– Результаты тестирования – количество выполненных, пройденных и непройденных тест–кейсов.
– Обнаруженные дефекты – статистика по обнаруженным ошибкам, включая их серьезность и приоритет.
– Анализ результатов – оценка результатов тестирования, включая соответствие продукта требованиям и ожиданиям.
– Выводы и рекомендации – анализ общего качества продукта на основе результатов тестирования и предложения по улучшению или необходимым доработкам.
– Приложения – дополнительные материалы, такие как детальные отчеты об ошибках, логи тестирования, скриншоты и другие доказательства выполненного тестирования.
Тест-репорт должен быть представлен в четкой и лаконичной форме, чтобы все заинтересованные стороны поняли полученные результаты. Тест-репорт используют не только для оценки текущего состояния продукта, но и для планирования будущих действий по улучшению качества продукта и процесса тестирования.
Пример тест-репорта
5.5. Requirements Traceability Matrix
Requirements Traceability Matrix (матрица трассировки требований) – это документ, который используют для отслеживания и подтверждения выполнения всех требований к продукту на протяжении всего жизненного цикла разработки. Матрица трассировки требований помогает убедиться, что каждое требование к программному обеспечению было протестировано, и что все тесты проведены корректно. Этот вид документации является всесторонне полезным инструментом, особенно для больших проектов.
Задачи матрицы трассировки требований:
– Она гарантирует, что для каждого требования разработан соответствующий тестовый случай.
– Помогает идентифицировать любые требования, для которых тесты еще не разработаны.
– Позволяет отслеживать изменения в требованиях и оценивать их влияние на уже разработанные тестовые случаи и результаты тестирования.
– Упрощает предоставление заинтересованным сторонам информации о статусе выполнения требований и результатах тестирования.
Пример простой матрицы трассировки требований
5.6. Test Strategy
Test Strategy (стратегия тестирования) является ключевым документом в процессе обеспечения качества программного обеспечения, определяющим общий подход и план действий по тестированию продукта. Этот документ описывает методологии, стандарты, цели, приоритеты, критерии успеха, ресурсы и график тестирования на самом высоком уровне. Разработанная стратегия тестирования служит основой для более детализированных тест-планов и задает общий ритм процесса.
Цели стратегии тестирования:
– Определение конечных целей тестирования в соответствии с бизнес–требованиями и ожиданиями заинтересованных сторон.
– Выбор методологий тестирования, то есть описание подходов и методик тестирования, которые будут использовать для достижения целей тестирования.
– Определение необходимых ресурсов, включая персонал, инструменты и оборудование.
– Определение потенциальных рисков и разработка стратегий их минимизации.
Стратегия тестирования играет важную роль в обеспечении качества программного продукта, так как она:
– Гарантирует единое понимание целей тестирования и подходов к нему всеми участниками проекта.
– Помогает оптимизировать процесс тестирования за счет эффективного распределения ресурсов и четкого планирования.
– Содействует выявлению и управлению рисками на ранних этапах проекта.
– Улучшает коммуникацию и координацию действий между командами разработки и тестирования.
Разработка стратегии тестирования требует глубокого понимания требований проекта, бизнес–целей, технических аспектов продукта, а также потенциальных рисков и ограничений. Это делает тестовую стратегию фундаментальным документом, определяющим успех обеспечения качества программного продукта.
Основные компоненты стратегии тестирования:
– Введение – общее описание проекта, его целей, области действия стратегии тестирования.
– Объекты тестирования – описание компонентов программного продукта, которые подлежат тестированию.
– Уровни тестирования – определение различных уровней тестирования, таких как модульное, интеграционное, системное и их взаимосвязь.
– Типы тестирования – перечень типов тестирования (функциональное, нефункциональное, регрессионное и т. д.), которые будут применять в проекте.
– Роли и ответственности – распределение задач и ответственности между участниками процесса тестирования.
– Оценка рисков и управление ими – анализ потенциальных рисков для проекта и меры по их предотвращению или минимизации.
– Инструменты тестирования – перечень программного обеспечения и инструментов, которые будут использовать для автоматизации тестирования и поддержки его процессов.
– Принципы подхода к планированию – описание принципов планирования тестирования, включая принципы выбора критериев начала и окончания тестирования, а также принцип расчета графиков тестирования для уменьшения рисков.
– Процедуры отчетности – система отчетности о ходе и результатах тестирования.
Пример простой стратегии тестирования
6. ПРОЦЕССЫ
6.1. Процессы на уровне компании
Процесс – это совокупность взаимосвязанных действий или задач для достижения определенного бизнес–результата или цели. Процессы не только охватывают разработку программного обеспечения, но и диктуют правила абсолютно для всех уголков компании.
В небольших или очень молодых компаниях процессы обычно простые и немногочисленные. Это связано с тем, что при малых размерах специалисты в жизни организации очень важны, а процессы – нет. В больших компаниях напротив: ими трудно управлять и полагаться только на людей уже ненадежно, ведь все мы вне зависимости от нашего опыта совершаем ошибки. Крупные компании обязаны заботиться о качественных и всеобъемлющих процессах, которые при этом должны быть достаточно гибкими там, где это необходимо и допустимо.
Процессы на первый взгляд могут показаться скучной частью мира ИТ. Однако для любой серьезной компании в мире высокой конкуренции это основополагающий аспект, от которого зависит судьба организации, всех ее сотрудников и в конечном счете клиентов.
Вы как QA инженер в большинстве случаев столкнётесь только с малой частью процессов, которые будут существовать в вашей компании, а влиять будете на еще меньшее их количество. Однако важно знать, как все устроено, и понимать, что каждый уровень по-своему важен для компании.
Уровни процессов в компаниях
– Стратегический – на этом уровне определяют миссию компании, ее видение, выстраивают стратегические цели и планы на годы вперед. Самое высокое руководство вместе с отделом стратегического планирования разрабатывает долгосрочные планы с учётом всех возможных аспектов. Именно тут определяют направление развития компании, выходы на новые рынки, разработку новых программных продуктов с учетом финансовых аспектов.
– Управленческий (Тактический) – на этом уровне происходит планирование и координация конкретных инициатив и проектов в рамках стратегических целей и планов компании. Менеджеры среднего звена рассчитывают и распределяют ресурсы, контролируют качество и сроки, управляют рисками, внедряют изменения в процессы.
– Операционный – на этом уровне создают и поддерживают программное обеспечение, услуги компании. Уровень включает ежедневную активность сотрудников разработки, тестирования, поддержки клиентов, инфраструктуры и других.
– Поддерживающий – на этом уровне обеспечивают всестороннюю поддержку функционирования компании. Сюда относится обеспечение безопасности, HR–процессы, юридическая поддержка, финансовое планирование и внутренние ИТ–службы.
– Уровень непрерывного улучшения (не всегда присутствует) – он проходит сквозь остальные и направлен на постоянное усовершенствование их процессов. Сюда могут входить советы и даже контроль менеджеров среднего звена и ниже за соблюдением инициатив по улучшению процессов. Портал для обучения сотрудников новым навыкам тоже относится к инициативе данного уровня, как и многое другое.
На вас как QA инженера будут так или иначе влиять все уровни. Сами же вы находитесь на Операционном. За ваш карьерный рост в виде новых должностей и проектов так или иначе влияют сотрудники прочих уровней:
– Стратегический уровень – тут появляются идеи новых проектов или объединения старых, из-за чего в компании могут ввести новые должности или сокращения.
– Управленческий уровень – тут рассчитывают, какие сотрудники и в каком количестве нужны в новых или существующий проектах.
– Поддерживающий уровень – тут происходит расчет зарплат и других компенсаций вашего труда.
В зависимости от процессов компании запрос на перемещение внутри нее по должностям может быть адресован как Поддерживающему уровню в виде HR специалиста, так и Операционному в виде QA менеджера.