Перепроверка: Полное руководство с примерами и лучшими практиками

Ретестирование – это процесс проверки конкретной функции, которая не сработала во время предыдущего теста. Оно выполняется для проверки, были ли исправлены тестовые случаи, сообщающие о некоторых ошибках во время выполнения.

В жизненном цикле разработки программного обеспечения основными критическими элементами являются тестирование функциональности, производительности, безопасности и других аспектов программного обеспечения, что включает проверку программного обеспечения на наличие ошибок. Однако основной вызов заключается в проверке работы программного обеспечения в соответствии с целевой аудиторией. Обеспечение эффективности и надежности разработанного программного обеспечения чрезвычайно важно, и здесь ретестирование выступает в роли спасителя.

Основная цель тестирования программного обеспечения – выявление ошибок или багов в программном приложении. Тестовые инженеры ответственны за определение этих ошибок и сообщение о них команде разработчиков для дальнейшей оценки. Позже такие проблемы решаются и отправляются тестовому инженеру для повторной верификации.

Ретесты обеспечивают, что дополнительные проблемы не возникнут во время выпуска программного обеспечения. Такой процесс может быть выполнен вручную с использованием определенного набора тестовых случаев. Независимо от сложности, связанной с ретестами, мы должны понимать это как основную часть тестирования программного обеспечения для предоставления продуктов высокого качества.

Что такое Ретестирование?

Вы должны привыкнуть к тому, что обнаружение багов во время тестирования программного обеспечения является ролью тестовых инженеров. Среди таких задач они ответственны за исправление и отправку ошибки или проблемы обратно разработчикам, чтобы они исправили такую ошибку или проблему. И вот здесь приходит ретестирование. Давайте разберемся в этом более четко.

В разработке программного обеспечения, повторное тестирование — это процесс проверки билда, предоставленного разработчиками, чтобы убедиться, что ошибка исправлена. Проще говоря, допустим, вы тестируете программное обеспечение, которое имеет “Номер билда 1”, и если возникает какая-либо ошибка, её идентификатор, например, A1. Затем тестировщик проверяет такую ошибку и называет её “Номер билда 2”.

Другими словами, ошибка, обнаруженная в Номере билда 1, тестируется снова в Номере билда 2, чтобы проверить, исправил ли разработчик ошибку. Тестировщик здесь повторно проверяет неудачные случаи, чтобы подтвердить исправление, сделанное разработчиками.

Это часть жизненного цикла дефекта, где тестируются неудачные тестовые случаи, которые были нефункциональны на момент предыдущего теста и исправлены разработчиками.

Следуйте этим пунктам, чтобы получить больше информации о процессе повторного тестирования:

• Неудачные тестовые случаи, соответствующие сообщенным ошибкам, повторно тестируются.
• Другое название повторного тестирования — подтверждающее тестирование.
• Для сообщенной ошибки в новом билде следует использовать аналогичные тестовые данные и процессы для подтверждения её воспроизводимости.

A comprehensive example of the retest process will help you get a clearer picture.

Почему Повторное Тестирование Важно?

Повторное тестирование, являясь частью жизненного цикла тестирования программного обеспечения, имеет несколько значимых аспектов, связанных с эффективной доставкой продукта. Несомненно, это основной элемент стандартного процесса тестирования программного обеспечения. Но, кроме того, оно обеспечивает продукту дополнительный уровень гарантии, проверяя его технические и функциональные характеристики перед выпуском конечным пользователям.

Бизнесы должны гарантировать высококачественные цифровые приложения на этом высококонкурентном рынке разработки программного обеспечения. Это требует не допускать компромиссов в качестве конечного продукта.

Платформы автоматизированного тестирования часто могут помочь вам получить лучшую рентабельность инвестиций для вашего выпущенного продукта. Однако повторное тестирование дает больше уверенности, проверяя каждый баг. По сравнению с исходным процессом тестирования, оно не добавляет дополнительных затрат на тестовые ресурсы и не влечет значительного времени. Известно, что оно выполняется в том же окружении с аналогичными данными, связанными с неудачными тестовыми случаями.

Кроме того, процесс повторного тестирования решает конкретные проблемы или ошибки, отмеченные в определенных модулях приложения. Поэтому вам не нужно создавать новые тестовые среды и прилагать больше усилий для проверки качества продукта с помощью комплексного тестирования.

Пример повторного тестирования

Хотя вышеприведенный пример может помочь вам получить поверхностную информацию, ниже мы рассмотрим аналогичный пример, с более глубоким пониманием его процесса.

Сценарий

В рамках процесса разработки программного обеспечения выпущен Build 2.0. Во время его тестирования команда обнаружила и выявила дефект (назовем его Defect 2.0.1). Аналогичный Defect 2.0.1 должен быть протестирован в Build 2.1 (при условии, что этот дефект указан в заметках о выпуске Build 2.1), чтобы обеспечить устранение дефекта.

Процесс выполнения

Согласно Жизненному циклу ошибки, когда ошибка регистрируется, она сразу же передаётся или сообщается команде разработчиков. После этого её статус отмечается как “Новая”. Теперь решение о принятии или отклонении ошибки зависит от команды разработчиков.

При принятии ошибки разработчик её исправляет и затем выпускает в следующей фазе. Её статус отмечается как “Готово для QA”. В настоящее время тестировщики проверяют ошибку, чтобы определить её решение. Таким образом, можно сказать, что повторное тестирование – это запланированное тестирование.

Тестировщик использует те же тестовые случаи и тестовые данные, что и в предыдущей сборке. Если ошибки не обнаружено, её статус будет отмечен как “Исправлено”. Напротив, статус остаётся “Не исправлено”. Затем документ по повторному тестированию дефектов передаётся команде разработчиков.

Чтобы иметь хорошее понимание повторных тестов, необходимо знать их основные особенности. Это не только поможет разнообразить ваше тестирование, но и расширит возможности для обеспечения качества программного обеспечения.

Особенности повторного тестирования

Высококачественное тестирование пользовательского опыта в программном обеспечении следует итерационному процессу. Для этого сохранение информации о ключевых аспектах процесса повторного тестирования позволяет улучшить доставку приложений.

Ниже приведены его основные особенности:

• Оно реализуется в аналогичном документе, как и предыдущий, и процессах в новой сборке.
• Выполнение происходит, когда определенные тестовые случаи считаются проваленными.
• Это происходит, когда необходимо провести повторное тестирование всего программного обеспечения для подтверждения его качества.
• Невозможно автоматизировать тестовые случаи, которые подлежат повторному тестированию.
• Процесс повторного тестирования зависит от команды разработчиков, которая отвечает за принятие или отклонение бага.
• Тестировщик учитывает мелкие детали изменённого аспекта функциональности.

Когда стоит проводить повторное тестирование?

Будучи тестировщиком, важно определить, когда следует проводить повторное тестирование. Ответ на этот вопрос прост. Во-первых, необходимо учитывать размер и особенности вашего проекта, которые требуют тестирования.

Например, повторное тестирование становится обычным, если организация имеет обширную линейку продуктов, распределённых по разным продуктам. Причина в необходимости своевременного выпуска программного приложения, так как это может также влиять на другие части системы различными способами.

Существуют различные сценарии, когда можно использовать повторное тестирование в качестве процесса. Некоторые из них объяснены ниже:

При обнаружении отклонённого бага

Часто случается, что баг, выявленный тестировщиком, отклоняется разработчиком и помечается как “Не воспроизводимый”. В таких случаях проводится повторное тестирование того же бага, чтобы уведомить разработчика о том, что проблема воспроизводима и действительна.

Требование исправить баг, выделенное в заметках о выпуске

В процессе разработки программного обеспечения, когда команда разработчиков выпускает новый билд, преобладает повторное тестирование. Здесь тестировщик проверяет ранее сообщённые баги, чтобы убедиться в их исправлении.

Запрос клиента

Качество программного обеспечения является важным вопросом для каждой организации. Для обеспечения этого клиент может попросить провести повторное тестирование для определенных сценариев использования, чтобы обеспечить качество продукта.

Другие Сценарии

Важно отметить, что каждый раз, когда исправляется ошибка, разработчики создают дополнительные тестовые случаи. Это означает, что следует больше времени уделять написанию тестовых случаев, а не их исправлению. Однако, даже если вы уверены в своем коде, все равно необходимо проводить повторное тестирование важных частей приложения при каждом релизе.

Например, новая функциональность вызывает непредвиденное поведение и проблемы с обнаружением ошибок в первый раз. Возможно это только тогда, когда такие проблемы становятся очевидными во время тестирования или на основе отзывов пользователей. В этой ситуации необходимо провести “повторное тестирование” для преодоления сомнений относительно недавно обнаруженных ошибок.

Преимущества повторного тестирования

Качество программного приложения зависит от успеха процесса повторного тестирования. Оно обеспечивает стабильность приложения в жизненном цикле разработки программного обеспечения.

Некоторые из ключевых преимуществ выделены ниже:

• Обеспечивает, что ошибка исправлена или нет.
• Улучшает качество продукта и разработанного приложения.
• Обеспечивает работу приложения или продукта в соответствии с ожиданиями пользователя.
• Требует меньше времени для исправления ошибок, так как устраняется конкретная проблема.
• Работает с теми же данными и процессами с новым билдом для своей работы.
• Не требует установки новой тестовой среды.

Несмотря на наличие нескольких преимуществ, процесс повторного тестирования также имеет некоторые недостатки. Давайте разберемся в этом по нижеследующему разделу.

Недостатки повторного тестирования

A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.

Давайте разберемся, что это:

• Требуется новый билд для проверки дефектов.
• Тестовые случаи для повторного тестирования могут быть получены только при его инициации.
• Невозможно автоматизировать тестовые случаи для повторного тестирования.
• Повторное тестирование не прошедших тестовых случаев требует дополнительного времени и усилий.
• Повторные тесты не могут быть гарантированы как часть процесса тестирования, за исключением случаев, когда обнаружен или исправлен баг.

Рассматривая недостатки повторного тестирования, можно сказать, что повторное тестирование может быть сложным для некоторых тестировщиков. Особенно новичок часто пытается найти альтернативный способ решения проблемы. Здесь их сбивает с толку термин “регрессионное тестирование”. Однако регрессионное тестирование и повторное тестирование имеют значительные различия.

В чем разница между регрессионным тестированием и повторным тестированием?

Если вы новичок в области тестирования программного обеспечения, вы можете подумать, что термины “повторное тестирование” и “регрессионное тестирование” похожи. Однако на самом деле они оба различны, хотя и связаны. В этом разделе мы рассмотрим, как процесс повторного тестирования отличается от регрессионного тестирования.

Во-первых, регрессионное тестирование и повторное тестирование являются частью верификации программного обеспечения в процессе разработки программного обеспечения. Повторное тестирование в основном выполняется в конце определенной стадии разработки. Другими словами, когда вы хотите убедиться, что работающий продукт не изобилует ошибками из предыдущих тестов, вы проводите повторное тестирование. Напротив, регрессионное тестирование может выполняться на любой стадии разработки для обеспечения правильной работы конкретного аспекта кода.

В некоторых ситуациях тестировщики могут проводить повторные тесты, просто читая предыдущие выходные данные тестов или отчеты, чтобы проверить любую проблему и ее устранение. Также может быть проведена всестороннее расследование путем индивидуальной проверки предыдущих случаев, чтобы убедиться, что они обрабатываются. Однако регрессионное тестирование в основном выполняется с помощью плана тестирования и его выполнения на каждой версии приложения, начиная с самой последней. В таком подходе необходимо убедиться, что каждое изменение приложения тщательно протестировано.

Ниже приведены некоторые ключевые моменты о различиях между процессами регрессионного тестирования и повторного тестирования:

Понимание регрессионного тестирования и повторного тестирования на примере

Различия между регрессионным тестированием и повторным тестированием можно объяснить следующим примером.

Допустим, в веб-приложении банка возникла проблема на странице входа, где клиенты не могут получить доступ к своим учетным записям. Несмотря на то, что им было предложено попытаться войти еще раз, они не смогли войти в свои учетные записи. Служба поддержки изучила проблему и обеспечила, чтобы такое больше не происходило.

Команда разработчиков внесла изменения на уровне кода, чтобы обеспечить успешное логирование на страницу учетной записи во всех браузерах. Однако тестирование здесь включает не только страницу входа, но и проверяет, что изменения кода не влияют на другие функции веб-приложений банка. Здесь проводится тестирование приложения на модификацию, которое называется регрессионным тестированием.

Проверив проблему снова в соответствии с внесенными изменениями, тестирующая команда попыталась войти на страницу, но это не удалось. Поддержка связалась с разработчиком и объяснила проблему. Однако разработчик сообщил, что проблема уже исправлена. Проверка работоспособности веб-приложения QA-командой для контроля за решением проблемы называется повторным тестированием.

Таким образом, повторное тестирование является важным этапом процесса тестирования программного обеспечения и является предварительным условием для обеспечения его функционирования.

Мы рассмотрели важность процесса повторного тестирования, который дает представление о его связи с тестированием программного обеспечения. Во-первых, давайте разберемся с некоторыми типичными применениями в тестировании программного обеспечения. Вот некоторые применения повторного тестирования в тестировании программного обеспечения:

• Применено для исправления любых конкретных ошибок или багов, которые требуют проверки.
• Проверяет работу всей системы для подтверждения окончательной функциональности.
• Проверяет качество определенной части системы.

Этапы повторного тестирования

Процесс повторного тестирования включает в себя ручной подход. Он также учитывает основные фазы для тестирования программного приложения.

Ниже приведены этапы, участвующие в процессе повторного тестирования:

1. Выбор тестовых случаев 

Выбор тестов – это подход, при котором выполняются конкретные тестовые случаи из набора тестов для проверки, были ли устранены ошибки в программном обеспечении. Обычно тестовые случаи подразделяются на повторно используемые и устаревшие, где повторно используемые тестовые случаи используются для повторного тестирования.

2. Применение тестовых случаев

Главная цель процесса повторного тестирования – сравнить ожидаемый результат тестовых случаев. Поэтому необходимо применять тестовые случаи с стандартными предварительно выполненными таблицами результатов.

3. Оценка времени

При выборе тестовых случаев тестировщики должны учитывать общее время выполнения повторных тестов. Факторы, такие как оценка тестовых случаев, могут добавить дополнительное время.

4. Отслеживание модулей

В случаях с неудачными тестовыми случаями, определение соответствующих модулей для ошибки является серьезной проблемой. Поэтому программное обеспечение делится на различные отдельные модули.

Для этого реализуются небольшие тестовые случаи для конкретных отдельных модулей. Модули, не показывающие ожидаемых результатов, маркируются как дефектные модули. Таким образом, отслеживание дефектных модулей выполняется.

5. Повторное тестирование модуля

Повторно тестируйте дефектный модуль до тех пор, пока он не будет исправлен.

6. Реинтеграция модуля

После исправления дефектного модуля применяется полная интеграция тестовых случаев к программному обеспечению. Далее проверяется работа программного обеспечения.

Как проводить повторное тестирование?

Повторное тестирование программного приложения может быть выполнено только вручную. Как упоминалось выше, основной причиной является то, что оно фокусируется только на конкретной ошибке. Поэтому для ручного тестирования это подходит, так как оно может быть выполнено точно, в отличие от автоматизированного метода.

Чтобы запустить повторное тестирование, команда тестирования должна хорошо знать текущий статус программного приложения. Знание работы программы и того, как сделать ее эффективной путем исправления ошибок, облегчает ручной подход.

Тестировщик выполняет тесты вручную для проверки внесенных изменений в приложении. Это делается для того, чтобы убедиться, что такие изменения не вызывают дополнительных дефектов, и что выявленные непройденные случаи устранены в новом релизе. Вы можете выполнить ручное повторное тестирование после изменения изменений в программе, устранения дефектов и завершения цикла тестирования программного обеспечения.

Вы можете следовать следующим шагам, чтобы выполнить повторное тестирование вручную:

1. Определите изменения в программном приложении и область, которая требует повторного тестирования.
2. Просмотрите и обновите тестовые случаи, требующие повторного тестирования, в соответствии с изменениями.
3. Разработанные тестовые случаи должны быть выполнены вручную.
4. Проанализируйте фактический результат с ожидаемым результатом, чтобы оценить, что изменения не вызывают новых дефектов.
5. Если обнаружена ошибка, задокументируйте ее и сообщите команде разработки.
6. Повторите процесс ручного повторного тестирования до тех пор, пока все недостатки не будут исправлены.

Однако вы можете задаться вопросом, почему повторное тестирование не может быть выполнено с использованием автоматизированного подхода. Существует несколько причин для этого. Давайте разберемся по порядку:

Может ли повторное тестирование быть автоматизированным?

Невозможно провести повторное тестирование приложения с использованием автоматизированного подхода. Ниже выделены некоторые общие причины:

• Сложность: Некоторые из невыполненных случаев могут возникать из-за сложности программного обеспечения. Поэтому такие невыполненные случаи трудно автоматизировать.
• Непредвиденный результат: Изменения, внесенные в программное обеспечение, могут привести к непредвиденным результатам. В таких ситуациях невыполненные случаи требуют ручного тестирования для проверки результата.
• Затраты и ресурсы: Автоматизация процесса повторного тестирования может быть дорогостоящей, так как это требует использования дополнительного аппаратного и программного обеспечения. Проблематично оправдать стоимость минимальных изменений в программном обеспечении.
• Ограничение по времени: Автоматизация процесса повторного тестирования требует большого количества времени, и поскольку может быть давление по срокам выпуска, лучшим вариантом является ручной подход.

Что учесть при проведении повторного тестирования

К настоящему времени мы уже поняли важность процесса повторного тестирования и как его проводить. Однако существуют важные моменты, которые необходимо учитывать при повторных тестах. Ниже приведены некоторые аспекты, которые следует принять во внимание.

• Процесс повторного тестирования требует создания новой сборки программного обеспечения, когда проблема устранена на основе первого отчета.
• Возможно, что программное обеспечение, отправленное на повторные тесты, может претерпеть изменения на уровне кода. Поэтому крайне важно провести регрессионное тестирование перед выпуском приложения.
• Количество и объем повторных тестов можно определить только после устранения проблемы. В результате автоматизация не может быть применена для повторного тестирования, как в случае с регрессией.
• Сроки разработки приложения могут увеличиться, если проблемы, обнаруженные при повторном тестировании, продолжают существовать. Необходимо провести более всестороннюю и стратегическую оценку для выявления причины.

Тем не менее, несмотря на сложности, возникающие в процессе повторного тестирования, организация должна сосредоточиться на методах тестирования с осознанием ответственности. Это может быть лучше сделано путем проведения повторных тестов в облаке. Давайте рассмотрим это подробнее.

Как выполнять повторное тестирование в облаке?

Автоматизация процесса повторного тестирования не всегда осуществима, и требуется ручное тестирование для обеспечения качества программного обеспечения. Однако в некоторых случаях это может занять много времени и не является масштабируемым процессом. Платформы облачного тестирования помогают преодолеть проблемы, связанные с инфраструктурой тестирования.