Уровень 4

Роли в тестировании. Тест дизайн

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

Итак, рассмотрим процесс разработки ->

 

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

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

Активности процесса тестирования ПО

Весь процесс тестирования, представлен примерно 20 основными активностями:

 

​- Для более наглядного структурирования активностей по этапам работ они будут рассмотрены в группах соответствующих этапов работ по тестированию.

- Не все активности являются строго обязательными, но большинство из них являются рекомендованными к выполнению.

Итак, какие же роли встречаются в тестировании:

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

(Test Manager, Test Project Manager)

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

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

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

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

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

Тест дизайнер  (Test Designer)

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

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

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

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

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

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

(Tester)

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

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

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

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

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

  • Документирует запросы на изменение

     

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

Обеспечивает управление и поддержку тестовых окружений и данных. Ответственность:

  • Администрирует систему управления тестированием

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

Администратор баз данных, менеджер баз данных (Database Administrator, Database Manager)

Обеспечивает управление и поддержку тестовых данных (баз данных). 

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

  • Администрирует тестовые данные (базы данных)

Тест-аналитик (Test-analyst)

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

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

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

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

Разработчик тестов (Implementer)

Разрабатывает юнит тесты (unit tests), тестовые классы и тестовые наборы (пакеты).

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

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

 
 
Роль
Описание

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

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

 

Я вам раскрою секрет всех айтишников, хоть все и говорят, что пользуются какой-то там методологией и с гордостью заявляют,-  "У нас все по Scram-у". То, в реальном мире у каждой компании свой микроклимат, свои правила, которые будут накладываться на выбранную методологию. Давайте же подробнее рассмотрим эти методологии. Хотя постойте, давайте вначале узнаем, чем же заняты в это время силы зла?

Активности тестирования по RUP

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

 

И кем же я буду в этой таблице??? Наверное, возьмут меня тест-менеджером сразу после курсов и будут на красной машине домой возить ... 

Ну да, размечтался! Роль джуниоров - это Tester и Test Designer. Это базовые роли, необходимые каждому тестировщику. Проходить тесты и писать тесты вы научитесь на этих курсах. Что касается тест анализа - это приходит только с опытом. Набрав достаточное количество знаний о проекте, вы сможете анализировать тест кейсы других тестировщиков и взглядом делать в них дыры!! Или хотя бы находить недочеты и, что не менее важно,- избыточные шаги и проверки.

Что касается Test Manager - это, конечно же, высший пилотаж, но вы научитесь создавать тест план, в котором как раз присутствуют все выше перечисленные роли и испробуете на себе удовольствие побыть тест менеджером.

Далее - подробнее об активностях в ролях тестирования.

 

 

Активности процесса тестирования ПО
  • Планирование тестов

    • Определение требований к тестам

    • Оценка рисков

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

    • Определение ресурсов

    • Создание расписания/последовательностей

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

  • Дизайн тестов (Design Test)

    • Анализ объёма работ

    • Определение и описание тестовых случаев

    • Определение и структурирование тестовых процедур

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

  • Разработка тестов (Implement Test)

    • Запись или программирование тестовых скриптов

    • Определение тесто-критичной функциональности в Дизайне и Модели реализации

    • Создание/подготовка внешних наборов данных

  • Выполнение тестов (Execute Test)

    • Выполнение тестовых процедур

    • Оценка выполнения тестов

    • Восстановление после сбойных тестов

    • Проверка результатов

    • Исследование неожиданных результатов

    • Описание обнаруженных дефектов

  • Оценка тестов (Evaluate Test)

    • Оценка покрытия функциональности приложения или системы тестовыми случаями

    • Оценка покрытия кода

    • Анализ дефектов

    • Определение критериев завершения и успешности тестирования (анализ метрик)

 

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

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

Agile - семейство процессов разработки объединяющее принципы всех гибких методологий. Agile не подразумевает пошаговых руководств и конкретных рекомендаций, а лишь очерчивает общие принципы, которые используют гибкие методологии. Они во многом легли в основу двух наиболее распространенных из них – scrum и kanban.

В ваших интересах подробнее прочитать про скрам и добавить эту чудо-метку в свое резюме :')

 

Практические аспекты тест дизайна
 

Ниже перечислены наиболее распространенные техники тест дизайна:

 

  • Эквивалентное Разделение (Equivalence Partitioning - EP). Вы разбиваете все возможные диапазоны значений на верные и неверные и выбираете по одному значению из кажого диапазона. Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение (внутри интервала), скажем, 5, и два неверных значение вне интервала:  -3 и 12.

 

  • Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10) и значения больше и меньше границ (0 и 11). Анализ Граничных значений может быть применен к полям, записям, файлам или к любого рода сущностям, имеющим ограничения.

 

  • Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона", а затем нажать кнопку "Добавить" - это "Причина". После нажатия кнопки "Добавить" система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".

 

  • Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "Пользователь должен ввести код". Тест аналитик  будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? "  и так далее. Это и есть предугадывание ошибки.

 

  • Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и,  в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным из-за огромного количества входных значений.

1

10

1

10

 

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

 

Итак, мы выяснили роли, методологии и активности в тестировании. Теперь мы готовы перейти к самой ответственной практической части в тестировании. От знания и умения пользоваться тест дизайном зависит умение тестировть. Это и есть "ядро" практического тестирования.

Практика

 

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

 

Внимание, задание:

Протестировать функциональность формы приема заявок . Ссылка на форму.

 

Итак, с чего начинается тестирование? Вопрос отнюдь не риторический. Тестирование начинается с требований. 

 

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

 

Рассмотрим требования  к тестированию данной формы. Для удобства они предоставлены в следующей таблице:

Элемент

Тип Элемента

Требования

Набор данных:

  1. Консультация

  2. Проведение тестирования

  3. Размещение рекламы

  4. Ошибка на сайте

* - на процесс выполнения операции приема заявок не влияет.

Тип обращения

combobox

Контактное лицо

1. Обязательное для заполнения

2. Максимально 25 символов

3. Использование цифр и спец символов не допускается

editbox

Контактный телефон

editbox

  1. Обязательное для заполнения

  2. Допустимые символы "+" и цифры

  3. "+" можно использовать только в начале номера

  4. Допустимые форматы:

    1. начинается с плюса - 11-15 цифр
      +31612361264
      +375291438884
      без плюса - 5-10 цифр, например:

0613261264
2925167

1. Обязательное для заполнения

2. Максимальная длина 1024 символа

text area

Сообщение

Отправить

button

Состояние:

1. По умолчанию - не активна (Disabled)

2. После заполнения обязательных полей становится активна (Enabled)

 

Действия после нажатия

1. Если введенные данные корректны - отправка сообщения

2. Если введенные данные НЕ корректны - валидационное сообщение

 
Определение набора тестовых данных
  • Отталкиваясь от требований к полям, используя техники тест дизайна, начинаем определение набора тестовых данных: в зависимости от того обязательное поле или нет, определим какие поля необходимо проверить на пустое значение, так как оно может вызывать ошибку (В результирующей таблице обозначено [1])

  • т.к. исчерпывающее тестирование не представляется возможным из-за огромного числа всевозможных комбинаций значений, в первую очередь необходимо определить минимальный набор данных. Это можно сделать используя такие техники, как Эквивалентное Разделение  и Анализ Граничных Значений. Обозначим как [2].

 

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

 

  • По завершению генерации данных, используя стандартные техники, можно добавить некоторое количество значений на основании личного опыта (техника Предугадывание ошибки) - это будет использование спецсимволов, очень длинных строк, разных форматов данных, регистров в строках (Upper, Lower, Mixed cases), отрицательные и нулевые значения, кейворды Null - NaN - Infinity и т.д. Сюда можно включить все, что вы полагаете, может вывести приложение из строя (В результирующей таблице [2])

Результат применения тест дизайна

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

Действия

Ожидаемый результат

1. Открываем форму отправки сообщения

  • Форма открыта

  • Все поля по умолчанию пусты

  • Обязательные поля помечены - *

  • Кнопка "Отправить" не активна

2. Заполняем поля формы:

  • Тип обращения

  • Контактное лицо

  • Контактный телефон

  • Сообщение

  • Поля заполнены

  • Кнопка "Отправить" - активна (Enabled)

3. Нажимаем кнопку "Отправить"

  • Если введенные данные корректны:

    • Сообщение "Заявка отправлена" выведено на экран.

    • Новая заявка появилась в списке на странице "Заявки".

  • Если введенные данные НЕкорректны:

    • Валидационное сообщение со всеми ошибками выведено на экран.

    • Заявка НЕ появилась в списке на странице "Заявки".

 
 
 
Пример позитивного тест кейса (все поля OK):

Действия

Ожидаемый результат

1. Открываем форму отправки сообщения

  • Форма открыта

  • Все поля по умолчанию пусты

  • Обязательные поля помечены - *

  • Кнопка "Отправить" не активна

2. Заполняем поля формы:

  • Тип обращения = Консультация

  • Контактное лицо = йцукенгшщзйцукенгшщзйцуке

  • Контактный телефон = +38-056-111-11-11

  • Сообщение

  • Поля заполнены

  • Кнопка "Отправить" - активна (Enabled)

3. Нажимаем кнопку "Отправить"

  • Сообщение "Заявка отправлена"выведено на экран.

  • Новая заявка появилась в списке на странице "Заявки".

4. Открываем форму отправки сообщения

  • Форма открыта

  • Все поля по умолчанию пусты

  • Обязательные поля помечены - *

  • Кнопка "Отправить" не активна

5. Заполняем поля формы:

  • Тип обращения = Консультация

  • Контактное лицо = @#$%^&;.?,>|\/№"!()_{}[<~

  • Контактный телефон = (916)333-33-33

  • Сообщение = йццуйцуйц(...)йцу - 1024 символа

  • Поля заполнены

  • Кнопка "Отправить" - активна (Enabled)

6. Нажимаем кнопку "Отправить"

  • Валидационное сообщение со всеми ошибками выведено на экран:
    "В поле "Контактное лицо" запрещено использование цифр и спец. символов."

  • Заявка НЕ появилась в списке на странице "Заявки".

 
Вебинар уровня 4

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

Ура! Ты добрался до конца этого уровня!

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

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

 

Задание 1 будет тебе по силам: 

воспользоваться техникой тест дизайна при создании тест кейса. Напиши тест кейс по тестированию контактной формы на сайте c печеньками.

Для создания тест кейса воспользуйся этим шаблоном Google таблицы.

 

Задание 2 еще интереснее:

Протестируй сайт и найди все баги! Все просто! То, что работает неправильно - это баг!

Отправь все задания мне через форму

Уровень 5

Для перехода на уровень 5, необходимо набрать минимум 19.2 балла (60%)  за задания уровня 4.