И защо имаме нужда от документация тест
Имало едно време ...
Някъде през младостта ми, започнах работа на отдела за тестове на служителите в една и съща фирма. Документацията на тест са съществували под формата на чек-листове в Excel и някои изисквания на страница 1-2 за разработчици, които понякога могат да погледнат и тестери. С течение на времето, компанията е престанал да отделя време да пиша CHL, но документацията за програмисти все още е в повече или по-малко прилична форма. Тъй като компанията е ангажиран в нормалното развитие на софтуер за мобилни устройства, които поддържат съответната документация тест и неговата обща застроена да тестери оказа скъпо. Спецификация е станал рядкост.
Аргументът да спре да пише тест документация и всички спецификации е, че загубата на продукция е по-голяма от печалбата. Спецификация и различни документи не са оправдани, тъй като търсенето високи цени за малки мобилни приложения компания не може. И това, което би могло да бъде контролните списъци за новата функционалност, когато:
- Така се стигна до това в ап поръчка за покупка!
- Временна анкетна събрание е на път! Един час по-късно, е необходимо да се изложи!
- Имаме също критични бъгове фиксирани и сега този "Gizmo" остана в кода.
- Пусни всеки Smoke изведнъж нещо се обърка!
- и така нататък ..
В крайна сметка, аз нямах документация, за да мисля за това, което е и какви части могат да повлияят. Спешната нужда да се извърши пълна проучвателно тестване за половин час! В този случай, че е необходимо да се намери критични бъгове за потребителите. Половин час - това е максималното време, защото проблемите, идентифицирани все още трябва да се определи и тествайте отново. С течение на времето, такова споразумение работникът или започват да имат проблеми:
- Слушай, някой си спомня какво се е случило тук? Някой знае как трябва да работи?
- Не си спомням. Необходимо е да се поиска от разработчиците ...
- Хм ... Мисля, че си спомням, че го направих преди три месеца? Имам 5 приложения! Не помня къде съм писал веднъж ...
... (време навън)
- Не знам. Е, нека да бъде.
- Имам си грешка няма да се повтори. А-ах ... сте ъ-ъ, натиснете бутона, когато излизате. И аз винаги натиснете ...
- Ей, не те помня, като тествахме такъв абонамент? И това е начина, по който трябва да бъде? Изглежда, че тя не трябва да е така ... не си спомням.
И никой да питате. Специалисти, които ще бъдат включени в документацията, не. Тестери често провеждат пълно тестване на заявлението, което отнема много време - в продължение на седмици, а понякога дори месеци. А на въпроса: "Когато сте готови с проверката", последван от отговора: "Критични грешки lezuuuut!" Имаше ясна представа колко време е необходимо за програмата за изпитване. И времето, както знаете - пари. Резултатът е нещо, което започва да живее живота си ...
Как, какво и при какви закони се случва - не е ясно на никого. Специално за нови предприемачи, които минаха по-нататъшно развитие:
Тъй като много компании работят. И не всички получите добри резултати.
Въпреки че по-горе е описано и неточна представа, защото те минаха много години и нещо, перифразирано, но смисълът е един и същ. Има фирми, които все още пишат тест документация и активно го използват. Обикновено това са големи компании, които развиват мащабна многофункционална система. И там са фирми на качеството и наличието на документация, която може да повлияе на живота на хората (например, компанията развива автопилот за самолет). Автопилотът може да се развива през годините, като резултат от един път като я освобождава за обществеността. Това е един много скъп процес. Ако автопилотът е бъги, загубите ще бъдат огромни.
Как да направите така, че продуктът се оказа високо качество и добри продажби? Ние трябва да започнем с документацията.
Под каква форма и това, което се нуждае от тест документация?
Има различни видове документи, използвани по време на изпитването. Всеки един от тях играе роля в постигането на една обща цел - създаването на един успешен продукт. Следващият разгледаме най-често срещаните видове документи и причините за тяхното използване.
Работни документи за проектиране, използвани от тестери
Техническо задание (ТЗ) - дава възможност да предадат същността на субекта на развитие на служителите на компанията. Тя ни помага да разберем каква функционалност е трябвало да разработи продукт (понякога с посочване на използваната технология и методи).
Ако TK е в публичното пространство, персоналът лошо пресичащи се с екипа за развитие ще бъде в състояние да го види. Възможно е, когато тестването се открие някакъв проблем е докладвано от тестера (например, програмата не изпълни целта, за която е била създадена).
Новите служители не трябва да се говори за значението на програмата и методите на неговото прилагане. Вие ще бъдете в състояние бързо да влезе в хода на нещата на всяко лице.
TK помага на служителите да разберат програмата по-добре. Неразбирането разработен продукт води до грешки.
Когато тестването няма да се случи опити да се провери ненужни. На първо място, проверете го подлага на това, което трябва задължително да работят по TK.
TK дава възможност да се разбере същността на продукта, предмет на развитие на персонала, който ще го представлява завършен вариант на изпълнение на обществена аудитория.
CTZ (конкретна спецификация) - създаден на базата на ТК. Обикновено, пълно описание на определена част от развития продукта и VI (случаи на използване се, сценарии за потребителите в развиващите се модели на обекти, разработени в рамките на разработването на обекта, неговата логика и същност).
Той помага на разработчиците да прилагат развит продукт точно така, както е предвидено. Той помага да се разбере логиката и правилата на регистрация.
Тя помага на новите служители разбират най-големите и мащабни проекти, тъй като някои системи се нуждаят от една седмица изучаване. Като взе под ръка CTZ, служителят ще може лесно да намерят необходимата информация веднага да започне тестване. Не е нужно да се включва друг персонал, знания продукт, като по този начин ги отвлича от работата. спестяване Очевидният път!
Това дава възможност да се оцени труда на разработка и тестване преди началото на работа.
Той помага тестери създават CHL и тестовете преди започване на работата и тестването.
CTZ и ТК могат да бъдат показани:
като текст със снимки
като графичен маса модел
под формата на мисловни карти, UML или подобен алгоритъм
Проектна документация, подготвя тестери
CHL (списък) - списък с нещата, за да се провери.
Той помага дати план за завършване в бъдеще и настояще, като в CHL, можете да посочите колко време трябва да се тества и колко са били изразходвани.
Тя пази история тестове минаха. Това няма да е лесно да се помни точно кои тестове са проведени с грешки, и то двойна проверка тях.
CHL с резултатите ясно показват, всеки служител на текущото състояние на разработения продукт. Той помага да се определи степента на готовност.
Той помага да се помни това, което вече е тествана, и това, което не е така.
Той помага да си спомните какво тестове трябва да се правят на първо място, което от друга страна, които в третата и т.н. Това поражда доверие, че определен определено време най-важните тестове ще бъдат проведени и резултатите от него - .. получи.
ние можем да напишете чек-листове:
под формата на таблици (най-добре в Google Таблици)
под формата на мисловни карти (под ръка в XMind)
под формата на проверки в списъка на специално предназначени система (полезен при Sitechco)
като списък в текстов документ, който е запознат.
TC (тест) - е създадена въз основа на CTZ (ако има такива), тест анализатори и тестери.
Защо е необходимо?
Заедно с CHL може да съхранява и показва историята на тестване, какво и как да се тества. Можете да бъдете сигурни, че този или тази функционалност е задължително да е или ще бъде тествана и докосна по време на изпитването.
Той помага да се включите бързо към новите служители. Служителите не са длъжни да се научат седмици, за да подлежи на развитие, това ще бъде достатъчно, за да отворите спаси ТК и да премине през това стъпка по стъпка, както и другият взе опитен професионалист, който преди това е работил в компанията.
Той помага да се види как темата за развитие (софтуер, уеб сайт и др. Н.) трябва да изглежда така. С наличните снимки на екрани на екрани, ако те са, не можете да забравите за това, че "има бутон" трябва да бъде сив, а не червено.
могат да бъдат показани тестови случаи:
под формата на таблица с данни на текст
специална услуга за провеждане на тестови случаи (например, в TestLink).
Протокол за изпитване - писмено или медиен доклад за извършената работа и резултатите от него.
Визуализирайте какво е в резултат на извършената работа се получава.
В исторически план, той записва информация. За да го винаги можете да се върнете и да видим какво е направено и това го имам в края на краищата.
Той уведомява за резултатите от всички онези, които са от значение да се знае за тях. Например, за персонала доклади подкрепа отдел на нова версия на програмата в процес на развитие, както и за най-важните въпроси. Ще имате възможност да се подготвят за поява на оплаквания.
Той помага да се вземе решение за по-нататъшни действия (например, дали да пусне версия на програмата в текущото му състояние).
Примерен доклад в писмена форма:
Как да се определи какъв вид документация е необходима за изпълнение на проекта?
Следните са примери за това кога и какви документи и инструменти могат да бъдат използвани като необходимия минимум.
На проекта до 15 души (проекти с ниска сложност) на:
Техническо задание (за предотвратяване на неправилно тълкуване на проблема, като разработчиците, така че документацията не е ..);
контролни листове (лесна за поддръжка, не отнеме много време);
доклади под формата на кратко писмо или се отпишете по специален управление на проекти услуга, с критични бъгове за освобождаването.
На проекта от 15 до 50 души (средно сложност на проекта):
база знания (например страница);
доклади под формата на писмо с прикачен CHL пътували с критични бъгове.
Big проект - от 50 души и повече (висока сложност проекти):
частни Техническо задание;
база знания (например страница);
отчети, приети под формата на една компания (обикновено под формата на писмо с подробен график и прикачените файлове);
Друго (зависи от вида, целите и нуждите на фирмата).
С този трансфер - служители да решат за себе си, така че те ще бъдат да се развива и да бъде в състояние да се разбере от какво имат нужда ... Всичко това - само груба идея и препоръки.
Какво става, ако документация писане се отнема много време?
Но се получи отрицателен резултат - резултат също! Трябва да можете да го използвате и да го вземе предвид в бъдещите си експерименти, докато се постигне приемлив резултат. Splendid вас и постигане на напредък в документацията писане!