Дефектен жизнен цикъл - Както може би вече сте наясно, че изпълнението на теста е фазата, в която тестерът всъщност ще изпълнява тестовите скриптове. Процесът на изпълнение на тестови скриптове варира от компания до компания и може да е различен в различните проекти в рамките на една и съща компания.
Сега вече има на разположение инструменти за изпълнение на тестове, инструменти като - Център за качество, визуално студио на Microsoft и т.н. Реалният процес на изпълнение на всяка стъпка за сравнение на действителния и очаквания резултат остава същият за функционалния тестер, независимо от използваните инструменти.
- Какво става, ако действителното поведение не е равно на очакваното поведение?
Когато тестер установи, че действителният резултат от изпитването не е равен на очаквания резултат, се регистрира дефект.
- Как да регистрирам дефект?
Днес на разположение са много инструменти, някои от инструментите за регистриране на дефекти са ClearQuest от IBM, Център за качество на HP, инструменти с отворен код като жизнения цикъл на дефектите в JIRA и т.н.
Има някои от задължителните полета, които са често срещани в различните инструменти за регистриране на дефекти, тези полета са -
- Жизнен цикъл на дефекта Описание
- Резюме на жизнения цикъл на дефекта
- Дефект, регистриран от
- Дефект, назначен за
- Дефектна тежест
- Приоритет на дефекта
- Допълнителни снимки
- Номер / име
Дефектния жизнен цикъл
Дефектният жизнен цикъл започва от регистрирането на нов дефект. Всеки път, когато се регистрира дефект, той преминава в състояние „Ново“.
Тестер - нов дефект
На кого да зададете нов дефект?
Тестерът може да присвои дефект на програмист или разработчик. Това решение за възлагане на дефект варира от проект до проект. На някои работни места има процес на жизнения цикъл на дефектите, за да го присвоите директно на съответния разработчик, а на някои места дефектът първо се присвоява на проводник на разработчиците, а отвеждащият от своя страна го възлага на програмист.
Задача за дефект (ново) - Разработчик на жизнения цикъл на дефекта
Задание за дефект (ново) - Dev Leadà Developer
Анализ на дефекти
Програмистът ще анализира дефекта, за да провери дали е възпроизводим. Тук най-важният принос от тестера е да се включат всички необходими детайли в дефекта. Обобщение на дефекта, подробното описание на дефекта са полетата, които помагат на заинтересованите страни да разберат дефекта в един момент. Обобщението за дефектите винаги трябва да съдържа само информация за високо ниво на дефекта. В същото време тя трябва да има достатъчно информация, за да опише прегледа на дефекта в един ред.
Описанието на дефекта е мястото, където се очаква тестерът да включва цялата необходима информация като среда, сценарий, използвани тестови данни, очакван резултат, действителен резултат, препратка към файлове / данни и препратка към моментна снимка.
Ето краткия преглед на различните елементи на дефектното подробно описание -
Заобикаляща среда
Тестова среда, където е открит дефектът. Често проектите имат множество тестови среди, където тестовият екип извършва тестване. Например - AT (среда за тестване на сглобяване), PT (среда за тестване на продукта), UAT (среда за тестване на приемане от потребителя) и така нататък. Целта на наличието на различни среди е, че тя осигурява гъвкавост в екипа за разработка и тестване, за да може кодът да бъде разгърнат във всяка от наличната среда, за да започне тестването навреме.
Има моменти, в които тестът на продукта (наричан още като тест на системата) и UAT тестване се припокрива, следователно наличието на множество среди е задължително да продължите паралелно тестване.
Има случаи, когато екипът за разработка се нуждае от допълнителна среда за отстраняване на грешки в проблемите, докладвани от тестващия екип. Също така екипът за разработка има специална среда за задача за тестване на единица.
Следователно с множество среди, трябва да се спомене в дефекта определена среда, в която е открит проблемът.
Сценарий
Сценарий е набор от стъпки, извършени от тестера, които доведоха до дефект. Тук се очаква тестер да спомене всички стъпки, които програмистът може да извърши, за да възпроизведе дефекта. Често има случаи, когато дефектът се съобщава от тестера, но разработчикът не е в състояние да копира същото и по този начин дефектът се отхвърля. Това може да се случи поради неправилни стъпки / липсващи стъпки, споменати в описанието. Ясните стъпки помагат на всеки да разбере дефекта и да го възпроизведе, без да има зависимост да стигне до тестер, за да получи информация. Добре документиран сценарий е лесен за четене, лесен за разбиране и точни стъпки, които трябва да се следват, за да се възпроизведе дефектът.
Данни от теста
Предполага се, че тестер ще споменава данните, използвани по време на теста, което доведе до проблем. Тази информация дава възможност на програмиста да използва подобни данни, за да възпроизведе дефекта и да намери първопричината за същото.
Има някои сценарии, при които тестер открива дефект, използвайки конкретни данни, но същият проблем не може да се възпроизведе при използване на подобен тип данни. Това може да се случи поради корупция на данните, поради което въвеждането на данни дава шанс да разберете първопричината за дефекта. Програмистът може да не изкопае до ниво код, ако случаят е с корупция на данни. Този вид дефект може да бъде преобразуван в дефект на данни.
Очакван и действителен резултат
Това е акцентът в полето за подробно описание, където тестер доказва, че възникналата грешка наистина е дефект. Ясното споменаване на очаквания резултат прави нещата ясни за всеки притежател на акции да счита грешката като дефект. Представете си, че дефект се записва с всички подробности, но не уточнява очаквания резултат от сценария!
Обикновено тестерът въвежда само очаквания резултат, може да е в ред или два, но е много важно да се спомене източникът на очаквания резултат. Източник тук позоваване на документа, където се споменава очаквания резултат. Това може да бъде документ за изискване или препратка към дъската за история.
Позоваване на файлове / данни
Понякога дефектът включва генериране на файл или въвеждане като файл. При този вид сценарии тестерът трябва да предостави информация за файла, който е бил използван и това е причинило проблема в приложението. Тези файлове могат да бъдат прикачени с помощта на инструмента за управление на дефекти или може да бъде предоставена справка за същите. Тези референтни места трябва да са достъпни от всички заинтересовани страни.
Позоваване на моментна снимка
Снимките играят много важна роля, когато искате да им покажете точното съобщение за грешка при прекъсване на страницата, както е показано на екрана, или когато искате да покажете подробности за навигацията на екрана. Снимката дава бърза представа за възникналия дефект, екрана, на който е открит дефект, използваните данни на екрана и т.н. Всеки инструмент за управление на дефекти има възможност за прикачване на снимките. Понякога тестер може да прикачи и таблиците на Excel или текстови документи.
Това бяха различните компоненти на регистрирането на дефекти и най-добрите практики за всеки от тях. Връщайки се към жизнения цикъл на дефектите, след като дефектът бъде възложен на програмист, той / тя ще го анализира, използвайки данните, предоставени в елемент на дефекта. Ако според анализа, регистрираният проблем наистина е дефект, разработчикът ще „отвори“ дефекта, за да работи по неговото отстраняване.
Препоръчителни курсове
- Уеб услуги в пакет за обучение на Java
- Обучение за разработване на игри в C ++
- Пълно обучение за етично хакерство
- Вегас Про 13 курсове за обучение
Ново - отворено
Дефект в отворения статус показва, че той е в табелата за разработка и разработчиците работят върху неговото поправяне. Ако анализът установи, че регистрираният проблем не е дефект, това може да се случи, когато има разминаване в разбирането в очакваното поведение на системата. Ако анализът каже, че дефектът е невалиден, разработчикът ще отхвърли дефекта. Терминологията е „Отхвърлена“ или „Връщане към тестване“.
Ново - Върнете се към тестване.
Как тестер трябва да валидира, ако дефектът наистина е невалиден дефект?
Това е сценарият, при който прецизен документ с изискване помага на всички в екипа да стигнат до заключението, ако регистрираният дефект е невалиден или валиден. Позоваването на документи за изискване на труда помага както на тестера, така и на разработчика да стигнат до същото заключение и това наистина облекчава процеса на дискусия.
Има сценарии, при които се поставя под въпрос коректността на документите за проектиране и изискване, докато се препращат тези документи в периоди на дискусии за дефекти, като в такива моменти връщането към Business Analyst се счита за най-добрият вариант за изясняване на заявките.
Като най-добра практика, изискването и документите за проектиране винаги трябва да бъдат актуални, за да се отнасят без неясноти.
В състояние „Отворено“ екипът за разработка работи по поправянето на дефекта, след като дефектът е фиксиран, състоянието се променя на „Готов за внедряване“.
Отворен - готов за внедряване
Разгръщането е процесът, при който промените се качват на сървъра, така че тестващият екип да може да работи върху фиксираната версия на кода. Обикновено всеки проект има отделен екип за внедряване за тази задача.
Така че на високо ниво софтуерен екип се състои основно от тези 3 групи -
- развитие
- Дефектен жизнен цикъл при тестване
- Внедряване (или понякога наричано като екип за изграждане)
След като изграждането е разгърнато и дефектът отново е достъпен за повторно тестване, той се назначава на подходящ тестер за задачата за повторно тестване.
Дефект, назначен за - Тест олово.
Тестово олово - индивидуален тестер.
Назначен дефект - индивидуален тестер.
На някои работни места дефектът първо се присвоява на Test Lead и той / тя от своя страна го присвоява на индивидуален тестер, но на някои места дефектът се назначава директно на тестера, който би го тествал, или на този, който е повдигнал дефекта.
Състоянието тук се променя от „Готов за внедряване“ - Готов за тестване на SIT.
Сега дефектът е в чинията на тестера. Екипът за тестване ще валидира дефекта и има две възможности, или коригирането ще работи правилно, или отново се среща същия проблем. В зависимост от дефекта на резултата може да преминете към следните състояния -
Готово SIT тестване - затворено
Готово SIT тестване - Отворете отново
И в горния сценарий се изисква тестер, за да добави коментарите на извършеното тестване. Това включва споменаването на тестваните сценарии и използваните данни. Ако дефектът се отвори отново, тестерът трябва да предостави точните изпълнени стъпки, което отново доведе до грешката.
Състояние на повторно отваряне е същото като „Ново“ състояние на дефект.
След като дефектът се отвори отново, той ще следва същия цикъл отново.
Предизвикателства на жизнения цикъл
- Решаване на тежестта на дефекта - това е една от често срещаните теми за обсъждане (често се бори) сред тестерите v / s разработчици.
- Дефектът не може да се възпроизведе в системата на разработчика.
- Дефект, повдигнат по сценария, който не се споменава в изисквания и документи за проектиране.
- Дефектът е открит, но същото не може да бъде повдигнато, тъй като появата на сценария в производствената среда не е възможно.
Как трябва да се преодолее тестер над предизвикателствата?
- Тежестта е пряко пропорционална на въздействието, което дефектът причинява на приложението, ако тестерът не може да продължи поради дефекта, той със сигурност е маркиран с най-голяма тежест.
- Ако съществува решение за продължаване на изпитването, то трябва да бъде отбелязано като средна тежест. Освен освен да се вземе предвид въздействието на по-нататъшното тестване на жизнения цикъл на дефектите, може да се реши и тежестта, като се има предвид ситуацията, при която цял модул се проваля, в този случай, въпреки че може да се извърши тестването на друг модул, но тежестта към текущия модул е висока така че дефектът трябва да бъде маркиран с най-голяма тежест.
- Ако дефект не може да се възпроизведе в системата на разработчика, има шансове средата за разработка и тест да не е синхронизирана. Дефект, възпроизводим на системата за тестване, винаги се счита за валиден дефект.
- Има ситуации, когато дефект се регистрира, като се вземе предвид общият бизнес сценарий, но директният сценарий не е посочен в изискванията или документа за проектиране. Винаги се смята за най-добра практика да се вземат предвид действителните бизнес сценарии, а не просто да се следват стъпките на теста. Комуникацията с бизнес анализатори и други заинтересовани страни в продуктите играе важна роля за регистриране на такива дефекти.
- Има сценарии, когато тестер открие пропаст в бизнес логиката по време на фазата на тестване. Намирането на такива пропуски отново се счита за голям плюс за изпитател. Пропуските в дизайна обикновено се обработват чрез подобрения.
- Подобрение - Ако трябва да се промени поведение по време на фазата на тестване на жизнения цикъл на софтуера, се създава подобрение, което може да бъде взето в текущата или следващата версия, като се имат предвид сроковете и честотната лента на екипите за разработка и тестване.
- Има някои сценарии, които тестер може да тества по време на ad-hoc тестване, които всъщност могат да бъдат невалидни сценарии, като се има предвид възможността за тяхното появяване в производството.
Кой е най-добрият приятел на тестера?
Къде трябва да отиде тестер в случай на неяснота? Отговорът зависи от вида на заявката, ако заявката е по отношение на изискванията, препоръчително е първо да се обсъди в екипа, за да се коригира разбирането на системата, може да се консултирате със старши членове. Следваща точка за контакт трябва да бъдат бизнес анализаторите.
Ако заявката е свързана с процеса на тестване, препоръчително е да се свържете с тестовия олово или мениджъра на теста.
Ако запитването се отнася до разбирането на техническите характеристики на приложението, членът на екипа за разработка може да бъде точният човек, на който да отидете.
Тъй като тестването е процес, който изисква цялостно разбиране на системата, комуникацията помага на тестера да получи бърз отговор на запитванията, просто зависи от задаването на правилни въпроси на правилните хора. Избягването от задаване на въпроси в подходящия момент може да доведе до дефект да изтече в производствената среда.
Колко важна е ролята на тестер в корпорацията днес?
Има проекти, при които екипът за тестване е еднакво важен като екипа за разработка и в някои сценарии има повече зависимост от тестовия екип, отколкото от екипа за разработка. По-късният сценарий е рядък, но той съществува на някои работни места. Това се е случвало с течение на времето и може да е за определен период от време, когато екипът за разработка няма много опит в сравнение с тестващия екип. Има хора, които разбират общия поток и функционалността по-добре от повечето от останалите членове на екипа. Такъв индивид може да бъде част от екипа за тестване / разработка. Това е един от факторите, който решава зависимостта от екип / индивид за конкретния проект.
Какъв е пътят на кариерата на изпитател?
На дадено лице може да отнеме известно време, за да разбере цялостния процес на тестване, домейна и други задачи, които той / тя се очаква да работи в ежедневния живот. Въз основа на това разбиране е препоръчително да вземете решение за проучване на други области, които може да заеме тестер. Винаги има възможности за автоматизиране на различни потоци. Създаването на малки комунални услуги също може да помогне на екипа по голям начин. Ако даден тестер е добър в програмирането, това се смята за голям плюс. Това отваря възможности за роли за автоматизация. Тестването на производителността също е една от пътеките за кариера на тестерите. Бизнес анализаторът е друга възможност. Добрите познания в областта на домейна с добри комуникационни умения са задължителните набори от умения, за да бъдете бизнес анализатори. Тестването отваря много възможности за тестерите да работят в различни области, инструменти, процеси и т.н. Просто зависи от човек, който да вземе и да започне да навлиза дълбоко в една от основните области за тестване. Има много сертификати, специфични за различни инструменти за специализиране в една от областите на тестване. Сертифицирането от стандартния доставчик е предимство за увеличаване на кариерата, но самият сертификат не може да ви помогне в дългосрочен план, ако не се комбинира с правилния трудов опит.
Препоръчителни статии
Ето няколко статии, които ще ви помогнат да получите повече подробности относно тестването на софтуера, така че просто преминете през линка.
- 6 най-невероятни въпроси за тестване на интервю за софтуер
- Кариери в тестване на софтуер
- Как да постигнем по-добър растеж в кариерата в работата на софтуерните тестери