Типична структура на процеса на тестване на софтуер

Като цяло проектите за разработка на софтуер протичат съгласно следната екипна структура

1) Екип от собственици на функции: Това е екип от най-високо ниво в йерархията, който директно взаимодейства с бъдещите клиенти. Той е отговорен да разбере внимателно изискванията на клиента и да ги групира в няколко функции. Различни членове в такъв екип могат да станат собственици на някои от тези функции. Членовете на екипа поемат дължимата инициатива и активно взаимодействат с различни екипи, стават инструмент за предоставяне на необходимите насоки при разработването на притежаваните от тях функции.

2) Екип за потребителски интерфейс: Потребителският интерфейс, наречен накратко UI, е изключително важен за продукта. Дори ако даден софтуерен продукт има серия от отлични функции, но неговият потребителски интерфейс не е ефективен и удобен, продуктът е обречен да се провали.

По този начин се създава независим екип за потребителски интерфейс. Членовете на екипа за потребителски интерфейс са специалисти в проектирането на потребителския интерфейс за софтуерните продукти и разбират разликата между добър и лош потребителски интерфейс. Единствената цел на такъв екип за потребителски интерфейс е да направи задълбочено проучване на потребителския интерфейс.

Екипът на потребителския интерфейс проектира потребителски интерфейс за продукта или неговите характеристики. В следващата стъпка екипът на потребителския интерфейс взаимодейства с екипа на собствениците на функции, за да даде съвместно практическа форма на потребителския интерфейс. Такава среща може да доведе до може да бъде „Дизайн на страници“ или някои „Мокапи“, съдържащи всички елементи на потребителския интерфейс, както се изисква на страницата. Макетите са полезни при представянето на желания външен вид или изглед на страницата. Действителната навигация между различни страници също се проверява по време на такива междуфункционални срещи.

3) Екип за разработка: Поверена е задачата за разработване на продукта.

4) Екип за тестване: Поверена е задачата да тества продукта.

ПОТОК НА ПРОЦЕСА:

1) Начало на проекта: Членовете на екипа на собствениците на функции започват процеса с разработването на проектен документ на високо ниво, приложим за всяка функция, и същият се пуска за всички заинтересовани.

2) Пускане на проектен документ от високо ниво: Освен документа за проектиране на високо ниво, изготвен от собствениците на функции, дизайните на страниците или макете на потребителския интерфейс се пускат на всички заинтересовани за справка от екипите на потребителския интерфейс.

3) Разработка на софтуер: Кодирането на желаните функции се стартира от екипа за разработка според публикуваните документи.

4) Тестване на софтуер: Ударът на екипа за тестване започва дейностите, свързани с тестването, по следния начин:

($) Подготовка на документ с описание на теста: Този документ описва подробности за потоците на теста или сценариите за множество тестове, проектирани на високо ниво. Схемата за изпитване трябва да съдържа кратка информация за това какво трябва да се провери в кой момент по време на потока.

В допълнение към подробностите за потоците, този документ за схемата на теста съдържа подробна матрица, описваща всички изисквания от Проектния документ на високо ниво (HLD) до тестовите потоци. В HLD уникален идентификатор може ясно да идентифицира всяко изискване. Целта на тази матрица е да се увери, че всички изисквания са внимателно проверени за някакви недостатъци.

($) Подготовка на тестови случаи: Всеки тестов сценарий допълнително се преобразува в индивидуален тестов случай, който съдържа цялата подробна информация. Той определя точните стъпки за навигация, желаните данни и подробна информация за това какво трябва да се провери. Подробното обяснение в Test Cases е полезно, особено когато лицата, които пишат тестовия случай, са различни от лицата, които ще ги изпълнят.

($) Автоматизация на тестовете: Въпреки че не е задължителна, автоматизацията на теста е незадължителна стъпка. Това включва автоматизация на проектираните тестови случаи с помощта на някакъв инструмент за автоматизация, най-подходящ за изискванията на компанията.

($) Едновременни дейности: Работата по разработка и тестване се извършва едновременно. Екипът за разработка се ангажира с основната задача да кодира желаните функции. Екипът за разработка понякога прави и някакъв вид тестване в своя край. Междувременно екипът за тестване подготвя тестовите случаи за ръчно тестване и скриптове за автоматизация за автоматизиране на изпълнението на теста с помощта на някакъв инструмент за автоматизация.

($) Тестване на продукта: Цикълът на тестване започва, когато екипите за тестване започнат активно тестването на продукта и започнат да регистрират грешките в дефинираната система за хранилище за грешки. Едновременно с това разработчиците се занимават с корекции на грешки.

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

($) Регистриране на грешки: Преди регистриране на грешка в системата за съхранение на грешки, се проверява дали можем да я възпроизведем в екземпляр, предназначен за разработчиците, или не. Ако грешката е възпроизводима, тя се възлага на съответния разработчик за необходимото коригиране. Когато грешката е отстранена, тогава корекцията на кода се прилага към екземпляра на разработчика, старателно се проверява и след това се прилага към екземпляра на екипа за тестване за регресионно тестване.

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

($) Регресионно тестване: Извършва се корекция на кода и тестерите повтарят тестването от началото. За да се коригират бъговете, честото пачове на системата се избягва. Съгласно най-добрата политика за корекция на грешките, включваща множество кръгове тестване, корекцията на всички грешки, натрупани между два кръга на тестване, се извършва само веднъж, Грешките се коригират и се поддържат готови за корекция заедно. Това също няма строго правило. Има изключения за грешки, които се считат за критични и които могат сериозно да попречат на тестването, могат да бъдат коригирани незабавно.

($) Тестване за здравина: След като корекцията е извършена, екземплярът на приложението се подлага на тест за здравина от екипа за разработка. След това се пуска за следващия кръг на тестване, включващ повторно изпълнение на всички тестови случаи. Това включва изпълнение на тестовите случаи, които се случват да преминат в предишния кръг.

($) Спиране на операцията по тестване: При сценарий на множество кръгове на тестване трябва да се вземе важно решение дали да се премине към следващия кръг от тестване или да се спре само там. Жизненоважното решение до голяма степен зависи от броя на грешките, регистрирани по време на предишния кръг от тестване. Два фактора могат да помогнат за вземането на такова решение са:

1) По-нататъшното тестване може да бъде спряно, когато не бъдат открити нови критични грешки и когато няма повече нужда от регресионно тестване.

2) По-нататъшното тестване може да бъде спряно, когато останат много по-малко малки проблеми. Терминът „По-малко“ е силно субективен и зависи до голяма степен от приложението, което се тества.

Empfohlene Artikel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.