Методологии за тестване на софтуер: QA модели
Томас Хамилтън
⚡ Умно обобщение
Методологията за тестване на софтуер определя стратегиите и типовете тестване, използвани за удостоверяване, че дадено приложение отговаря на очакванията на клиента. Водопадното, итеративното, гъвкавото и екстремното програмиране определят кога започва тестването и как се връща обратната връзка.
Какво представлява методологията за тестване на софтуер?
Методологията за тестване на софтуера се дефинира като стратегии и видове тестване, използвани за удостоверяване, че Тестваното приложение отговаря на очакванията на клиента. Тестовите методологии включват функционално и нефункционално тестване за валидиране на AUT. Примери за методологии за тестване са Единично тестване, Тестване на интеграцията, Тестване на системата, Тестване на производителността и т.н. Всяка методология за тестване има дефинирана цел на теста, стратегия за тестване и резултати.
Забележка: Тъй като софтуерното тестване е неразделна част от всяка методология за разработка, много компании използват разговорно термина методологии за разработка и методологии за тестване. Следователно методологиите за тестване могат също да се отнасят до водопад, гъвкав и други QA модели в сравнение с горното определение на методологии за тестване. Обсъждането на различни видове тестове не добавя стойност към читателите. Затова ще обсъдим различните модели на развитие.
Методология на тестване срещу вид тестване срещу стратегия за тестване
Горната бележка загатва за истинска неяснота в индустрията. Три термина се използват взаимозаменяемо в разговора, но означават различни неща в проектния документ и объркването им води до тестови планове, които отговарят на грешен въпрос.
| термин | Въпрос, на който отговаря | Решение от | Примери |
|---|---|---|---|
| Методика на тестване | Кога и как тестването се вписва в цикъла на разработка? | Използваният модел на развитие | Водопадно, итеративно, гъвкаво, екстремно програмиране |
| Тип тестване | Кой аспект на продукта се проверява? | Покритие на риска и изискванията | Устройство, интеграция, система, производителност, сигурност |
| Ниво на тестване | До каква дълбочина се изследва софтуерът? | Позиция в йерархията на изграждането | Компонент, интеграция, система, приемане |
| Тествайте стратегия | Какъв е нашият организационен подход към качеството? | Лидерство в осигуряването на качеството, прилага се във всички проекти | Базирано на риска, автоматизация на първо място, изместване наляво |
| План за тестване | Какво точно ще тества този проект, кога и от кого? | Мениджър тестване, специфичен за проекта | Обхват, график, ресурси, критерии за влизане и излизане |
Полезно правило: методологията задава ритъма, видът определя целта, а план за изпитване регистрира ангажимента. Разделите по-долу разглеждат методологиите.
Модел на водопад
Какво е това?
в модел водопад, напредък в разработката на софтуер през различни фази като анализ на изискванията, дизайн и т.н. – последователно.
В този модел следващата фаза започва само когато по-ранната фаза е завършена.
Какъв е подходът за тестване?
Първата фаза в модела на водопада е фазата на изискванията, в която всички изисквания на проекта са напълно дефинирани преди започване на тестването. По време на тази фаза тестовият екип обмисля обхвата на тестването, тестовата стратегия и изготвя подробен тестов план.
Едва след като дизайнът на софтуера приключи, екипът ще премине към изпълнение на тестовите случаи, за да гарантира, че разработеният софтуер се държи според очакванията.
При тази методология екипът за тестване преминава към следващата фаза само когато предишната фаза е завършена.
| Предимства | Недостатъци |
|---|---|
| Този модел на софтуерно инженерство е много лесен за планиране и управление. Следователно проекти, където изискванията са ясно дефинирани и заявени предварително, могат лесно да бъдат тествани с помощта на каскаден модел. | В модела на водопада можете да започнете със следващата фаза само след като предишната фаза е завършена. Следователно този модел не може да поеме непланирани събития и несигурност. |
| Тази методология не е подходяща за проекти, където изискванията се променят често. |
Итеративно развитие
Какво е това?
В този модел, голям проект е разделен на малки части, като всяка част е подложена на множество итерации на водопадния модел. В края на итерацията се разработва нов модул или се подобрява съществуващ модул. Този модул се интегрира в софтуерната архитектура и цялата система се тества заедно.
Какъв е подходът за тестване?
Веднага след като итерацията приключи, цялата система се подлага на тестване. Обратната връзка от тестването е незабавно достъпна и се включва в следващия цикъл. Времето за тестване, необходимо при последователна итерация, може да бъде намалено въз основа на опита, натрупан от минали итерации.
| Предимства | Недостатъци |
|---|---|
| Основното предимство на итеративното разработване е, че обратната връзка от теста е незабавно достъпна в края на всеки цикъл. | Този модел значително увеличава комуникационните разходи, тъй като в края на всеки цикъл трябва да се даде обратна връзка относно резултатите, усилията и т.н. |
Agile методология
Какво е това?
Традиционните методологии за разработка на софтуер работят на предпоставката, че софтуерните изисквания остават постоянни по време на целия проект. Но с увеличаване на сложността, изискванията претърпяват множество промени и непрекъснато се развиват. Понякога самият клиент не е сигурен какво иска. Въпреки че итеративният модел се занимава с този проблем, той все още се основава на модела на водопада.
В Agile методологията софтуерът се разработва в постепенни, бързи цикли. Взаимодействията между клиентите, разработчиците и клиента се наблягат по-скоро на процесите и инструментите. Гъвкавата методология се фокусира върху реагирането на промените, а не върху обширното планиране.
Какъв е подходът за тестване?
Инкременталното тестване се използва в гъвкави методи за разработка и следователно всяко издание на проекта се тества щателно. Това гарантира, че всички грешки в системата са коригирани преди следващото издание.
| Предимства | Недостатъци |
|---|---|
| Възможно е по всяко време да се направят промени в проекта, за да се съобразят с изискванията. | Постоянното взаимодействие с клиента означава допълнителен натиск във времето върху всички заинтересовани страни, включително самия клиент, екипите за разработка на софтуер и тестване. |
| Това постепенно тестване минимизира рисковете. |
Екстремно програмиране
Какво е това?
Екстремното програмиране е вид гъвкава методология, която вярва в кратките цикли на разработка. Проектът е разделен на прости инженерни задачи. Програмистите кодират прост софтуер и се връщат към клиента за обратна връзка. Revт.е. точките от клиента се включват и разработчиците продължават със следващата задача.
В екстремното програмиране разработчиците обикновено работят по двойки.
Екстремно програмиране се използва на места, където изискванията на клиентите се променят постоянно.
Какъв е подходът за тестване?
Екстремното програмиране следва разработка, управлявана от тестове, която е описана по следния начин –
- Добавяне на Тестов случай към тестовия пакет, за да се провери новата функционалност, която все още не е разработена
- Изпълнете всички тестове и очевидно добавеният нов тестов случай трябва да се провали, тъй като функционалността все още не е кодирана
- Напишете някакъв код, за да приложите функцията/функционалността
- Стартирайте тестовия пакет отново. Този път новият тестов случай трябва да премине, тъй като функционално е кодиран
| Предимства | Недостатъци |
|---|---|
| Клиентите, които имат неясен софтуерен дизайн, биха могли да използват екстремно програмиране | Срещите между екипа за разработка на софтуер и клиенти увеличават изискванията за време. |
| Непрекъснатото тестване и непрекъснатото интегриране на малки версии гарантират, че доставяният софтуерен код е с високо качество |
V-модел и спирален модел
В повечето проекти се появяват още два модела, които допълват картината, защото всеки от тях отговаря на слабост на водопадния подход по различен начин.
V-модел. Често наричан верификация и валидиране, V-моделът свързва всяка фаза на разработка със съответна тестова фаза, изобразена като двете рамена на V. Изискванията се свързват с приемателни тестове, дизайнът на високо ниво със системно тестване, дизайнът на ниско ниво с интеграционно тестване и кодирането с модулно тестване. Ценността е, че тестовият дизайн започва успоредно с всяка фаза на разработка, а не след кодирането, така че двусмислените изисквания се откриват от човека, който пише приемателните тестове, месеци преди да може да бъде изграден дефект. Слабостта му е наследена от каскадния модел: моделът все още приема, че изискванията са стабилни.
Спирален модел. Спиралата обгръща итерацията около изричен анализ на риска. Всеки цикъл съдържа четири дейности: определяне на цели, идентифициране и разрешаване на рискове, разработване и тестване, след което планиране на следващата итерация. Следователно тестването се концентрира там, където рискът е най-висок, вместо да се разпределя равномерно. То е подходящо за големи, скъпи, дългосрочни програми, като например аерокосмически или банкови основни системи, където цената на закъснялото откриване е висока. За малък уеб проект разходите за формален анализ на риска за всеки цикъл рядко са оправдани.
И двата модела са разположени между каскадната дисциплина и гъвкавата реакция. Където честотата на освобождаване е по-важна от всеки от двата, a DevOps Пайплайнът (pipeline) измества тестването в непрекъсната интеграция, така че всеки commit се проверява автоматично.
Коя софтуерна методология да избера?
Има тонове налични методологии за разработка на софтуер и съответното му тестване. Всяка техника и методология за тестване е предназначена за конкретна цел и има своите относителни предимства и недостатъци.
Изборът на конкретна методология зависи от много фактори като естеството на проекта, изискванията на клиента, графика на проекта и др.
От гледна точка на тестване, някои методологии настояват за тестване на входящи данни в началото на жизнения цикъл на разработката, докато други чакат, докато бъде готов работещ модел на системата.
Как да настроите методологии за тестване на софтуер?
Методологиите за тестване на софтуер не трябва да се създават само в името на тестването на софтуерния код. Трябва да се разгледа общата картина и основната цел на проекта трябва да бъде удовлетворена от методологията за тестване. Обърнете се към този списък с уважавани доставчици на услуги за тестване на софтуер които могат да ви помогнат да създадете ефективни стратегии за тестване, съобразени с целите на вашия проект.
Scheduling
Реалистичният график е ключът към прилагането на успешна методология за тестване и графикът трябва да отговаря на нуждите на всеки член на екипа.
Дефинирани резултати
За да поддържате всички членове на екипа на една и съща страница, трябва да се предоставят добре дефинирани резултати. Резултатите трябва да съдържат пряко съдържание без никаква неяснота.
Тестови подход
След като планирането е завършено и дефинираните резултати са предоставени, екипът за тестване трябва да може да формулира правилния подход за тестване. Дефиниционните документи и срещите на разработчиците трябва да посочват на екипа най-добрия тестов подход, който може да се използва за проекта.
Докладване
Прозрачното отчитане е много трудно постижимо, но тази стъпка определя ефективността на подхода за тестване, използван в проекта.
