Жизненный цикл дефекта. Как вы уже знаете, выполнение теста - это фаза, на которой тестировщик фактически выполняет сценарии тестирования. Процесс выполнения тестовых сценариев варьируется от компании к компании и может отличаться в разных проектах в рамках одной компании.
В наши дни доступны инструменты для выполнения тестов, такие как - Quality Center, Microsoft visual studio и так далее. Фактический процесс выполнения каждого шага для сравнения фактического и ожидаемого результатов остается неизменным для функционального тестера независимо от используемых инструментов.
- Что если фактическое поведение не равно ожидаемому поведению?
Когда тестировщик обнаруживает, что фактический результат тестирования не равен ожидаемому результату, регистрируется дефект.
- Как зарегистрировать дефект?
В настоящее время доступно множество инструментов, некоторые из них - ClearQuest от IBM, центр качества HP, инструменты с открытым исходным кодом, такие как жизненный цикл дефектов в JIRA и т. Д.
Есть некоторые обязательные поля, которые являются общими для различных инструментов регистрации дефектов, эти поля:
- Дефект жизненного цикла Описание
- Краткое описание жизненного цикла дефекта
- Дефект зарегистрирован
- Дефект назначен
- Степень серьезности дефекта
- Приоритет дефекта
- Дополнительные снимки
- Номер релиза / Название
Жизненный цикл дефекта
Жизненный цикл дефекта начинается с регистрации нового дефекта. Всякий раз, когда дефект регистрируется, он переходит в состояние «Новый».
Тестер - Новый Дефект
Кому назначить новый дефект?
Тестер может назначить дефект разработчику или руководителю разработки. Это решение о назначении дефектов варьируется от проекта к проекту. На некоторых рабочих местах существует процесс жизненного цикла дефекта для назначения его непосредственно соответствующему разработчику, а в некоторых местах дефект сначала назначается ведущему устройству, а ведущее устройство в свою очередь назначает его разработчику.
Назначение дефекта (новый) - разработчик жизненного цикла дефекта
Назначение дефектов (новый) - разработчик Dev Leadà
Анализ дефектов
Разработчик проанализирует дефект, чтобы проверить его воспроизводимость. Здесь самым важным вкладом тестера является включение всех необходимых деталей в дефект. Краткое описание дефекта, подробное описание дефекта - это поля, которые помогают заинтересованным сторонам понять дефект за один раз. Сводка дефекта всегда должна содержать только информацию высокого уровня дефекта. В то же время он должен иметь достаточно информации, чтобы описать обзор дефекта в одной строке.
Описание дефекта - это место, где тестер должен включать всю необходимую информацию, такую как среда, сценарий, использованные данные теста, ожидаемый результат, фактический результат, ссылка на файлы / данные и ссылка на снимок.
Вот краткий обзор различных элементов Дефекта. Подробное описание -
Окружающая обстановка
Тестовая среда, в которой был обнаружен дефект. Часто проекты имеют несколько сред тестирования, в которых группа тестирования выполняет тестирование. Например - AT (Среда тестирования сборки), PT (Среда тестирования продукта), UAT (Среда тестирования приемлемости пользователя) и так далее. Цель наличия различных сред состоит в том, что она обеспечивает гибкость в группе разработчиков и тестировщиков для развертывания кода в любой доступной среде для своевременного начала тестирования.
Бывают случаи, когда тестирование продукта (также называемое тестированием системы) и тестирование UAT частично совпадают, поэтому для продолжения тестирования параллельно необходимо наличие нескольких сред.
Бывают случаи, когда команде разработчиков требуется дополнительная среда для устранения проблем, сообщенных группой тестирования. Также команда разработчиков имеет специальную среду для задачи модульного тестирования.
Следовательно, для нескольких сред необходимо указать в дефекте конкретную среду, в которой была обнаружена проблема.
сценарий
Сценарий - это набор шагов, выполненных тестером, которые привели к дефекту. Здесь тестер должен упомянуть все шаги, которые разработчик может выполнить, чтобы воспроизвести дефект. Часто бывают случаи, когда тестер сообщает о дефекте, но разработчик не может его воспроизвести, и, следовательно, дефект отклоняется. Это может произойти из-за неправильных шагов / пропущенных шагов, упомянутых в описании. Четкие шаги помогают каждому понять дефект и воспроизвести его, не имея зависимости от обращения к тестеру для получения входных данных. Хорошо документированный сценарий имеет легкий для чтения, легкий для понимания и точный шаг, который необходимо выполнить, чтобы воспроизвести дефект.
Тестовые данные
Предполагается, что тестер упоминает данные, использованные в ходе тестирования, которое привело к проблеме. Эта информация дает разработчику возможность использовать подобные данные, чтобы воспроизвести дефект и найти его причину.
Есть несколько сценариев, в которых тестировщик обнаруживает дефект, используя определенные данные, но та же проблема не воспроизводится при использовании данных подобного типа. Это может произойти из-за повреждения данных, поэтому ввод данных дает возможность выяснить причину неисправности. Разработчик может не докопаться до уровня кода, если имеет место повреждение данных. Этот вид дефекта может быть преобразован в дефект данных.
Ожидаемый и фактический результат
Это основной момент поля подробного описания, в котором тестировщик доказывает, что обнаруженная ошибка действительно является дефектом. Четкое упоминание ожидаемого результата позволяет каждому заинтересованному лицу понять, что ошибка является дефектом. Представьте, что дефект записан со всеми деталями, но он не определяет ожидаемый результат сценария!
Обычно тестер вводит только ожидаемый результат, может быть в одну или две строки, однако очень важно указать источник ожидаемого результата. Источник здесь - ссылка на документ, где упоминается ожидаемый результат. Это может быть документ с требованием или ссылка на раскадровку.
Ссылка на файлы / данные
Иногда дефект включает в себя создание файла или ввода в виде файла. В таких сценариях тестер должен предоставлять информацию об используемом файле, который вызвал проблему в приложении. Эти файлы могут быть прикреплены с помощью инструмента управления дефектами, или может быть предоставлена ссылка на них. Эти эталонные места должны быть доступны для всех заинтересованных сторон.
Ссылка на снимок
Снимки играют очень важную роль, когда вы хотите показать им точное сообщение об ошибке разрыва страницы, отображаемое на экране, или когда вы хотите показать подробности навигации по экрану. Снимок дает быстрое представление о обнаруженном дефекте, экране, на котором обнаружен дефект, данных, используемых на экране, и так далее. Каждый инструмент управления дефектами имеет возможность прикрепить снимки. Иногда тестер также может прикреплять электронные таблицы Excel или текстовые документы.
Это были различные компоненты регистрации дефектов и лучшие практики для каждого из них. Возвращаясь к жизненному циклу дефекта, как только дефект назначен разработчику, он / она проанализирует его, используя данные, представленные в элементе дефекта. Если в соответствии с анализом зарегистрированная проблема действительно является дефектом, разработчик «откроет» дефект, чтобы поработать над его исправлением.
Рекомендуемые курсы
- Веб-сервисы в Java Training Bundle
- Тренинг по разработке игр на C ++
- Пройдите обучение этике хакерства
- Vegas Pro 13 учебных курсов
Новый - Открытый
Дефект в статусе Open показывает, что он находится на платформе разработки, и разработчики работают над его исправлением. Если анализ обнаружит, что зарегистрированная проблема не является дефектом, это может произойти, если в ожидаемом поведении системы есть пробел в понимании. Если анализ говорит, что дефект недействителен, разработчик отклонит дефект. Терминология «Отклонено» или «Вернуться к тестированию».
Новое - Вернуться к тестированию.
Как тестер должен проверить, действительно ли дефект был недействительным?
Это сценарий, в котором точный документ с требованиями помогает каждому в команде прийти к выводу, был ли зарегистрированный дефект недействительным или действительным. Ссылка на документы с требованиями помогает тестировщику, а также разработчику прийти к одинаковому выводу, и это действительно облегчает процесс обсуждения.
Существуют сценарии, в которых правильность документов разработки и требований ставится под сомнение при обращении к этим документам во время обсуждений дефектов, и в такие моменты возврат к Business Analyst считается наилучшим вариантом для уточнения запросов.
В соответствии с передовой практикой, требования и проектные документы должны всегда быть актуальными, чтобы на них можно было ссылаться без двусмысленностей
В статусе «Открыто», команда разработчиков работает над исправлением дефекта, после устранения дефекта статус меняется на «Готов к развертыванию».
Открыто - готово к развертыванию
Развертывание - это процесс, в котором изменения загружаются на сервер, поэтому группа тестирования может работать с фиксированной версией кода. Обычно каждый проект имеет отдельную группу развертывания для этой задачи.
Так что на высоком уровне команда разработчиков программного обеспечения состоит в основном из этих трех групп:
- развитие
- Жизненный цикл дефекта в тестировании
- Развертывание (или иногда его называют командой сборки)
Как только сборка развернута и дефект снова доступен для повторного тестирования, он назначается соответствующему тестировщику для задачи повторного тестирования.
Дефект, назначенный - тестовый вывод.
Test Lead - Индивидуальный тестер.
Назначенный дефект - Индивидуальный тестер.
На некоторых рабочих местах дефект сначала назначается тестирующему проводнику, и он / она, в свою очередь, назначает его отдельному тестировщику, однако в некоторых местах дефект назначается непосредственно тестировщику, который будет его тестировать, или тому, кто выявил дефект.
Статус здесь меняется с «Готов к развертыванию» - «Готово SIT Testing».
Теперь дефект в табличке тестера. Команда тестирования проверит дефект, и есть две возможности: исправление будет работать корректно, или с той же самой проблемой снова столкнутся. В зависимости от результата дефект может перейти к следующим статусам -
Ready SIT Тестирование - Закрыто
Ready SIT Testing - Вновь открыть
В обоих вышеописанных сценариях тестировщик должен добавить комментарии о проведенном тестировании. Это включает упоминание проверенных сценариев и использованных данных. Если дефект вновь открывается, тестер должен предоставить точные выполненные шаги, которые снова привели к ошибке.
Повторно открыть статус такой же, как «Новый» статус дефекта.
После повторного открытия дефекта он будет повторять тот же цикл.
Проблемы жизненного цикла дефектов
- Определение серьезности дефекта - это одна из распространенных тем обсуждения (часто ссор) среди тестировщиков и разработчиков.
- Дефект не воспроизводится в системе разработчика.
- Дефект возник по сценарию, который не упоминается в требованиях и проектной документации.
- Дефект обнаружен, но его нельзя устранить, так как возникновение сценария в производственной среде невозможно.
Как тестер должен преодолевать вышеперечисленные проблемы?
- Серьезность прямо пропорциональна влиянию, которое дефект вызывает в приложении. Если тестер не может продолжить работу из-за дефекта, он обязательно помечается с наивысшей серьезностью.
- Если существует обходной путь для продолжения тестирования, его следует пометить как средний уровень серьезности. Кроме того, помимо учета влияния дальнейшего тестирования жизненного цикла дефекта, серьезность также может быть решена с учетом ситуации, когда происходит сбой всего модуля, в этом случае, даже если тестирование другого модуля может быть выполнено, но серьезность для текущего модуля высока поэтому дефект должен быть отмечен с наибольшей серьезностью.
- Если дефект не может быть воспроизведен в системе разработчика, есть вероятность, что среда разработки и тестирования не синхронизированы. Дефект, воспроизводимый в системе тестирования, всегда считается допустимым дефектом.
- Существуют ситуации, когда дефект регистрируется с учетом общего бизнес-сценария, но прямой сценарий не упоминается в требованиях или проектной документации. Рекомендуется всегда рассматривать реальные бизнес-сценарии, а не просто следовать шагам тестирования. Связь с бизнес-аналитиками и другими заинтересованными сторонами продукта играет важную роль для регистрации таких дефектов.
- Существуют сценарии, когда тестировщик обнаруживает пробел в бизнес-логике на этапе тестирования. Поиск таких пробелов снова считается большим плюсом для тестировщика. Пробелы в дизайне обычно обрабатываются с помощью улучшений.
- Улучшение. Если поведение необходимо изменить на этапе тестирования жизненного цикла программного обеспечения, создается усовершенствование, которое может быть принято в текущем или следующем выпуске с учетом сроков и пропускной способности групп разработчиков и тестировщиков.
- Существует несколько сценариев, которые тестировщик может протестировать во время специального тестирования, которые на самом деле могут быть недопустимыми сценариями, учитывая возможность их появления в производстве.
Кто лучший друг тестера?
Куда должен идти тестер в случае двусмысленности? Ответ зависит от типа запроса, если запрос касается требований, желательно сначала обсудить в группе, чтобы правильно понять систему, возможно, посоветовавшись со старшими членами. Следующей точкой контакта должны стать бизнес-аналитики.
Если запрос касается процесса тестирования, рекомендуется обратиться к руководителю или руководителю тестирования.
Если запрос касается понимания технических особенностей приложения, то член команды разработчиков может быть правильным человеком, к которому можно обратиться.
Поскольку тестирование - это процесс, который требует общего понимания системы, общение помогает тестировщику быстро получить ответы на вопросы, оно просто зависит от правильных вопросов к правильным людям. Уклонение от необходимости задавать вопросы в нужное время может привести к утечке в производственную среду.
Насколько важна роль тестера в корпоративной среде сегодня?
Существуют проекты, в которых команда тестирования в равной степени важна, как команда разработчиков, и в некоторых случаях зависимость от команды тестирования больше, чем от команды разработчиков. Более поздний сценарий редок, но он существует на некоторых рабочих местах. Это происходило с течением времени и может происходить в течение определенного периода времени, когда команда разработчиков не имеет большого опыта по сравнению с командой тестирования. Есть люди, которые понимают общий поток и функциональность лучше, чем большинство других членов команды. Такой человек может быть частью команды тестирования / разработки. Это один из факторов, который решает зависимость от команды / человека для конкретного проекта.
Каков карьерный путь для тестировщика?
Человеку может потребоваться некоторое время, чтобы понять весь процесс тестирования, предметную область и другие задачи, над которыми он / она должен работать в повседневной жизни. Основываясь на этом понимании, желательно принять решение, чтобы исследовать дальнейшие области, которые может занять тестировщик. В этом процессе всегда есть возможности для автоматизации различных потоков. Создание небольших утилит также может помочь команде. Если тестер хорош в программировании, это считается большим плюсом. Это открывает возможности для автоматизации ролей. Тестирование производительности также является одним из треков карьеры для тестировщиков. Бизнес-аналитик является еще одним вариантом. Хорошие знания предметной области с хорошими коммуникативными навыками являются необходимыми навыками для бизнес-аналитики. Тестирование открывает множество возможностей для работы тестировщиков в различных областях, инструментах, процессах и так далее. Это просто зависит от человека, который должен взять и начать углубляться в одну из основных областей тестирования. Существует множество сертификатов, специфичных для различных инструментов, которые специализируются в одной области тестирования. Наличие сертификата от стандартного поставщика является преимуществом для карьерного роста, но сам по себе сертификат не может помочь вам в долгосрочной перспективе, если он не сочетается с правильным опытом работы.
Рекомендуемые статьи
Вот несколько статей, которые помогут вам получить более подробную информацию о тестировании программного обеспечения, поэтому просто перейдите по ссылке.
- 6 самых удивительных вопросов для интервью по тестированию программного обеспечения
- Карьера в тестировании программного обеспечения
- Как добиться лучшего карьерного роста в работе тестировщика программного обеспечения