Для начинающих: для чего нужен чек-лист в тестировании, основные понятия, пример
Допустим, вы имеете общее представление о тестировании, ознакомились с основными терминами и примерами. Но, когда дело доходит до конкретного случая, не знаете, с чего начать и за что взяться. Как вообще проверять продукт, пусть даже и вручную? Как не забыть что-то важное? Для этого существуют чек-листы. Сегодня мы о них и поговорим.
Что такое чек-лист?
Чек-лист – это базовый инструмент тестирования, который поможет вам не забыть о важных тестах, отслеживать прогресс и результат работы. Обычно он выглядит как таблица-список возможных проверок составляющих продукта: страниц, блоков и прочих элементов. Пункты такого списка должны быть минималистичными и предельно понятными. Обязательными столбцами являются версии операционных систем и браузеров, так как в них продукт будет вести себя по-разному. Также стоит отметить, что чек-лист – это уникальный список, создаваемый под конкретный продукт. Под другой продукт применять его будет уже неверно.
Одна строка чек-листа должна отражать одно действие, описанное глаголом в начальной форме. Например:
- оформить заказ;
- оплатить заказ.
- оформить и оплатить заказ.
Смешивать и соединять две операции (действия) в один пункт нельзя.
- оформление заказа.
Каждый пункт должен описываться с помощью глагола, а не существительного. Так будет понятно конкретное, а не абстрактное действие для проверки.
При выполнении пункта чек-листа в столбце статуса отмечается этап проверки, например, Passed (пройден) или Failed (не пройден). В последнем случае можно добавить комментарий о багах. Также суествуют статусы Not run (тест пока не проводился) и Blocked (проверка заблокирована).
Ниже представлен один из базовых примеров чек-листа:
Статус Passed зеленым цветом показывает, что проверка успешно пройдена.
Если же статус – Failed, желательно добавлять в примечания ссылку на баг-репорт.
Плюсы чек-листов:
- исключается повторная проверка по тем же кейсам;
- повышается качество тестирования, так как снижается вероятность оставить какой-либо пункт без внимания;
- экономия рабочего времени: однажды написанный чек-лист можно использовать повторно на одном и том же проекте.
Насколько детальным будет чек-лист, зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Подробнее о чек-листах мы рассказываем на курсе ПОИНТ, который стартует ежемесячно. Следить за актуальным расписанием можно в нашей группе VK.
Присоединяйтесь, чтобы попрактиковаться в составлении чек-листов и получить множество других полезных знаний о тестировании, которые помогут вам быстро найти работу в индустрии. Курс ПОИНТ ориентирован на практику: вас ждет 17 вебинаров и 17 практических заданий, за время которых вы освоите все нюансы профессии!
Skip и xfail : работа с тестами, которые не могут быть пройдены¶
Тестовые функции, которые не могут быть запущены на определенных платформах или от которых вы ожидаете сбоя, можно пометить так, чтобы pytest работал с ними соответствующим образом и представлял сводку сеанса тестирования, считая набор тестов пройденным и помечая его зеленым.
skip (пропуск) используется в случае, когда вы ожидаете, что ваш тест пройдет только при соблюдении некоторых условий, в противном случае pytest должен полностью пропустить выполнение теста. Распространенными примерами являются пропуск тестов только для windows на платформах, отличных от windows, или пропуск тестов, зависящих от внешнего ресурса, который в данный момент недоступен (например, базы данных).
xfail применяется, когда вы ожидаете, что тест по каким-то причинам должен упасть. Обычный пример — это тест на еще не реализованную функцию или еще не исправленную ошибку. Когда тест, помеченный pytest.mark.xfail , проходит, несмотря на ожидаемое падение, в сводке результатов он будет помечен как xpass.
pytest подсчитывает и перечисляет тесты, помеченные skip и xfail , отдельно. Подробная информация о пропущенных / упавших тестах по умолчанию не отображается, чтобы не загромождать выходные данные. Чтобы увидеть детали, соответствующие «коротким» буквам, показанным в ходе выполнения теста, можно использовать параметр -r , как показано ниже:
pytest -rxXs # показывать дополнительную информацию о тестах xfailed, xpassed, и skipped
Больше информации о параметре -r можно получить, выполнив команду pytest -h (вызов справки).
Пропуск тестовых функций¶
Простейший способ пропустить тестовую функцию — пометить ее декоратором skip , которому может быть передана в качестве параметра reason причина пропуска:
@pytest.mark.skip(reason="no way of currently testing this") def test_the_unknown(): .
Также можно пропустить тест непосредственно во время выполнения, вызвав функцию pytest.skip(reason) :
def test_function(): if not valid_config(): pytest.skip("unsupported configuration")
Такой способ может быть полезен, когда невозможно определить условие пропуска во время импорта.
Можно также пропустить выполнение всего тестового модуля — для этого на уровне модуля используется метод pytest.skip(reason, allow_module_level = True) :
import sys import pytest if not sys.platform.startswith("win"): pytest.skip("skipping windows-only tests", allow_module_level=True)
skipif ¶
Этот декоратор используется, если вы хотите пропускать или не пропускать тесты в зависимости от выполнения какого-либо условия. Ниже — пример тестовой функции, которую следует пропустить при запуске интерпретатора Python ниже версии 3.6:
import sys @pytest.mark.skipif(sys.version_info (3, 6), reason="requires python3.6 or higher") def test_function(): .
Если во время сбора данных условие выполняется (принимает значение True ) — тестовая функция будет пропущена, а указанная причина при использовании параметра -rs отобразится в отчете.
Маркер skipif можно использовать совместно для нескольких модулей. Рассмотрим следующий тестовый модуль:
# content of test_mymodule.py import mymodule minversion = pytest.mark.skipif( mymodule.__versioninfo__ (1, 1), reason="at least mymodule-1.1 required" ) @minversion def test_function(): .
Можно импортировать маркер и использовать его в другом тестовом модуле:
# test_myothermodule.py from test_mymodule import minversion @minversion def test_anotherfunction(): .
Для больших наборов тестов обычно рекомендуется иметь один файл, в котором определяются маркеры, которые затем последовательно применяются во всем наборе тестов.
Кроме того, можно использовать строки условий (см. Conditions as strings instead of booleans) вместо логических значений, но их нельзя легко переносить между модулями, поэтому они поддерживаются главным образом из соображений обратной совместимости.
Пропуск всех тестовых функций класса или модуля¶
Маркер skipif (так же, как и остальные маркеры) можно использовать для класса:
@pytest.mark.skipif(sys.platform == "win32", reason="does not run on windows") class TestPosixCalls: def test_function(self): "will not be setup or run under 'win32' platform"
Если условие выполняется, маркер будет применен для каждого тестового метода класса.
Если вы хотите пропустить все тестовые функции модуля, вы можете использовать pytestmark на глобальном уровне:
# test_module.py pytestmark = pytest.mark.skipif(. )
Когда к тестовой функции применяется несколько декораторов skipif , она будет пропущена, если верно любое из условий пропуска.
Пропуск файлов и директорий¶
Иногда может потребоваться пропустить весь файл или каталог, например, если тесты основаны на специфических для версии Python функциях или содержат код, который вы не хотите запускать с помощью pytest . В этом случае необходимо исключить файлы и каталоги из коллекции. Дополнительную информацию смотрите в разделе Настройка поиска тестов .
Пропуск тестов в зависимости от успешности импорта¶
Вы можете пропустить тесты в случае неудачного импорта, применив pytest.importorskip на уровне модуля, в рамках теста или «setup»-фикстуры:
docutils = pytest.importorskip("docutils")
В данном случае, если docutils не будет импортирован, то тест будет пропущен. Также можно пропустить тест в зависимости от версии импортируемой библиотеки:
docutils = pytest.importorskip("docutils", minversion="0.3")
При этом версия считывается из специального атрибута модуля __version__ .
Краткая сводка¶
Вот краткая шпаргалка, как пропускать тесты в различных ситуациях:
- Пропустить все тесты модуля:
pytestmark = pytest.mark.skip("all tests still WIP")
- Пропустить все тесты модуля при выполнении какого-то условия:
pytestmark = pytest.mark.skipif(sys.platform == "win32", reason="tests for linux only")
- Пропустить все тесты модуля при неудачном импорте:
pexpect = pytest.importorskip("pexpect")
XFail : маркируем тесты, которые должны упасть¶
Маркер xfail используется для пометки ожидаемо падающих тестов:
@pytest.mark.xfail def test_function(): .
Такой тест будет запущен, но при падении не вызовет сообщения об ошибке. В отчете он будет помещен в раздел ожидаемых сбоев ( XFAIL ) или неожиданно прошедших ( XPASS ).
Маркировку xfail можно установить непосредственно в функции (или в «setup»-фикстуре):
def test_function(): if not valid_config(): pytest.xfail("failing configuration (but should work)")
def test_function2(): import slow_module if slow_module.slow_function(): pytest.xfail("slow_module taking too long")
Эти два примера иллюстрируют ситуации, в которых вы не хотите проверять условие на уровне модуля.
Обратите внимание, что в случае вызова pytest.xfail (в отличие от маркировки с помощью @pytest.mark.xfail ) код, расположенный после этого вызова, выполняться не будет. Это происходит потому, что внутренне метод реализуется путем создания определенного исключения.
Параметр strict ¶
Ни XFAIL , ни XPASS по умолчанию не приводят к падению всего набора тестов. Но это можно изменить, установив параметру strict значение True :
@pytest.mark.xfail(strict=True) def test_function(): .
В этом случае, если тест будет неожиданно пройден ( XPASS ), то это приведет к падению всего тестового набора.
Значение по умолчанию параметра strict можно изменить в настройках (в файле«pytest.ini«), используя опцию xfail_strict :
[pytest] xfail_strict=true
Параметр reason ¶
Так же, как и при использовании skipif, можно установить зависимость маркировки xfail от определенного условия:
@pytest.mark.xfail(sys.version_info >= (3, 6), reason="python3.6 api changes") def test_function(): .
Параметр raises ¶
Если вы хотите уточнить причину сбоя теста, вы можете указать одно исключение или кортеж исключений в параметре raises :
@pytest.mark.xfail(raises=RuntimeError) def test_function(): .
В этом случае тест будет объявлен в отчете, как обычный сбой, если он не выполняется с исключением, упомянутом в параметре raises .
Параметр run ¶
Если тест должен быть помечен и учитываться в отчете как маркированный xfail , но при этом даже не должен выполняться, можно установить параметр run в значение False :
@pytest.mark.xfail(run=False) def test_function(): .
Это особенно полезно для тестов xfail , которые приводят к сбою интерпретатора и должны быть исследованы позже.
Игнорирование xfail ¶
Используя параметр —runxfail , можно принудительно запускать и выполнять тесты, помеченные xfail , как обычные непомеченные тесты:
pytest --runxfail
В этом случае метод pytest.xfail также будет игнорироваться.
Примеры¶
Простой тест с несколькими примерами:
import pytest xfail = pytest.mark.xfail @xfail def test_hello(): assert 0 @xfail(run=False) def test_hello2(): assert 0 @xfail("hasattr(os, 'sep')") def test_hello3(): assert 0 @xfail(reason="bug 110") def test_hello4(): assert 0 @xfail('pytest.__version__[0] != "17"') def test_hello5(): assert 0 def test_hello6(): pytest.xfail("reason") @xfail(raises=IndexError) def test_hello7(): x = [] x[1] = 1
Запустив его с параметром -rx (report-on-xfail), получим следующий отчет:
example $ pytest -rx xfail_demo.py =========================== test session starts ============================ platform linux -- Python 3.x.y, pytest-5.x.y, py-1.x.y, pluggy-0.x.y cachedir: $PYTHON_PREFIX/.pytest_cache rootdir: $REGENDOC_TMPDIR/example collected 7 items xfail_demo.py xxxxxxx [100%] ========================= short test summary info ========================== XFAIL xfail_demo.py::test_hello XFAIL xfail_demo.py::test_hello2 reason: [NOTRUN] XFAIL xfail_demo.py::test_hello3 condition: hasattr(os, 'sep') XFAIL xfail_demo.py::test_hello4 bug 110 XFAIL xfail_demo.py::test_hello5 condition: pytest.__version__[0] != "17" XFAIL xfail_demo.py::test_hello6 reason: reason XFAIL xfail_demo.py::test_hello7 ============================ 7 xfailed in 0.12s ============================
Skip / xfail с параметризацией¶
При использовании параметризации можно маркировать skip/xfail отдельные экземпляры тестов:
import pytest @pytest.mark.parametrize( ("n", "expected"), [ (1, 2), pytest.param(1, 0, marks=pytest.mark.xfail), pytest.param(1, 3, marks=pytest.mark.xfail(reason="some bug")), (2, 3), (3, 4), (4, 5), pytest.param( 10, 11, marks=pytest.mark.skipif(sys.version_info >= (3, 0), reason="py2k") ), ], ) def test_increment(n, expected): assert n + 1 == expected
pytest
- Что такое pytest
- Установка
- Содержание
- Примеры
- Конфигурирование
- Лицензия
- Skip и xfail : работа с тестами, которые не могут быть пройдены
- Пропуск тестовых функций
- skipif
- Пропуск всех тестовых функций класса или модуля
- Пропуск файлов и директорий
- Пропуск тестов в зависимости от успешности импорта
- Краткая сводка
- Параметр strict
- Параметр reason
- Параметр raises
- Параметр run
- Игнорирование xfail
- Примеры
Навигация:
- Оглавление
- Предыдущий раздел: Маркировка тестов
- Следующий раздел: Параметризация фикстур и тестовых функций
Полезные ссылки
- pytest @ PyPI
- pytest @ GitHub
- 3rd party plugins
- Issue Tracker
- PDF Documentation
©2015–2020, holger krekel and pytest-dev team. | Powered by Sphinx 2.1.0 & Alabaster 0.7.12 | Page source
Свойства качественных тест-кейсов
Тест-кейс, как и чек-лист, является направляющим документом. Он содержит полноразмерное описание всего процесса работы по проверке функциональности цифрового продукта. Благодаря этому документу тестировщик систематизирует и упрощает свою деятельность. Структуризация – один из лучших способов сделать информацию понятной и последовательной. Чтобы тест-кейс можно было считать качественным, он должен отвечать ряду требований. Они непосредственно касаются содержимого документа, его структуры и используемых формулировок.
Каковы характеристики хорошего тест-кейса?
Тест-кейсы, в отличие от чек-листов, являются объёмными и детализированными. Но недостаточно только грамотно оформить этот документ и привести его структуру в порядок. Следующие свойства тест кейсаявляются показателями их качества:
- грамотный технический язык, чёткость используемых формулировок;
- последовательное и понятное изложение, отсутствие «пробелов» в информации;
- использование только безличных глаголов (например, «войти» вместо «войдите»);
- конкретика, детальность всех стадий;
- правильное указание названий, наименований в тексте.
Нежелательно и добавлять в документ объяснение примитивных вещей. Команда тестировщиков «по умолчанию» должна знать базовые принципы взаимодействия с компьютером. Также недопустимо называть одинаковые явления разными словами, поскольку это может вызвать недопонимание. Хороший тест кейс– это сочетание лаконичности, конкретики и аккуратного оформления.
Что должен содержать тест-кейс?
Составляемый документ должен содержать как семь базовых атрибутов. Их отсутствие также указывает на неудовлетворительное качество работы. Существуют и другие типичные ошибки ручных тестировщиков, которые чаще совершаются начинающими QA-специалистами.
Следующие атрибуты тест кейсаявляются обязательными:
- Уникальный идентификационный номер. По этому значению на тест-кейс будут ссылаться из других документов. Необязательно использовать только цифры: допустимы комбинации с буквами.
- Краткое описание. Это маленький текст, излагающий содержание документа.
- Входные данные. Атрибут, представляющий собой информацию об исходном состоянии системы.
- Пошаговые мероприятия. Это последовательные пункты, описывающие действия тестировщика.
- Ожидаемый результат. Этот атрибут часто базируется на требовании к ПО.
- Действительный результат.
- Статус. Атрибут отражает нынешнее состояние кейса.
Какие виды тест-кейсов бывают?
Классификация всех тест-кейсов отталкивается от формата первичных данных, от предполагаемого результата работы. На основании этого выделяют положительные, отрицательные и деструктивные документы. Сущность каждого поможет раскрыть тест кейс пример.
Предположим, что есть следующее условие к нынешней системе расписания учебных занятий – «В программу необходимо добавить новый урок». Положительный тест покажет, что при вводе корректных данных он в итоге появится.
Негативный же будет пытаться «ломать» нормальное функционирование системы. К примеру, новый урок добавляется, но в расписании места больше нет.
Деструктивный тип тест-кейса отражает, будет ли сохранен график занятий при сбоях. К примеру, при резком завершении программы или избыточном количестве вводимых данных.
В зависимости от конкретности входных данных также различают высокоуровневые и низкоуровневые тесты.
Какие статусы есть у тест-кейсов?
Предусмотрено шесть статусов, отражающих нынешнее положение тест-кейса. К ним относятся:
- «Passed». Статус означает, что ПО проверено и удовлетворило ожидания. Оно работает исправно и соответствует требованиям. Комментарий не нужен.
- «Failed». Поведение тестируемой системы не отвечает ожидаемым результатам, обнаружен дефект. Расписывается исчерпывающий комментарий.
- «Blocked». Статус говорит о невозможности выполнения тестирования, т. е. существуют препятствия для проверки. Например, тот или иной модуль или компонент, блокирующий весь процесс. Комментарий описывает причину.
- «Skipped». Статус, означающий, что тестирование пропущено. Среди потенциальных причин – отсутствие нужного модуля для планируемой проверки.
- «Draft». Статус показывает, что либо отсутствует субъект проверки, либо она ещё не начиналась.
- «In progress». Указывает на долгосрочное исполнение.
Как понять, что требования полные?
Чтобы понять, насколько качественным получился тест-кейс и все ли требования в нём соблюдены, рекомендуется предложить его коллегам, не знакомым с проверяемым продуктом. Если они после прочтения документа смогут чётко определить суть проекта – значит, работа удалась.
Понять, что тест-кейс сполна соответствует требованиям, можно даже при беглом его осмотре. В первую очередь оценивается заголовок: он должен быть крайне ёмким, но при этом раскрывать смысл проводимой проверки. По общему правилу название не содержит в себе описание исполняемых шагов и ожидаемые результаты.
Что касается описания стадий проверки, они тщательно детализируются. Однако чрезмерная конкретика тоже не приветствуется. Например, вместо пункта «ввести число 10» не стоит писать «нажать на клавиатуре цифру 1», а затем – «0».
Кроме того, в тексте тест-кейса нельзя оставлять ссылки на другие аналогичные документы.
Кто должен писать тест-кейсы?
Тест-кейсы составляются QA-специалистами. Они же готовят и исходные сведения для проведения планируемой проверки. Кроме того, тестировщик подбирает типы и методики работы, основываясь на имеющихся требованиях. Если документ составляется для целой команды, хранят его в общедоступном месте.
Существует и противоположная позиция – написание тест-кейса перекладывается на отдел разработчиков. Это не только снимает нагрузку с QA-специалистов, но и очевидно ускоряет релизный цикл. Кроме того, если разработчики будут одновременно писать и тест-кейс, и фичу, это заметно повысит качество последней.
Умение писать тест-кейсы требует не только теоретической подкованности и аналитического мышления. Полезным качеством является и любознательность.
Заключение
Обобщив материал, выделим пять свойств качественно написанного тест-кейса: чёткость формулировок, последовательность изложения, умеренная детализация шагов, грамотный технический язык и присутствие базовых атрибутов.
Умение писать тест-кейсы – не врождённый талант, а приобретённый практический навык. Но освоить его самостоятельно может быть непросто. Обучиться этому можно в учебном центре «Планетf тестирования». Курсы по тестированию программного обеспечения предполагают и дополнительное изучение технического английского языка. Дистанционный формат практических занятий является комфортным и продуктивным для слушателей. Предусмотрены также очная и индивидуальная форма обучения.
Глубже в тему: еще статьи
- Типичные ошибки при составлении чек-листов и тест-кейсов
- 6 типичных ошибок начинающего тестировщика ПО
- Основные определения и понятия тестирования ПО
Тестовая документация: что, где, когда
В этой статье мы расскажем о чек-листах, баг-репортах, юзкейсах и других популярных видах тестовой документации
Тестовая документация – это набор документов, который создается на протяжении всего цикла тестирования.
Документация помогает команде однозначно трактовать шаги, сроки тестирования, результаты, обращаться к этой информации в спорных моментах. Это отчет о проделанной работе тестировщика для менеджеров и клиентов. Объем документации и обязательные разделы в разных компаниях могут отличаться. При этом создание и поддержка такой базы требует большого количества времени и компетенций специалиста.
В этой статье мы расскажем о наиболее популярных видах документации.
План тестирования
План тестирования (тест-план) содержит критерии начала и окончания тестирования, описание конкретных параметров: что именно подлежит тестированию, с помощью каких техник, на каких платформах будет проверяться функционал.
Выделяют следующие типы тест-планов:
- По уровням: планы модульного, интеграционного, системного, приемочного тестирования;
- По типам: планы функционального, автоматизированного тестирования; тестирования производительности или юзабилити и т.д;
- Мастер тест-план: комплексный план тестирования всего проекта.
Тест-кейс
Тест-кейс – это набор условий, действий и ожидаемых результатов, направленных на проверку какого-либо функционала. Тест-кейс представляет собой описание одной показательной проверки на соответствие требованиям, прямым или косвенным. Тест-кейсы содержат как положительные, так и негативные проверки.
Наличие тест-кейсов позволяет:
- Структурировать подход к тестированию;
- Обеспечить полноту тестирования;
- Отслеживать прогресс реализации/выполнения плана;
- Достичь взаимопонимания между заказчиком и командой разработки;
- Хранить информацию для дальнейшего обмена опытом между командами и новыми сотрудниками, для быстрого подключения к проекту;
- Проводить повторное и регрессионное тестирование;
- Повышать качество требований.
Часто тест-кейсы упорядочивают и собирают в наборы – тест-сьют, в котором результат выполнения одного тест-кейса является предусловием для выполнения следующего.
Чек-лист
Чек-лист — список проверок для тестирования ПО. Чек-листы содержат перечень элементов, которые подлежат тестированию: блоки, секции, страницы и другие.
Классический чек-листы состоят из заголовка, статуса, заметки.
Возможные статусы: “Passed” (пройдено), “Failed” (не пройдено), “Blocked” (заблокировано), “Skipped” (пропущено), “Not run” (не проводился).
Среди преимуществ чек-листов выделяют наглядное и компактное отображение объема проделанных работ, предстоящих работ по тестированию. В них зафиксирован перечень проверок, который необходим для сдачи/приемки проекта.
Важно отметить, что чек-лист не является заменой тест-кейсов. Чек-листы содержат описание направления тестирования, а тест-кейсы – способы, алгоритмы тестирования. Поэтому чек-лист проще в составлении, но сложнее в применении. Опытному тестировщику не составит труда протестировать функционал по чек-листу, а новому специалисту может быть сложно вникнуть в суть функционала без детализации.
Юзкейс
Юзкейсы (Use case) содержат сценарии взаимодействия пользователя с системой, описание того, что именно делает программа.
Рассмотрим значение юзкейсов для каждого из участников проекта разработки:
- Заказчик . В юзкейсах отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования очевидна даже для нетехнического специалиста.
- Разработчик . В юзкейсах отражается наглядное представление бизнес-логики и поведения системы
- Тестировщик . Юзкейсы — хорошая основа для формирования тест-кейсов. Это пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании.
Баг-репорт
Баг-репорт – это документ, в котором содержится полная информация о найденном баге (шаги воспроизведения, описание, локализация и т.д.). Подробное описание ошибки поможет в ее быстром устранении и правильной перепроверке.
При создании баг-репорта стоит локализовать ошибку, проверить её наличие на разных устройствах и версиях ПО, как можно четче описать несоответствие ожидаемому результату.
Баг-репорт присутствует на любом проекте, независимо от того, пишутся ли другие тестовые документы. От правильности его составления зависит скорость понимания ошибки и качество отладки.
Отчет по тестированию
Отчет по тестированию – отчет о проделанной работе с описанием результатов. Может содержать текст, таблицы, графики и диаграммы.
В зависимости от того, для кого предназначен отчет, меняются представление информации и акценты в описании.
У отчетов есть разные варианты:
- Отчет по инциденту содержит описание события, которое произошло во время тестирования и подлежит исследованию;
- Отчет о результатах тестирования. Представляет собой периодический отчет, в котором фиксируется подробная информация о выполнении тестирования и его результатах, а также об оставшейся работе;
- Отчет о ходе тестирования. Документ, в котором подводится итог тестирования, с целью отслеживания прогресса;
- Итоговый отчет о тестировании. В этом отчете содержится полная информация о тестировании, проведенном на протяжении всего жизненного цикла разработки ПО.
Итак, мы ознакомились с основыми видами тестовой документации. Еще раз отметим, что создание такой базы — трудоемкий, но очень важный этап в жизненном цикле разработки. С ее помощью все участники процесса разработки смогут получить актуальную информацию о состоянии системы, повысить эффективность работы.
- Пропуск тестовых функций