ШИФТ 2 лекция (updated)

1. Тестовая документация

1

2. Основные этапы тестирования

Процесс тестирования
1.
Описываем,
что и как
будем
тестировать
2.
Тестируем
3.
Составляем
отчёты
2

3. Тестовая документация появляется на трех стадиях: планировании, непосредственно тестировании и отчетности по результатам

Тестовая документация
1.
Планировани
е
2.
Тестирование
3.
Отчётность
3

4. Документация на этапе планирования

1
Документация на этапе планирования
4

5.

Тест-план
Тест-план (test plan) – документ, описывающий и
регламентирующий перечень работ по тестированию, а также
соответствующие техники и подходы, стратегию, области
ответственности, ресурсы, расписание и ключевые даты
5

6.

Составляя тест-план, отвечаем на вопросы:
Что надо тестировать? – Цель тестирования
Что будете тестировать? – Области, подвергаемые тестированию, и области, не
подвергаемые тестированию
Как будете тестировать? – Тестовая стратегия (уровни тестирования, виды
тестирования)
Каковы критерии приемки, начала и завершения тестирования и т.д.?
Ресурсы
Когда будете тестировать? – Расписание
Роли и ответственность
Оценка рисков
Тестовая документация
6

7.

Чек-лист
Чек-лист (сheck list) – документ разного уровня детализации,
описывающий, что должно быть протестировано. Набор идей для
проверки какой-то области, свойства, характеристики приложения и
т.д с требуемой степенью детализации
7

8.

Чек-листы менее формализованы и позволяют
ориентироваться в процессе тестирования
позволяет не забыть о важных тестах
фиксировать результат работы
помогает осуществлять контроль за тестированием, отслеживать статистику о статусе
программного продукта
8

9.

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

10.

Недостатки чек-листов
начинающие тестировщики не всегда
эффективно проводят тесты без
достаточно подробной документации
невозможно использовать для
обучения начинающих сотрудников,
т.к. в них недостаточно подробной
информации
The calmest checklist fan
Average test-plan
enjoyer
10

11. Документация на этапе тестирования

2
Документация на этапе тестирования
11

12.

Тест-кейсы
Тест-кейс (test case, тестовый
случай, тестовый сценарий) – набор
входных данных, условий
выполнения и ожидаемых
результатов, разработанный с целью
проверки того или иного свойства
или поведения программы.
12

13.

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

14.

Структура тест-кейса
Предусловия и входные данные
Список действий, которые приводят систему к состоянию пригодному для
проведения основной проверки. Либо список условий, выполнение которых говорит о
том, что система находится в пригодном для проведения основного теста состояния.
Описание
Список действий теста + ожидаемый результат
Постусловия
Список действий, переводящих систему в первоначальное состояние (состояние до
проведения теста)
14

15.

Формальная запись тест-кейса имеет общепринятую
структуру с конкретным набором атрибутов (полей)
15

16.

16

17.

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

18.

Чит-листы
Чит-лист (сheat sheets) - список
повторяющихся проверок, которые
можно переиспользовать в разных
условиях. Например, для валидации
поля e-mail, проверки ограничений
полей и т.д.
18

19.

Чит-листы упрощают процесс тестирования
стандартизация тестирования
разум освобождается для более важных задач
позволяют покрыть большую часть проверок
применяются различные техники тест-дизайна (спойлер)
можно обсудить с коллегами
19

20.

Баг-репорт
Баг-репорт (bug-report, отчет о
дефекте)— документ, описывающий
и приоритизирующий обнаруженный
дефект, а также содействующий его
устранению
20

21.

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

22.

Формальная запись
отчета о дефекте
имеет общепринятую
структуру с
конкретным набором
атрибутов (полей)
22

23.

Хорошее краткое описание (заголовок) содержит
исчерпывающий ответ на три вопроса:
Что?
Где?
Когда?
Пример:
«Отсутствует логотип на странице приветствия,
если пользователь является администратором»
23

24.

Примеры плохих и хороших описаний
Плохо
Ничо не работает
В исследуемой системе при
вводе в поле “Имя” символов
русского алфавита, английского
алфавита, спецсимволов и
символов в неправильной
кодировке поведение программы
неверное
Хорошо
Авторизация через твиттер падает с HTTP
500
Падает отправка письма в кодировке UTF08
Нет подсказок по двойным именам в ФИО
Двойные имена
24

25.

Попробуем сами сформулировать краткое описание
на основе заданной ситуации
Ситуация 1
Поле комментария на форме
должно допускать ввод максимум
250 символов; в процессе
тестирования оказалось, что
этого ограничения нет
Краткое описание:
Нет ограничения максимальной
длины поля «Комментарий»
Ситуация 2
Попытка открыть в приложении пустой файл
приводит к падению клиентской части
приложения и потере несохранённых
пользовательских данных на сервере
Краткое описание:
Падение клиента и потеря данных
при открытии пустых файлов
25

26. Отчетная документация

3
Отчетная документация
26

27.

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

28.

Пример схемы отчета для всех проектов в одной из
компаний
Расписание (с указанием того, кто и в какие сроки что делал)
Результаты по типам проведенных тестов (список протестированной
фунциональности, разные графики по performance и т.п.)
Заключение (общие выводы о качестве продукта, с описанием критических вещей) –
самая читаемая часть
Приложение со списком багов и распределениями багов по
приоритету/компонентам/времени и т.п.
28

29.

Пример заключения
29

30.

Отчетность «для себя»
30

31.

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

32. На этом пока всё! (почти)

32