Меню

Ръководство за документация за тестване на софтуер (Защо е важно)

software testing documentation guide

Опитайте Нашия Инструмент За Премахване На Проблемите

В кариерата си за тестване на софтуер никога не съм чувал хора да говорят много за документация за тестване на софтуер. Общото мнение за документацията за тестване е, че всеки, който има свободно време, може да направи документацията като тестово дело, план за тестване, доклад за състоянието, доклад за грешки, проектно предложение и т.н.

Дори не наблягах повече на документацията, но мога да кажа, че имам навика да поставя всички данни в черно и бяло и да актуализирам и други за това.

Ръководство за документация за тестване на софтуер (Защо

Какво ще научите:

Моят опит

Просто искам да споделя моя опит с вас:

Бяхме доставили проект (с неизвестен проблем в това) на един от нашите клиенти (ядосан клиент). И те откриха проблема от страна на клиента, което беше много лоша ситуация за нас и както обикновено, цялата вина беше на QA’s.

Въпросът беше нещо по отношение на съвместимостта на един уебсайт. Що се отнася до мен, имах доказателство, че не съм получил такъв документ за изискване, който гласи, че трябва да проверя и съвместимостта на уебсайта. Слава богу, че бях в безопасност.

Това беше урокът за мен, осъзнах важността на документацията и от този ден започнах да работя по документи и създадох тестови документи като план за тестове, тестови случаи, контролен списък за тестване на здравословното състояние, доклад за грешки и много други.

„Мастилото е по-добро от най-добрия спомен“ - китайска поговорка

Тестова документация: Какво е това?

Всички четем различни статии за тестване на технологии и методи, но колко от нас са виждали статии за документация? Без съмнение има малко, това ли е, че документите не са важни? Не, но това е, защото все още не сме осъзнали важността на документите.

Но ако наблюдаваме, тогава фактът е, проектите, които имат всички документи, имат високо ниво на зрялост.

Повечето компании не придават дори малко значение на документацията, колкото отдават на процеса на разработване на софтуер. Ако търсим в мрежата, тогава можем да намерим различни шаблони за това как да създаваме различни видове документи. Но колко от тях наистина се използват от организации или лица?

Факт е, че внимателната документация може да спести време, усилия и пари на организацията.

Докато се подлагате на какъвто и да е тип сертифициране, защо се набляга на документацията, това е просто защото показва важността на клиента и процесите за отделния човек и организацията. Освен ако не можете да изготвите документ, който е удобен за потребителя, независимо колко добър е вашият продукт, никой няма да го приеме.

какво е управление на тестови данни при тестване на софтуер

Моят опит е, че притежаваме един продукт, който има малко объркваща функционалност.

Когато започнах да работя по това, поисках някои помощни документи на мениджъра и получих отговор „Не, ние нямаме никакви документи“. Тогава направих проблем с това, тъй като като QA знаех, никой не може да разбере как да използвайте продукта без документи или обучение. И ако потребителят не е доволен, как ще спечелим пари от този продукт?

„Липсата на документация се превръща в проблем за приемане“ - Wietse Venema

Дори същото нещо е приложимо за ръководствата за потребителя. Вземете пример за Microsoft, те пускат всеки продукт с подходящи документи, дори за Office 2007 имаме такива документи, които са много обяснителни и лесни за разбиране за всеки потребител. Това е една от причините всички техни продукти да са успешни.

В малките компании винаги сме чували „отхвърлянето на проект в предложение или фаза на стартиране“ е просто защото документацията на предложенията няма кратък и изразителен език и показва способността на организацията.

Не че малките компании не могат да изпълняват качествени проекти, но е неспособността им да изразят способността си. (Аз също работя с малка организация от 80 служители и това чух много пъти)

Аз лично смятам, че качеството е единственият отдел, който може да го направи възможен. Ние сме единственият отдел, който може да спори по този въпрос и може да осигури успешно бъдеще на нашите организации.

Нека организираме цялата дискусия в няколко точки от гледна точка на качеството:

- Изяснете целта и методите за качество
- Осигурете яснота относно задачите и последователност на изпълнението
- Осигурете вътрешна координация в работата на клиента
- Осигурете обратна връзка за превантивни действия
- Осигурете обратна връзка за вашия цикъл на планиране
- Създайте обективни доказателства за ефективността на вашата система за управление на качеството

10 съвета, които да ви помогнат да постигнете целта на тестовата документация

Както споменах в по-ранния си пост, като цяло разбирането за документацията за тестване на софтуера е „Това може да бъде направено само от човека, който има свободно време“. Трябва да променим това мислене и тогава само ние можем да използваме мощта на документацията за нашите проекти.

Не че не знаем как да направим документацията правилно. Просто не смятаме, че е важно.

Всеки трябва да има стандартни шаблони за всички видове документация, започвайки от Тестова стратегия, Тестов план, Тестови случаи и Тестови данни до отчета за грешки.

Те трябва просто да следват някои стандарти (CMMI, ISO и др.), Но когато става въпрос за реалното изпълнение, колко от тези документи наистина се използват от нас? Просто трябва да синхронизираме нашия процес по качество със стандартите за документация и друг процес в организацията.

Най-простото нещо за спазване на всякакъв вид документация е да се включи човек в проекта от началната фаза, който разбира динамиката на проекта, областта, целта и технологията. И кой друг по-добър от QA човек за това (разбира се, има технически автори, които да направят това - но като се има предвид общ сценарий на малки компании, където техническите автори не присъстват).

За да постигна тази цел на тестване и документиране, смятам, че трябва да се съсредоточим върху някои точки.

Ето топ 10 съвета, които ще ви помогнат да постигнете целта на тестовата документация:

# 1) QA трябва да участва в първата фаза на проекта, така че QA и документацията да работят ръка за ръка.

# две) Процесът, определен от QA, трябва да следва технически специалисти, което помага да се отстранят повечето дефекти на много начален етап.

# 3) Само създаване и поддържане Шаблони за тестване на софтуер не е достатъчно, принудете хората да ги използват.

# 4) Не само създавайте и оставяйте документа, Актуализирайте, както и когато е необходимо.

# 5) Изискването за промяна е важна фаза на проекта, не забравяйте да ги добавите към списъка.

# 6) Използвайте контрола на версиите за всичко. Това ще ви помогне да управлявате и проследявате документите си лесно.

# 7) Улеснете процеса на отстраняване на дефекти, като документирате всички дефекти. Не забравяйте да включите ясно описание на дефекта, да възпроизведете стъпки, засегнатата област и подробности за автора, докато документирате всеки дефект.

# 8) Опитайте се да документирате какво е необходимо, за да разберете работата си и какво ще трябва да представите на заинтересованите страни, когато е необходимо.

# 9) Използвайте стандартния шаблон за документация. Както всеки шаблон на Excel лист или шаблон на файл на документ и се придържайте към него за всички нужди на вашия документ.

# 10) Споделяйте всички свързани с проекта документи на едно място, достъпно за всеки член на екипа за справка, както и за актуализиране, когато е необходимо.

Не казвам, че прилагайки стъпки, ще получите внезапни резултати. Знам, че тази промяна няма да се случи след ден-два, но поне можем да започнем, така че тези промени да започнат да се случват бавно.

В края на краищата „документацията се нуждае от документация“. Нали?

Има стотици документи, използвани в жизнения цикъл на разработката и тестването на софтуер.

Важни документи за тестване на софтуер

Тук изброявам няколко важни документа за тестване на софтуер, които трябва да използваме / поддържаме редовно:

1) План за тестване
2) Дизайн на теста и Спецификация на тестовия случай
3) Тестова стратегия
4) Обобщени доклади от тестове
5) Седмичен доклад за състоянието
6) Потребителски документи / ръководства
7) Доклад за приемане от потребителя
8) Оценка на риска
9) Тестови дневник
10) Доклади за грешки
единадесет) Тестови данни
12) Тестов анализ

Също така, софтуерните тестери редовно трябва да се позовават на следните документи:
1) Спецификации на софтуерните изисквания
2) Функционални документи

Заключение

Документите за тестване на софтуер винаги играят важна роля във фазата на разработване / тестване на проекта. Затова винаги пазете нещата документирани, когато е възможно. Не разчитайте на вербална комуникация. Бъдете винаги на сигурно място.

Документацията не само ще ви спести, но и ще помогне на организацията в дългосрочен план да спести хиляди долари за обучение и по-важното за отстраняване на проблеми, причинени поради липса на документи за разработка и тестване.

Не документирайте само, за да избягвате да ви сочат с пръст, но навикът да документирате със сигурност ще внесе систематичен подход в процеса на тестване, оставяйки ad hoc тестването зад себе си.

За автора: Тази статия е написана от член на екипа на STH Техасвини. Тя работи като QA мениджър в организация.

Какви други документи поддържате при ежедневните си тестови дейности?

Препоръчително четене

^