7 step practical implementation manual testing before production release
В предишната публикация от тази поредица около Ръчно тестване се опитах да хвърля възможно най-много светлина върху основите на Ръчното тестване.
Ако сте го пропуснали, можете да го прочетете тук .
Надявам се, че беше успешен да ви отведе възможно най-близо до отговорите, които търсите.
В такъв случай не бихте ли искали да научите повече за практическото изпълнение на ръчното тестване, как да се запознаете по-добре с него и как всъщност да започнете кариера в него?
Тази статия ще хвърли светлина върху всички тези аспекти.
Да започваме.
Какво ще научите:
- Цикъл на ръчно тестване
- 7 Практически стъпки за ръчно тестване преди пускане в производство
- # 1) Събиране на изисквания
- # 2) Обсъждане / споделяне на изискванията
- # 3) Проектиране
- # 4) Сценарий на теста / Проектиране на тестови казуси
- # 5) Фаза на развитие
- # 6) Фаза на тестване
- # 7) Преглед на бизнес анализатор (BA)
- # 8) Доставка / освобождаване
- Видове ръчни (прочетени човешки) тестове
- Препоръчително четене
Цикъл на ръчно тестване
Да разбере Цикъл на ръчно тестване или жизнен цикъл на софтуерния тест (STLC), на първо място, трябва да разберем жизнения цикъл на разработката на софтуер (SDLC), за който съм сигурен, че вече имате разбиране.
Хората се отнасят към тях отделно, но не са сигурни дали наистина могат да съществуват съвместно. Те са толкова тясно интегрирани един с друг. Е, дори тези цикли имат толкова много версии, създадени и плаващи в интернет пространството, те се различават значително в зависимост от избрания модел на развитие.
Както повечето от светът става пъргав тези дни ще запазя нещата си опростени около Agile.
7 Практически стъпки за ръчно тестване преди пускане в производство
Ето ме.
Не забравяйте, че говоря както за SDLC, така и за STLC.
# 1) Събиране на изисквания
Бизнес анализаторът (лице / екип, отговарящ за събирането на изисквания) документира изискванията. Те документират изискванията, това е най-важното, можете да запазите фокуса само върху това. Където е документирано, има по-малко значение.
Хората използват всичко, за да документират тези, които им подхождат, но не само традиционни платформи като MS word doc, модерни платформи като Jira / Rally и new age инструменти като Trello.
# 2) Обсъждане / споделяне на изискванията
След това бизнес анализаторът трябва да споделя документирани изисквания с екипа за разработка, екипа за тестване и екипа на UX (ако е необходимо). Това обикновено се случва чрез официална среща, на която SPOC (Single Point Of Contacts или цял екип, зависи) от трите функции отговарят и разбират цялото изискване.
В една здравословна работна култура изискванията се обсъждат от всеки ъгъл и всеки член на срещата може да задава въпроси и съмнения. След като се отговори на всички въпроси и се извърши необходимата промяна в изискването, тази фаза може да се счита за завършена. Отново това, което човек нарича тази конкретна среща / стъпка и нейната документация, се различава от компания до компания.
Допълнителна информация=> Как да прегледате SRS документа
След като се отговори на всички въпроси и се направят необходимите промени в изискването, тази фаза може да се счита за Свършен .
Отново това, което човек нарича тази конкретна среща / стъпка и нейната документация, се различава от компания до компания.
Например, документацията се извиква или разбива като SRS (Спецификация на системните изисквания), Документ на изискването, Epic, User Story, Story point (евентуално, най-малката единица на изискване) и др. Изискване Дискусионна среща, Груминг, среща с пробиване на дупки и др., Надявам се да разберете моята точка?
Натискайки тези терминологии, така че винаги да помните основната идея, независимо от различните имена.
Публикувайте тази среща две стъпки се задействат едновременно, без определен ред, вижте следващите две стъпки.
# 3) Проектиране
Екипът за разработка започва с техническото си проектиране веднага щом се обсъдят изискванията и когато няма важни предстоящи точки. Това, което се прави в тази фаза, отново се различава от компания до компания.
Тази фаза може да включва, но не само следните задачи:
- Решаване на подхода за развитие
- Изготвяне на проектния документ
- Проектиране на блок-схеми
- Оценка на усилията
- Разбиране на въздействието на това ново изискване върху съществуващата функционалност
- Необходимо е да се закърпят съществуващите данни и т.н.
Екипът на UX може също да се включи в тази фаза, когато има промяна на потребителския интерфейс или трябва да се разработи нов екран. Екипът на UX помага на екипа за разработка и екипа за тестване с прототип на потребителския интерфейс за функционалността / характеристиката в дискусията. Това може да бъде документ на Photoshop, просто изображение, презентация на PowerPoint или нещо друго, което ще накара екипа за разработка да разбере как трябва да се разработят екраните.
Забележка: В идеалния случай тези екрани или поне техните чернови версии са показани в дискусионната сесия на изискванията само за да помогнат на екипа да изгради по-добро разбиране. Той се маркира към първоначалното изискване, така че да може да бъде посочен по всяко време.
# 4) Сценарий на теста / Проектиране на тестови казуси
Успоредно с фазата на проектиране, екипът за тестване започва с изграждането на тестови сценарии и / или тестови казуси въз основа на обсъдени изисквания. Дали тестовите сценарии винаги се пишат първо и след това да проникнат в тестови случаи е нещо, което отново не е постоянно.
Според мен, независимо дали документирате тестовите сценарии или не, те винаги са налице преди тестовите случаи. Тестовият сценарий е вашата точка, която можете да кажете, те ви насочват да разберете по-нататък. След като писането на тестовия случай приключи, то може да бъде споделено с екипа за разработка, за да им даде представа за обхвата на тестване, а също така те могат да се уверят, че развитието, което се е случило или се случва, отговаря на писмените тестови случаи.
След като писането на тестовия случай приключи, то може да бъде споделено с екипа за разработка, за да им даде представа за обхвата на тестване, а също така те могат да се уверят, че развитието, което се е случило или се случва, отговаря на писмените тестови случаи.
Тестовите случаи, след като са написани в идеалния случай, се преглеждат от тестовия лидер или партньор от много ъгли като:
- Покритие на изискванията
- Правописна граматика
- Стандарти за писане на тестови казуси (нищо друго освен шаблон, който екип / компания следва)
- Обратна съвместимост
- Съвместимост с платформата
- Препратки към данните от теста
- Видове целеви тестове и др.
Допълнителна информация=> Писане на тестови случаи от SRS документ
В идеалния случай, само след преглед и необходима модификация, те се предават на екипа за разработка.
Когато казах „веднъж приключването на изпитването е приключило“, имах предвид веднъж „всички тестови случаи са написани въз основа на пълното познаване на дадено изискване и възможни тестови сценарии, разкрити до този конкретен момент“. Почти невъзможно е да имате 100% покритие на тестовите случаи на първо движение.
Ще има дефекти, които ще откриете при случайни (но предвидени) действия, при чисто произволни действия (тестване на маймуни) и в някои редки сценарии. Има шансове да пропуснете малко от тях. И по някое време може да пропуснете дори много основни, в края на краищата вие сте човек. Но тук поне един добър преглед на тестовия случай и структуриран начин за писане на тестови казуси могат да ви спасят.
По-често тестващият или тестващият екип продължава да добавя все повече тестови случаи към съществуващата част, докато разкриват истината или мислят повече за изискванията.
Е, досега някои от вас сигурно се съмняват в познанията ми за тестване на софтуер, тъй като някаква дума (която някак си стана норма в софтуерното тестване) все още не се използва от мен. План за тестване нали?
Позволете ми да кажа нещо по този въпрос. Силно вярвам в необходимостта от по-голямата част от информацията, която е спомената в тестовия план, но документирането им на едно и също място и превръщането й в абсолютно задължително е нещо, което намирам за спорно.
Както и да е, това е съвсем отделна тема за обсъждане. Трудно е да споделите информация за „отговаря на всички“, но нека да опитам.
Или вие, вие с вашия тестов олово или вашият тестов олово изготвяте план за тестване, или документирате необходимата информация на различни места.
Допълнителна информация=> Как да напиша документ за план за изпитване
Информация, която трябва да бъде напълно замразена на този етап:
- Обхватът на тестване: Изискване, обратна съвместимост, платформи, устройства и др.
- Човек / Екип, който ще тества
- Оценка на усилията за изпитване
- Ограничения: Всички направени предположения или ограничения, приети предварително.
- Хората допълнително документират критерии за влизане, критерии за излизане, риск и т.н., което според мен не се нуждае от отделно споменаване, тъй като по-скоро трябва да бъде нормално разбиране.
- Критерии за влизане (Кога да започне тестването): Малко стартират, когато има тестваема част от функционалността, достъпна за тестване. Малцина чакат цялата функционалност да бъде проверяема. След като се установи, че основният поток работи, тестването започва.
- Критерии за изход (Кога да спре): Когато няма блокер, критичните и големи (подложени на удар) дефекти при тестване на отворен етап могат да бъдат спрени. Или по средата, когато има твърде много дефекти, пред които е изправено тестването, могат да бъдат спрени от подходящи заинтересовани страни.
- Риск : Бизнес риск или функционален риск, ако тестването не се случи съгласно документиран план.
# 5) Фаза на развитие
Екипът на разработчиците след фазата на проектиране започва с действителната разработка и тестването на модулите, както и когато са готови с разработването на проверими парчета изисквания. Те могат да предават функционалността за тестване на парчета, както и когато тя е внедрена, или могат да предават цялата функционалност наведнъж.
В идеален сценарий официалният преглед на кода и тестването на бялото поле се извършват преди предаването на разработената функционалност за тестване. в идеалния случай екипът за разработка трябва да се позове и на тестови случаи, предоставени от екипа за тестване, в допълнение към изискванията и проектните документи.
# 6) Фаза на тестване
Както споменахме по-рано, началото на тази фаза се различава от компания до компания, от екип до екип.
Екипът за тестване започва тестване или когато е разработена част от цялото изискване, когато е проверяема (нещо, което може да бъде тествано независимо), или когато е разработено цялото изискване.
как да стартирате jar файлове на Windows
Позволете ми да разгледам по-нататък в тази фаза и да говоря за важните задачи:
- Екипът за тестване / тестване започва с кръг на тестване (изследователско тестване и изпълнение на писмени тестови случаи) и дефекти в регистрацията
- Екипът за разработка ги разрешава според приоритета.
- Нова компилация (код) е взета за среда, в която се провежда тестване
- След това отстранените дефекти се проверяват от тестващия / тестващия екип и се маркират като поправени
- Този цикъл продължава до достигане на критериите за излизане от времето.
- Моля, обърнете внимание, че при необходимост дефектите също са маркирани като Невалидни, Дублирани и могат да бъдат категоризирани като Подобрения.
Друго нещо, което се различава от компания до компания, е колко тестове да бъдат направени. Както в някои случаи, първият кръг на тестване се извършва на малки части на елемента, когато са готови, последван от кръг на тестване от друга до друга среда, след като всички изисквания бъдат разработени. Но отново, чувал съм и за хора, които са правили три правилни пълни тестови кръга и четвърти като здравословен / димен кръг.
Първата програма, която стои зад извършването на множество кръгове за тестване, е тестване на функционалността в различни среди и втора за извършване на тестване от край до край, след като всички точки от историята са разработени. Обикновено кръгът на здравия разум придобива бърза увереност, след като всички истории в дадена версия са разработени и тествани независимо.
Прочетете подробни стъпки=> Тест Изпълнение фаза
# 7) Преглед на бизнес анализатор (BA)
Бизнес анализаторът прави преглед на зададената функционалност или като се позовава на резултата от теста, или като се позовава на резултата от теста, плюс да си поиграе с приложението, за да получи истинско усещане. Тази стъпка отново е подложена на различни действия в различните компании.
BA може да прегледа обхвата на цялото издание едновременно или на парчета. В зависимост от същото, тази стъпка може да дойде преди окончателното тестване за здравословно състояние или след последния кръг за тестване на здравословното състояние от екипа за тестване.
Над 7 стъпки се случват за всички потребителски истории / изисквания, които трябва да бъдат изпълнени, по-специално Освобождаване (пратка). След като всички тези стъпки са изпълнени за всички изисквания, се казва, че изданието е готово за изпращане.
# 8) Доставка / освобождаване
Изданието е маркирано като Готово за изпращане след успешен преглед от бизнес анализатора.
Препоръчително четиво=> Процес на тестово освобождаване
Видове ръчни (прочетени човешки) тестове
Е, ако трябва да говорим за общи видове тестване в цифри, тогава някъде намерих повече 100 вида тестване с различни имена . За да бъда честен, аз не съм достатъчно умен, за да разбера разликата между всички тези типове (предназначен за игра на думи).
Той е прав и прост: Тестване на функционалността на приложението спрямо даденото изискване с човешки усилия и интелигентност. Той се разделя допълнително на няколко типа въз основа на обхвата и програмата на тестване. Видове, изброени в следващия параграф.
Той се разделя допълнително на няколко типа въз основа на обхвата и програмата на тестване. Видове, изброени в следващия параграф.
Ако ми е позволено, позволете ми да изкажа няколко реда на тестване на хора (което насърчавам всеки тестер да прави само с ръчно функционално тестване). Сега не се бъркайте, според мен ръчното функционално тестване е подмножество на човешкото тестване. Защото има толкова много неща, които само човешкият ум може да направи.
По-долу е списъкът с някои от популярните и важни видове тестване, които могат да бъдат категоризирани в тестване на хора:
- Ръчно функционално тестване : Тестване на функционалността на приложението спрямо даденото изискване с човешки усилия и интелигентност. Освен това се разделя на няколко вида въз основа на обхвата и програмата на тестване, като системно тестване, модулно тестване, димно тестване, тестване на здравословното състояние, тестване на интеграция, регресионно тестване, тестване на потребителския интерфейс и т.н.
- Тестване на производителността : Това се категоризира в Нефункционално тестване, нали? Но отново човекът го изпълнява, макар че изпълнението се извършва или от човек, или от инструмент. Изпитателят трябва да направи това тестване поне по отношение на времето за реакция (за да види дали е приемливо), ако не трябва да използва никакъв инструмент за тестване на натоварване и всичко останало.
- Браузър / Тестване на съвместимост с платформа: Тестваното приложение трябва да изглежда и да работи според очакванията (очевидно може да има малка разлика в зависимост от двигателя на браузъра) в браузърите и платформите (или устройствата, ако е мобилно приложение).
- Тестване на използваемостта : Нека първо се съглася, че това е огромна тема сама по себе си и обикновено се притежава от специалисти по тестване на използваемостта. Все още вярвам, че като тестер трябва поне да докладваме или да подчертаваме, ако открием нещо като по-малко използваемо, или да споделяме нашето виждане.
- Тестване на сигурността : Отново много огромен тип тестване и изисква много практически знания, разбира се. Тестерът трябва да се опита да научи и изпълни поне основни тестове като фалшифициране на URL адреси, скриптове между сайтове, SQL инжекция, отвличане на сесии и др. В зависимост от наличните знания и където е приложимо.
- Тестване на няколко наема: Ако вашето приложение е с много клиенти, т.е. един екземпляр, съдържащ данни на множество клиенти, това тестване е задължително. Независимо от изричното споменаване в изискванията, това трябва да се направи. Данните на един клиент, които се показват на друг, са вид престъпление за разработване и тестване.
Забележка: Горните възгледи са моите лични възгледи. Също така ви препоръчвам да разгледате обширния списък от видове тестове за вашите знания и да ги следвате / използвате, ако сметнете за необходимо. От години разбрах, че независимо дали използвате нещо или нито, вярвате ли в нещо или не, все пак трябва да имате известни познания за широко използваните концепции във вашата област.
Това е всичко за тази част. Благодаря ви, че четете. Споделяйте вашите мнения / отзиви в коментари.
В следващата и последната част на това поредица от ръководства за ръчно тестване , Ще се опитам да ви помогна на всички каква подготовка трябва да правите, ако искате да влезете в полето за тестване и какви са възможните начини да влезете там.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Помощ за ръчно тестване eBook - Безплатно изтегляне отвътре!
- Изтегляне на eBook за тестване на Primer
- Предизвикателства при ръчно тестване и автоматизация
- Тестване на натоварване с уроци за HP LoadRunner
- Вие сте експерт по ръчно тестване или автоматизация? Работете на непълно работно време за нас!
- Практическо тестване на софтуер - Нова БЕЗПЛАТНА електронна книга [Изтегляне]
- Разлика между тестване на настолни компютри, клиентски сървър и уеб тестване