После предварительной оценки проекта и рисков по тестированию самое время переходить к написанию тест плана или планов, что советует Rex Black. Вы приступаете к ознакомлению с моими цитатами из 2-й главы. Managing the testing process
1. Нужно создавать несколько отдельных тест планов по тествовым подпроектам, которые отличаются друг от друга:
- по времени ( планируется в другое время)
- используемым методам
- по различным целям (написание тест планов component, integration, system позволяет сфокусироваться только на каждом отдельно и их конкретных целях)
- по различным аудиториям (тк тест план предмет review, то нужно уметь чётко донести свою мысль, чтобы взамен иметь хорошую обратную связь)
2. Когда есть несколько тест планов, то создаётся ещё единый master test plan, что обобщает текущие тест планы со всеми ссылками на них
3. Начальный вариант тест плана всегда полон скобок, в которых написаны вопросы кому-то или вопросы для разбора самому. Определение и запись таких вопросов - однин из самых важных аспектов планирования тестирования.
4. Необходимо иметь критерии для начала, продолжения и окончания тестирования по тест плану. Лучше всего иметь один серьёзный критерий, что действительно серьёзно может повлиять на работу команды в деле тестирования продукта. Его уже никто оспорить не сможет.
5. Когда тестирование только начинается или заканчивается, надо оценить текущую ситуацию согласно выбранному критерию. Если статус критерия жёлтый или красный (зелёный - всё ок), то это необходимо подкрепить соответствующими данными.
6. Успешное прохождение smoke tests один из часто используемых инструментов оценки текущего релиза для тестирования ( entry criteria)
7. При оценке ресурсов для выполнения текущего тест плана необходимо предусмотреть ситуацию, а что, если один из ключевых участников проекта не сможет принять участие в проекте.
8. Необходимо изолировать баги, те работать с системой, пока не найдёшь очевидных, кратких вероятностей и закономерностей возникновения бага.
9. Предпочтительно иметь релиз раз в неделю. Это практика показала себя с самой лучшей стороны на многочисленный проектах.
10. Релиз должен выходить в стандартном формате со стандартной процедурой установки. Тестирование установки (installation testing) - ключевой аспект тестирования любой программы. Также важно не забывать и об обратном, удаление программы.
11. Для каждой из активностей по тестированию, ролям, ответственности проводятся дополнительные совещания. Все эти моменты должны быть включены в тест план.
12. Лучший подход для "продажи" тест плана - это провести митинг со всеми менеджерами. Без подобного митинга можно просто остаться без обратной связи по тест плану. Личная же встреча заставляет хотя бы ознакомится с документом.
13. После ревью-митинга надо иметь тест план с большим количеством пометок и замечаний. Это будет означать, что final version не за горами.
14. Не пиши в документе, что что-то должно быть сделано. Вместо этого чётко формулируй КТО ЧТО и КОГДА. Распределение ролей и обязанностей позволит чётко расставить акценты в проекте и избежать проьлемы с ответсвенностью за ту или иную задачу.
