Как да напиша QA документация, която всъщност ще работи

Софтуерен продукт е като самолет: той трябва да бъде подложен на техническа проверка преди изстрелването.

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

Има толкова много видове софтуерно тестване - автоматизирано и ръчно, проучвателно и функционално, съвместимост, UI / UX, регресия, модул, API и тестване на производителността. Успех да си увиете главата около всички тях!

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

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

Направете план за изпитване и доклад за напредъка на теста

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

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

Планът на теста ще ви помогне да разберете следното:

  • Какви са критериите за приемане?
  • Какви ресурси са ви необходими? Какви операционни системи, колко копия и с какъв лиценз? Имате ли нужда от технически консултанти?
  • Добре ли са определени вашите роли и отговорности?
  • Какво представляват сроковете за тестване?

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

План за тестване и доклад

Създаване на тестови случаи

След като сте изяснили набора от функции, които трябва да бъдат тествани във вашия план за тестване, трябва да създадете тестов случай за всяка част от вашия софтуер.

Тестовите случаи са доста прости - тази QA документация се състои от 7 раздела: ID, Test Case, Testing Steps, Очакван резултат, Състояние, Действителен резултат и Коментари.

  1. ID е уникален номер, присвоен на вашия тестов случай.
  2. В раздела Тестови случаи посочвате изискванията, които ще тествате, и предоставяте връзка към тях в документа за спецификации.
  3. В раздела Стъпки за тестване изброявате всички действия, необходими за завършване на тест.
  4. В раздела Очакван резултат обобщавате резултата от даден тест, ако е успешен.
  5. В раздела Състояние посочвате дали определена стъпка е преминала или не е тествала.
  6. В раздела Действителен резултат обяснявате резултата от неуспешен тест.
  7. Разделът за коментари не е задължителен, но можете да го добавите, за да оставите някои допълнителни бележки.
Тестов случай

Напишете доклад за дефекти

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

Звучи просто, нали? Да, но само докато започнете да документирате. Тук можете да видите пример за типичен доклад за дефект:

Доклад за дефект

Докладът за дефект се състои от следните раздели: идентификатор, резюме, описание, стъпки за възпроизвеждане, възпроизводимост, сериозност, приоритет, среда и прикачени файлове.

  1. На всеки конкретен софтуерен проблем се присвоява уникален номер - идентификаторът . Той оптимизира навигацията през QA документи и улеснява комуникацията между разработчици, тестери и PM.
  2. В раздела за резюме давате кратък отговор на три прости въпроса: какво се е случило, къде и при какви обстоятелства.
  3. В описание секцията , описали бъг в детайли. Трябва да разкажете за действителните резултати и очакваните. Полезно е да предоставите връзка към вашите софтуерни изисквания.
  4. След това пишете за стъпките за възпроизвеждане (STR) . Това показва на разработчиците как точно да възпроизведат проблема. Не пропускайте стъпка или докладът ви може да се върне при вас.
  5. В раздела за възпроизводимост пояснявате дали грешката се появява всеки път, когато следвате STR. Трябва да използвате числа, за да покажете приблизителни шансове, например 7 пъти от 10.
  6. В раздела за сериозност обяснявате колко вреда може да донесе грешката на проекта. С други думи, той показва технологичната степен на влияние на дефекта върху цялата система. Дори малък проблем може да повлияе зле на цялото приложение.
  7. Приоритетът показва колко е важен даден доклад за дефект. Приоритетът може да бъде обозначен с помощта на букви - „А“ за най-спешното и „Z“ за най-неотложното, цифри - „1“ за най-спешното и „9“ за най-неотложното или просто думи като „високо ”,„ Среден ”или„ нисък ”.
  8. В раздела за околната среда трябва да определите кои операционни системи или версии на браузъра са били засегнати.
  9. И накрая, прикачените файлове включват списък с видеоклипове, екранни снимки или файлове на регистрационните файлове на конзолата, добавени към отчета за дефекти.

Запазете тези полезни съвети за писане на дефекти в ума

  1. Напишете достатъчно и адекватно резюме. Няма значение дали е дълъг или къс. Важното е, че трябва да е ясно.
  2. Погледнете резюмето и описанието. Изглеждат ли почти еднакво? Трябва да сте забравили да очертаете очакваните и действителни резултати в описанието и да добавите връзката към изискванията.
  3. Заснемете проблема с помощта на екранна снимка. Това може да спести на вас и на екипа за разработки много време. Понякога само един поглед към снимката е достатъчен, за да разберете ситуацията.
  4. Преди да докладвате за проблема, опитайте се да го възпроизведете поне 3 пъти, за да сте сигурни, че той съществува.
  5. Съобщете за проблема възможно най-скоро и уведомете мениджъра на проекта или собственика на продукта, ако проблемът е основен.
  6. Проверете за граматически грешки във вашата QA документация, за да не бъдете свалени от граматическата полиция.
  7. Колкото и комично да звучи, уверете се, че проблемът не е функция - прегледайте документацията отново!
  8. Не пропускайте важна информация във Вашите стъпки за възпроизвеждане.

Подайте доклад за дефекти

Докладите за дефекти преминават през жизнен цикъл - от момента, в който докладвате проблем, до момента, в който проблемът е затворен.

Жизнен цикъл на доклад за дефекти

Първата стъпка е да се състави и подаде доклад за дефект. В този момент ръководителят на проекта или технически ръководител решава дали да го възложи на разработчик или да го откаже на основание недостатъчност или недостатъчност.

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

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

За да приключи

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

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

Трябва ли да подобрите качеството на вашия софтуер?

Моята компания KeenEthics предоставя солидни услуги за развитие и осигуряване на качеството. В случай, че имате нужда от прогноза за подобен проект, не се колебайте да се свържете .

Ако харесате статията, трябва да продължите с Какво представлява прототипирането и защо ни е нужно и Минимален жизнеспособен продукт: Между идея и продукт.

PS

Оригиналната статия, публикувана в блога на KeenEthics, можете да намерите тук: Как да напиша QA документация, която ще работи?