Уровень 8                     Работа с требованиями

Уровень 8

На этом уровне  ты изучишь 

работу с требованиями, пока мы уничтожаем императорские войска в системе Dagobah.

 

Поторопись, нам нужна твоя помощь!

Роли при создании тест плана

Далее будут перечислены основные роли, которые Вам придется примерять на себе при создании тест плана. Это не значит, что на вашем рабочем месте Вы будете их все выполнять (хотя скорее всего это и будет так). Ясно-понятно, что нужно быть готовым ко всему. Ведь не скажешь работодателю - я как-то не очень полюбил администрировать базу данных, попросите Васю сделать это. Перечислим все роли, которые пригодятся, но не стоит заострять на них много внимания, так как эта информация уже была дана в 4-ом уровне. Вспомним, какие роли мы рассматривали.

 

Основные роли:       

  • Тест-менеджер, менеджер проекта по тестированию

  • Тест-аналитик                                                                                        

  • Тест-дизайнер                                                                                             

  • Тестировщик, Инженер по тестированию                                                                                       

Вспомогательные роли:                                                                                                            

  • Администратор тестовой системы и приложений, поддерживающих жизненный цикл тестирования                                                                          

  • Администратор баз данных, менеджер баз данных

  • Разработчик тестов

После того, как ты узнал все роли в тестировании, предлагаю разобрать каждую поподробнее. А в это время  Имперская армия отступила и занимается своими делами.

 
Тест-менеджер, менеджер проекта по тестированию

Производит управленческий контроль (management oversight)                                                                                             

Ответственность:

  • Обеспечивает техническое направление    

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

 

  • Получает необходимые ресурсы        

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

 

  • Обеспечивает управленческую отчётность

Пример: Оформляет необходимую документацию по предыдущим двум пунктам.

Обычно это обязанности тим лидера тестировщиков. Если вы - один тестировщик в отделе, то вам повезло, заниматься всем этим придется только Вам.

 

Тест аналитик

Определяет, приоритезирует и обеспечивает разработку тестовых сценариев

 

Ответственность:

  • Разработка плана тестирования

На этой роли лежит главная ответственность за координирование действий по созданию плана тестирования

 

  • Разрабатывает модель тестирования    

Пример: выбирает виды тестирования, количество и длительность тестовых циклов

                                

  • Оценивает эффективность тестирования

Осуществляется с помощью расчета покрытия проекта тестами, созданием карты проекта, расчета уровня качества ПО в процентах

Тест-дизайнер

Устанавливает и определяет операции, атрибуты и связи тестовых классов    

                                                                     

Ответственность:

  • Устанавливает и определяет тестовые классы                   

  • Устанавливает и определяет тестовые наборы (пакеты)

Пример: создает задачи по написанию тест-кейсов, тест-скриптов. Объединяет все тесты в тест-сьюты

Тестировщик, Инженер по тестированию

Выполняет тестовые сценарии  

                                                

Ответственность:

  • Выполняет тесты

  • Фиксирует результаты

  • Восстанавливает тесты и систему после сбоев

  • Документирует запросы на изменение (обнаруженные дефекты, предложения к улучшению)

 

Как все сложно! Давайте попытаюсь все объяснить простыми словами на клингонском.

Какой ужас! Вы не понимаете клингонского?!

Ладно, объясню так:

 

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

 

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

 

3. Затем подходит очередь тест дизайнера. По каждому тестовому разделу он создает тест кейсы или чек листы или автотесты. Затем после создания тестового покрытия на нем будет ответственность - дать отчет по тестовому покрытию. Также он отвечает за поддержку всех тестов.

 

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

Работа с требованиями

Пример нетестируемого требования производительности ПО

 

Что мы упустили в требовании?

Какое время отклика? При какой загруженности пропускного канала? Не должно превышать 1 секунды, при каких условиях? Наконец, время выполнения чего?!

  • Время отклика системы должно находиться в приемлемых рамках    

                    

  • Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: UI, DB, client + server + network?) должно находиться (Условия? Нагрузка?) в приемлемых рамках (Какие эти приемлемые рамки в цифрах?)

Что с ресурсами? Какими они должны быть?

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

  • Время отклика системы с точки зрения конечного пользователя (end-to-end) во время продуктивной нагрузки (50 пользовательских сессий в режиме «менеджер» / 15 пользовательских сессий в режиме «аналитик») при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec, не должно превышать одной секунды для операций создания записи и три секунды для операций поиска записи.

 

  • Время выполнения аналитических отчётов определяется отдельно для каждого отчёта.

 

  • Объём используемой оперативной памяти должен оставаться стабильным.

Практические советы:

 

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

 

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

 

 

  • При условии «плавающих» требований, анализ покрытия производится по факту поставки версии системы, в которую включается набор актуальных требований. Данный подход увеличивает общее время, отведённое на тестирование за счёт технологических простоев

 

  • Каждое требование должно быть протестировано (иметь тест)

 

  • Каждый тест должен относиться к какому-либо требованию

 

  • Требования могут порождаться тестами (при использовании agile-методологий)

 

  • Требования обязательно должны находиться под версионным контролем.

Прежде, чем магистр проверит твои знания, посмотри - чем сейчас занимаются силы зла,

ибо они не дремлют!

Проверь себя  перед тем как двигаться дальше
Обзор артефактов тестирования по ролям

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

Тестировщик ПО:
  • Test script

  • Test log

Аналитик:
  • Test Case

  • Test-Ideas List

  • Workload Analysis Model

  • Test Data

  • Test results

Тест-дизайнер
  • Test Strategy

  • Test Automation Architecture

  • Test Environment Configuration

  • Test Suite

Тест-менеджер
  • Test Plan

  • Test Evaluation Summary

Все это - график структуры артефактов 

тестирования, предлагаемый стандартом IEEE 829

 
 
 

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

Дальнейший обзор артефактов тестирования приводится в разрезе определённых раннее ролей в группе тестирования

Тестировщик ПО

Test script – пошаговое описание действий, которые надо провести для выполнения одного тестового сценария. Тестовый скрипт должен описывать действия для ручного выполнения, пригодные для передачи в группу автоматизации тестирования.

 

Test log – протокол выполнения скрипта в системе, заносимый в тестовый отчёт результат выполнения тестового скрипта или отметка о нормальном прохождении тестового набора в контрольном листе.

Аналитик

Workload Analysis Model – рабочая модель нагрузки, которая определяет условия и конфигурацию системы во время проведения тестирования.

 

Test Data – формальное описание тестовых данных, которые будут использованы для проведения тестирования или алгоритмов получения тестовых наборов, если они не могут быть описаны и представлены в силу размера или сложности.

 

Test results – суммарный отчёт, составляемый на основании тестовых логов и информации о дефектах,  зафиксированных для текущего состояния системы.

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

 

Test-Ideas List – нумерованный список идей, которые могут быть реализованы в виде тестовых сценариев. Служит для предварительного согласования направления и подходов к тестированию.

Тест-дизайнер

Test Strategy – документ, который определяет стратегию (совокупность действий, выполняемых типов тестов, требуемых ресурсов и т.д.) тестирования системы в тестировании. RUP предлагает стратегию тестирования как основную часть Тест Плана проекта по тестированию.

 

Test Automation Architecture – документ, фиксирующий подходы к автоматизации тестирования, а также спецификации тестов, которые подлежат автоматизации и описание  инструментальных решений автоматизации тестирования ПО.

 

Test Environment Configuration – описание программной и аппаратной конфигурации тестового стенда, а также особенностей настройки и администрирования прикладного ПО.

Test Suite – документ, описывающий набор тестовых сценариев, покрывающих бизнес-транзакции и отображающий возможности анализа состояния системы под тестом путём анализа тестовых логов и сообщений о зафиксированных ошибках.

Устал наверно, силы тьмы тоже отдыхают. Слушай шуточку:

"Какой же я тогда был зеленый..."- подумал Йода  после просмотра первого эпизода.

Тест-менеджер

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

 

Test Evaluation Summary – документ, представляющий суммарный анализ результатов тестирования в разрезе затраченных ресурсов и достигнутых результатов, готовности системы к выпуску и прогнозов по улучшению соотношения затраты/результат на дальнейшие этапы проекта.

Цель тестирования

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

Стратегия

Стратегия процесса тестирования планируется в три этапа. Рассмотрим этапы проведения процесса тестирования:

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

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

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

 

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

 

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

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

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

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

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

 
 
Определения

Проект – Проект «bla bla» служит для создания .......

 

Функциональное тестирование – тестирование функций приложения на соответствие требованиям

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

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

Purpose

Цели документа (purpose):
Целью настоящего тест плана является описание процесса тестирования сайта bla-bla.ru (полный адрес http://bla-bla.ru). Данный документ позволяет получить представление о плановых работах, сроках и стратегиях тестирования. В данном документе не предполагается описание текст кейсов, ссылки на найденные дефекты, а так же их анализ.

Ура! Ты теперь знаешь, что такое тест план и легко сможешь его написать! Думаешь, шутка?

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

Магистр тебе все подробно объяснит. 

Всегда было для меня загадкой, как штурмовики ходят в туалет в своем скафандре?

Ах да, извини, я отвлекся, давай начнем с определений...

Смоук тестирование

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

Функциональное тестирование

Цель: Выявление функциональных ошибок, несоответствий ТЗ и ожиданиям пользователя путем реализации стандартных, а также нетривиальных тестовых сценариев.

Тестирование в определенной среде

Цель: Проверить корректную работу и дизайн проекта в различных браузерах и при различных разрешениях монитора.

Описание конфигураций:

Браузер/Разрешение

1680*1050/Internet Explorer 11

Моя совсем ничего не понимать! Тест план большой и страшный. Там все на англиском. Ужжассс!! Брррр! Магистр помоги моя!

Моя совсем ничего не понимать! Тест план большой и страшный. Там все на английском. Ужжассс!! Брррр! Магистр, помоги моя!

Что за голос у моя в голове? Кажется, магистр Йода начал телепатическую передачу, чтобы объяснить нам смысл тест плана. Да пребудет с нами Сила!

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

Итоги теоретической части курса,

всего, что мы выучили  до этого уровня

 

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

 

  • Определение тестирования ПО и качества информационных систем

  • Место тестирования в процессе разработки ПО

  • Требования к процессу тестирования

  • Цели и задачи тестирования

  • Уровни тестирования

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

  • Виды тестов

  • Роли в тестировании

  • Работа с дефектами

  • Обзор артефактов тестирования и тестовой документации

 
 
 

Время покажет, что ты понял в курсе.

А сейчас пройди тест уровня - удиви магистра. 

Надеюсь, ты отправил тест план еще с прошлого уровня, если нет, то поспеши

отправить его. Форма та же. Если Вы отправили его ранее, то повторно отправлять не нужно.

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

Для перехода на уровень 9, необходимо набрать минимум 28,2 балла (60%)  за задания уровня 8.

  • Facebook Social Icon
  • Instagram
  • Vkontakte Social Icon
  • YouTube Social  Icon
  • mail_icon

© 2017 Galaxy QA Academy. All rights are protected.