practical software testing qa process flow
Пълен преглед на процеса на тестване на софтуера за QA от край до край:
Забележка - Преиздаваме тази полезна публикация с актуализирано съдържание.
Работата на специалист по тестване на софтуер не е лесна. Той е изпълнен с предизвикателства, което е също толкова взискателно. Тестерите трябва да бъдат нащрек и ентусиазирани във всяка фаза от жизнения цикъл на приложението.
Въпреки че има предизвикателства, има и няколко огромни възможности за изучаване и изследване на различните аспекти на тестовите методологии, процеси и разбира се софтуера в детайли.
Ролята на тестов инженер започва много рано. И точно от концептуализацията на проекта тестерите участват в дискусии със собственика на продукта, ръководителя на проекта и различни заинтересовани страни.
Този урок за „Процес на процеса на тестване на софтуер“ ви дава пълен преглед на различните фази в STLC заедно с предизвикателствата и най-добрите практики за преодоляване на тези предизвикателства по лесно разбираем начин.
Какво ще научите:
- Изискване за издаване - пълен преглед
- QA Процес на тестване на реален проект - Метод на водопада
- Стъпки в изискванията за освобождаване
- Заключение
- Препоръчително четене
Изискване за издаване - пълен преглед
Точно от изискването за освобождаване, всяка фаза е обяснена ясно. Нека ги разгледаме подробно.
# 1) Изискване
Проектът не може да започне, без да има ясни изисквания. Това е най-важната фаза, в която идеите трябва да бъдат написани в добре разбираем и форматиран документ. Ако сте част от проекта, в който участвате във фазата на събиране на изискванията, тогава се смятайте за късметлия.
инструменти за анализ на големи данни с отворен код
Чудите се защо? Това е така, защото сте свидетели на проект за правене от нулата. Въпреки че има гордост да бъдеш от самото начало, това идва и с някои отговорности и предизвикателства.
Предизвикателства
Човек не може да си представи всички изисквания за събиране на едно заседание. Бъдете достатъчно търпеливи.
Ще се случат много дискусии, някои от които може да са просто без значение за вашия проект, но дори тогава те могат да съдържат важна информация за вашия проект. Понякога скоростта на дискусии може да надхвърли вашите възможности за схващане или просто не бихте обърнали внимание на собственика на продукта.
Картината по-долу подчертава ключовите стъпки, свързани със събирането на изискванията:
Всяка пропусната информация оказва огромно влияние върху цялостното разбиране и тестване на проекта. За да се преодолее това, ето някои най-добри практики, които трябва да се следват през този етап.
Най-добри практики
- Дръжте ума си отворен и обръщайте внимание на всяка дума на собственика на продукта.
- Не просто слушайте, изчистете съмнението си, колкото и малко да изглежда.
- Винаги използвайте тетрадки за бързо водене на бележки. Трябва да използвате лаптоп, само ако наистина можете да пишете с честна скорост.
- Повторете изреченията и ги изяснете от поръчката, която според вас е това, което сте разбрали.
- Начертайте блок-схеми, текст на връзки и т.н., за да направите изискванията по-ясни в по-късен период от време.
- Ако екипите са на различни места, опитайте се да го направите WebEx или подобен запис. Винаги ще помогне, когато имате съмнения след приключване на дискусиите.
Въпреки че няма отделна стена като такава за всяка фаза, изискванията се променят дори много късно в развитието. Идеята е да вземете по-голямата част от изискването и да документирате това правилно.
След като бъде документирано с всички необходими точки, разпределете и обсъдете всички заинтересовани страни, така че всякакви предложения или промени да бъдат уловени рано и преди да продължите напред, всички са на една и съща страница.
# 2) Тестова стратегия
Тестерите трябва да излязат с тестова стратегия, която е не само достатъчна, за да тества софтуера по-добре, но също така трябва да внуши доверие на всички заинтересовани страни по отношение на качеството на продукта.
Предизвикателства
Най-важният аспект на тази фаза е да се създаде стратегия, която, когато се работи по нея, трябва да достави софтуерен продукт, който е без грешки, устойчив и се приема от крайните потребители.
Тестовите стратегии са нещо, което няма да променяте през ден. В някои случаи трябва да обсъдите своите стратегии за тестване и с клиентите. Така че тази част трябва да се разглежда с голямо значение.
Най-добри практики
- Ето някои от най-добрите практики, които при спазване могат да ви осигурят голямо облекчение и да доведат до плавно тестване.
- Прегледайте документа за изисквания още веднъж. Маркирайте точките за импортиране по отношение на средата на целевия софтуер.
- Направете списък на среди, в които софтуерът действително ще бъде разположен.
- Средата може да се разбира като вид операционни системи или мобилни устройства.
- Ако Windows е операционната система, посочете всички версии на прозореца, където ще тествате вашия софтуер. Ако версиите viz. Windows 7, Windows 10 или Windows Server (s) все още не са дефинирани в документа за изискванията, тогава е крайният момент да се обсъдят.
- По подобна бележка вземете целевите браузъри с обсъдените и документирани версии, ако AUT е уеб базирана система.
- Направете списък на целия софтуер на трети страни, от който приложението ще се нуждае (ако се изисква / поддържа). Те могат да включват Adobe Acrobat, Microsoft Office, всякакви добавки и др.
Тук идеята е да запазим всяка необходима и необходима платформа, устройства и софтуер, които нашето приложение ще трябва да функционира преди нас, за да може да се формулира цялостна стратегия.
Фигурата по-долу ще ви помогне да разберете схемата на тестовата стратегия, ако работите по гъвкав проект:
# 3) Планиране на тестове
След като тестерите са въоръжени с цялата информация относно AUT, фазата на планиране е мястото, където Стратегията се прилага.
Подобно на тестовата стратегия, планирането на теста също е решаваща фаза.
Предизвикателства
Тъй като успехът (или неуспехът) на AUT зависи до голяма степен от начина на провеждане на тестовете, тази фаза се превръща във важен аспект от целия жизнен цикъл на теста. Защо? Тъй като в тази фаза е дефинирана част от тестването.
За да се преодолеят някои предизвикателства, тези най-добри практики наистина могат да бъдат полезни.
Най-добри практики
- Винаги имайте предвид, да не оставяте камъни на камък, когато става въпрос за тестване на вашето приложение.
- Време е да формулираме тестова стратегия.
- Създайте матрица на средата, така че софтуерът да бъде тестван на всички платформи.
- Подобно на Windows 10 + Internet Explorer 11+ Windows Office 2010+.
- Подобно на Android 4.2.2+ браузър Chrome.
- Ако вашето приложение работи с множество бази данни (Ако е документирано), съхранявайте базите данни (MySQL, Oracle, SQLServer) в тестовата матрица по такъв начин, че да са твърде интегрирани с някои тестове.
- Конфигурирайте тестовите машини съответно и ги наречете като SetUp1, SetUp2 и т.н.
- SetUp1 ще има Windows 7+ IE 10+ Office 2007+.
- SetUp2 може да има Windows 10+ IE Edge + Office 2013+.
- SetUp3 може да има телефон с Android с инсталиран .apk файл.
- Честито! Вашата тестова настройка е готова и вие също така включихте всяка възможна комбинация от платформи, върху които ще работи вашето приложение.
# 4) Тестване
И накрая, компилацията на вашето приложение е изчерпана и сте готови да намерите грешки! Сега е време да поработите върху планирането на теста и да намерите възможно най-много грешки. Ще има някои фази между тях, ако работите в гъвкава среда, а след това просто следвайте тези скрам методи.
По-долу диаграмата изобразява категоризацията на различни видове тестване:
Предизвикателства
Тестването е тромав процес, който сам по себе си е склонен към грешки! Човек открива много предизвикателства, докато тества приложението. По-долу са дадени някои най-добри практики за спасяване.
Най-добри практики
Горе главата! Опитвате се да намерите дефекти в кода. Трябва да обърнете внимание на цялостната работа на софтуера.
- Винаги е препоръчително да разгледате приложението с нов вид, БЕЗ ДА ПРЕМИНАТЕ ЧРЕЗ ИЗПИТВАТЕЛНИ СЛУЧАИ.
- Следвайте навигационния път на вашия софтуер (AUT).
- Запознайте се с AUT.
- Сега прочетете тестовите случаи (Всички) на всеки конкретен модул (Може би по ваш избор).
- Сега отидете на AUT и съпоставете констатациите с тези, споменати в очаквания раздел на тестовите случаи.
- Идеята зад това е да се тества всяка спомената функция на всяка поддържана платформа.
- Забележете всяко отклонение, колкото и тривиално да изглежда.
- Запишете стъпките как да постигнете някакво отклонение, направете екранни снимки, заснемете регистрационни файлове за грешки, регистрационни файлове на сървъра и всякаква друга подкрепяща документация, която може да докаже съществуването на дефекти.
- Не се колебайте да попитате. Въпреки че имате документа с изискванията, ще има моменти, в които ще се съмнявате.
- Обърнете се към разработчиците (ако те седят до вас или са достъпни) със съмнение, преди да се свържете със собственика на продукта. Разберете перспективата на разработчика за работата на софтуера. Разберете ги. Ако смятате, че това изпълнение не отговаря на изискванията, информирайте мениджъра на теста.
# 5) Преди освобождаване
Преди да пуснем който и да е продукт на пазара, трябва да се гарантира качеството на продукта. Софтуерът е разработен веднъж, но всъщност е тестван, докато не бъде заменен или премахнат.
Предизвикателства
Софтуерът трябва да бъде тестван стриктно за много от неговите параметри.
Параметрите не могат да бъдат ограничени до:
- Функционалност / Поведенчески.
- Производителност.
- Мащабируемост.
- Съвместим с посочените платформи.
Предизвикателството е също така да се предскаже степента на успех на приложение, което зависи от много итерации на извършеното тестване.
Най-добри практики
- Уверете се, че всички функции на всички платформи са тествани.
- Маркирайте областите, които не са тествани или тази, която се нуждае от повече усилия за тестване.
- Запазете матрица на всички резултати от теста преди пускането. Тестовата матрица ще даде цялостна картина на стабилността на продукта. Също така ще помогне на ръководството да се обади на датите на пускане.
- Предоставете вашите мнения / предложения на екипа за вашия опит, докато тествате продукта.
- Вашата информация, която се смята за краен потребител, ще се възползва от софтуера като цяло.
- Поради срив във времето или друга подобна ситуация, ние или пропускаме някои тестове, или не навлизаме дълбоко в това. Не се колебайте да кажете на своя мениджър състоянието на тестване.
- Представете здравната карта на заявлението на заинтересованите страни. Здравните карти трябва да имат редица регистрирани, отворени, затворени, периодични дефекти със своята тежест и приоритет.
- Изгответе документ за освобождаване и го споделете в екипа.
- Подгответе документа за освобождаване.
- Подобрете областите, които са предложени от ръководството / екипа.
Долната снимка показва картата на жизнения цикъл на издаването на софтуера:
# 6) Освобождаване
И накрая, идва моментът, когато трябва да доставим продукта на предвидените потребители. Всички ние като екип работихме усилено, за да подпишем продукта и да оставим софтуера да помогне на своите потребители.
Предизвикателства
Инженерите за тестване на софтуер са отговорни главно за издаването на всеки софтуер. Тази дейност изисква ориентиран към процеса работен процес. Ето някои от най-добрите практики, които участват в тази фаза.
Най-добри практики
- Винаги помнете, че не работите по документа за освобождаване на датата на АКТУАЛНО ИЗПУСКАНЕ.
- Винаги планирайте дейността по издаване преди действителната дата на пускане.
- Стандартизирайте документа според фирмените политики.
- Вашият документ за издание трябва да се опита да установи положителни очаквания от софтуера.
- Споменете ясно всички софтуерни и хардуерни изисквания, специфични за техните версии, в документа.
- Включете всички отворени дефекти и тяхната тежест.
- Не скривайте големи засегнати зони поради отворени дефекти. Отделете им място в документа за издаване.
- Получете прегледа на документа и цифровия подпис [може да се различава според фирмената политика].
- Бъдете уверени и изпратете документа за освобождаване заедно със софтуера.
QA Процес на тестване на реален проект - Метод на водопада
Получих интересен въпрос от читател, Как се извършва тестване в компания, т.е. в практическа среда?
Тези, които просто излизат от колежа и започват да търсят работа, имат това любопитство - как би била действителната работна среда в една компания?
Тук съм се съсредоточил върху действителния работен процес на Тестване на софтуер във фирмите .
Винаги, когато получим някакъв нов проект, има първоначална среща за запознаване с проекта. На тази среща основно обсъждаме кой е клиентът? каква е продължителността на проекта и кога е неговата доставка? Кои всички участват в проекта, т.е. мениджър, технически ръководители, QA потенциални клиенти, разработчици, тестери и т.н.?
От SRS (спецификация на софтуерните изисквания) се разработва проектният план. Отговорността на тестерите е да създадат план за тестване на софтуер от този SRS и план на проекта. Разработчиците започват да кодират от дизайна. Работата по проекта е разделена на различни модули и тези модули на проекта се разпределят между разработчиците.
Междувременно отговорността на тестера е да създаде тестов сценарий и да напише тестови случаи според зададените модули. Опитваме се да покрием почти всички функционални тестови случаи от SRS. Данните могат да се поддържат ръчно в някои шаблони за тестове на Excel или инструменти за проследяване на грешки.
Когато разработчиците завършат отделните модули, тези модули се присвояват на тестерите. Тестването на дим се извършва на тези модули и ако те не успеят на този тест, модулите се преназначават на съответните разработчици за поправка.
За преминатите модули се извършва ръчно тестване от писмените тестови случаи. Ако бъде открита грешка, която се присвоява на разработчика на модула и се регистрира в инструмент за проследяване на грешки . При отстраняване на грешки тестерът прави проверка на грешки и тестване на регресия на всички свързани модули. Ако грешката премине проверката, тя се маркира като проверена и се маркира като затворена. В противен случай гореспоменатият цикъл на грешки се повтаря. (Ще разгледам жизнения цикъл на грешките в друга публикация)
Извършват се различни тестове за отделни модули и интеграционни тестове за интеграция на модули. Тези тестове включват тестване на съвместимост, т.е. тестване на приложения на различен хардуер, версии на ОС, софтуерни платформи, различни браузъри и т.н.
Тестовете за натоварване и стрес също се извършват съгласно SRS. И накрая, системното тестване се извършва чрез създаване на виртуална клиентска среда. След като всички тестови случаи са изпълнени, се изготвя протокол от теста и се взема решение за пускане на продукта!
Стъпки в изискванията за освобождаване
По-долу са дадени подробностите за всяка стъпка на тестване, която се извършва във всяко качество на софтуера и жизнения цикъл на тестване, посочени от IEEE и ISO стандарти.
# 1) Преглед на SRS : Преглед на спецификациите на софтуерните изисквания.
# 2) Цели са настроени за основни издания.
# 3) Целева дата планирани за изданията.
# 4) Подробен план на проекта е построен. Това включва решението относно проектните спецификации.
# 5) Разработване на план за изпитване се основава на спецификациите на дизайна.
# 6) План за тестване: Това включва цели, методология, приета по време на тестване, характеристики, които трябва да бъдат тествани, а не да бъдат тествани, критерии за риск, график на тестване, мултиплатформена поддръжка и разпределение на ресурсите за тестване.
# 7) Спецификации на теста: Този документ включва технически подробности (софтуерни изисквания), необходими преди тестването.
# 8) Писане на тестови случаи
- Дим ( BVT ) тестови случаи
- Тестове за здрав разум
- Случаи с тестове за регресия
- Отрицателни тестови случаи
- Разширени тестови случаи
# 9) Разработка: Модулите се разработват един по един.
# 10) Обвързване на инсталаторите: Инсталаторите са изградени около отделния продукт.
как да отворя eps файл
# единадесет) Процедура за изграждане : Компилация включва инсталатори на наличните продукти - множество платформи.
# 12) Тестване: Тест за дим (BVT): Основен тест за приложение, за да се вземе решение за по-нататъшно тестване.
- Тестване на нови функции
- Кръстосан браузър и междуплатформено тестване
- Стрес тестване и тестване на паметта.
# 13) Резюме на теста
- Доклад за грешка и се създават други отчети
# 14) Код замразяване
- Към този момент не се добавят повече нови функции.
# 15) Тестване: Тестване на компилация и регресия.
# 16) Решение за пускане на продукта.
# 17) Сценарий след освобождаване за по-нататъшни цели.
Това беше резюме на действителен процес на тестване във фирмена среда.
Заключение
Работата на софтуерен тестер е пълна с предизвикателства, но все пак приятна. Това е за някой, който е еднакво страстен, мотивиран и изпълнен с ентусиазъм. Намирането на грешки у някого не винаги е лесна работа! Това изисква много умения и поглед към дефектите.
Освен всички качества, тестерът трябва да бъде и ориентиран към процеса. Както всички останали индустрии, проектите в ИТ се преработват на етапи, където всяка фаза има някои точно определени цели. И всяка цел има добре дефиниран критерий за приемане. Тестовият инженер трябва да носи много товари със софтуерно качество на раменете си.
Докато работят във всяка фаза на софтуера, тестерите трябва да следват най-добрите практики и трябва да се приведат в съответствие с процеса, включен в съответните фази. Следването на най-добрите практики и добре формулирания процес не само помага да се улесни работата на тестерите, но също така помага да се гарантира качеството на софтуера.
Били ли сте част от някоя от горните фази? Чувствайте се свободни да споделите своя опит по-долу.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Тестване на софтуер QA Assistant Job
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Някои интересни въпроси за интервю за тестване на софтуер
- Обратна връзка и рецензии на курсове за софтуерно тестване
- Как да подобря процеса на издаване на тест за успешен софтуер за производство без грешки