Вы находитесь на странице: 1из 30

Введение в тестирование

Урок 1

Введение в
тестирование
Основные понятия
Регламент курса
● 8 уроков по 2 часа;
● домашнее задание для каждого урока;
● срок сдачи домашних заданий — за 4 часа до начала следующей
лекции;
● видеозапись лекции будет доступна;
● вопросы — в комментариях к уроку или в личных сообщениях на сайте;
● можете задавать вопросы наставникам.
Советы

1. Используйте OneNote или его аналоги.


2. Записывайте термины, определения и понятия.
3. Составляйте резюме заранее.
4. За практикой — на краудтестинг.
ISTQB
International Software Testing Qualifications Board

● Международный совет по тестированию программного обеспечения;

● цель — стандартизировать знания и умения тестировщиков.


План урока

1. Общие знания о тестировании и тестировщиках.


2. Терминология.

3. Как определить качество ПО.

4. Дефекты и отчёты о дефектах.

5. Один день тестировщика.


Определения

Тестировщик (tester) — опытный специалист, принимающий


участие в тестировании компонента или системы.

Специалист по тестированию ПО — специалист, основная цель


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

Тестирование — процесс, содержащий в себе все активности жизненного цикла, как динамические, так
и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с
этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать,
что они подходят для заявленных целей и для определения дефектов.
QA/QC/Tester
Tester (тестировщик) — разработка и прохождение тест-кейсов,
локализация дефектов и прочее.

QC (контроль качества продукта) — анализ результатов


тестирования и качества билдов в процессе разработки.

QA (обеспечение качества) — изучение возможностей по


изменению и улучшению процесса разработки, улучшению
коммуникаций в команде.
Валидация vs верификация
Верификация (verification) — процесс оценки системы или её компонентов, чтобы понять,
удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого
этапа: выполняются ли цели, сроки, задачи по разработке проекта. Процесс оценки соответствия
продукта явным требованиям (спецификациям).

Валидация (validation) — определение соответствия разрабатываемого ПО ожиданиям и потребностям


пользователя, его требованиям к системе.
Качество ПО
Качество — степень, в которой компонент, система или процесс отвечают определённым требованиям и
(или) требованиям и ожиданиям пользователя.

Качество продукта — совокупность функциональных возможностей и характеристик ПО, которые


удовлетворяют заявленным или подразумеваемым требованиям.
Стандарт ISO/IEC 25010
Дефект

Дефект — отклонение фактического результата от


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

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе,


способный привести к сбою или отказу.
Сбой (interruption) или отказ (failure) — отклонение
поведения системы от ожидаемого.

Сбой — самоустраняющийся или однократный отказ,


устраняемый незначительным вмешательством.

Отказ — событие, нарушающее работоспособность


приложения.

Инцидент (incident, deviation) — любое сообщение о сбое в


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

Отчёт о дефекте (bug report) — это документ, описывающий


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

Отчёт о дефекте — документ, описывающий и


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

● предоставить информацию о проблеме;


● приоритизировать проблему;
● содействовать устранению проблемы.

Качественный отчёт о дефекте не только предоставляет все необходимые подробности для


понимания сути случившегося, но также может содержать анализ причин возникновения
проблемы и рекомендации по исправлению ситуации.
Атрибуты отчёта о дефекте
Атрибут Что писать Пример

Присваивается автоматически, может содержать в себе данные о требовании, на


Уникальный идентификатор (ID) 1254_17
которое ссылается дефект
Обязательные поля для заполнения не отмечены на форме регистрации после нажатия на кнопку
Тема (краткое описание) (Summary) Кратко сформулированная суть дефекта по правилу «Что? Где? Когда?» «Отправить»
Обязательные поля для заполнения не отмечены на форме регистрации после нажатия на кнопку
Подробное описание (Description) Более широкое описание сути дефекта (при необходимости)
«Отправить» (отсутствует выделение поля красной рамкой и сообщение об ошибке внизу поля)

Пример:
Последовательное описание действий, которые привели к выявлению дефекта 1. Перейти на сайт (доменное имя сайта).
Шаги для воспроизведения (Steps To
(которые нужно выполнить для воспроизведения дефекта). Описываются максимально 2. Нажать на кнопку «Регистрация».
Reproduce)
подробно, с указанием конкретных вводимых значений 3. Нажать на кнопку «Отправить».
4. Обратить внимание на форму регистрации

Указывается, что не так работает, в каком месте продукта и при каких условиях.
Обязательные поля для заполнения не отмечены на форме регистрации после нажатия на кнопку
Фактический результат — Actual result Описывая фактический результат, необходимо ответить на три вопроса: что? где?
«Отправить»
когда?

Указывается, как именно должна работать система по мнению тестировщика, Обязательные поля для заполнения отмечены на форме регистрации после нажатия на кнопку
Ожидаемый результат — Expected result
основанному на требованиях и прочей проектной документации «Отправить»
Тестовое окружение - Environment Указывает, на какой платформе (и в каком браузере, в случае с веб-приложениями) этот  Safari Версия 14.0 (15610.1.28.1.9, 15610), MacOS Catalina
дефект воспроизводится (iOS, Android, Windows, Mac)

Один из вариантов градации:


S1 Блокирующая (Blocker)
S2 Критическая (Critical)
S3 Значительная (Major)
Серьёзность дефекта (важность) (Severity) Характеризует влияние дефекта на работоспособность приложения
S4 Незначительная (Minor)
S5 Неудобство (Tweak)
S6 Текст/опечатка (Text)
S7 Тривиальная (Trivial)

Один из вариантов градации:


Указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше P1 Высокий (High)
Приоритет дефекта (срочность) (Priority) приоритет, тем быстрее нужно исправить дефект P2 Средний (Medium)
P3 Низкий (Low)
Порядок исправления ошибок по их приоритетам: High → Medium → Low

Новый (New) — новый баг-репорт.


Открыт (Opened) — баг-репорт открыт.
Определяет текущее состояние дефекта. Отражает жизненный цикл дефекта от Назначен (Assigned) – баг-репорт назначен разработчику.
Статус (Status) начального состояния до завершения. Названия статусов дефектов могут быть разными Исправлен (Fixed) — дефект исправлен.
в разных баг-трекинговых системах Ретест (Retest) — дефект исправлен, требуется проверка тестировщиком.
Открыт снова (Reopened) — дефект проверен тестировщиком, ошибка не исправлена.
Закрыт (Closed) — дефект проверен тестировщиком, баг-репорт закрыт.
Атрибуты отчёта о дефекте
Второстепенные атрибуты  

Attachments (Вложения)
Скриншоты, видео или лог-файлы

Fix Version (Версия) Указывает, на каком этапе разработки программного продукта был обнаружен дефект

Указывается личность, на которую данный баг-репорт назначается для дальнейшей проверки


Assignee (Назначение)
или исправления

Build (Номер сборки) Указывается номер билда, в котором был обнаружен дефект
Что? Где? Когда?

Что? Что происходит или не происходит согласно спецификации или представлению


тестировщика о нормальной работе продукта.

Где? В каком месте интерфейса пользователя или архитектуры программного продукта


находится проблема.

Когда? В какой момент работы программного продукта, по наступлении какого события или
при каких условиях проблема проявляется.
Примеры
● приложение зависает на уровне редактирования данных о пользователе во время сохранения
текстового файла размером больше 500 Мб;

● данные не сохраняются на форме «Профайл» после нажатия кнопки «Сохранить»;

● поле «Подтвердите пароль» не является обязательным во время регистрации аккаунта;

● текст выпадающего списка отображается за пределами выделенной области на главной


странице во время просмотра вкладки меню «Книги».
Шаги воспроизведения
● являются самой ценной информацией в отчёте;

● представляют собой руководство к действию для тех, кто будет решать проблему;

● в шагах нужно отвечать на вопрос «Что необходимо сделать?»;

● необходимо коротко написать, что сделать, куда нажимать, не уточняя названия страницы;

● описывается как минимум два шага, но не больше семи-восьми шагов;

● в шагах нужно уточнять, на что именно необходимо нажимать (на ссылку, кнопку, логотип);

● шаги необходимо писать с заглавной буквы;

● в последнем шаге необходимо описать, на какую область посмотреть, на что обратить внимание;

● иногда для воспроизведения дефекта нужен ряд условий — их можно вынести в «Предусловие»
Фактический и ожидаемый результаты

● необходимо описывать информативно, соблюдая правило «Что? Где? Когда?»;

● сначала фактический, затем ожидаемый результат;

● один результат в одном дефекте;

● результаты следует описывать полными предложениями, с подлежащим и сказуемым;

● результаты необходимо писать с заглавной буквы.


Пример
Тема: Элементы подменю «Courses» отображаются за
границами выпадающего списка в главном меню после
наведения курсора на блок «Courses».
Описание: Элементы подменю «Courses» отображаются за
границами выпадающего списка в главном меню после
наведения курсора на блок «Courses».
Шаги воспроизведения:
1. Открыть сайт http://clgcms.qa-testlab.net/.
2. Навести курсор на раздел «Courses».
3. Обратить внимание на расположение надписей в
выпадающем списке.
Фактический результат: Элементы подменю «Courses»
отображаются за границами выпадающего списка в главном
меню после наведения курсора на блок «Courses».
Ожидаемый результат: Элементы подменю «Courses»
находятся в пределах выпадающего списка в главном меню
после наведения курсора на блок «Courses».
Правила работы с дефектами
1. Старайтесь следовать правилу «Что? Где? Когда?».
2. Одна ошибка — один отчёт о дефекте.
3. Старайтесь быть лаконичными при описании дефекта в теме дефекта.
4. Каждый дефект должен быть воспроизведён повторно перед написанием отчёта.
5. Отчёт о дефекте должен быть составлен сразу, не откладывайте на потом.
6. Минимизируйте количество шагов в описании.
7. Пишите техническим языком с применением принятой на проекте терминологии.
8. Прикрепляйте дополнительные файлы (логи, скриншоты, видео).
Дополнительно об отчётах
1. Старайтесь часть самих логов прикреплять в описании. Это поможет при поиске дефектов
по сообщениям об ошибках, которое выдает само приложение.
2. Используя видео, вы можете короче описать дефект и избежать недопонимания.
3. Прикрепляйте ссылки к требованиям, это поможет избежать споров и сэкономить время.
4. Избегайте дубликатов дефектов: прежде чем составлять отчёт о дефекте, спросите у коллег
или проверьте в баг-трекере, есть ли уже такой дефект.
5. Указывайте версию ПО и тестовый стенд (окружение), на котором был обнаружен дефект.
6. Попробуйте воспроизвести дефект, следуя вашим собственным шагам.
Состав команды

Как правило, команда разработки состоит:

● из разработчика (-ов);

● аналитика (-ов);

● тестировщика (-ов);

● менеджера проекта.

Дополнительно — DevOps и служба поддержки.


Пути развития
Рабочий день тестировщика
1. Проверка почты о новых билдах/сборках. Уточнение у разработчиков.
2. Ежедневный митинг Stand Up. Общение со всей командой.
3. Комментарии на дефекты. Обсуждение дефектов.
4. Задание от Team Lead, обсуждение задач.
5. Написание тест-кейсов, уточнение/обсуждение требований с аналитиком.
6. Тестирование новой функциональности.
7. Ретест (повторное тестирование) исправленных дефектов.
8. Регрессионное тестирование.
9. Создание отчётов о дефектах, обсуждение дефектов с разработчиком.
10. Тестирование требований. Общение с аналитиком, разработчиком.
11. Результаты тестирования, обсуждение результатов с руководителем.
Полезные ссылки
Составление и оформление отчётов о дефектах
Почему грамотное оформление баг-репортов так важно
Как правильно необходимо описывать шаги в баг-репорте
Основные атрибуты баг-репорта
Баг-репорт: об использовании «некорректных» слов
Материалы лекции №1 «Вводная часть. Что такое баг (дефект)» по курсу «Основы тестирования ПО»
Правила описания результатов в баг-репорте
Правила описания багов на английском языке. Использование пассива
С чего начинать описание шагов воспроизведения дефекта (бага)?
Как правильно составить описание бага в баг-трекере. Принцип «Что? Где? Когда?»

Книга Software Testing — Base Course (Svyatoslav Kulikov), с. 164–204.

Рассказ о себе
Tell me about yourself job interview question

Общее о тестировании
Материалы ISTQB
Основные положения тестирования
Образ современного тестировщика. Что нужно знать и уметь
Вопросы

Вам также может понравиться