Тестовая документация: что выбрать?
С требованиями разобрались - это то, на что QA ориентируется как на ожидаемое поведение программы.
Но их сами тоже нужно тестировать: искать несоответствия, несостыковки, непонятные формулировки и стремиться к единообразию.
Лучше заранее заложиться на то, чтобы оценивать ваше тестовое покрытие: например, сделать табличку, где будут крупные фичи в порядке приоритета, все виды нужных документов с требованиями и процент покрытия каждого из них тестами. Так будет легче понимать, сколько ещё предстоит работы по написанию тестов.
Виды и уровни тестирования на этом этапе не важны - функциональное ли, автоматизированное, интеграционное или разные виды перформанса. Подобрать их - отдельная задачка.
Но что за документы вам будут нужны? Здесь много специфики, но базу я вижу вот так
Бирюзовым обозначены документы и подходы, которые у вас будут наверняка, жёлтым - по выбору, серым - те, которых не будет.
Почему так? Чем больше продукт разрастается, тем больше растут потребности в покрытии. Всё сложнее удержать в голове всё, что нужно проверить. И тем ниже скорость изменений и влияние каждого отдельного изменения на результат. При высокой скорости изменений вам вообще практически не нужна документация - нет смысла фиксировать то, что изменится через день, слишком много лишней работы. И наоборот - чем скорость ниже, тем дольше состояние приложения держится в том эталоне, соответствие которому вы хотите проверять.
С новыми этапами разработки появляются новые виды тестирования и редкие кейсы, которые нужно перепроверять регулярно, потому что привет, легаси. Более простые и визуально-ориентированные виды документов, вроде майндмапов, уходят на второй план, оставаясь в нише схемок пользовательского пути или карт переходов.
Сравните эти вот два майндмапа, которые я нашла в интернетиках. Впечатляет разница?
Что может повлиять на выбор документов, кроме указанного в табличке? Размер вашего продукта. Для мобильной игры-айдлера или приложения заметок нужно будет меньше тестов, чем для массовой онлайн-игры или большого магазина. Всего лишь из-за разницы в количестве фич. Ещё повлияет специфика сферы: например, в медицине, авиа или банках, скорее всего, будет больше именно тест-кейсов, т.к. точность работы программ в критичности взлетает до небес.
Поясню ещё вот этот отдельный кусок
Всё просто: если у вас в команде в доступе только джуны QA, на ранних этапах они совсем не привлекаются или занимаются изучением проекта и работой в отдельной песочнице. На сам продукт это может в итоге как повлиять, так и нет.
На днях разберём, как писать смоук и регрессионные тесты, а пока почитайте статью Насти Шариковой, тимлида Bооkmate, о пользе чеклистов. У неё, кстати, есть замечательный telegram-канал на тему тестирования, где она рекомендует и пишет интересные материалы, зацените.