Тестирование ПО. Уровень 1

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

На этом уроке

Кто такой тестировщик? Что такое тестирование? Что такое качество? Стандарт ISO/IEC 25010. Что такое дефект? Правила оформления дефектов. Состав команды разработки. Направления развития.

Введение в курс

В рамках теоретического курса вы сможете освоить следующие навыки:

1. Владение основной терминологией.
2. Поиск дефектов и составление отчётов по найденным дефектам.
3. Использование техник тест-дизайна для составления тест-кейсов.
4. Основные виды и подходы ручного тестирования.
5. Основные виды тестовой документации.
6. Первые практические навыки тестирования веб-приложений.
7. Инструменты: Dev Tools, Fiddler, Charles proxy, Wireshark, Postman.

В качестве рекомендации — несколько советов, чтобы вы получили максимальный результат от обучения:

1. Старайтесь выполнять домашнее задание в полном объёме. Так вы получите практический опыт.
2. Используйте текстовые редакторы либо OneNote для ведения записей.
3. Создайте для себя глоссарий определений и терминов, который вы могли бы использовать в работе или для повторения.
4. Постарайтесь составить резюме как можно раньше. После каждого урока анализируйте, можете ли вы добавить в резюме что-то новое, что вы действительно поняли и закрепили. Но имейте в виду, закреплять надо и дальше.
5. Практику старайтесь закреплять на краудтестинговых площадках, таких как uTest.com или test.io. Их на самом деле больше, но эти — одни из самых популярных.
6. Структурируйте и фильтруйте поступающую информацию. Пользуйтесь только проверенными источниками.
7. Старайтесь помогать советом и делом своим сокурсникам.

В рамках курса рекомендуется использовать определения из глоссария ISTQB. Ссылки на ресурсы вы найдёте в конце методички.

Тестировщик и тестирование

Кто такой тестировщик?

Рассмотрим два определения «тестировщик» — в соответствии с ISTQB и с профстандартом РФ.

В соответствии с ISTQB:

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

В соответствии с профстандартом (Приказ Минтруда России от 11.04.2014 «Об утверждении профессионального стандарта «Специалист по тестированию в области информационных технологий»):

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

Определение профстандарта говорит, что основная задача тестировщика — проверка соответствия продукта заявленным требованиям. Или, если иначе, — тестирование.

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

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

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

Что такое тестирование?

Что такое тестирование в соответствии с ГОСТ Р 56920-2016?

Тестирование — набор операций, проводимых для выявления и/или оценки свойств одного или более элементов тестирования (ГОСТ Р 56920-2016 — Системная и программная инженерия. Тестирование программного обеспечения).

Теперь посмотрим определение, которое даёт нам ISTQB.

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

Тестирование — один из аспектов контроля качества. Он входит в обеспечение качеством.

Testing (тестирование) — разработка и прохождение тест-кейсов, локализация дефектов и пр.

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

QA (обеспечение качества) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде и т. д.

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

Чем занимается тестировщик:

1. Тестирование и анализ продукта.
2. Составление тестов для дальнейшего тестирования.
3. Взаимодействие с разработчиками и в целом с командой для анализа и исправления дефектов.
4. Составление отчётной документации о результатах тестирования на определённых этапах.

Чем занимается инженер по обеспечению качества (помимо тестирования):

1. Формирование критериев качества и контроль за их соблюдением.
2. Внедрение стандартов.
3. Изучение возможности по изменению и улучшению процесса разработки.
4. Обучение специалистов.
5. Улучшение коммуникаций в команде.

В процессе тестирования часто встречаются два термина — валидация и верификация.

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

К примеру, тестирование требований, например составленных описаний EPIC и US для разработчиков по предоставленному ТЗ от заказчиков.

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

К примеру, функциональное тестирование US для определения того, что ПО работает согласно требованиям.

Верификация фокусируется на вопросе «Соответствует ли результат определённой технической спецификации?».

Валидация ориентирована на рассмотрение продукта с точки зрения пользователя и сфокусирована на вопросе «Соответствует ли результат поставленной цели?». Например, даёт ли результат решение проблемы?

Что такое качество?

Качество — понятие, которое многие могут понимать по-своему.

По ISTQB:

Качество — степень, с которой какой-то компонент, система или процесс отвечает определённым требованиям и/или требованиям и ожиданиям пользователя/заказчика.

Мы видим, что качество связано с требованиями, которые явно (или неявно) предъявляются к продукту.

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

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

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

Международный стандарт качества ISO/IEC 25010

Сейчас действующий международный стандарт качества — ISO/IEC 25010, который вытеснил стандарт ISO/IEC 9126-1 и включает в себя 8 характеристик качества и 31 подхарактеристику.

Рассмотрим 8 характеристик этого стандарта.

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

Эта характеристика состоит из следующих подхарактеристик:

● Функциональная полнота — степень, в которой набор функций охватывает все указанные задачи и задачи пользователя.

● Функциональная правильность — степень, в которой продукт или система обеспечивает правильные результаты с необходимой степенью точности.

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

К примеру, мы определяем, что через интернет-магазин можно купить то, что он продаёт. Можно ли сделать доставку товара на дом, как заявляется на его странице?

2. Эффективность производительности(здесь — эффективность) — характеристика, которая представляет производительность относительно количества ресурсов, используемых в указанных условиях.

Эта характеристика состоит из следующих подхарактеристик:

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

● Эффективность использование ресурсов — степень соответствия количества и типов ресурсов, используемых продуктом или системой при выполнении своих функций.

● Вместимость — степень, в которой максимальные пределы продукта или системного параметра соответствуют требованиям.

К примеру, сколько ваше приложение потребляет серверных ресурсов.

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

Эта характеристика состоит из следующих подхарактеристик:

● Завершённость — степень, в которой система, продукт или компонент удовлетворяют потребности в надёжности при нормальной работе.

● Доступность — степень работоспособности и доступности системы, продукта или компонента, когда это необходимо для использования.

● Отказоустойчивость — степень, в которой система, продукт или компонент работает как предполагалось, несмотря на аппаратные или программные сбои.

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

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

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

Эта характеристика состоит из следующих подхарактеристик:

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

● Обучаемость — степень, с которой будущим пользователям легко будет работать с разрабатываемым приложением. Или насколько легко его будет изучить.

● Работоспособность — степень, в которой продукт или система имеет атрибуты, облегчающие управление и контроль.

● Защита пользователя от ошибок — степень, в которой система защищает пользователей от ошибок.

● Эстетика пользовательского интерфейса — степень, в которой пользовательский интерфейс позволяет приятное и результативное взаимодействие.

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

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

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

Эта характеристика состоит из следующих подхарактеристик:

● Сосуществование — степень, в которой продукт может эффективно выполнять требуемые функции при совместном использовании общей среды и ресурсов с другими продуктами без вредного воздействия на любой другой продукт.

● Совместимость — степень, в которой два или более продукта, системы или компонента могут обмениваться информацией и использовать её.

К примеру, ваш интернет-магазин может работать с платёжными или другими внешними системами.

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

Эта характеристика состоит из следующих подхарактеристик:

● Конфиденциальность — степень, в которой продукт или система гарантируют, что данные доступны только тем, кому разрешён доступ.

● Целостность — степень, в которой система, продукт или компонент предотвращают несанкционированный доступ, модификацию компьютерных программ или данных.

● Отслеживаемость или невозможность отказаться (non-repudiation) — степень, в которой может быть доказано, что действия или события могут иметь место, так что они не будут отклонены позже.

● Ответственность (Accountability) — степень, в которой действия объекта могут быть однозначно прослежены до него.

Примечание: в оригинале Accountability: degree to which the actions of an entity can be traced uniquely to the entity.

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

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

К примеру, защищённость ваших личных данных при создании аккаунта электронной почты.

7. Переносимость — степень эффективности и результативности, с которой система, продукт или компонент могут быть перенесены из одного аппаратного, программного, операционного или эксплуатационного окружения в другое.

Эта характеристика состоит из следующих подхарактеристик:

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

● Простота (лёгкость установки) — степень эффективности и продуктивности, с которой продукт или система могут быть успешно установлены и/или удалены в определённой среде.

● Заменяемость — степень, в которой продукт может заменить другой указанный программный продукт для той же цели в той же среде.

К примеру, вы можете переносить данные из одной базы данных в другую без их потери.

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

Эта характеристика состоит из следующих подхарактеристик:

● Модульность — степень, в которой система или компьютерная программа состоит из отдельных компонентов, так что изменение одного компонента оказывает минимальное влияние на другие.

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

● Пригодность к анализу — степень эффективности и результативности, с которой можно оценить влияние на продукт или систему предполагаемого изменения одной или нескольких его частей, диагностировать продукт на наличие недостатков или причин отказов или определить детали, подлежащие модификации.

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

● Тестируемость — степень эффективности и результативности, с которой могут быть установлены критерии тестирования для системы, продукта или компонента, и могут быть проведены тесты для определения, были ли выполнены эти критерии.

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

Ошибка, дефект и сбой / отказ

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

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

Какая это может быть ошибка?

● Неправильно или неполно сформированные требования.

● Ошибка при выборе архитектурного построения системы приложения.

● Ошибка при написании программного кода.

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

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

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

Найденные дефекты могут снижать качество продукта.

Дефект — это несовершенство или недостаток в работе продукта, когда он не отвечает требованиям или спецификации.

Можно сказать, проще: дефект — расхождение ожидаемого и фактического результата.

Ожидаемый результат — поведение системы, которое мы можем взять из требований.

Фактический результат — поведение системы, наблюдаемое в процессе тестирования.

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

Российский ГОСТ 27.002-89 расшифровывает сбой и отказ следующим образом:

● Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.

● Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.

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

Отчёт о дефекте

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

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

Можно выделить три основные цели создания отчётов о дефектах:

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

● назначить приоритет проблеме,

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

В зависимости от полноты и корректности созданного отчёта о дефекте зависит, как быстро разработчик сможет выяснить корень проблемы (root cause) и приступить к её устранению. Поэтому на многих проектах стараются придерживаться определённой стилистики и требований к написанию\составлению отчётов о дефектах.

В качестве примера рассмотрим поля отчёта о дефекте в баг-трекинговой системе Redmine.

Можно выделить следующие поля:

1. Тип задачи.
2. Тема (название, заголовок).
3. Описание.
4. Статус.
5. Приоритет.
6. Назначена или нет.
7. Категория.
8. Версия.
9. Важность (Серьёзность).
10. Дата начала.
11. Срок завершения.
12. Оценка временных затрат.
13. Готовность.
14. Модуль (место, раздел в системе, где найден дефект).
15. Файлы.

В большинстве баг-трекинговых систем поля отчётов о дефектах схожи. Кроме того, можно дополнительно добавлять необходимые поля в соответствии с потребностями проекта.

Критерии начала тестирования:

■ готовность проекта и модулей по отдельности

■ законченность разработки требуемого функционала

■ наличие необходимой документации

Критерии окончания тестирования:

■ полное тестовое покрытие

■ результаты тестирования удовлетворяют критериям качества продукта

■ проверка исправления найденных багов

Жизненный цикл дефекта

У каждого дефекта свой жизненный цикл.

Рассмотрим жизненный цикл дефекта на примере баг-трекинговой системы JIRA.

Основные этапы:

1. Дефект ОТКРЫТ, когда его обнаружили и создали отчёт о нём.
2. Дефект В РАБОТЕ, когда он назначен на разработчика и тот начал работу над ним.
3. Дефект ИСПРАВЛЕН, когда разработчик внёс изменения (исправление или fix) в программный код и сохранил эти изменения в общем репозитории кода.
4. Дефект ЗАКРЫТ, когда проверили, что он действительно исправлен в новой версии продукта.
5. Дефект ОТКРЫТ ЗАНОВО в случае, если ранее исправленный дефект снова был обнаружен в системе.

Атрибуты отчёта о дефекте

Среди основных атрибутов дефекта можно выделить следующие:

1. Уникальный идентификатор (ID).
2. Тема (краткое описание) — Summary.
3. Подробное описание — Description.
4. Шаги для воспроизведения — Steps To Reproduce.
5. Фактический результат — Actual result.
6. Ожидаемый результат — Expected result.
7. Вложения — Attachments.
8. Серьёзность дефекта (важность) — Severity.
9. Приоритет дефекта (срочность) — Priority.
10. Статус — Status.

Уникальный идентификатор (ID). Присваивается автоматически (может содержать в себе данные о требовании, на которое ссылается дефект).

Такой идентификатор уникален в баг-трекинговой системе.

К примеру, ID = 1254_17.

Тема (краткое описание или Summary) — кратко сформулированная суть дефекта по правилу «Что? Где? Когда?».

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

К примеру: «Обязательные поля для заполнения не отмечены на форме регистрации после нажатия на кнопку «Отправить».

Или: «Отсутствует логотип на странице приветствия, если пользователь является администратором».

Подробное описание (Description). Более широкое описание сути дефекта (при необходимости).

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

Шаги для воспроизведения (Steps To Reproduce). Последовательное описание действий, которые привели к выявлению дефекта (которые необходимо выполнить для воспроизведения дефекта). Описываются максимально подробно, с указанием конкретных вводимых значений.

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

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

Пример:

1. Перейти на сайт (доменное имя сайта).
2. Нажать на кнопку «Регистрация».
3. Нажать на кнопку «Отправить».
4. Обратить внимание на форму регистрации.

Фактический результат (Actual result). Указывается что не так работает, в каком месте продукта и при каких условиях (описывая фактический результат, необходимо ответить на три вопроса: «Что? Где? Когда?».

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

Ожидаемый результат (Expected result).Указывается, как именно должна работать система по мнению тестировщика (основанному на требованиях и прочей проектной документации).

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

Вложения (Attachments). Дополнительная информация, которая может помочь определить, в чём заключается проблема.

К примеру, скриншоты, видео или лог-файлы.

Серьёзность дефекта (важность), или Severity. Характеризует влияние дефекта на работоспособность приложения. Как правило, её определяет тестировщик.

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

● S1. Блокирующая (Blocker).

● S2. Критическая (Critical).

● S3. Значительная (Major).

● S4. Незначительная (Minor).

● S5. Неудобство (Tweak).

● S6. Текст/опечатка (Text).

● S7. Тривиальная (Trivial).

Приоритет дефекта (срочность), или Priority. Указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект. Как правило, определяет либо менеджер проекта, либо руководитель отдела разработки.

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

● P1. Высокий (High).

● P2. Средний (Medium).

● P3. Низкий (Low).

Порядок исправления ошибок по их приоритетам: High -> Medium -> Low.

На проектах тестировщики могут заполнять только «Важность» (Severity), а иногда — и «Важность», и «Срочность» (Priority).

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

Пример градации:

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

● Открыт (Opened) — баг-репорт открыт.

● Назначен (Assigned) — баг-репорт назначен разработчику.

● Исправлен (Fixed) — дефект исправлен.

● Ретест (Retest) — дефект исправлен, требуется проверка тестировщиком.

● Открыт снова (Reopened) — дефект проверен тестировщиком, ошибка не исправлена.

● Закрыт (Closed) — дефект проверен тестировщиком, баг-репорт закрыт.

Дополнительными атрибутами могут быть:

● Component (Компонент), или Environment (Среда). Указывает, на какой платформе этот дефект воспроизводится (iOS, Android, Windows, Mac и т. д.).

● Assignee (Назначение). Указывается тот, на кого назначается баг-репорт для дальнейшей проверки или исправления.

● Build (Номер сборки). Указывается номер билда, в котором был обнаружен дефект.

Правила оформления дефектов

Основные атрибуты баг-репорта

I. Заголовок отчёта о дефекте. Старайтесь следовать правилу WWW — What? Where? Under Which circumstances? — при описании дефекта в заголовке.

Отвечая на вопросы «Что? Где? Когда (при каких условиях)?», вы сможете легче сформулировать заголовок для дефекта.

«Что?» — что происходит или не происходит согласно спецификации или представлению тестировщика о нормальной работе продукта.

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

«Когда?» — в какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Примеры:

1. Приложение зависает на уровне редактирования данных о пользователе во время сохранения текстового файла размером больше 500 Мб.
2. Данные не сохраняются на форме «Профайл» после нажатия кнопки «Сохранить».
3. Поле «Подтвердите пароль» необязательно во время регистрации аккаунта.
4. Текст выпадающего списка отображается за пределами выделенной области на главной странице во время просмотра вкладки меню «Книги».

II. Шаги воспроизведения:

● самая ценная информация в отчёте,

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

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

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

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

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

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

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

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

III. Фактический и ожидаемый результаты:

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

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

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

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

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

● фактический результат — это то что вы получили, а ожидаемый берётся из требований или следуя здравому смыслу.

Рекомендации и советы при оформлении дефектов

1. Старайтесь следовать правилу WWW — What? Where? Under Which circumstances? при написании темы дефекта.
2. Старайтесь быть лаконичными при описании дефекта в теме.
3. Каждый дефект должен быть воспроизведён повторно перед написанием отчёта.
4. Отчёт о дефекте должен быть составлен сразу, не откладывайте на потом.
5. Минимизируйте количество шагов в описании, убирайте всё, что не помогает воспроизведению бага.
6. Пишите техническим языком с применением принятой на проекте терминологии.
7. Прикрепляйте дополнительные файлы (логи, скриншоты, видео), но убедитесь, что они помогают в понимании бага.
8. Старайтесь часть самих логов прикреплять в описании. Это поможет при поиске дефектов по сообщениям об ошибках, которое выдаёт само приложение.
9. Старайтесь записать видео, демонстрирующее шаги и баг, минимальное по времени и достаточного качества, так как размеры дисков ограничены.
10. Прикрепляйте ссылки к требованиям, это поможет избежать споров и сэкономить время.
11. Не плодите дубликаты дефектов — проверьте в баг-трекинговой системе, прежде чем составлять отчёт о дефекте, или спросите у коллег, создавал кто-нибудь такой дефект или нет.
12. Указывайте версию ПО (версию браузера, операционной системы, разрешение экрана) и тестовый стенд (окружение), на котором был обнаружен дефект.
13. Попробуйте воспроизвести дефект, следуя вашим собственным шагам. По вашим шагам баг должен повторить даже человек, незнакомый с проектом.
14. Проверяйте ссылки, добавленные в баг-репорт. Они должны открываться и предоставлять только нужную информацию о баге.
15. Если в найденном дефекте есть ещё какие-то особенности, на ваш взгляд, или влияние на что-то другое, вы можете обратить внимание разработчика и менеджера, дописав это в описании после шагов в «Дополнительно» в качестве PS, например, так: «PS: Это также влияет на авторизацию пользователя».

Пример оформления отчёта о дефекте

Дефект 1

Тема: Сумма скидки прибавляется к основной стоимости книги в корзине Shopping Cart при расчёте итоговой стоимости.

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

Предварительные условия: пользователь зарегистрирован.

Шаги воспроизведения:

1. Перейти на страницу Learn to Test.
2. Авторизоваться в системе.
3. Добавить книгу в корзину.
4. Перейти в корзину.
5. Обратить внимание на расчёт итоговой стоимости книги с учётом скидки.

Фактический результат: сумма скидки прибавляется к стоимости книги в корзине Shopping Cart при расчёте итоговой стоимости.

Ожидаемый результат: сумма скидки вычитается из стоимости книги в корзине Shopping Cart пользователя при расчёте итоговой стоимости.

Тестовое окружение: браузер Chrome 77.012.32.

Вложения: https://is.gd/l7MZqy

Дефект 2

Скриншот_1

Тема: окно «Не нашли, что искали?» перекрывает каталог частых услуг в случае неуспешного поиска для неавторизованного пользователя.

Описание: в случае, если неавторизованный пользователь введёт в поле поиска запрос и результат поиска будет пустым, на странице с результатами поиска окно «Не нашли, что искали?» частично перекроет каталог частых услуг.

Предварительные условия: пользователь не авторизован.

Шаги воспроизведения:

1. Перейти на страницу Портал государственных услуг РФ.
2. В поле поиска ввести gender и нажать кнопку поиска.

Фактический результат: окно «Не нашли, что искали?» частично перекрывает каталог частых услуг.

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

Тестовое окружение: браузер Chrome 77.012.32

Вложения: скриншот 1.

Тестировщик в составе команды разработки

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

● Разработчика/ов.

● Аналитика/ов.

● Тестировщика/ов.

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

Дополнительно бывает дизайнер, DevOps и служба поддержки.

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

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

Когда задача реализована, и разработчики сообщили что новая фича/функциональность (feature) внедрена, выпускается новый тестовый билд, то есть сборка, в которую входят реализованные фичи. Дальше билд передаётся команде тестирования. Тестировщики в своей работе основываются на требованиях. Если поведение программы отличается от ожидаемого, они составляют отчёт о дефекте. Тестировщики, как правило, должны разбираться в готовом продукте. Исключения могут составлять узконаправленные специалисты по тестированию, например, по нагрузочному тестированию, автоматизации или тестированию безопасности. Здесь часто бывает, что они узко ограничены сферой предметной области продукта.

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

Рабочий день тестировщика

Новый день на проекте может отличаться от предыдущих. Можно выделить основные активности в рабочем дне инженера по тестированию:

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

Пути развития в тестировании

Возможно, вы уже слышали, что дорога в IT через тестирование считается одной из самых лёгких. Но какой карьерный путь может пройти начинающий тестировщик?

Вы начнёте с должности Junior-специалиста, далее идёт Middle-специалист, дальше Senior/старший специалист.

Иногда встречается такое понятие, как Key Tester, то есть ключевой тестировщик на проекте. Это, как правило, опытный специалист, проработавший достаточно давно на проекте и знающий его очень хорошо. Также есть руководитель команды тестирования — QA Team Lead. Кроме того, вы можете быть QA Lead на одном проекте, а на другом быть рядовым тестировщиком.

Выше руководителя команды тестирования — QA Manager проекта. Не стоит путать с Product Manager, руководителем отдела/департамента по тестированию или Head QA Department. QA Manager проекта следит за качеством продукта на проекте и руководит командами тестирования, если их несколько.

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

Надо хорошо понимать, в каком направлении вы хотите расти и развиваться, какие темы, технологии или направления вас увлекают. Один из распространённых вопросов на собеседованиях «Кем вы видите себя через 1, 3, 5 лет?».

Глоссарий

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

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

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

Тестирование — деятельность, выполняемая для оценки и улучшения качества программного обеспечения (Профессиональный стандарт Министерства труда РФ от 11 апреля 2014 года).

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

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

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

Качество — степень, с которой какой-то компонент, система или процесс отвечает определённым требованиям и/или требованиям и ожиданиям пользователя/заказчика.

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

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

Дефект — несовершенство или недостаток в работе продукта, когда он не отвечает требованиям или спецификации.

Ожидаемый результат — поведение системы, которое мы можем взять из требований.

Фактический результат — поведение системы, наблюдаемое в процессе тестирования.

Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.

Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.

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

Практическое задание

Используя приложенную таблицу, выполните следующие задания:

1. Прочитать книгу Святослава Куликова (Software Testing — Base Course), страницы 167-206 (Глава 2.5. Отчёты о дефектах)
2. Ответить на вопросы в приложенной ниже форме.
3. Составить отчёты о дефектах в приложенной форме.
4. * Создать свой собственный глоссарий определений для подготовки к собеседованиям в будущем.

Требования к выполненной работе

1. Практическое задание должно быть выполнено в приложенной форме.
2. Расширение файла должно быть формата Excel (XLS, XLSX).
3. Название файла не менять, и вместо ФИО укажите свои фамилию и имя.

Дополнительные материалы

1. Что такое ISTQB?
2. Глоссарий ISTQB на русском языке.
3. Статья-обзор за 2019 год о тестировщиках, их уровне ЗП и востребованных навыках.
4. Почему грамотное оформление баг-репортов так важно.
5. Как правильно необходимо описывать шаги в баг-репорте.
6. Основные атрибуты баг-репорта.
7. Баг-репорт: об использовании «некорректных» слов.
8. Глоссарий по теме «Основы веб-тестирования. Что такое баг (дефект)?»
9. Правила описания результатов в баг-репорте.
10. Правила описания багов на английском языке. Использование пассива.
11. С чего начинать описание шагов воспроизведения дефекта (бага)?
12. Как правильно составить описание бага в баг-трекере. Принцип «Что? Где? Когда?».
13. Вопрос на собеседовании: «Расскажите о себе». Видео на английском языке.
14. Материалы ISTQB.
15. Основные положения тестирования.

Используемые источники

Для подготовки методического пособия мы использовали эти ресурсы:

1. Software Testing — Base Course (Svyatoslav Kulikov).

2. ГОСТ 27.002-89. Надёжность в технике (ССНТ). Основные понятия. Термины и определения.

3. ISTQB Glossary Search.

4. ISO/IEC 25010.

5. ГОСТ Р 56920-2016. Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения.