Тестирование продукта Frontend

Backend vs Frontend

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

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

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

Взаимодействие происходит посредством API:

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

💡 О взаимодействии поговорим посредством API подробнее позже.

Пример взаимодействия фронтенда и бэкенда! Представим процесс покупки товара в интернет-магазине: 1. Пользователь на фронтенде:
Шаг 1: Открывает страницу с каталогом товаров. Шаг 2: Нажимает кнопку "Добавить в корзину" у выбранного товара.
2. Фронтенд:
Шаг 3: Собирает информацию о товаре, который пользователь хочет купить (название, цена, количество). Шаг 4: Формирует запрос к бэкенду для добавления товара в корзину.
3. Бэкенд:
Шаг 5: Получает запрос с фронтенда о добавлении товара в корзину. Шаг 6: Проверяет наличие товара, доступность и его цену в базе данных. Шаг 7: Добавляет информацию о товаре в базу данных покупок, формирует подтверждение о добавлении товара в корзину.

4. Фронтенд:
Шаг 8: Получает от бэкенда подтверждение о том, что товар успешно добавлен в корзину. Шаг 9: Обновляет страницу пользователя, отображает подтверждение о добавлении товара в корзину и обновленную информацию о корзине.

Стенды / Окружения / Environment

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

Есть разные тестовые среды, у каждой из них есть определенная цель и ценность, но их наличие очень разнится от проекта к проекту. Здесь мы опишем основыне типа тестовых сред.

Среда разработки (Development Environment): Здесь создаются и отлаживаются программы. Разработчики исправляют ошибки и тестируют отдельные модули.
Среда тестирования (Test Environment): Тестировщики проверяют работу ПО и выполняют различные виды тестирования, такие как дымовое тестирование или санитарное тестирование.
Интеграционная среда (Integration Environment): В этой среде проводится интеграционное тестирование для проверки взаимодействия между модулями и системами.
Превью/Предпродакшн среда (Preview/Preproduction Environment): Это окружение, близкое к окружению продакшна. Здесь проводится финальное тестирование перед выпуском ПО.
Продакшн среда (Production Environment): Это окружение, где работает конечный пользователь. Здесь установлено и используется программное обеспечение.

💡 В других источниках вы можете услышать слово “стейдж”, оно не должно вас пугать. Стейдж или stage - то же самое что и окружение. Например: тестовая среда сайта может называть stage.example.com

Frontend

Тестирование фронтенда, это как раз то самое тестирование о котором все думают, когда говорят о, собственно самом, тестировании!

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

Примеры фронтенд-тестирования:

Тестирование пользовательского интерфейса (UI):

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

Тестирование навигации:

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

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

Проверка, как веб-приложение реагирует на изменения размеров окна браузера или устройства, и что оно корректно адаптируется для разных разрешений экрана.

Тестирование форм и валидации:

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

Тестирование динамических элементов:

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

Тестирование анимаций и визуальных эффектов:

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

Тестирование кросс-браузерной совместимости:

Проверка, как ваше приложение работает в разных веб-браузерах (Chrome, Firefox, Safari, Edge и др.), чтобы убедиться, что оно одинаково хорошо отображается и функционирует везде.

Тестирование респонсивности и скорости загрузки:

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

Тестирование доступности:

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

Тестирование роутинга (навигации внутри приложения):

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

💡 Например мы сравниваем макет в фигме, с тем что сделано у нас на проекте:

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

Пример макета в фигме:

И как это выглядит на проде:

Да, одинаково, именно так и должно быть.

Тестирование GUI: мини-гайд

Основы GUI

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

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

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

Элементы UI

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

Список компонентов, требующих проверки, обширен. Некоторые из наиболее распространенных включают:

Текстовые поля для ввода данных.
Чекбоксы для выбора нескольких вариантов.
Радиокнопки для выбора одного варианта.
Кнопки действий.
Значки социальных сетей для шаринга.

Также необходимо учитывать состояния элементов GUI:

Активировано / деактивировано.
Заполнено / не заполнено.
Скрыто / отображено.
Параметры по умолчанию.
Поведение при наведении мыши.

Хорошая статья которая показывает в иллюстрациях как выглядят те, или иные элементы UI.

Ключевые критерии качества GUI

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

Вот что важно учитывать:

Стили и внешний вид: Таблицы стилей и эстетика интерфейса.
Совместимость: Обеспечение совместимости с различными браузерами или операционными системами.
Валидация и целостность данных: Проверка вводимых данных на корректность и целостность.
Навигация и удобство использования: Удобство навигации и общее удобство использования интерфейса.
Безопасность: Безопасное применение различных режимов и функций.
Реакция на пользовательские действия: Корректная обработка действий пользователя и сочетаний клавиш.

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

Методологии тестирования

Давайте подробнее рассмотрим методы тестирования графического пользовательского интерфейса (GUI), используемые для обеспечения соответствия программы определенным стандартам и доступности всех функций для пользователя без ошибок.

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

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

💡 Эти методы не проводятся в очередности, или обязательно все. Скорее они проводятся на разных этапах тестирования. Об этом поговорим чуть позже

Подход к тестированию графического пользовательского интерфейса

Как тестировщику подступиться к тестированию пользовательского интерфейса?

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

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

Чеклисты

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

Компоненты пользовательского интерфейса

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

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

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

Приложение открывается двойным кликом.
Поведение при запуске нескольких экземпляров приложения соответствует ожидаемому.
В информации о программе отображается название приложения, версия и другие важные сведения.
Строки заголовков окон и нейминг последовательны.
При закрытии приложения пользователю предлагается подтвердить закрытие и выводится предупреждение о любой несохраненной работе.
Динамические элементы, такие как индикаторы выполнения или значки песочных часов, показывают, требуется ли процессам время для загрузки или завершения.
Онлайн-справка доступна через меню «Справка» и клавишу F1.
Навигация по вкладкам работает и имеет порядок слева направо и сверху вниз.
Обязательные поля выделены и имеют валидацию.
Команды окна имеют соответствующую клавишу быстрого доступа.

Практический пример

Давайте рассмотрим практический пример стандартного юзкейса тестирования GUI. Зеленые пометки на скриншоте — это ссылки на конкретные действия по тестированию, описанные ниже.

UI-1: проверьте метку страницы, шрифт и позиционирование.
UI-2: проверьте правильность заголовка страницы и шрифт.
UI-3: проверьте, находится ли фокус курсора на поле по умолчанию. Также проверьте:

какие поля являются обязательными (нажимая «Next» с пустой формой)
метку поля и прием допустимых и недопустимых символов
выравнивание и положение текстового поля.

UI-4: проверьте метку поля и прием допустимых и недопустимых символов. Также проверьте выравнивание и положение текстового поля.
UI-5: проверьте метку поля и прием допустимых и недопустимых символов. Также проверьте выравнивание и положение текстового поля.
UI-6: попробуйте ввести текст без орфографических ошибок. Попробуйте ввести разрешенные и запрещенные символы.
UI-7: протестируйте гиперссылки и всплывающие окна.
UI-8: проверьте метку поля и прием допустимых и недопустимых символов. Проверьте выравнивание и положение текстового поля.
UI-9: проверьте метку поля и прием допустимых и недопустимых символов. Введите несовпадающий пароль. Проверьте выравнивание и положение текстового поля.
UI-10: проверьте, работает ли значок «показать / скрыть пароль». Проверьте положение и качество изображения.
UI-11: попробуйте ввести текст без орфографических ошибок. Проверьте сообщение, введя разрешенные и запрещенные символы.
UI-12: Протестируйте гиперссылки и всплывающие окна.
UI-13: Проверьте положение и четкость управляющих компонентов. Протестируйте отправку тестовой формы.

HTML / СSS

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

HTML

HTML, сокращение от Hyper Text Markup Language (язык разметки гипертекста), представляет собой основу веб-страниц. Он определяет структуру и содержимое страницы, устанавливает, где и как следует размещать каждый элемент, от текста и изображений до ссылок и таблиц.

Отметим важное: HTML фокусируется на разметке контента, а не на программировании. Однако его роль в построении Интернет-страницы несомненно значима.

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

Каждый элемент веб-сайта описывается одной или несколькими строками HTML-кода. При запросе веб-страницы браузером (например, Chrome, Opera, Firefox, Safari, MS Edge) происходит доступ к серверу, где хранится содержимое сайта. Браузер анализирует строки HTML-описания страницы, определяет объекты и строит их отображение на экране. При необходимости браузер также загружает файлы, такие как изображения, аудио и видео, которые также описываются с использованием HTML.

Пример HTML

HTML-код страницы, который хранится на сервере, представляет собой набор строк, в каждой из которых указаны характеристики объектов, их тип, размер, а также стили оформления и другие свойства.

Каждая строка содержит теги, которые являются операторами и записываются в графической форме <> и </>. Открывающий тег (<title>, <body>, <h1>, <h2> и т.д.) начинает действие, указывая на начало определенного элемента, в то время как закрывающий тег (</title>, </body>, </h1>, </h2> и т.д.) завершает это действие. Например, тег <title> сообщает браузеру, что следующий текст будет отображен в заголовке окна страницы. Тег <body> определяет содержимое, которое будет видно на странице. Теги <h1>, <h2> и так далее обозначают заголовки разных уровней в тексте, который будет отображен на странице.

Как посмотреть HTML-код

Есть простой способ открыть и посмотреть HTML-код страницы в браузере. Открыть DevTools)

Давайте рассмотрим форму авторизацию в html:

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

Пример одной их самых распространённых форм — вход на сайт. Так форма выглядит в браузере:

А вот так — в исходном коде:

Обратим внимание на некоторые элементы, которые могут быть полезны в процессе тестирования.

Во-первых, открывающий тег формы:

Параметр action указывает на скрипт, который будет обрабатывать эту форму, method — post или get — каким HTTP-методом данные будут передаваться на сервер. Подавляющее большинство форм отправляет данные в теле запроса методом POST.

Это поле ввода имени пользователя или электронной почты. Тип поля — text, а это значит, что дополнительной фильтрации со стороны HTML нет. HTML5 имеет встроенную поддержку разных типов полей: email, tel, url, number, time, date, datetime, datetime-local, month, week, range, search, color. Также присутствует атрибут required="required", который означает, что поле обязательно для заполнения. В предыдущих примерах вы видели, что атрибут required был указан без его значения. Это не ошибка, а два разных способа указания значения. Они оба на данный момент являются верными, но более рекомендуемым является все же запись в форме required, без значения.

Аналогично с полем пароля:

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

Специальная кнопка с типом submit служит для отправки формы:

У неё нет каких-то особых параметров.

А вот ссылка «Забыли пароль?» хоть и расположена внутри формы, но фактически — не её элемент:

Кроме того, на форме есть элементы с типом type="hidden". Они не видны пользователю, но нужны для передачи различной технической информации.

CSS

CSS, или Cascading Style Sheets (каскадные таблицы стилей), определяют внешний вид HTML-документов. Внешние стили размещаются в отдельных файлах с расширением .css и подключаются к HTML-странице при помощи тега <link> в секции <head>

<!DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/css" href="styles.css"> </head> <body> <!— Содержимое HTML --> </body> </html>

Внутренние стили могут быть определены непосредственно внутри HTML-страницы при помощи тега <style> в секции <head>:

<!DOCTYPE html> <html> <head> <style> /* CSS-стили */ body { font-family: Arial, sans-serif; background-color: #f4f4f4; } /* ...другие стили... */ </style> </head> <body> <!— Содержимое HTML --> </body> </html>

Или применены как атрибуты к конкретным HTML-элементам:

<p style="color: red; font-size: 16px;">Текст</p>

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

Тестировщику важно учесть следующие аспекты CSS при тестировании фронтенда:

Корректность отображения: Убедитесь, что стили применяются корректно ко всем элементам, включая текст, изображения, фоны и позиционирование.
Отзывчивость и адаптивность: Проверьте, как веб-страница отображается на разных устройствах и разрешениях экранов, убедитесь, что элементы интерфейса адекватно реагируют на изменения размеров экрана.
Кроссбраузерная совместимость: Гарантируйте, что стили работают одинаково в разных браузерах (Chrome, Firefox, Safari, Edge и других).
Верстка и компоненты: Тестируйте различные компоненты, убедитесь, что верстка элементов (кнопки, меню, формы и т.д.) соответствует заданным стилям и требованиям дизайна.
Интерактивность: Проверьте, что стили корректно реагируют на пользовательские действия, такие как наведение курсора, клики и т.д.
Загрузка и производительность: Убедитесь, что использование CSS не замедляет загрузку страницы, особенно при наличии большого объема стилей.
Обработка ошибок: Тестируйте варианты, когда CSS-файлы не загружаются или загружаются неполностью, чтобы гарантировать, что страница отображается приемлемо.
Доступность: Проверьте, что стили учитывают принципы доступности веб-страницы для пользователей с ограниченными возможностями.
Актуальность и обновления: Убедитесь, что стили и их обновления не нарушают уже существующую функциональность и дизайн приложения или сайта.

Devtools: обязательный инструмент тестировщика

У наших коллег из QA Studio вышел прекрасный тренажер по DevTools

DevTools Workshop

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

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

Что такое тестовая документация?

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

В чем важность тестовой документации?

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

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

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

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

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

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

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

Виды тестовой документации

Развернем самые главные и часто используемые (либо те, которые необходимо знать)

План тестирования

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

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

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

Объект тестирования: Полное описание того, что будет тестироваться. Это может быть приложение, веб-сайт, программное обеспечение и другие компоненты.
Стратегия тестирования: Определяет методы и подход к тестированию, включая ресурсы и время, необходимые для каждой фазы тестирования.
Тест-процедуры: Подробные инструкции, описывающие шаги для настройки, выполнения и оценки результатов теста.
Критерии начала и окончания тестирования: Условия, которые должны быть выполнены, чтобы начать и завершить тестирование. Они определяют готовность продукта к релизу.
Ресурсы для тестирования: Определяют необходимые ресурсы, включая персонал, среды тестирования, оборудование и инструменты.
Предварительные условия: Описывают состояние системы и ее окружение, которые необходимы для успешного тестирования.
Оценка рисков: Идентификация потенциальных проблем и способы их устранения для обеспечения успешного завершения тестирования.

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

💡 Кто пишет тест-план? Обычно тест-план пишет либо тимлид тестирования, либо тест-менеджер. Линейнеы или “обычные” тестировщики тоже могут писать тест-планы, но в очень редком случае. (я, Эд, на своем опыте ни разу не писал тест-план, только в рамках тестового задания при поиске работы)

Пример тест-плана:

Название проекта: Мобильное приложение для планирования поездок

Объект тестирования: Мобильное приложение для iOS и Android, предоставляющее возможность создания и управления планами путешествий.

Цель тестирования: Убедиться в функциональной работоспособности основных функций приложения и соблюдении стандартов безопасности.

Стратегия тестирования:

Функциональное тестирование: проверка добавления, редактирования и удаления планов поездок.
Тестирование совместимости: проверка работы приложения на iOS 15 и Android 12 на разных устройствах.
Тестирование безопасности: проверка защищенности личных данных пользователей.

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

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

Тестовые процедуры:

Проверка функции создания нового плана поездки.
Проверка функции редактирования деталей плана поездки.
Проверка функции удаления плана поездки.
Проверка защищенности данных пользователя.

Ресурсы для тестирования:

Персонал: 2 QA-инженера.
Среда тестирования: iPhone 13 (iOS 15), Google Pixel 6 (Android 12).
Инструменты: Xcode Simulator, Android Emulator.

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

Установленные версии операционных систем iOS 15 и Android 12 на тестируемых устройствах.

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

Потенциальный риск: несовместимость приложения с определенной версией операционной системы.
Способ устранения: тщательное тестирование на разных устройствах и операционных системах.

Тест-кейс

Тест-кейс (Test case) — пошаговое описание действий, которые нужно произвести для проверки какой-либо функции ПО.

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

Во время тестирования QA-специалист выполняет пошагово предписанные действия и делает отметки, соответствует ли полученный результат действия ожидаемому. Если не соответствует – это дефект, по нему пишется баг-репорт и отправляется разработчикам.

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

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

Пример простого тест-кейса

Виды тест-кейсов:

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

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

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

Атрибуты тест-кейсов:

Выделяют следующие основные атрибуты (поля) тест-кейсов:

ID (уникальный идентификатор) — номер тест-кейса.
Название (заголовок, краткое описание) — краткое, но понятное описание содержания тест-кейса. Можно содержать указание на тестируемое бизнес-требование к ПО.
Предусловие (входные данные): То, в какое состояние ПО нужно привести перед началом проверки. Например, закрыть определенные модули. Или зайти в специальный раздел сайта.
Шаги (этапы) — действия проверки step-by-step.
Ожидаемый результат — что тестировщик должен получить на экране после завершения шагов (если там не будет багов, конечно)
Приложения — скриншот или видео, которое объясняет куда именно необходимо посмотреть, или на что следует обратить внимание

Выделяют следующие основные атрибуты (поля) тест-кейсов:

ID (уникальный идентификатор) — номер тест-кейса.
Название (заголовок, краткое описание) — краткое, но понятное описание содержания тест-кейса. Можно содержать указание на тестируемое бизнес-требование к ПО.
Предусловие (входные данные): То, в какое состояние ПО нужно привести перед началом проверки. Например, закрыть определенные модули. Или зайти в специальный раздел сайта.
Шаги (этапы) — действия проверки step-by-step.
Ожидаемый результат — что тестировщик должен получить на экране после завершения шагов (если там не будет багов, конечно)

Для указания результатов тестирования есть также поля:

Фактический результат — что тестировщик увидел на экране после завершения шагов.
Статус – краткое, как завершился тест-кейс. Например, «успех», «провал», «блокировка» или другие заранее согласованные варианты.
Приложения – сюда прикрепляется все, что поможет разработчикам для устранения бага. Например, скриншоты.
История редактирования – краткий журнал изменений, если тест-кейс до этого был модифицирован (кто, когда, как, с какой целью).
Постусловие – действия, которые надо сделать после прохождения тест-кейса. Например, чтобы вернуть систему в исходное состояние для следующей проверки.

Пример рабочего тест кейса:

Имя автора
Серьезность
Статус актуальности
Приоритет
Позитивность/негативность
Тип (смок, регресс, критикал паз)
Статус автоматизации (автоматизирован/нет)
Линки к джире (прикрепленние к задачам в джире в рамках которых были написаны тест-кейсы)
айди тест-кейса
Название
Предусловия
Постусловия
Шаги
Описание действия
Ожидаемый результат действия

Баг-репорт

Отчет о дефекте (defect report, bug report) – это документ, содержащий отчет о любом недостатке в программном обеспечении, системе или ее компоненте. При этом такой недостаток может привести программу к невозможности выполнить требуемую функцию.

Баг-репорт выполняет несколько функций.

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

Главные потребители отчета о дефекте – программисты. Баг-репорт дает им важные данные для дальнейшей работы.

Пример баг-репорта:

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

ID (уникальный идентификатор) — номер найденного бага.
Тестовое окружение — на каком устройстве, под какой операционной системой и в какой версии программы/браузера баг был обнаружен.
Заголовок (краткое описание) — лаконичное и однозначно понятное описание дефекта.
Предусловие (входные данные): То, в какое состояние нужно привести ПО, чтобы воспроизвести баг (например, закрыть открыть определенные модули или зайти в специальный раздел сайта).
Шаги для воспроизведения — какие действия нужно произвести, чтобы данный баг появился.
Фактический результат — что тестировщик увидел на экране после завершения шагов.
Ожидаемый результат — что тестировщик должен был получить на экране после завершения шагов согласно требованиям к ПО.
Приложения – скриншоты и другие файлы, которые могут помочь разработчикам в устранении бага
Серьезность бага – насколько серьезно дефект «ломает» ПО.
Приоритет бага – насколько срочно надо устранить дефект.

Пример рабочего баг репорта:

Название баг-репорта
Окружение
Шаги воспроизведения
Фактический результат
Ожидаемый результат
Приложенный скрин

Чек-лист:

Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.

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

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

Чек-лист Плюсы и минусы

Плюсы:

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

Минусы:

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

Разница чек-листа и тест-кейс

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

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

Пример рабочего чек-листа:

Задача:

Пример чек-листа по ней:

О том, в каких случаях мы используем чеклисты или тест-кейсы подробнее рассказано в Workshop #1

Статья по остальным видам тестовой документации для общего развития и знания