#пособие
Модели жизненного цикла и технология проектирования программного обеспечения

1. Структурный анализ
1.1. Декомпозиция процессов
1.2. Модели и стадии жизненного цикла
2. Процессы жизненного цикла
2.1. Основные определения
2.2. Критерии для процессов
2.3. Описание процессов
2.4. Категории процессов жизненного цикла
3. Модели жизненного цикла
3.1. Каскадная модель ЖЦ
3.2. Спиральная модель ЖЦ
4. Технологии проектирования ПО
4.1. Rational Unified Process RUP (IBM)
4.2. Custom Development Method CDM (Oracle)
4.3. Microsoft Solution Framework MSF (MicroSoft)
4.4. Extreme Programming XP

Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Под тест кейсом понимается структура вида: Action > Expected Result > Test Result

Отчет о дефекте (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Написание хороших баг репортов — это самый важный навык тестировщика! Баг — это отклонение фактического результата от ожидаемого результата.
фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла

Тестовое Покрытие (Test Coverage) - это набор тестов для проверки тестируемой функции. Расчет тестового покрытия проводится по формуле: отношение количества строк кода, покрытых тестами, к общему количеству строк кода тестируемой функции, умноженное на 100%.
Существуют три подхода для оценки качества и выражения тестового покрытия в численном представлении в зависимости от области проверки: покрытие требований, покрытие кода и покрытие на базе анализа потока управления.

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

Время Прохождения Тест Кейса (Test Case Pass Time) - это время от начала прохождения шагов тест кейса до получения результата теста.

#Полезныестатьи
Баг и баг репорт

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

Тестовое Покрытие (Test Coverage). Критерии тестового покрытия в Тестировании ПО
#теория

Мифы О Тестировании
#тестирование #тестировщик

🚫Цель тестирования - демонстрация отсутствия ошибок в продукте

🚫Есть код, который нет нужды тестировать

🚫Тестирование – это просто. Все способны тестировать

🚫Тестирование – случайный, не систематизируемый процесс

🚫Тестированию не нужно учиться

🚫Тестирование = отсутствие карьерного роста

🚫Продукт может быть протестирован полностью

🚫Тестирование позволяет найти все дефекты продукта

🚫Все дефекты должны быть исправлены

🚫В пропущенных багах виноваты тестировщики

🚫Тестировщики ответственны за качество продукта

🚫Можно полностью протестировать программу

🚫Единственная задача тестировщика – поиск багов

🚫Кто угодно может тестировать программное обеспечение

🚫Тестирование — это монотонная и скучная работа.

🚫Автоматизированный тест эквивалентен аналогичному
выполненному человеком

🚫Тестирование слишком дорогое

🚫Тестирование занимает много времени

🚫Тестируются только готовые продукты

🚫Машины заменят тестировщиков, и они станут ненужными (Автоматизированное тестирование устраняет необходимость ручного тестирования ).

🚫Провести исчерпывающее тестирование возможно.

🚫Тестировщики не ладят с разработчиками.

🚫Работа тестировщика лишена творчества

🚫Тестирование осуществляется только после завершения стадии разработки.

🚫Тестирование увеличивает стоимость разработки.

ЕЩЕ БОЛЬШЕ МИФОВ о тестировании и тестировщиках
дополнительный материал:

⏳5 мифов о тестировании
⏳Мифы и факты о тестировании программного обеспечения
⏳Мифы о тестировании
⏳7 популярных мифов о тестировании
⏳МИФЫ О ТЕСТИРОВАНИИ / Могу ли я стать тестировщиком?
⏳Тестирование ПО - Мифы
⏳Мифы о тестировщиках 7 мифов о тестировании и тестерах
⏳Мифы о тестировании программного обеспечения
⏳7 мифов о профессии тестировщика

Для себя выделила следующие пункты:
1⃣. Принять ситуацию и не жалуйтесь, начинайте сразу действовать
2⃣. Познакомиться с командой, назначить встречу для передачи знаний
3️⃣. Больше общаться с разработчиком, он уж точно знает информацию, если давно на проекте.
Или
узнать, кто в вашей команде является основным носителем знаний о создаваемом приложении, подготовить список вопросов и обсудить его с этим человеком.
4⃣. Постарайтесь как можно больше узнать про архитектуру и конечный дизайн продукта
5⃣. Не бойтесь задавать вопросы
6⃣. Если в проекте есть руководитель тестирования, то запишите все вопросы, предварительно обсудите их с вашим руководителем и назначьте встречу с другими членами команды
7⃣. Стать реальным пользователем и опираться на свою логику, исследуйте (ad-hoc testing), самостоятельно изучите продукт
8⃣. Опираться на прошлый опыт - на прошлые проекты, если имелись (можно использовать чужой опыт)
9⃣. Обязательно фиксировать изученную информацию в общий доступ, например, в confluence.

#полезныестатьи

Новый функционал без ТЗ

Оценка тестового покрытия на проекте
Оцениваем покрытие требований тестами
🔅Проблема: требования не атомарны.
🔅Проблема: требований нет вообще.
🔅Проблема: требования не трассируемы.
🔅Проблема: требования всё время меняются.
🔅Проблема: не хватает времени документировать тесты.

Тестирование «без» требований: поиск и организация информации

5 Советов: Тест дизайн в условиях отсутствия требований

За долгое время не было тестов. Сегодня в течении дня #тестыдлязакреплениязнаний

Повторим😄

Популярные системы управления тестированием на 2020 г

ALM Octane
Test IT
TestRail
Zephyr
Allure EE
TM4J
Qase
PractiTest
Testuff
Azure
MTM TFS
Kualitee

Про каждую систему можно ознакомиться в статье
https://www.software-testing.ru/library/around-testing/management/3457-top-12-best-test-management-systems-2020

🔷🔷🔷🔷🔷
Test Management System - TMS

Пользователь TMS ожидает увидеть следующее:

🔹Удобная установка и поддержка.
🔹Удобный и понятный интерфейс.
🔹Создание и управление проектами.
🔹Создание пользователей и проектных ролей для пользователей.
🔹Удобная интеграция с автоматическими тестами.
🔹Создание тест-плана.
🔹Создание тест-кейса.
🔹Создание чек-листа.
🔹Создание общего шага
🔹Версионирование тест-кейса/чек-листа.
🔹Создание пользовательских атрибутов/конфигураций.
🔹Прогон тест-кейса/чек-листа.
🔹Понятная система отчётности.
🔹Встроенная система баг-трекинга.
🔹Возможность оповещения коллег внутри и вне системы.
🔹Возможность интеграции с другими инструментами.

Потренируемся!!!
Натолкнулась на опросник, но я всё равно буду придумывать свои тесты😄😄😄

https://istqb-training.ru/Training