Рекомендация, поучаствую в адвенте!

I want to repeat English for QA! 😁

Только в нельзяграме Адвент!

Вопрос на собеседовании!
Мой ответ:
👇👇👇

Как тестировать документацию?

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

Итак, давайте к делу, как вы многие слышали, что у требований есть свои характеристики:
🔷Полнота
🔷Однозначность
🔷Непротиворечивость
🔷Необходимость
🔷Полезность при эксплуатации
🔷Осуществимость
🔷Тестируемость
🔷Завершённость
🔷Корректность
🔷Недвусмысленность
🔷Проверяемость (тестопригодность)
🔷Модифицируемость
🔷Прослеживаемость (трассируемость)
🔷Понимаемость (понятность, ясность)
🔷Обязательность
🔷Выполнимость
🔷Актуальность
🔷Упорядоченным по важности, стабильности и срочности.
🔷Осуществимость
🔷Атомарность
🔷Логика
🔷Интеграция
🔷Четкость (краткость)
🔷Точность
🔷Независимость

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

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

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

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

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

Трассируемость
В первой компании мы вели матрицу трассировки, она была у нас слишком обьемна, каждое требование должно было покрыто тест-кейсом.

Выше есть еще характеристики: какую характеристику разобрать?
Поделитесь своим опытом как вы проверяете требования?

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

@protestinginfo

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

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

Проводила вебинар про тестовую модель и тестовые прогоны в рамках курса по тестам, добавила немного фрагментов, просмотреть только тут https://news.1rj.ru/str/info_course_protestinginfo

Напоминаю, в понедельник закрываю продажи.
Следующий поток через 1,5 месяца.

Когда я в субботу немного поработала 🤣

Важно для ознакомления!

Docker для тестировщиков

Добрый день. Написала дополнение к данной статье, изменилась документация по api и сам описанный сайт в статье.
Добавила новые тест-кейсы.
Для улучшения указала примеры коллекций запросов в Postman и Insomnia.

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

ПРОСМОТРЕТЬ