Меню

Обучение за тестване на софтуер: Обучение от край до край по проект на живо - Безплатно онлайн обучение за QA, част 1

software testing training

Опитайте Нашия Инструмент За Премахване На Проблемите

БезплатноОбучение за тестване на софтуерПо проект в реално време на живо:

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

Накратко, бъдете готови за кратък онлайн курс за тестване на софтуер.

_Завършете обучението по проект на живо

Важна забележка : Долните безплатни уроци са полезни за започване, но ако се интересувате от най-добрия онлайн курс за тестване на софтуер на живо от експерти, моля проверете тази страница.

Тестване на QA обучение

=> Тук есписък на всички уроцив тази безплатна серия от обучения за Live Project QA:

въпроси и отговори за интервю за мобилно тестване за опитни

Защо това безплатно QA обучение?

Получаваме много запитвания от нашите читатели, за да споделим нашия опит в точен процес на тестване на софтуера последван от екипите за тестване на софтуер. Затова решихме да документираме този пълен STLC с помощта на примерно приложение на живо, което е достъпно за тестване в Интернет.

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

Какво ще научите:

Обучение за тестване на софтуер по проект на живо - какво е това?

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

Избрахме приложение на живо (чиито подробности са по-долу) и започнем с:

- По принцип всичко, което обикновено бихме направили в проект за тестване на софтуер в реално време - с примери в реално време, артефакти и продукти, създадени в процеса.

Как да следвам тази серия курсове за тестване на софтуер?

Етап 1) Въведение и разходка за SRS - Ще започнем този мини курс за тестване на софтуер с разходка за SRS. Създадохме и споделихме примерен SRS документ. Преминете през него, тъй като всички следващи стъпки зависят от вашето разбиране за това приложение.

Стъпка 2) Подготовка на SRS за преглед и тестов сценарий.

Стъпка # 3) Тестов план - завършете процеса на създаване на тестов план от нулата. Окончателната версия на тестовия план ще бъде споделена с вас за справка.

Стъпка # 4) Тестови случаи - завършете процеса на писане на тестови случаи с някои примерни тестови случаи. Можем да използваме всеки инструмент за управление на тестове или електронна таблица за писане на тестови случаи.

Стъпка # 5) Упътване за приложението и изпълнение на теста - Как да изпълнявам тестови случаи и да записвам резултатите от теста?

Стъпка # 6) Отчитане на дефекти

Стъпка # 7) Проверка на дефекти, процес на повторно тестване

Стъпка # 8) QA Sign-off

Намерението е да ви дадем усещане за опит и опит в проекти в реално време. Надяваме се тази серия да ви бъде полезна.

Приложение, което ще използваме допълнително

Въведение

Клиент: Оранжево
Приложение: Демонстрация на OrangeHRM .
Доставчик на услуги: SoftwareTestingHelp.com

Описание на проекта

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

Той има 2 версии: Професионални и предприемачески.

Характеристиките включват

  • Управление на личната информация
  • Разширено управление на отпуск
  • Проследяване на времето и посещаемостта
  • Управление на ефективността на служителите
  • подбор на персонал
  • Разширено отчитане
  • Управление на служители, основано на държава / местоположение
  • Локализирани правила за отпуск
  • Конфигурируеми работни потоци
  • Платинена поддръжка
  • Отчитане по държави / местоположение
  • Персонализирано отчитане

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

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

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

python срещу c ++ синтаксис

Традиционен Проект за водопад (SDLC) има следните фази:

Процес на разработка на софтуер

  • Тъй като QA’s, всички знаем, че въпреки че „Тест“ е стъпка 5 от този поток, това не е единственото място, където тестерите играят важна роля.
  • Също така тестването е реактивна работа. Без код / ​​приложение, готово да тестваме, ние наистина не можем да ‘тестваме’ нищо. За да бъдем готови и да реагираме по възможно най-ефективния начин, ние се опитваме, доколкото можем, да планираме и да се подготвим напред. Така че, въпреки че фаза 5 е за тестване, нашите дейности започват много напред.

С две думи, това се случва във всяка фаза !!

Иницииране:

След като производителят и клиентът се споразумеят за условията - производството на софтуер започва.

  • На тази фаза се събират и анализират бизнес изискванията. Анализът ще включва решения, включително технологични съображения, хардуерни и софтуерни спецификации, хора, усилия, време, уместност и подобрения.
  • В тази стъпка участват бизнес анализатори, ръководители на проекти и представители на клиенти.
  • В края на тази стъпка и основния проект се изготвя планът.
  • Изработват се специфични за проекта документи като обхват и / или бизнес изисквания.
  • Участие в осигуряването на качеството на този етап обикновено не се очаква. (Това е леко отклонение от това, което трябва да бъде, защото за да се идентифицират проблемите в началото на фазите на развитие, най-добре е да се включи QA още от самото начало.)

Определете:

Финализираните бизнес изисквания са входните данни за тази стъпка.

  • Тази фаза включва превръщането на бизнес изискванията във функционални изисквания за софтуера. Например , ако бизнес изискването е да позволи на потребителя да купи нещо от даден сайт. Функционалното изискване ще съдържа подробности като Формат на сайта-> Име и разположение на опцията за меню-> Търсене на продукт-> Количка-> Плащане (регистрация или не) -> Опции за плащане-> Потвърждение за продажба.
  • В тази фаза участват разработчици, бизнес анализатори, ръководители на проекти
  • Резултатът от тази фаза е подробен документ, съдържащ функционалните изисквания на софтуера. Този документ се обозначава с много имена - Спецификация на софтуерни изисквания (SRS), Документ за функционални изисквания (FRD) или Спецификация на функционални изисквания (FRS).
  • Тук се включва екипът на QA - след попълване на документацията за SRS.
  • Докато тече финализирането на функционалните изисквания и документацията на SRS, мениджърът / ръководителят на QA участва в изготвянето на първоначална версия на тестовия план и сформирайте QA екип.
  • Участието на екипа за осигуряване на качеството ще стане, след като SRS бъде документиран.
  • На този етап или екипът за разработка, или бизнес анализаторът, или понякога дори ръководителят на екипа за осигуряване на качеството ще предостави преглед на SRS на екипа за осигуряване на качеството.
  • В случай на нов проект, най-добре работи задълбочено ръководство под формата на конференция или среща
  • В случай на по-късни издания за съществуващ проект, документ се изпраща по имейл или разположение в общо хранилище до екипа на QA. В този момент екипът за QA ще го прочете / прегледа офлайн и ще разбере системата напълно.
  • Тъй като основната целева аудитория за SRS документа не са само тестери, не всички те са полезни за нас. Ние, тестерите, трябва да бъдем достатъчно усърдни, когато преглеждаме този документ, за да решим кои части от него са полезни за нас и кои части от него не са.

SRS документ за този проект на живо

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

==> Изтеглете примерен SRS документ на живо на проект .

Заключение

В тази статия ви запознахме с процеса на разработване и тестване на софтуер. Също така споделихме примерен SRS документ за проекта на живо, който ще тестваме.

=> Предстоящата статия в тази поредица от обучения за софтуер ще бъде - Преглед на SRS и процесът на създаване на тестови сценарии .

Забележка: Докато се пише следващата статия в тази QA серия за обучение, работете с нас паралелно тук за повечето преживявания на живо . Опитайте се да прочетете добре документа на SRS и след това ще продължим със следващите стъпки, когато се срещнем отново.

Честито тестване, до тогава!

За автора: Членът на екипа на STH Swati Seela ни помага да представим тази поредица от обучения за QA проект на живо.

Препоръчително четене

^