Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Основные QA (Тестовые) артефакты

Лекция



Привет, сегодня поговорим про основы qa, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое основы qa, тестовые артефакты , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

  • Зачем нужны, почему существуют, сколько надо тратить на них времени
  • Задачи, подход, наполнение:
    • Test Plan и стадия планирования работы
    • Test Case & Test Scenario - когда что используем
    • Check List - работа с да/нет задачами
    • QA Reports - как и о чем отчитываемся

тестовые артефакты

Основные QA (Тестовые) артефакты

В соответствие с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:

  • План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
  • Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
  • Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

Тест План (План тестирования)

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

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

  1. Test Plan Template RUP
  2. Test Plan Template IEEE 829

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

  1. Что надо тестировать?
    • описание объекта тестирования: системы, приложения, оборудования
  2. Что будете тестировать?
    • список функций и описание тестируемой системы и ее компонент в отдельности
  3. Как будете тестировать?
    • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
  4. Когда будете тестировать?
    • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
  5. Критерии начала тестирования:
    • готовность тестовой платформы (тестового стенда)
    • законченность разработки требуемого функционала
    • наличие всей необходимой документации
    • ...
  6. Критерии окончания тестирования:
    • результаты тестирования удовлетворяют критериям качества продукта:
      • требования к количеству открытых багов выполнены
      • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
      • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
    • ...

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

  • Окружение тестируемой системы (описание программно-аппаратных средств)
  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
  • Риски и пути их разрешения

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

  1. Мастер Тест План (Master Plan or Master Test Plan)
  2. Тест План (Test Plan), назовем его детальный тест план)
  3. План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

Рецензия и Утверждение

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

  • Ведущий тестировщик
  • Тест менеджер (менеджер по качеству)
  • Руководитель разработки
  • Менеджер Проекта

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

Вывод

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

Тестовый случай (Test Case)

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части.

Под тест кейсом понимается структура вида:

Action > Expected Result > Test Result

Пример:

Action Expected Result Test Result
(passed/failed/blocked)
Open page "login" Login page is opened Passed

Виды Тестовых Случаев

Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен иметь 3 части:

PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Об этом говорит сайт https://intellect.icu . Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

Пример тест кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:

Action Expected Result Test Result
(passed/failed/blocked)
PreConditions
do A1 verify B1
do A2 verify B2
Test Case Description
do A3 verify B3
PostConditions

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

Теперь ответим на вопрос: "Почему данное разбиение удобно использовать?"

Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Action Expected Result Test Result
(passed/failed/blocked)
PreConditions
do A1 verify B1 passed
do A2 verify B2 failed
Test Case Description:
do A3 verify B3 blocked
PostConditions

Детализация описания тест кейсов (Test Case Specification)

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


Пример тест кейса 1:

Проверка отображения страницы

Действие Ожидаемый результат Результат теста
Открыть страницу "Вход в систему" - Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Логотип компании отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
- Ссылка "забыл пароль" - доступна
...


Пример тест кейса 2:

Название: Проверка отображения страницы
Действие: Открыть страницу "Вход в систему"
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему")

В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.

На нашем сайте вы также сможете найти пример оформления тест кейса

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

Вывод

В заключение скажу, для того чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию. То, что предлагаем мы - это структура PreConditions, Test Case Description, PostConditions, и уже ваше личное дела - пользоваться ей или придумать свой "велосипед".

Баг Репорт (Bug Report)

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

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

  • Структура баг репорта
  • Серьезность и Приоритет дефекта
  • Написание баг репортов
  • Жизненный цикл бага

Предлагаем Вам комментарий одного разработчика:
- Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.

С этим можно соглашаться или не соглашаться, но смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом "Отклонен", "Не воспроизводится", "Требуется информация" (Rejected, Can't Reproduce, More info) - это потеря времени, как вашего так и разработчика. А время, как известно - это деньги, которые мы получаем, за то что делаем нашу работу лучше всех!

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

Шаблоны и примеры документов

Исследовав запросы пользователей нашего сайта, мы решили опубликовать самые восстребованныыедокументы по тестированию на одной страинце.

Тест Планы

  1. Тест план IEEE 829
  2. Тест план RUP
  3. План приемо-сдаточных испытаний RUP
  4. План проведения нагрузочного тестирования (RU / русский)

Спецификация проектирования тестов (Test Design Specification)

  1. Пример спецификации проектирования тестов MSF
  2. Пример спецификации проектирования тестов IEEE 829-1998

Тест Кейс

  1. Пример оформления тест кейса

Основные QA (Тестовые) артефакты

Баг репорт

  1. Пример оформления баг репорта

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

пример чеклиста (check list)

Основные QA (Тестовые) артефакты

Тестовые атефакты- test plan

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

test strategy стратегия тестирования

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

отчет о тестировании test result report

Основные QA (Тестовые) артефакты

Основные QA (Тестовые) артефакты

Виды источника тестовых данных

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

  1. Копии баз данных реальных продакшн-версии на тестовый сайте.
  2. Базы данных других систем клиента, которые могут использоваться в текущей.
  3. Генераторы тестовых данных.
  4. Ручное создание тестовых данных.

Копии существующих баз данных (1,2) предоставляют нам реальные тестовые данные. Они создаются при существующих процессах пользователями или системой.
Источники из пунктов 3 и 4 мы называем «синтетическими тестовыми данными» . Такие данные мы создаем сами для целей разработки и тестирования.

Например комбинаторым способом или случайным при этом нестоит забывать что нет необнодимости тестировать всежлемены диапазона а важно выбрать в каждом множестве все кричические диапазоны (классы эквивалентности и граничные значения) - например для количества и целыхчисел -2222 -1, 0 , 1, 100, 10000, 1111111111111111 , для строковых данных А, Абрикос, Иванов Иван, Абракадабраизсотенбукводнимсловомибезпереновв, пустая срока '' , специальные сиволы и тд

Основные QA (Тестовые) артефакты

Вау!! 😲 Ты еще не читал? Это зря!

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.

создано: 2015-11-03
обновлено: 2023-06-26
133527



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Качество и тестирование программного обеспечения. Quality Assurance.

Термины: Качество и тестирование программного обеспечения. Quality Assurance.