Занятия 2 раза в неделю

ДЗ в формате pdf (всего 30 баллов, первое без баллов). Полнота, соответствие

практики изложенной теории по занятию
Два рубежных контроля, пересдавать нельзя (по 20 баллов)

Баги в джире искать, будет плюсом

Итоговый экзамен (30 баллов)

90 - 100 - отлично
61-89 - хорошо
меньше 60 - удовлетворительно

--------------------------------------

***1 лекция***

1999, Сем Каннер, Тестирование: техническое исследование программы для получения

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

2000 - Selenium, Jira

Тестирование - проверка соответствия между реальным поведением программы и ее

ожидаемым поведением, инфа. качестве продукта

Жизненный цикл разработки ПО:

1) Концепция
2) Описание требований
3) Дизайн
4) Реализация
5) Тестирование
6) Инсталяция и наладка
7) Эксплуатация и поддержка
8) Вывод из эксплуатациии

QC - Quality Control - контроль качества, готовность к выпуску в продашн

QA - Quality Assurance - настраивают систему для отлаживания проблем, проверка

кода на стандарты (ревью)

Качество это соответсиве требованием и пригодность к использованию. При проверке

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

Характеристики качественного ПО:

1. Функциональность
2. Надежность
3. Удобство использования
4. Эффективность
5. Удобство сопровождения
6. Портативность

Обеспечение качества на продукт:

1. Денежные потери
2. Снижение репутации
3. Потеря потенциальных клиентов
4. Рост косвенных затрат на создание продукта
Идеальный тестировщик:

- Soft Skills:
Внимательность
Усидчивость
Коммуникабельность
Умение аргументировано отстаивать свою точку зрения
Активность
Умение примерять роль различных пользователей
Планирование
Ответственность за свои решения и дейтствия
Структурированная, граммотная речь

- Hard skills:
Работа с различными ОС
Знаине англ
Понимание клиент-серверного взаимодейтствия
умение гуглить
Charles (или любой другой сниффер): просмотр запросов, rewrute запросов
Postman
Представление о тест-кейсах, чек-листах
Jira/Redmine/Trello/TFS - баг трекеры

-------------------

ДЗ:

Эссе "Почему я хочу пойти в тестирование, как я вижу свое развитие" в пдф.

Тестирование - это процесс проверки программы на соотвествие требованиям.

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

Автоматизированное тестирование - это тестирование с помощью программы, которая

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

Дефект - это не соответствия фактического результата ожидаемому.

Баг - это дефект, не соответствует документации.

Ошибка - это действие, которое совершает пользователь, чтобы совершить какой-то

результат (приводит к обнаружению дефекта).

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

QC - Quality Control - контроль качества, готовность к выпуску в продашн

QA - Quality Assurance - обеспечение качества, настраивают систему для

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

Тестирование - нашел ошибку и репортнул ее. Контроль качества - занимается

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

Качество ПО - это соответствие всем запросом потребителей,

 1) Функциональность

2) Надежность

3) Удобство использования

4) Эффективность

5) Удобство сопровождения

6) Портативность

Зачем обеспечивать качество - чтобы мы были конкурентно способными на рынке,

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

---------------------

***2 лекция***

**Теория тестирования**

Всего 4 уровня тестирования:

1. модульное (компонентное)
2. интеграционное
3. системное - это когда тестируем продукт со стороны пользователя( когда
реализованы все составные части приложения и тестируем систему в целом)
4. (Регресионное)?доп
5. приемочное доп

Отличия Функционального (Ф) тестирования от нефункционального(НФ) -

Ф - по документации по спеку (ЧТО ДОЛЖНА ВЫПОЛНЯТЬ ПРОГРАММА) Пример, проверить

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

НФ - не прописывается в спеце, производится самими разрботчиками (КАК ОНА ДОЛЖНА

ЭТО ИСПОЛНЯТЬ). Проверяет удобство надежность производительность безопасность
маштабируемость проксируемость свойства. Пример: нагрузочное (много апи запросов
отправить на создание какой-то сущности и посмотреть как система себя поведёт, в
какой момент повалиться и какой у нее предел ), посмотреть, удобно ли расположены
кнопочки, проверить пут до нужного

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

Зачем нам тестирование?

Повысить вероятность того, что приложение, предназначенное для тестирования,

будет работать правильно при любых обстоятельствах (то что описано в документации).

Повысить вероятность того, что приложение, предназначенное для тестирования,

будет соответствовать всем описанным требованиям

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

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

несоответствующим спецификации (дейтсвительности).

**Уровни тестирования**

- модульное (компонентое, юнит) - самые маленькие кусочки, эти тесты пишут

разработчики
- интеграционное - тестируют минимум два модуля
- системное - тестируют всю программу
- приемочное - приемка для заказчика (соответствие на ТЗ по пунктам)

Модульное тестирование - Проверка функциональности в частях приложения, которые

доступны и могут быть протестированы по-отдельности (модули программ, объекты,
классы, функции и т.д.). + Лучшеи чище код, оптимизируют, минимизируем количество
зависимостей в системе, не зависит от других частей системы

Интеграционное тестирование - На соответствие требований проверяется интеграция

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

- снизу вверх (один плюс один, потом к этим модулям еще плюс один и т.д.)
- сверху вниз (уменьшаем)
- большой взырв (все модули соединяем и тестируем)

Системное тестирование - Тестирование программного обеспечения выполняемое на

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

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

Подходы:

- Интуитивное (на базе случаев использования) - тестирование с вариантами

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

Самый объемный уровень тестирования

Приёмочное тестирование - это Вид тестирования, проводимый на этапе сдачи

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

Результат - приемка или отправка на доработку. Тестируется базовый функционал,

который заказывали.

**Классификация**

### **Виды тестирования**

- Функциональное - провлдятся на всех уровнях тестирования

- Не функциональное
- Изменений

Функциональное тестирование - Проверка соответствий функциональных требований ПО

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

Фунциональное - тестироваение функций приложения на соответсиве требованиям

(заказчика менеджер, тз).

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

- На основе функциональных требований, указанных в спецификации требований

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

- На основе бизнес-процессов, которые должно обеспечить приложение (корректность

бзер-кейсов, чтобы приложение могло отвечать на звонки при плохой сети, а маски
работают или нет - не важно уже)

Примеры функциональных тестов

- Приложение для заказа еды

базовые функции:

Установка
 Авторизация на корректные данные и разлогиниться

кликабельность кнопок

добавление в корзину

интерфейс приятный

рабочая корзина

оформление адреса (правильность)

привязка карты и оплата карты (на безопасность)

пуш уведомления

наглядность прогресса заказа

отказ от заказа

определение региона

эппл пей, Гугл пей

Удаление

- Почтовое приложение

регитсрация нового аккунта

на существующую почту

Пароль мин

уведомления (звук например)

разлогин

отправка сообщения на другой почтовый адрес

удобно ли читать текст

шрифты

отправка ссылок, файлов

отправка в корзину, спам (ярлыки как работают)

кликабельность кнопок

добавление более одной почты

сохранение черновиков

ответ на письма

пересылка
 Отмена отправки письма, после какое-то время после отправки

проверка безопасности (двухфакторная атвризация)

поле ввода отправителя (что можно ввести несколько6 что они валидный)

прочитанность

Удаление

- Мессенджер

установка и удаление приложение

запуск приложение

Регистрация (привязка телефона к мессенджеру и отвязка)

удаление аккаунта

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

синхронизация контактов с телефонной книгой

отправка текстовых сообщений, голосовых

отправка сообщения заново, если потеряна сеть

получение сообщений

удаление сообщений (когда отправил)

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

пересылка сообщений

вставка текста

прикрепление файлов различных

навигация между разделами

создание беседы

уведомление о сообщениях(вклю, выкл)

настройки профиля (фио, фото, доп инфа, тема приложения, ящык приложение)

загрузка файлов собеседника

отображение и отправка стикеры эмодзи

статус собеседника

Двухфакторная аутентификация работает ли

 резервная копия сообщений

в каком формате работает (портретный или альбомный режим, развернул или сжал
окно)

- Приложение госуслуг

Скачать и удалить приложение

запуск приложения

Регистрация (логин и разлогин)

Синхронизация мобильного и на компе

Восстановка доступа к аккаунту

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

Верификация данных

проверка смены местоположения

заказ услуг, получение услуг, стутус услуг, отказ от услуг

поиск

доступность услуг

платежная система

корректность данных

Служба поддежрки

Локализация

Двухфакторка и отпечаток пальца

резервное копирование и безопасность данных, чтобы не слили

- Приложение «Напоминания»

установка и удаление приложение

запуск

одинаковый функционал на различных ос

Crud операции

Выбор даты и времени уведомления

Настройка уведомления
 Повторы

приоритетность напоминаний

Создание учетной записи, вход через Гугл

проверка уведомлений, что работает корректно

можно ли смахнуть уведомление (завершить)

преднастроенное время

по геолокации чтобы напоминало

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

- Shazam

Установка и удаление

Запуск

регистрация, логин и разлогин

Проверка кнопок на различных ос

работа с различными микрофонами

Доступ к микрофону

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

и выдает ли вообще

определение музыки в шумной обстановке

Определение человеческого голоса

локализация

история поиска

возможность отправить найденную музыку

проигрыш музыки

Ссылка на эту песню

поиск и сортировка

уведомление о найденной музыке

работа фонового режима

Если не найдена, повторить?

- Spotify

Установка и удаление

Запуск

регистрация, логин и разлогин

прослушивание музыки в реальном и в фоном режиме

один трек, шафл, следующая песня, предыдущая и т.д.

скачивание и воспроизведение

Покупка подписки

стутус пользователя

перенос с других платформ плейлистов

кроссплатформенность и кроссбраузерность

поиск по критериям

подбор подходящей музыки

Пуш уведомления

Объединение плейлистов пользовтаелй

система платежей

проверка режимов для бега и т.д.

сортировка своего плейлиста

синхронизация между устройствами

- Инстаграм

Установка и удаление

Запуск

регистрация, логин и разлогин

доуступ к фотографии

кнопка загрузки

можно ли загрузить из файловой системы телефона

проверка кнопки далее

сделать фотографию в приложении

работа фильтров
 интенсивность всех фильтров

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

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

подпись

отметка людей и геолокации

опубликовать в другие аккаунты инсты, соц сети

поделиться

сохранить

лайк

комментарии

добавить в истории

сохраняли фотографии

архивация

ограничение символов

уведомление (лайки, комментарии, сохр и т.д)

Синхронизация между устройствами (типо на компе выложил, а в телефоне корректно

появилось)

- Калькулятор

Установка, удаление и обновление

запуск

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

проверка арифметических дейтствий (также деление на нуль, что будет)

удаление символов

нельзя вводить буквенные символы

Если нет второго оператора, то равно что выведет

Количество вводимых символов

работа с памятью

история вычислений

дробные числа

проверка поля ввода калькулятора

 откат на шаг назад

Нефункциональное тестирование

Тоже прописывается в ТЗ, все прорисовывается

Уровень тестирования - системный

Основная задача—тестирование свойств, которые не относятся к функциональности

системы

- Надежность(реакция системы на непредвиденные ситуации)

- Производительность(Работоспособность системы подразными нагрузками)
- Удобство(Исследование удобности работы с приложением с точки зрения
пользователя)
- Масштабируемость(Требования к горизонтальному или вертикальному
масштабированию приложения)
- Безопасность(Защищенность пользовательских данных, отследить утечку данных,
css, sql-инъекции, проверка логов, тестирование установки, например, с удаления
приложения, обновление, что после обновления пользователя не разлогинивает)
- Портируемость(Переносимость приложения на различные платформы( Проверка на ОС).

Примеры нефункциональных тестов

- Приложение для заказа еды

- Почтовое приложение

проверка шифрования

защита от скриншота

защита от записи экрана

- Мессенджер

- Приложение госуслуг

при низком заряде устройства

биометрия и двухфакторная

открыто много приложений (опер. Память)

Заполненная файловая система

при какой скорости рабтает приложение

Юзерфрендли
 - Приложение«Напоминания»

- Shazam

- Spotify

Надежность: устновка, реакция на отсутсвие соединения, на подключение

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

много пользователей

удобство расположений кнопок (интерфейс)

Безопасность:скрытый пароль, личные данные, sql-инъекции, сохраненные девайсы

кросбраузерность и кроссплатформенность,проверка верстки

- Инстаграм

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

рефреш, кросплатформенность, проверка верстки

при вводе пароля, чтобы прикрывался (то что это вообще есть), автозаполнение,
sql-инъекции

при отсутвии соединении - чтобы был просмотр загруженных, восстановление

соединение- догружает

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

- Калькулятор

запуск нескольких копий приложения

удобство расположение кнопок, обозначение]6 размер

Альбомное-книжное расположение, кросплатформенность и кроссбраузерность

если телефон сел, то телефон сохранил данные(на отказ восстановление или

стресс-тестирование)

поддержка ОС

вставка из буфера значений удобное

**Тестирование производительности** - опрдеелние работоспособности, стабильности,

потребление ресурсов, нагрузках

- Определения рабочего количества пользователей приложения

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

- Нагрузочное - времени отклика системы на запросы

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

**Тестирование на отказ и восстановление**

- Поведение ПО при прерывании обработки данных

- При потере сети
- При отключении электричества (на стороне клиента или сервера).
- Потеря подключения носителей данных.

**Тестирование удобства (юзабилити)**

- Оценка соответствия дизайна приложения к его функциональности, заданной

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

Тестирование проводится методом черного ящика (на системном уровне и на

приемочном тестировании)

Используют принцип защиты (например ограничить поле ввода)

Тестирование пользовательского интерфейса - включает в себя функциональное

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

тестирование удобства - проводит не каждый, зависит от приложения

**Тестирование локализации**

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

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

**Тестирование установки**

- Установка ПО на поддерживаемые платформы

- Обновление ПО
- Удаление ПО

**Тестирование конфигурации**

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

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

Если телефон корпортивный, то нельзя устанавливать определенные приложения,

заходить на сайты и т.д.

- клиентская
- кросплатформенная
- Кросбраузерная
- Драйвера

- Серверная
- взаимодействие с сетевыми адаптерами

ДЗ: выбрать экран приложения (по вариантам)

интуитивно тестируем его

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

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

в пдф

Связанное с изменениями

Виды:

- дымовое (смоук) - тесты, которыми проверяются что приложение устанавливается,

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

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

- ввод валидных данных - авторизация

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

- Негативное - странное поведение (сценарии, которые соответствуют внештатному

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

- нельзя отправить пустое поле

- нельзя ввести недопустимые символы,

- заполнить меньше 3 букв,

- заполнить больше 10 букв,

- заполнить только логин или пароль

- ввести неверный логин или пароль

- ввести логин вместо пароля и наоборот

- попробовать вставить картинку, файл и т.д

- ввести строчку кода вместо пароля

- Вставка из буфера - не вставилось или вставилось неверно

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

- чекбокс скрыть/показать пароль. Если выбрано скрыть - нескрываем

- для восстановления аккаунат не приходит письмо на почту

- если пользователя нет - происходит авторизация

- ввести неверно 3 раза пароль -не выводит капчу (если это было предусмотрено)
**Знание о системе**

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

Подход:

- по документации (ТЗ, продуктовая) - составляем тест-кейсы по ним

- Интуитивное - тестируем просто интерфейс

Степень автоматизации:

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

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

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

- полнота и соотвест действительности (весь фукнционал детально расписан)

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

В какой момент начинается тестирование? - на моменте определения требований (анализ

и верификация)

В какой момент заканчивается тестирование? - выполнены все тест-кейсы, когда сроки

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

**Тестовые артефакты**

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

---------------------

**Лекция 3**

Требования к ПО - совокупность утверждений относительно атрибутов, свойств или

качеств программной системы, подлежащей реализации.

Спецификация требований – законченное описание поведения программы, которую

требуется разработать. (как себя должна вести программа)

Зачем нужны требования?

- чтобы реализовать все функции, которые ожидает увидеть в продукте заказчик

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

Какие бывают требования:

- Бизнес-требования - Определяют назначение ПО (для чего это по)

- Пользовательские требования - Набор пользовательских задач, которые должна решать
программа, а также способы (сценарии) их решения в системе. Пользовательские
требования могут выражаться в виде фраз утверждений, в виде сценариев
использования, пользовательских историй, сценариев взаимодействия
- Функциональные требования - Охватывают предполагаемое поведение системы,
определяя действия, которые система способна выполнять
- Нефункциональные требования - Не влияют на юзерские кейсы и поведение системы
(поддержка различных версий устройств(минимальная Версия андроила 5, + поддержка
последних версий), поддежрка минимльной версии браузера защита данных, https
протокл, критерии к соержанию данных в БД (нормальные формы), какая БД)

**Техники тестирования требований**

Тестирование требований относится к нефункциональному тестированию (non- functional

testing).

Основными техниками являются:

- Взаимный просмотр.
- Вопросы.
- Уточняющие вопросы.
- Продумывание тест-кейсов (чек-листов).
- Исследование системы.
- Визуализация
- Прототипирование.

Выбор техник зависит от проекта, поэтому их набор может изменяться.

**Качественными можно называть требования которые соответствует перечисленным ниже

свойствам**
- Завершенность (completeness).полный набор инфы о том, какие должны быть
однозначные очевидные
- Атомарность (atomicity). отделенные, неделимые на подтребования
- Последовательность (consistency).
- Недвусмысленность (clearness). Непротиворечивые
- Выполнимость (feasibility). ресурс времени, людей, бюджету
- Обязательность (obligatoriness).
- Актуальность (up-to-date).
- Прослеживаемость (traceability).
- Модифицируемость (modifiability). Изменчивые
- Важность (importance). роль в проекте
- Стабильность (stability). что не будут меняться в краткосрочной перспективе
- Срочность (priority). по этапам приоритеты
- Проверяемость (verifiability). (можно написать кейсы)

Примеры требований к ПО (например, форма регистрации должна содерждать поле логина,

пароля, кнопка регистрации, поле логина тольо из 3 до 10 букв, если требование не
выполнено - подчёркивается красный), телефон в формате строки, веб-приложение
должно содержать расчет ипотеки, чтобы снизить нагрузку на операторов):

1. Spotify

Пользовательское: один плейлист на двоих

Бизнес: чтобы было больше клиентов с подпиской

Функциональное: поиск по исполнителям, фоновый режим, история прослушиваний

НФ: сжимать музыку определенным образом, оптимизация, безопасность аккаунтов

2. TikTok

Пользовательское: ргеитсрация, кнопка загрузки видео, просмотр чужих видео

Бизнес: видео платформ для оротких видео, интеграция рекламы между роликами

Ф:загрузка видео из галереи, навигация, комментарии к видео и реакции, поиск по

пользователям,

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

сервис,

3. Приложение для заказа пиццы

Пользовательское: приятный интерфейс, описание корзины и меню

Бизнес: простое и удобное приложение для зазаказы пиццы с меню и оплатой любым
способом

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

создание заказа, отслеживание заказа,

НФ: запуск на различных устройствах, нагрузка на приложение

4. Инстаграм

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

 Бизнес:делиться фото и видео с другими

Ф: комментарии, реакции, проистывание видео свайпом

НФ:безопасность данных, доступность сервиса

5. ВК

Пользовательское:удобная навигация,

Бизнес: общениес друзьями, делиться новостями с другими

Ф: создание бесед, отправка сообщений, звонки

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

сервис, безопасность сервиса

6. Авито

Пользовательское: продажа вещей и услуг, размещение объявлений

Бизнес: продавать вещи и услуги

Ф: создать объявление, crud операции, поиск

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

сервис, безопасность сервиса

7. Покупка авиабилетов

Пользовательское: удобная навигация,визуализация маршрута, сравнение билетов,

условия билета (багаж и т.д)

Бизнес: создание по для продажи билетов на самолет

Ф: поиск билетов, покупка билетов, система оплаты, добавление в корзину, возврат

билета

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

сервис, безопасность сервиса

8. Юла

Пользовательское: удобная форма создания объявления, фильтр и поиск по

объявлениям, удобный личный кабинет с меню магазинов, галочка в качестве верности
объявление

Бизнес: платформа для продажи и обмена товарами

Ф:создать объявление, история запросов, регитсрация с помощью соц.сетей,

создание коинов для отплаты, обязательная фотография

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

сервис, безопасность сервиса

9. Telegram

Пользовательское: простота создания профиля, поиск по каналам

 Бизнес: создание конфиденциального мессенджера

Ф:звонки, голосовые, отправка сообщений, поиск по файловое системе

НФ: конфиденциальность, работа на разных платформах

**Тестовые артефакты**

- Баг-репорт - описывает найденный дефект

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

Это точно баг? если функционал не прописан в требованиях, но работает, то это ФИЧА
и ее документируют

- требования
- пользовательский опыт

Баг-репорт - документ, содежражий в себе описание бага:

- Заголовок -
- Принцип “Где? Что? Когда?”
- Где? —В каком элементе ПО возникает дефект
- Что? —Что происходит/непроисходит согласно документации/представлению о
нормальной работе продукта
- Когда? —При каких действиях возникает дефект
- Приоритет
- Шаги воспроизведения
- Фактический результат
- Ожидаемый результат
- Окружение

- Заголовок - креш приложения при открытии профиля пользователя из чата

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

1. Открыть групповой чат

2. Получить сообщение от пользователя А
3. Нажать на аватарку пользователя

- Фактический результат - Приложение падает [файл дампа, ссылка на дамп]

- Ожидаемый результат - Открывается профиль пользователя А

- Окружение - Версии 1.1.1, устройство/ОС

Дополнительно в баг-репорте:

1. Прикладываем видео/скриншоты, если можно их приложить

2. Ссылки на макеты/документацию, если ссылаемся на них
3. Дампы, ссылки на дампы, логи и другая дебажная информация
4. Указываем версию приложения, версию системы, устройство, если проблема Device
Specific

Какой он – идеальный баг-репорт?

- Баг-репорт должен быть настолько подробный, чтобы любой

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

**Тест-кейсы**

Тест-кейс—это тестовый артефакт, суть которого заключается в выполнении некоторого

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

Состоит из:

- ID кейса Пример, 1
- Заголовок Пример, тест-кейс для отправки файла в чат
- Шаги Пример, нажать плюс у поля ввода в чате, выбрать файл из фалйовой системы,
нажать отправить
- Ожидаемый результат Пример, файл отправлен

Предусловие: ПО запущено, пользовтаель авторизован и т.д.

Улучшения

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

предварительные условия)
- Не писать лишние детали (название файла)
- Вынести во внешний документ повторяющиеся сценарии (например, проверку, что меню
по(+) появляется)

Пример

- ID кейса Пример, 1
- Заголовок Пример, тест-кейс для отправки файла в чат
- Шаги Пример,
1. выбрать файл из файловой системы для отправки - файл выбран
2. Отправить файл - файл отправлени виден в чате у отправителя и получателя
- Ожидаемый результат Пример, файл отправлени виден в чате у отправителя и
получателя

Предусловие: ПО запущено, пользовтаель авторизован и т.д.

Как лучше не делать:

- Кейс А не должен зависеть от кейса Б (например, проверять Б можно только после А)

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

**Чек-лист**

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

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

Из чего-состоит:

- Id тест-кейса (действия)
- название тест-кейса (действия)
- Результат

Плюсы:

- история тестов - можно выделить Failed и перепроверять только их

- Наглядность - легко оценить стадию продукта и стадию проверок

Минусы:

- Слабый уровень детализации

- отсутствие подробной документации - трудность для новых сотрудников

**Тест-план**

Тест-план - Документ, описывающий весь объем работ по тестированию, начиная с

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

Плюсы:

- возможность приоритезации задач по тестированию

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

Шаблон:

- назначение - для чего

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

**Тестовое покрытие**

Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая

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

Покрытие требований - оценка покрытия тестами функциональных и нефункциональных

требований к продукту путем построения матриц трассировки.

Расчет тестового покрытия относительно требований проводится поформуле: Tcov=

(Lcov/Ltotal) * 100%,

где:Tcov-тестовое покрытие

Lcov-количествотребований, проверяемых тест кейсами

Ltotal-общее количество требований

---------------------

**Лекция 4**

**Приоритет и серьезность**

<u>Приоритет</u> - срочность, с которой необходимо исправить баг (менеджерская

сторона)

<u>Серьезность</u> - степень влияния бага на систему (техническая сторона)

Зависимость приоритета от серьезности - чем выше серьезность, тем выше

приоритетность - 99%

Серьезность, классификация:

- высокая - критическая для проекта

- средняя - требует решения обязательного и не критичное
- Низкая - не требует срочного решения и не критичное

Как оценить серьезность бага: как работает программа с этим багом, как влияет на
функционал

- Оценка:
- базовый функционал
- основной
- Дополнительный

Как узнать, что функционал - дополнительный?

- Никак
- договориться заранее
- описать это сразу в документации
- использовать логику и интуицию

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

Приоритет, классификация:

- Блокирующий (Blocker) - нерабочее состояние приложения (нельзязалогиниться или

зарегаться, данные раздела не получить, креш приложения при каких-то частых
условиях)
- Критический (Critical) - неправильно работает ключевая бизнес логика (но не
часто) (открытие витрины стикеров из чата и из настроек, если пр иоткрытии стикеров
из настроек - приложение падает, но из чата работает, то это критическая)
- Стандартный (Major) - основная бизнес логика работает не так, как задумывалась
(визуальные несоответствия, пропадает инфа) (превью стикеров в чате не
отображается, )
- Желательный (Minor) - незнавчительная ошибка не нарушающая на бизнес логику
(орфографические ошибки в неприоритетном контенте (глубоко в приложении),
несущественные улучшение UI/UX)
- Незначительный (Trivial) - плохо воспроизводимая проблема, проблема сторонних
библиотек или сервисов, пиксель уехал, пользователь можетдаже не заметить

Что может влиять на приоритет бага?

- блокируется или затрудняется работа основной функции приложения

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

То, приоритет бага определяется:

1. Серьзность (влияние на работспособность, с точки зрения функиональности)

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

вопросы для оценки приоритетности бага(Оценка):

- Сколько пользователей заметят баг?

- Сколько пользователей будут страдать от этого бага? Что у них не будет работать?
- Это воспроизводится? и как часто?
- Это работало в прошлом релизе?Кто-то заметил?
- Какой фунционал затронут?
- Баг может повлиять на репутацию приложения или компании? О котором могут написать
в носотях и т.д.
- Наличие бага влечет за собой финансовые потери? Если нам за что-то платят, а это
не работает, то гг
- Дополнительно:
- Рекламные, маркетинговые акции, в которых привлекут внимание к этому
функционалу
- Другие баги в очереди

!! приоритетность ПРОПИСЫВАЕТСЯ В БАГ-РЕПОРТЕ!!!

**Псевдо-блокеры** ненастоящие блокеры

- завышение приоритета, чтобы на баг обратили внимание

- Неправильно оценить затронутый функционал (Какой дополнительный, какой основной,
базовый)
- состояние паники (ААА, крем! АА, у нас не работает!)

**Adventure time**

- Что?
- Мессенджер

**Какой функционал базовый, основной, дополнительный?**

Базовый (то, для чего приложение создавалось):

- регистрация
- Отправка/получение сообщений
- Отправка/получение файлов
- Авторизация
- установка мессенджера
- создание профиля
- Уведомления
- доступ к контактам и отображение имени
- удаление мессенджера

Основной (необходимые функции, без которых п):

- редактирование профиля
- звонки
- Аватарки профиля
- Пересылка, редактирование и удаление сообщений
- голосовые сообщения
- групповые чаты
- Блокировка пользователя
- Пины сообщений
- поиск по чатам
- местоположение
- Стикеры
- Видеозвонки
- Смена языка
- никнейм
- статус пользователя (ластсин)
- прочитанное сообщение или нет

Дополнительный:

- перевод голоса в текст

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

Не отправляется сообщение:

- приоритет: (критический - один или нет, а вдруг затронет других)(желательный,

если пользовтаель один),
- серьезность - высокая

Не скачиваются файлы формата .bmp (насколько часто этот формат скачивается?):

- приоритет - желательный
- Серьезность - средняя, низкая

Опечатка на окне логина:

- приоритет - блокирующий
- Серьезность - высокая

не устанавливается аватар у трех пользователей:

- Приоритет - стандартный
- серьезность - средняя

Пропущена запятая в окне изменения никнейма:

- приоритет - желательный
- Серьезность - низкий

**Методологии разработки ПО:**

1. «Waterfall Model» (каскадная модель или«водопад») - старая модель, особенность -

каждая стадия должназавершиться до начала предыдущей, Проектирование- дизайн -
кодирование - тестирование - поддержка. Быстрая разработка и стоимость и сроки
известны. Недостатки: шаг назад сделать нельзя. Если на этапе тестирования нашли
ошибку, то возвращаются в первый пункт. В небольших проектах - ок.
2. «V-Model» - очень качественное, тщательное тестирование (механизмы в больницах
или в машинах). Четкие требования,
3. «Incremental Model» (инкрементная модель) - там, где отдельные вопросы на
изменения ясны, когда на рынок хотим раньше вывести, а потом доделать,когда
несколько фич хотим вывести, но н знаем, какая выстрелит (все по кругу) - по
кусакам. Рабочее получаем в конце
4. «RAD Model» (rapid application development model или быстрая разработка
приложений) - на команды разделены, и у команд ожинаковые сроки, а потом соединяют
5. Agile Model» (гибкая методология разработки) - после каждой итерации, заказчик
наблюдает результат, все по спринтам. трудозатраты не оценить. Для больших
проектов. Потребности быстро меняются,
6. «Iterative Model» (итеративная или итерационная модель) - нет четких требований.
Сначала базовый, потом основной функционал. На каждом этапе все лучше и лучше и все
предыдущее должно работать. Рабочее на каждом этапе
7. «Spiral Model» (спиральная модель) - похожа на инкрементную. Критически важны
приложения для бизнеса. акцент на анализ рисков. сначала планируем - анализируем
риски - конструируем, разрабатываем, тестируем - оценка результатов - формирование
требований - и т.д. Для блоьших проектов

**Баг-трекеры**

Способы передачи задачи:

- голосом - недостатки: можно забыть или переврать

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

Недостатки:

- нельзя быстро внести и согласовать изменение

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

Другие:

- гитхаб
- система управления проектами

Bug tracking system (BTS) —прикладная программа, разработанная с целью помочь

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

- trello
- jira
- redmine
- mantis
- VS
- bugzilla

Общий флоу работы баг-трекера:

- Назначить задачу на себя

- Переводить задачи в правильный статус
- Следить за оформлением задачи (все вложения прикрепились, после тебя задача на
правильном исполнителе)

Полезное:

- JQL —язык Jira для поисковых запросов. Удобно использовать для поиска задач,
более гибкая настройка

Фильтры:

- Быстрый поиск задач

- Отчеты на почту
- Графики

Борды:

- Визуальное представления задач из фильтра на одном экране

- Можно вывести с помощью списка, диаграммы, графика

---------------------

**Лекция 5**

Баг-трекер - программа для отслеживания багов, для внесения багов в упорядочную

систему

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

Зачем назначать задачу на себя пр иработе с ней? чтобы ее не забрали, чтобы ее не

потерять, чтобы другие видели, над чем работаешь

**Тест-дизайн**

Тест-дизайн–это этап процесса тестирования ПО, на котором проектируются и создаются

тест-кейсы в соответствии с определёнными ранее критериями качества и целями
тестирования. Процесс написания тест-кейсов

Тест-дизайнер–это сотрудник, в чьи обязанности входит создание тестовых случаев,

обеспечивающих оптимальное тестовое покрытие трестируемого продукта.

Зачем нужен тест-дизайн:

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

- сделать максимальное тестовое покрытие

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

- 0—15(интервал) —красный
- 16 —27 —синий
- 28 —59 —зеленый
- 60 —100 —желтый

Позитивный: от 0 до 100

Негативный: отрицательные значения, больше ста, буквы, символы

Класс "красный" - 7 (это любое число из интервала). это проверка алгоритма,

покрасилось ли 7 в красный

Класс "синий" - 20

Класс "зеленый" - 35

Класс "желтый" - 70

- Граничные значения

- 0—15(интервал) —красный
- 16 —27 —синий
- 28 —59 —зеленый
- 60 —100 —желтый

Класс "красный": 0, 15, -1, 1 ,14, 16

Класс "синий":16, 27, 15, 17, 26, 28

Класс "зеленый": 28, 59, 27, 29, 58, 60

Класс "желтый": 60, 100, 59, 61, 99, 101

Далее убираем повторяющиеся:

Класс "красный": 0, -1, 1 ,14

Класс "синий":16, 15, 17, 26,

Класс "зеленый": 28, 27, 29, 58

Класс "желтый": 60, 100, 59, 61, 99, 101

Накладываем граничные значения на значения классов эквивалентности:

Класс "красный": 1

Класс "синий":17

Класс "зеленый": 29

Класс "желтый": 61

- Таблица принятия решений

 - Если красный и зеленый, то 1
- Если красный и НЕ зеленый, то 2
- Если НЕ красный и зеленый, то 3
- Если НЕ красный и НЕ зеленый, то 4

строим таблицу:

| | Тест1 | Тест2 |
Тест3 | Тест4 |
| ------------------------------------------------------------ | ----- | ----- |
----- | ----- |
| Условия (то, какая комбинация произошла, почему авторизация прошла или нет) |
| | | |
| Красный (номер состоит только из цифр) | Да | Да |
Нет | Нет |
| Зеленый (всего 11 чисел) | Да | Нет |
да | Нет |
| Действие(что сделать нужно) | | |
| |
| Итог (авторизовалась или нет, например) | 1 | 2 |
3 | 4 |

- Состояний и переходов

Вода в нескольких состояниях:

- пар - нагреть до определенной темп

- жидкость - ничего не делать
- Лед - охладить до определенной темп

самая базовая и основная проверка

- Попарное тестирование

Смысл: сделать как можно меьнше проверок, но чтобы они были достаточны для
качественного проекта. По правилу Паретта 80:20 (80%качества достичь при 20
комбинациях данных) 98%деффектов возникали при конфликте пар или одного входного
параметра

- email (поле 1)
- gender (поле 2)
- Чек-бокс (поле 3)

| поле 1 | поле 2 | поле 3 |

| ------ | ------ | ------ |
| **0** | **0** | 0 |
| **0** | **1** | 0 |
| **1** | **0** | 1 |
| **1** | **1** | 1 |

снала комбинируем поле 1 и поле 2, а затем к полю 2 добавляем поле 3

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

Двумерная таблица, содержащая соответствие функциональных требований (functional

requirements) продукта и подготовленных тестовых сценариев (test cases).

Чтобы построить эту таблицу, нужно:

1. Декомпозиция требований
2. Разработка тест-кейсов и чек-листов
3. Заполнение матрицы
4. Поддержка матрицы

| Требования/тест-кейсы | Test.1 | Test.2 | Test.3 |

| --------------------- | ------ | ------ | ------ |
| req.1 | | | X |
| req.2 | | X | |
| req.3 | | X | |
| req.4 | X | | |

Нужно составить тест-кейсы по вариантам:

Доступные устройства: HuaweiAndroid 11, Google Pixel 2 Android 10, Samsung Android
11, Google Pixel 3 Android 10, Xiaomi Mi 8 Lite Android 8, Windows 10, Windows 7,
macOS 11.0, macOS 10.13, Ubuntu 18.04, Ubuntu 20.04

1. В чате есть две кнопки для записи голосового сообщения. Было ограничение на
запись голосового сообщения 5 минут. Ограничение убрали

Эквивалентное разбиение:

красное - 0 минут - 5 минут

Зеленое - 0 - 5

Красноте 3 минуты

Граничные значения: 0:01, 4:59, 5:00, 5:01

Таблица принятия решений

К1 нажимается - 1

к1 не нажимается - 2

К2 нажимается - 3

К2 не нажимается - 4

Если на К1Ограничение убрали, на К2 убрали - 5

Если на К1Ограничение не убрали, на К2 убрали - 6

Если на К1Ограничение убрали, на не К2 убрали - 7

 Если на К1Ограничение не убрали, на К2 не брали - 8

Попарное тестирование:

Условие: две кнопки (на виду и скрыта)

значит берем К1 и записываем голосовое меньше 5 минут

а К2 и записываем голосовое больше 5 минут

длина голосового огрнаичение 5 минут убрали

состояний и переходов:

нажать на кнопку - Записывается, записано,нажать на кнопку - отправлено,

доставлено

матрица составления требований

2. Изменили критерии к никнеймам.Было:только латинские буквы. Стало: латинские

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

классы эквивалентности:

примеры всякие test1 - ok

2test3 = ok

_test = no

граничные значение:

принятие решений:

начинется. с латинской буквы(позитивный)

начинается с символа(позитивный)

начинается с цифры

Содержи лат буквы

Содержит .

содержит -

содержит недопустимые символы

1. В трёх сообщениях можно отправить максимум 10к символов. При этом слово не может
разбиваться посередине

классы эквивалентонсти
 диапазон от 1 до 10к + (отправка трех сообщений с общим количеством символов 10
к)

0 (лотправка пустого сообщения)-

больше 10к - (превышение пустого сообщение)

разбиение слова посередине -

граничные значения:

0 1 2 9.999 10.000 10.001

сценарии исползвоания

3 сообщения отправляются при количестве

2. На окне регистрации есть три поля:Имя,Фамилия, Пароль и кнопка

«Зарегистрироваться». Есть обработка ошибок. Поля могут принимать латинские,
русский буквы и цифры

3. Есть окно логина по номеру телефона и кнопка Войти. Принимаеттолько российские

номера (те, что начинаются +7)

4. Добавили две настройки: скрывать текст сообщений и скрывать автора сообщений.

Нельзя включить скрытие автора сообщений без скрытия текста сообщений. При
отключении скрытия автора сообщений

5. Была возможность переслать сообщение в один чат. Сделали возможность переслать

сообщение в несколько чатов одновременно

6. Добавили две формы поиска: по чату и по всем чатам одновременно. Поиск принимает
латинские буквы, цифры, символы (точка, дефис). В поиск можно вбивать символы
одновременно (и искать одновременно)