/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ: - ТЕСТИРОВАНИЕ ` Копнуть мудрости ` Тестирование: QC И QA ` Цикл тестирования ` Уровни тестирования ` Виды тестирования ` Методы: ручное и авто ` Баг-репорт ` Шаблоны документов ` JIRA & Adaptavist + Тестирование требований + Тест-анализ и тест дизайн + Импакт-анализ в тестировании + Тест план + API, интеграционное и E2E + Метрики качества + Android + Автоматизация + Selenium WebDriver + XPATH + Различные расчёты + Безопасность + Нагрузочное
- Качество определяется как соответствие требованиям.
- Способ обеспечения качества — предотвращение, а не оценка.
- Мера качества — цена несоответствия, а не индексы.
- Стандартом работы должно быть отсутствие дефектов.
Книги
- (PDF) Тестирование программного обеспечения (Святослав Куликов, 2018). Курс в книжке хоть и позиционируется как "базовый", но предметная область расписана глубоко, наглядно, со множеством примеров.
Тестирование в условиях микросервисной архитектуры и Service mesh
- Testing Strategies in a Microservice Architecture (Martin Fowler, 2014) — статья Мартина Фаулера о тестировании в микросервисной архитектуре. Листать слайды стрелочками вверху.
- История service mesh в компании (Александр Лукьянченко, Авито, 2019). Об изначальных проблемах, о подходе к Service Mesh, о проблемах с эксплуатацией Istio, о создании собственного решения в виде sidecar-сервиса Netramesh (Golang + K8s / bare metal), о внедрении OpenTracing с инструментом Jaeger (что позволяет получать карты взаимодействия сервисов), о тестах и выделении критичных путей, о своего рода канареечных тестах с подменой роутинга для тестов.
- Реализация Consumer-Driven Contract подхода для тестирования микросервисов (Фрол Крючков, Авито, 2018)
Chaos testing
Тестирование ПО = процесс исследования/испытания ПО, имеющий своей целью проверку соответствия между реальным и ожидаемым поведением ПО на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005).
Цель тестирования или цель разработки и выполнения тестов:- обеспечить очищение ПО от ошибок до приемлемого уровня (вы не можете предоставить 100% покрытие, но вы должны сделать всё возможное, и гарантировать, что очевидные ошибки исправлены);
- убедиться, что ПО отвечает требованиям;
Задача QC (Quality Control, контроль качества) — контроль и фиксация качества производимых артефактов, промежуточных и конечных результатов работы. Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом тестирование является неотъемлемой частью контроля качества.
Здесь очень подходит термин Verification с вопросом "Are we building the product right?" — правильно ли мы делаем продукт, проверяется соответствие планам, спецификациям, дизайну, правилам составления кода, проход тест-кейсов. Проверяем CORRECTNESS.
QA (Quality Assurance, обеспечение качества) = часть менеджмента качества, ориентированная на создание и настройку процессов, целью которых является обеспечение гарантии того, что требования к качеству будут выполнены (продукт будет соответствовать ожиданиям качества заказчика).
Состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки ПО (SDLC), и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование.
Занимается вопросами "а какие виды и методы тестирования мы будем использовать?", "как будем измерять качество?" и т.п.
Здесь очень подходит термин Validation с вопросом "Are we building the right product?" — правильный ли продукт мы делаем, удовлетворяет ли продукт нуждам пользователя. Проверяем COMPLETENESS.
Чтобы предоставляемые услуги имели ценность, необходимо, чтобы тестирование было нацелено на проверку функций, которые:
- значимы для Заказчиков/Пользователей
- оказывают влияние на мнение пользователя о работе с системой
- снижают потенциальные затратные риски
-
Тест-анализ — анализ требований (Requirement analysis) и (опционально) Тестирование требований.
Результат: Матрица трассировки Требований и Тест-кейсов (Requirement Traceability Matrix, RTM), зарегистрированные дефекты документации и более качественная документация для разработчиков. -
Планирование (Test Management, Test Planning).
Результат: тест-план (Test Plan) / стратегия тестирования, оценка трудозатрат (Effort Estimation) -
Проектирование тестов (Test Design, Test Development).
Результат: набор тест-кейсов (test cases), которые необходимо пройти, тестовые данные (test data) -
Выполнение (Test Execution). Используются методы тестирования (methods of testing).
Результат: отчёт о тестировании, багрепорты (bug report). -
Анализ результатов тестирования (Test Result Analysis). Используются метрики (QA metrics).
Результат: выводы для исправления ошибок в планировании и контроле над процессом тестирования/разработки.
Unit testing — Модульное тестирование
Модульное тестирование (Unit testing) = тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что:- если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки: моки и стабы. Stub’ы предназначены для получения нужного состояния тестируемого объекта, а Mock’и применяются для проверки ожидаемого поведения тестируемого объекта.
- код не должен работать с сетью (и внешними серверами), файлами, базой данных (иначе мы тестируем не саму функцию или класс, а еще и диск, базу, ит.д.)
Обычно юнит-тест передаёт функции различные входные данные и проверяет, что она вернёт ожидаемый результат. Например, если у нас есть функция проверки правильности номера телефона, мы даём ей заранее подготовленные номера и проверяем, что она определит их правильно. Если у нас есть функция решения квадратного уравнения, мы проверяем, что она возвращает правильные корни (для этого мы заранее делаем список уравнений с ответами).
Выполняется разработчиками, зачастую методом автоматизированного тестирования.
Integration testing — Интеграционное тестирование
Интеграционное тестирование (Integration testing) = проверка связи между модулями (компонентами) кода, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). Если проводить аналогии, например с тестированием авиадвигателя, то юнит-тесты — это тестирование отдельных деталей, клапанов, заслонок, а интеграционное тестирование — это запуск собранного двигателя на стенде.
Выполняется разработчиками, зачастую методом автоматизированного тестирования.
System testing — Системное тестирование
Системное тестирование (System testing) = процесс тестирования системы в целом с целью проверки того, что она соответствует установленным Спецификациям к Требованиям к ПО (SRS).
Удостовериться, что Система умеет принять какие-то данные от поставщиков, обработать их, передать данные потребителям, всё это в правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное — наша система работает правильно в правильном окружении.
При этом выявляются дефекты как: неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные варианты использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
Подробнее этот вид тестирования рассмотрен тут.
API testing — тестирование API
Тестирование API (API testing) = процесс тестирования приложения (сервиса) с целью проверки того, что реализация внешних интерфейсов соответствует установленным требованиям.
Тестирование API можно отнести и к интеграционному тестированию и к системному, в зависимости от того что мы в рамках своей задачи считаем тестируемой системой (SUT, system under testing) — отдельный сервис или некую платформу как совокупность сервисов.
Как обычно происходит — вызываем методы API, сверяем реакцию на корректность (логику самого метода, ответные данные, бизнес-логику "за" методом). Подробнее здесь.
Acceptance testing — Приёмочное тестирование
Приёмочное тестирование (Acceptance testing) или Приёмо-сдаточные испытания (ПСИ) — формальный процесс тестирования, который проверяет соответствие системы Бизнес/Пользовательским требованиям и проводится с целью: определения удовлетворяет ли система приёмочным критериям, вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. Выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению.
End-to-End testing — Сквозное тестирование
Сквозное тестирование (End-To-End, E2E или Chain testing) = проверка некоей функциональности (фичи Продукта, услуги) по всему клиентскому сценарию: от инициирующих действий Клиента (либо клиентского приложения) через все задействованные в цепочке системы нашего Продукта до предоставления Клиенту результата.
Для сквозных сценариев при большом количестве систем частенько используется последовательность из уже ранее разработанных тестов для каждой из систем, где конец одного теста есть логическое начало следующего.
Мартин Фаулер предупреждает о том, что написание и поддержка E2E-тестов достаточно дороги, а значит:
- их не должно быть много
- время прохода E2E-тестов должно исчисляться минутами, а не часами
- E2E-тесты должны кореллировать с CJM
- если какой-нибудь внешний сервис очень часто является причиной задержек в выполнении E2E-сценария, рекомендуется его исключить, организовав заглушку вместо него
- нужно стараться делать E2E-тесты независимыми от предподготовленных данных, отсутствие или плохое качество которых часто является причиной ошибок. Если есть сервисы (воззможно, среди тестируемвых), которые предоставляют API по созданию объектов сущностей, то следует использовать его. Если такого нет, то нужные данные следует импортировать на уровне БД.
| Основные группы тестирования | |
|---|---|
| функциональная группа |
нефункциональная группа |
|
|
| тестирование связанное с изменениями (включают и функциональные и нефункциональные тесты) | |
|
|
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приёмочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.
Функциональное тестирование (functional testing)
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приёмочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде вариантов использования системы (use cases).
Функциональное тестирование бывает:
- "Позитивное" (positive testing) — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
Основной целью "позитивного" тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась. - "Негативное" (negative testing) — это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы — различные сообщения об ошибках, исключительные ситуации, "запредельные" состояния и т.п.
Основной целью "негативного" тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).
Позитивное тестирование является гораздо более важным, но это не означает, что "негативными" тестами можно пренебречь.
Подробнее о позитивном/негативном тестировании: https://guru99.com/positive-and-negative-testing.htmlТестирование безопасности (security and access control testing)
Тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Сканирование на предмет наличия уязвимостей (Vulnerability Scanning): Выполняется с помощью специальных программ-сканеров уязвимостей.
Сканирование безопасности (Security Scanning): Включается в себя идентификацию сетевых и системных недостатков (слабых мест), а затем предоставляет решения для сокращения таких рисков.
Тест на проникновение (Penetration testing): симулирует нападение злоумышленника. Это тестирование включает анализ конкретной системы с целью проверить потенциальную уязвимость к внешним попыткам взлома.
Оценка риска (Risk Assessment): включает в себя анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как слабые (low), средние (medium) и высокие (high). Этот вид тестирования рекомендует методы контроля и снижения рисков.
Тестирование ролевой модели (testing of role model)
Тестирование ролевой модели = тестирование системы с точки зрения пользователя, наделённого правами доступа к функциям и данным системы согласно ролевой модели, заданной в этой системе.
Тестирование ролевой модели относится к функциональной группе, при этом частично пересекаясь по своему смыслу с тестированием безопасности.
Во многих системах существует ролевая модель, в самом банальном исполнении это администратор и простой пользователь. В какой-нибудь банковской системе это может быть администратор, клиент, оператор, андеррайтер, специалист отдела X, Y, Z и т.д. В какой-нибудь системе складского учёта это может быть администратор, начальник склада, заместитель начальника склада, кладовщик, грузчик.
Каждая роль наделена определённым уровнем прав доступа к тем или иным функциям в АС (автоматизированной системе, ПО), к чтению/изменению/удалению данных на формах GUI, настройкам самой системы и т.п.
В общем случае, тестирование ролевой модели подразумевает проверку того, что пользователю, имеющему в рамках системы такую-то роль:
- доступны такие-то функции, а такие-то НЕ доступны.
- (не)доступны для чтения/редактирования/удаления такие-то данные на таких-то формах GUI.
- достаточно тех или иных прав для выполнений своих задач согласно сценариям использования системы, в которых его роль задействована. Т.е. он способен выполнять задачи в рамках отведённого ему (участка) бизнес-процесса.
Тестирование производительности (performance testing) или нагрузочное тестирование (load testing)
Тестирование производительности = автоматизированное тестирование, имитирующее работу определённого количества пользователей на каком-либо общем (разделяемом ими) ресурсе. Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций
- определение количества пользователей, одновременно работающих с приложением
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)
- исследование производительности на высоких, предельных, стрессовых нагрузках
Стрессовое тестирование (stress testing) = тестирование приложения под экстремальными нагрузками, определение способности обрабатывать высокий уровень траффика или обработки данных. Целью является определить переломную точку приложения.
Задачей тестирования стабильности (stability) / надежности (reliability) — является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Тестирование выносливости (endurance testing) = убеждение в том, что приложение может безопасно находиться под высокими нагрузками долгий период времени.
Объёмное тестирование (volume testing) = получение оценки производительности при увеличении объёмов данных в базе данных приложения.
Тестирование удобства использования (usability testing)
Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, "обучаемости", понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]Удобство (User Friendliness):
- управление и работа с системой организованы очевидным образом, нет необходимости в специальном обучении;
- эстетичность расположения и внешнего вида содержимого, цветов, иконок;
- наличие раздела справки;
- сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше — лучше);
- универсальность формата окон/страниц в приложении/веб-сайте;
- нет грамматических, синтаксических ошибок, не выводятся устаревшие или неверные данные;
- нет битых ссылок;
Тестирование на отказ и восстановление (failover and recovery testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основные функции систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
Тестирование на отказ и восстановление очень важно для систем, работающих по принципу "24x7", например интернет-магазины, ERP-системы.
- отказ электричества на машине-сервере;
- отказ электричества на машине-клиенте;
- незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации);
- объявление или внесение в массивы данных невозможных или ошибочных элементов;
- отказ носителей данных.
Тестирование графического пользовательского интерфейса (GUI testing)
- проверить для всех элементов GUI размеры, позицию и принятие букв и цифр. Например, во всех полях ввода возможно производить ввод
- удостовериться, что графический интерфейс позволяет полностью реализовать весь функции приложения
- проверить верность отображения предупреждающий сообщений и сообщений об ошибках
- проверить читабельность шрифтов, используемых приложением, их выравнивание, цвет
- проверить отображение и расположение изображений
- проверить расположение элементов интерфейса при различных разрешениях экрана
- ...
Тестирование совместимости (compatibility testing)
Аппаратное обеспечение: совместимость с различными аппаратными конфигурациями.Операционные системы: совместимость с различными операционными системами: Windows, *nix, Mac OS и т.д.
Программное обеспечение: совместимость с различным программным обеспечением. Например, MS Word совместим с MS Outlook, MS Excel, VBA и т.д.
Сеть: Оценка производительности системы в сети с изменяющимися параметрами, такими как пропускная способность, рабочая скорость, ёмкость. Проверка возможности применения приложения при различных вариантах значений этих параметров.
Браузер: проверка совместимости веб-сайта с основными по-популярности: Firefox, Google Chrome, Internet Explorer, Opera, Safari.
Устройства: совместимость с различными устройствами: принтерами, сканерами, средствами беспроводной связи, USvoid-устройствами.
Мобильные устройства: совместимость с мобильными платформами, такими как Android, iOS и т.д.
Версии программного обеспечения: совместимость с различными версиями программного обеспечения. Например, совместимость Microsoft Word с Windows 10, Windows 8, Windows 7, Windows XP, Windows XP SP2 и т.д.
Дымовое тестирование (Smoke testing)
Дымовые тесты выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции Приложения/Системы работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.
Ре-тест (Re-test)
Проверка того, что ранее обнаруженный при тестировании дефект был успешно исправлен.
Санитарная проверка (Sanity check)
Используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Иными словами, здесь проходит валидация того, что важные части функциональности системы работают согласно требованиям на низком уровне.
Регрессионное тестирование (regression testing)
Проводится для того, чтобы убедиться что добавленные/изменённые функции приложения и исправленные дефекты не оказали негативного влияния на уже успешно действующую в Проме функциональность.
РТ занимает львиную долю времени, и как раз для сокращения затрат и существует автоматизация тестирования.
Пример, разъясняющий разницу между тестами после изменений
У нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
- Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
- все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json
Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:
- Выполнив один простой GET-запрос к одной из этих точек входа. Если от сервиса пришёл ответ в формате JSON, т.е. не вернул ошибку 4хх или 5хх или что-то невнятное, то он не "задымился". На этом можно сказать что "дымный" тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
- Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в API.
- Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в API следующем билде отрабатывает как задумывалось.
-
Регрессионные тесты будут состоять из Smoke + Sanity + UI выполняемые вместе в одной куче:
- Выполнения запроса ко всем 10 точкам входа в API, сверкой полученного JSON с ожидаемым, а так же наличием требуемых данных в нём
- проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.
Пример регрессионного тестирования для условного банка
Ручное (manual testing) = выполнение тестировщиком тестовых сценариев и тестовых случаев вручную.
К автоматизации тестирования (automation testing) существуют следующие основные подходы:- тестирование на уровне кода — модульное тестирование (unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
-
тестирование API. API — это набор функций, которые можно вызывать, чтобы получить какие-то данные.
Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым. - тестирование пользовательского интерфейса — (GUI-тестирование). Имитация действий пользователя с помощью специальных тестовых фреймворков.
Некоторые инструменты для автоматизации тестов
Полезные статьи
- Автоматизированное Функциональное Тестирование
- Как стать автоматизатором тестирования?
- Manual Testing Tutorial for Beginners
- AUTOMATION TESTING Tutorial: Process, Planning & Tools
- https://gist.github.com/codedokode/a455bde7d0748c0a351a — Автоматизированное тестирование
- Антипаттерны тестирования ПО (unit-тесты, интеграционные тесты) (2018)
Баг репорт (bug report) = документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Составлять следует стремиться так, чтобы по названию или краткому описанию бага (summary) разработчик понял в чём соль проблемы, а прочитав детальное описание бага (description) он примерно представлял в в каком компоненте или даже его части ему надо искать ошибку.
| Значимость/серьёзность (severity) ошибок | |||
|---|---|---|---|
| 0 | остановка системы | server down | остановка работы системы |
| 1 | Потеря данных | data loss | Потеря пользовательских, операторских, системных данных |
| 2 | Потеря функциональности | functional loss | Блокирование основной функциональности. Могут включать в себя нефункциональные проблемы, например связанные с производительностью, которые вызывает неприемлемые задержки в использовании функций |
| 3 | Дыра в безопасности | security loss | |
| 4 | Потеря функциональности с наличием обходного пути | functional loss but alternate path exists | Блокирование основной функциональности, но для пользователя существует разумный обходной путь |
| 5 | Частичная потеря функциональности | partial functionality loss | Блокирование использования некоторой несущественной функциональности |
| 6 | Косметическая ошибка | cosmetic error | Значительные недостатки в пользовательском интерфейсе или в способности системы реагировать на запросы пользователя |
Тестировщики должны защищать качество и мнение пользователей о системе. Но они не должны это делать, выступая в качестве соперников программистов, выдвигая претензии личного характера или в неконструктивной манере. Предпочтительнее, если мы будем это делать путём, объединяющим реалии бизнеса с системной разработкой и сопровождением.
Правила оформления названия (subject) баг-репорта
Структура понятного названия таска:
<Где (название страницы)> : <Какой элемент/функция страницы> - <суть ошибки/задания>
Catalog Editor: Copy — not all existing catalogs shown in "select catalog" combobox
или Catalog Library -> Duplicate Catalog — If 'Use audience' option is marked, 'Shared with' data must be copied to the new catalog>
это годные названия. Ради того чтобы понять насколько проблема велика и срочна — не нужно открывать этот issue.
"Organizer", "Catalog properties page" — за такие названия тасков всего 400 лет назад отправляли на костёр. Потому что из него не понятно в чём суть, "ну page, ну и что, в чём проблема-то??".
Шаблон "тела" баг-репорта
DO: ("ДЕЙСТВИЯ", "ШАГИ ВОСПРОИЗВЕДЕНИЯ")
Укажите последовательность действий, поведайте — что именно было сделано вами для достижения того состояния системы, при котором вы столкнулись с ошибкой
RESULT: ("РЕЗУЛЬТАТ:")
Опишите последствия ваших действий, расскажите, что случилось, когда достигнута "точка невозвращения" и как баг проявляет себя
EXPECTED RESULT: ("ОЖИДАЕМЫЙ РЕЗУЛЬТАТ:")
Описание ожидаемого поведения системы при прохождении пользователем шагов, указанных в "DO". Ожидаемый результат должен соответствовать требованиям заказчика описанным документации либо здравому смыслу. Разработчик должен знать что ему надо сделать.
ADDITIONAL INFO: ("ДОПИНФО:")
Чтобы сделать хороший баг-репорт отличным — используйте любую возможность дополнить его, как то:
- Добавьте скриншоты (отметив на них, если нужно, важные места).
- Добавьте лог сервера или текст сообщения об ошибке (если эти сведения доступны).
- Добавьте свои соображения и предположения по поводу встреченного бага (коротко, если таковые имеются).
Пример баг-репорта
в проекте JIRA:
- добавить пользователей
- распределить их по группам
- настройка workflow для Тасков
- настройка состава полей для Тасков
- настройка канбан-досок
- создание components для того, чтобы отмечать к каким сервисам какой Таск-ТК трассируются
- настройка ролёвки для adaptavist по вышесозданным группам + включить трассировку Таск---ТК
в Test Adaptavist, связанном с этим проектом:
- кастомные поля для ТК (кто автоматизатор, какие компоненты/сервисы используются)
- components для заполнения кастомного поля в ТК
- настройка предоставлений списка ТК
- посоздавать папки, раскидать ТК
Способы уведомления о готовности тасков к автоматизации
- ассайном таска, связанного ссылкой с ТК;
- сменой статуса такого таска
- упоминанием в комменте таска
- голосом на дэйли
- письмом
- сменой статуса ТК в адаптависте