Въведение в работата с тестер на софтуер
Кое е първото нещо, което ви идва наум, когато мислите за работа за тестване на софтуер? Некодираща работа? Или професия, която е много лесна, тъй като ви дава възможности да намерите грешки в работата на други хора (намирането на грешки, когато в други е най-лесната задача за всички нас)? Или мислите за това като професия, която се занимава с проверка на коректността на продукта? Всички тези мисли са верни и са ежедневни дейности за работа на софтуерен тестер. Тестване на софтуер обаче не се ограничава само до тези дейности.
Разбиране на приложението
Приложението може да бъде от всеки домейн - здравеопазване, застраховане, финанси и др. Научаването на домейна на приложението е много важно за всяка софтуерна работа, за да отвори вратите за мислене от различни ъгли и различни потребителски гледни точки, докато тествате приложението. Откриването и утвърждаването на очевидните и не толкова очевидни пътища на приложение винаги е основното очакване от това. Притежаването на задълбочени познания за приложението помага на валидирането на продукта ефективно, в същото време изпитателят може да се превърне в актив на проект, където той / тя се счита за един от основните източници на знания по отношение на поведението на продукта.
Докато изучаването на домейн и функционалност е непрекъснат процес, за всеки друг важен фактор е знанието за процеса на тестване.
Процес на тестване
Процесът на тестване може да варира от тази компания до компания или дори от един проект до друг. Днес имаме различни модели за разработка на софтуер като V модел, модел на прототипиране или напълно различна методология като Agile подхода за разработване на софтуер. С промяната на модела на развитие варира и подходът за тестване, който трябва да се следва. Работата във V модел ще има добре дефинирани процеси, докато тази работа по гъвкава методология се очаква да се тества при постоянно променящи се условия.
Работата все още не е гладка с приемливи познания в областта на домейните и разбиране на процеса на тестване, следващото предизвикателство, което идва в живота на, е изучаването на различни инструменти.
Инструменти
Инструментите предполагат инструменти за управление на тестове, инструменти за дефектиране на журнали, инструменти за управление на база данни и т.н.
С различни софтуер за регистриране на дефекти, той има качества и инструменти, някои отворени източници и някои лицензирани, винаги е предимство да имате познания за повече от един инструмент. Помага му лесно да преминава проекти или екипи, следвайки различни инструменти. С адекватното познаване на домейна, процеса и инструментите има повече за живота на софтуера за тестер на софтуера, което прави работните му дни предизвикателни и вълнуващи. Сътрудничеството в екипи е един от важните фактори за успеха на всеки проект, а за ефективното сътрудничество комуникацията играе много важна роля.
Препоръчителни курсове
- Пълен J2EE комплексен курс
- Онлайн обучение по R програмиране
- Отидете на курс по програмиране
- Обучение за онлайн сертифициране по програма Haskell
общуване
Комуникацията играе много важна роля за нейните качества на софтуера, тъй като от началните фази на разработването на софтуера членовете на екипа за тестване участват (като най-добра практика) в обсъждането на изискванията, разпитват бизнес анализатори в случай на някакви запитвания или пропуски в изискването. Тестерът с ефективни комуникационни умения може да комуникира ефективно рисковете, може да комуникира ефективно с екипа за разработка и може ефективно да комуникира резултатите от тестовете и докладите за тестване.
Планиране на софтуерни тестер работи
Както подсказва името, планирането на теста е фазата, в която се извършва подготовката за тестване. Подготовката за тестер ще включва различни видове дейности, които тестер извършва с цел ефективно приложение. Това ще помогне за валидиране на приложението и ефективно разкриване на дефектите в приложението. За да започне планирането, тест преминава през изискванията, за да разбере очакванията.
1. Изисквания
Изискванията могат да бъдат зададени на екипа за тестване под формата на телени рамки, дъски с разкази, екшън листове. Целта на всички тези документи е да се представят изискванията на клиента по ефективен и лесен за разбиране начин. Документът с рамка не е нищо друго освен документ, който може да бъде под формата на презентация на PowerPoint, който изобразява изискванията на клиента. На същите линии, разказвачите обикновено изобразяват необходимия вид / дизайн на екраните. Днес на пазара се предлагат различни инструменти, които могат да се използват за подготовка на необходимите документи. Създаването на необходимите документи е основната отговорност на бизнес анализатора. Очаква се дегустация, която да разбере добре изискванията. За да могат тестът, както и разработчиците да разберат правилно изискванията, бизнес анализаторите поддържат форума отворен за всички, за да повдигнат и да получат отговори на запитвания по всяко едно от изискванията. Платформата за обсъждане и комуникация на отворените въпроси и запитвания варира от проект до проект. Това може да бъде веригата от имейли или конферентен разговор или дори хранилище за споделено устройство, поддържано, за да се следят всички открити въпроси и техните отговори, предоставени от бизнес анализатора.
Ясна комуникация и запис на комуникация играят много важна роля за доказателство. Малко предположение за изискването понякога може да доведе до голям дефект в продукта. На всеки етап се препоръчва качествата на софтуерен тестер, за да се поддържа комуникацията чиста. Софтуерът за тестер на работа Работна комуникация може да бъде с бизнес анализатори или дори в екип. Ясната комуникация помага да се избегнат предположенията по време на планирането и изпълнението. В същото време се препоръчва да имате запис на комуникация (за предпочитане комуникация по имейл). Наличието на писмена комуникация на запитвания в изискванията помага в по-късните етапи на тестовото изпълнение, където функционалността може да не е разработена, както е потвърдено в записаната комуникация.
2. Сценарий
След като изискванията са разбрани, тестерът започва да документира сценариите в документа на тестовия сценарий. Сценарий, както подсказва името, е поток от функционалност, който потребителят следва, за да изпълни задача.
Примери за сценарии -
- Потребителят трябва да може да влезе успешно.
- Потребителят трябва да може да резервира билети в системата.
- Потребителят трябва да може да анулира билети в системата.
- Потребителят трябва да може да разглежда / актуализира детайлите на профила.
Това са логическите задачи, които потребителят изпълнява в системата. Тези логически задачи, групирани заедно, помагат да се отбележи всички възможни сценарии, които се очаква да изпълнява потребител. Тези сценарии обикновено се документират в листовете на Excel или понякога се използват някои инструменти. Доказателство процъфтява да извлече всички подобни сценарии от документите за изискване. Документ, съдържащ такива сценарии, се нарича Test Test Scenario Document (или някъде като документ за сценарий на високо ниво). Този документ служи като входен документ за изготвяне на тестови случаи.
3. Дело
Този случай е по-подробната версия на работния сценарий на софтуерния тестер, където сценарият е разбит на по-подробни стъпки, които потребителят действително ще извърши, докато използва приложението. Един прост пример, базиран на горепосочените сценарии, е:
Сценарий - Потребителят трябва да може да влезе успешно.
Тестови случаи:
- Проверете дали потребителят може да въведе правилното потребителско име.
- Проверете дали потребителят може да въведе паролата.
- Проверете при натискане на бутона за влизане след въвеждане на правилно потребителско име и парола, потребителят може да влезе успешно.
Такъв списък от тези случаи може да продължи да включва проверка за валидиране на всяко поле, проверка на отрицателни сценарии и т.н.
По-долу са някои от допълнителните примери за тези случаи -
- Проверете дали потребителското име, когато не е въведено, системата хвърля подходяща грешка.
- Проверете дали паролата не е въведена, системата хвърля подходяща грешка.
- Проверете дали потребителското име и паролата, когато не са въведени, системата хвърля подходяща грешка.
- Проверете дали системата въвежда неправилна парола и системата изпраща подходящо съобщение за грешка.
- Проверете, че при въвеждане на неправилно потребителско име системата изпраща подходящо съобщение за грешка.
4. Матрица за проследяване на изискванията (RTM)
Матрицата за проследяване на изискванията, както подсказва името, помага да се докаже проверката и включването на покритието на изискванията, предоставени от бизнеса в документите за тестване, като сценарии и тестови случаи.
Като най-добра практика това е отделен документ, показващ съпоставянето на номера на изискването с този на сценарии / случаи, включващи това изискване.
Този документ може да не се използва от всички видове проекти, но когато се използва, той помага по силния начин да се проследят сценариите на високо ниво, съпоставящи се с изискванията. Той показва покритието и може да се използва за проверка на наличието на поне един такъв случай срещу всяко изискване. Създаването и поддържането на RTM документа се счита за най-добрата практика, но не всички видове проекти (като Agile) използват софтуер, доказващ Работен документ. Когато изискванията се променят много често, поддържането на този документ може да бъде подслушано. За да се избегне това главно и в същото време да се намери начин за проследяване на изискванията, някои проекти включват частта за проследяване в работния случай на софтуерния тестер или в самия негов сценарий.
Важният аспект е да има начин да се проследят сценариите / случаите към изискванията и обратно. Добре документираните изисквания правят задачата за Prover по-лесно да създава и поддържа тези документи. Нееднозначните изисквания, непрекъснато променящите се изисквания правят живота на доказателство по-труден и може да доведе до непоследователни документи, които могат да бъдат доставени, което води до пропускане на някаква проверка и следователно дефект в крайния продукт.
Досега пътуването за тестер планираше и се подготвяше за тестване. Тъй като подготовката за война е част от войната, тук важи същото. Колкото по-сбити са създадени тези документи, по-лесно е доказателствата да валидират функционалността и да разкрият почти всички дефекти. Следващата фаза на пътуването на изпитателя е Изпълнение.
Изпълнението на софтуерния тестер работи
Това е фазата, в която всички горепосочени документи са въведени в употреба. Изискванията бяха използвани за създаване на сценарий, сценарият беше използван за създаването му Случаи. този документ на случая е самодостатъчен документ тук, за да започнете валидиране на приложението. Prover започва да валидира приложението, като изпълнява стъпки от този документ. Множество тези случаи могат да бъдат използвани за валидиране на един сценарий или дори един тестов случай може да съответства на един сценарий за тест. Всичко зависи от сложността на сценариите или понякога от стандарта, следван в тестовия екип. Следователно един тестов документ може да съдържа 20-50 тестови случая или може да има 100-120 тестови случая. Тези цифри са само с цел обяснение, може да варират силно от проект до проект. Резултатът от тази фаза е тестови дефекти. Броят на валидните дефекти, повдигнати в тази фаза, дава добра представа за стабилността на приложението, качеството на тестване, качеството на изграждане и много такива фактори, които пряко влияят върху продукта. Тази фаза е най-важната фаза, тъй като тестерът процъфтява за покриване на всички тестови случаи (валидиране на почти всички необходими потребителски пътеки) и в същото време повдига възможно най-много валидни дефекти. Всички подготовки, комуникационни умения, запитвания, поискани от бизнеса, влизат в тази фаза на тестване.
Дефектите на софтуера тестер работи
Докато изпълнявате този случай, всяко поведение, което не е равно на очаквания резултат, се издига като Дефект. Всеки тестов случай има описание, очакван резултат и колона за действителен резултат. Докато тези документи за планиране на софтуерния тестер за работа имат описание и очаквани резултати и празна колона за действителни резултати. Докато изпълнява тестовите случаи, тестерът трябва да попълни колоната с действителни резултати. В същото време, ако действителното не е равно на очаквания резултат, дефектът се записва. Записването на дефект просто не означава информиране на програмиста за проблема. Това отново е формален процес, който обикновено се извършва с помощта на инструмент. В момента на пазара има различни инструменти, някои с отворен код и някои лицензирани. Всеки инструмент за регистриране на дефекти има следните полета -
- Име на проекта / изданието
- Обобщение на дефекта
- Описание на дефекта
- Дефектна тежест
- Приоритет на дефекта
- Фаза е открит дефектът
- Възлага се на
- Прикачени
Както можем да видим, целта на всички тези полета е да има официален процес, в който да се намерят подробни подробности за проблема. Това помага на разработчиците да възпроизведат дефекта в средата си и да го отстранят. По-долу е краткото описание на всички тези полета -
- Име на проекта / изданието - Име на изданието, където е открит дефектът, обикновено проектът има множество версии и един и същ проект може да има множество подпроекти. Това поле помага да се повдигне проблем за конкретно издание.
- Обобщение на дефекта - Кратко описание на открития дефект с една линия.
- Детайлно описание на дефекта - Това е подробното описание на дефекта, то трябва да включва подробности като среда, в която е открит дефектът, и използваните тестови данни, действителни резултати, очакван резултат и всяка допълнителна информация, която добавя по-ценна информация за заинтересованите страни да разберат дефект.
- Тежест на дефекта - означава колко тежък е дефектът. Обикновено той има стойности, подобни на критични, високи, средни, ниски или числови стойности като 4, 3, 2, 1.
- Приоритет на дефекта - означава колко спешно е да се поправи дефектът.
- Фаза на дефекта е открита - Тъй като има много фази, когато дефектът може да бъде регистриран, фаза на тестване на единица, SIT (тестване на системната интеграция), UAT (тестване на приемане от потребителя) или дори фаза на производство.
- Присвоено на - Име на разработчика или водещия разработчик.
- Приложения - Това дава възможност на тестера да прикачи моментната снимка на екрана, където е възникнал проблемът.
Изпълнението на теста и регистрирането на дефектите е фазата, при която има много предизвикателства, пред които може да се изправи тестер. Някои от тях общуват ефективно с разработчиците. Можем ли да твърдим, че регистрирането на дефект с цялата необходима информация, недостатъчна за разработчиците да разберат дефекта?
То е и в някои от случаите изисква допълнително обяснение / обсъждане с разработчиците. Има случаи, в които изпитател среща неочаквано поведение, за което може да не е сигурен дали е дефект. Тези обстоятелства обикновено се сблъскват с доказали се, които са нови в екипа, които имат ограничени познания в областта или имат неяснота относно изискванията. Е, тук не трябва да се обвинява тестерът, ако има строги срокове и има постоянно променящи се изисквания и в повечето случаи се доказва за домейна, докато всъщност планира и изпълнява тестови случаи. Както виждаме пътят на тестер не е толкова лесен, колкото се възприема. Това изисква винаги отношение към обучението, добри комуникационни умения, добри умения за сътрудничество и нетърпение да се приспособявате към условия, при които има промени в използваните домейни, инструменти, процеси. Докато говорихме за пътуването на ръчни тестери, цялостният процес се отнася и за тестерите за автоматизация. Автоматизацията, от друга страна, имат значителни промени в процеса, тъй като обхватът на тестване и планиране, изпълнението варира значително.
Като се има предвид пътуването на доказателя, както беше разгледано по-горе, все пак можем ли да кажем, че работата с качествата на тестера на софтуер е по-лесна от тази на разработчика?
Може да се каже, че повече от сравняването на ролите на разработчиците на tester v / s, ще бъде по-полезно да се обсъди как сътрудничеството на двама може да доведе до голям успех на продукта като цяло. Понякога забравяме, че задачата на тестера е да намира проблеми в приложението и да не посочва грешки на разработчиците. Когато забравим самата идея за нашата работа, това понякога води до ненужна дискусия. Наблюдава се обаче, че има еднакво добри екипи за тестване, разработки, при които всички разбират, че крайната цел е да се направи приложението да работи както се очаква. Да се надяваме всички да гледат на положителната страна на тестовата работа като на роля, която помага при почистването на продукта, а не като на тази, която просто открива грешки!
Препоръчителни статии
Това е ръководство за разкриване и утвърждаване на очевидните и не толкова очевидни пътища на приложение, винаги е основното очакване от работата на софтуерния тестер. Това са следната външна връзка, свързана с работата на тестера на софтуер.
- Дефектен жизнен цикъл при тестване на софтуер
- 6 най-невероятни въпроси за тестване на интервю за софтуер
- Кариери в тестване на софтуер