Това, което ви предлагам е следното…да си структурите по следният начин цялата информация за общите сведения за тест плана:
Цел на документа
Тук опишете какво се цели със създаването на тест плана – провеждането на тестове с цел осигуряване на качествто на продукта, информация за всички видове тестове прилагани върху системата.
Включете информация за това на какви документи се базира създаването на този тест план. Обикновенно това е функционална спецификация, use cases и/или бизнес анализ.
Обхват на документа
Поместете информация за обхвата на тест плана, какво ще се тества и с какво.
Основни насоки при процеса на тестване
Информация за основните насоки. Оптимален брой тестове, за да се потвърди качеството на продукта и да се отстранят максимално всички бъгове или дефекти.
Наблегнете на кой ключови функционалности ще се обърне повече внимание.
Ресурси
Тук включете два подраздела. В единия отбележете човешките ресурси, заети в разработването на проекта – членовете на екипа от бизнес анализаторите, през програмистите и накрая да не забравите себе си, като QA.
В другата част включете информация за системните изисквания. Можете да си направите по една табличка за консигурацията на сървъра, където е разположено приложение и една за конфигурацията на машината, от която се провеждат тестове.
Тя би изглеждала по следния начин:
Системни ресурси | |
Ресурс | Наименование / вид / модел |
Сървър база данни | |
Мрежа | |
Име на сървъра | |
Име на базата данни | |
Тестов компютър | |
Хралище за тест документи | |
Мрежа | |
Име на сървър | |
Клиентски компютър |
Срокове на провеждане на тестове
След като вече сте попълнили информация за обхвата и целта на тест плана, записали сте кои са участниците, идва ред да определите график за провеждане на тестовете.Това нещо не може да го направите, ако предварително не сте го коментирали с ръководител проект. Той ще ви каже какво време имате отделено за тестване. Борете се, борете се то да е максимално – колкото повече време имате, толкова повече свеждате възможността от поява на сериозни бъгове и дефекти в приложението.
За да определите и фиксирате точно определеното ви време за провеждане на тестовете, мога да ви препоръчам да си направите една проста табличка. Тя се състои от три колони:
N
|
Дейност/тестове
|
Начална дата
|
Крайна дата
|
1 | Създаване на тест план | Стартова дата | Крайна дата |
2 | Дизайн на ТС | Стартова дата | Крайна дата |
3 | Създаване на ТС | Стартова дата | Крайна дата |
4 | Изпълнение на ТС | Стартова дата | Крайна дата |
5 | Load тестове | Стартова дата | Крайна дата |
6 | Performance тестове | Стартова дата | Крайна дата |
Таблицата е допишете с всички видове тестове, които смятате да извършвате и прилагате върху даденият софтуер или приложение. Всичко това го праим с единствената цел да си облекчите работата и за да може в началото да
фиксиране и разпределите работата. Никои не е казал, че това са твърдо определени дати. Те могат да варират в зависимост от характеристиката и текущото състояние на проекта ви. Те са просто ориентир във времето.
Документи в тест плана
След като вече сте определили първоначалните срокове, тук е добре опишете с какви документи е свързано създаването на този тест план. Това включва функционална спецификация, доклади и репорти от извършени
тестове и т.н. Ако разполагате със resource сървър (SVN и друго) поместете и пълен адрес къде могат да се достъпят те. За да си ви по-подредени нещата, може да си направите една проста табличка с няколко реда и колони, където да поместите информацията за тези документи.
N
|
Наименование на документ
|
Местоположение в SVN
|
1 | ||
2 | ||
3 | ||
4 | ||
5 | ||
6 |
what do you think?