Тестироваие - процесс сверки ожидаемого результата и фактического. Это лишь часть того, чем занимается QA инженер.

QA - Quality Assurance - обеспечение качества продукта.

QA инженер - адвокат пользователя и помощник менеджмента в выстраивании процессов на проекте.

Что ещё входит в задачи Ольги:
Она следит, чтобы все фичи были покрыты кейсами.
Отслеживает, чтобы все баги отрабатывались разработчиками.

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

1. Определение бизнес потребности.
2. Предпродажа.
3. Инициация.
4. Проективроание и дизайн - здесь врывается QA.
5. Имплементация
6. Тестирование
7. Внедрение
8. Сопровождение
9. Смерть продукта

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

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

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

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

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

Баг-репорт - подробный отчёт об ошибке. Bug workflow. Там есть шаги и воспроизведение всего процесса, который привёл к ошибке, критичность и приоритетность бага.

Под баги можно написать буквально табличку.

Тестирование есть смысл проводить в пресс-релиз, только после этого можно нести людям.

Что важно при написании документации:

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

Postman - тестирование API (можно протестировать "ручки" без визуального дизайна, условно нужно проверить, что по кнопке выдаётся нужная информация, но самой кнопки пока нет).
Charles - сниффер - инструмент, позволяющий перехватывать, анализировать и можернизировать все запросы, которые через него проходят.
Chrome Web Inspector - инстурмент для тестирования и отладки.