Меню

Точна разлика между проверката и проверката с примери

  • Основен
  • Други
  • Точна разлика между проверката и проверката с примери

exact difference between verification

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

Проверка срещу проверка: Разгледайте разликите с примери

Това е обратно към основите хора! Класически поглед към разликата между Проверка и валидиране .

В света на тестването на софтуер има много объркване и дебати около тези термини.

В тази статия ще видим какво представляват проверката и валидирането от гледна точка на софтуерното тестване. До края на тази статия ще получим разликата между различните термини.

Разлика между проверка и проверка

Следват някои от важните причини да разберете разликата:

  1. Това е фундаментална концепция за осигуряване на качеството, поради което е почти градивният елемент за това да бъдете запознат с качеството.
  2. Това е често задавано Въпрос за интервю за софтуерно тестване .
  3. Сертифициране учебната програма има голям брой глави, въртящи се около това.
  4. И накрая, и на практика, тъй като ние тестерите изпълняваме и двата вида тестване, може и да сме експерти в това.

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

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

В контекста на тестването „ Проверка и валидиране ”Са двата широко и често използвани термина. В повечето случаи считаме и двата термина за еднакви, но всъщност тези термини са доста различни.

Има два аспекта на задачите за V&V (Verification & Validation):

  • Потвърждава изискванията (Изглед на производителя за качеството)
  • Годен за употреба (изглед на потребителите за качество)

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

Когато изпълняваме V&V задачите, трябва да се концентрираме и върху двете гледни точки за качество.

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

Забележка: Тези определения са, както се споменава в CSTE CBOK на QAI (вижте тази връзка, за да научите повече за CSTE).

Какво е проверка?

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

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

Сега въпросът тук е: Какви са посредническите или посредническите продукти?

Е, те могат да включват документите, които са създадени по време на фазите на разработка, като спецификация на изискванията, проектни документи, дизайн на таблица на база данни, ER диаграми, тестови случаи, матрица за проследяване и т.н.

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

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

Къде се извършва проверка?

Специфични за ИТ проектите, са някои от областите (трябва да подчертая, че това не е всичко), в които се извършва проверка.

Ситуация за проверкаАктьориОпределениеИзход
Преглед на документацията за теста (партньорска проверка)Членове на QA екипаПартньорска проверка е мястото, където членовете на екипа преглеждат работата на другия, за да се уверят, че няма грешки в самата документация.Тестова документация, готова за споделяне с външните екипи.
Преглед на бизнес / функционални изискванияРазработващ екип / клиент за бизнес изисквания.Това е необходима стъпка, за да се уверите не само, че изискванията са събрани и / или правилно, но и да се уверите дали са осъществими или не.Финализирани изисквания, които са готови да бъдат използвани от следващата стъпка - дизайн.
Преглед на дизайнаЕкип за разработчициСлед създаването на дизайна, екипът на Dev го преглежда щателно, за да се увери, че функционалните изисквания могат да бъдат изпълнени чрез предложения дизайн.Дизайнът е готов за внедряване в ИТ система.
Упътване за кодаИндивидуален разработчикВеднъж написаният код се преглежда, за да се идентифицират всякакви синтактични грешки. Това е по-небрежно по характер и се извършва от отделния разработчик по кода, разработен от самия него.Код готов за модулно тестване.
Инспекция на кодаЕкип за разработчициТова е по-официална настройка. Експерти и разработчици на темата проверяват кода, за да се уверят, че е в съответствие с бизнес и функционалните цели, насочени към софтуера.Код готов за тестване.
Преглед на плана за изпитване (вътрешен за екипа за осигуряване на качеството)QA екипЕкипът за проверка на качеството проверява вътрешно плана за тестване, за да се увери, че е точен и пълен.Документ за план за изпитване, готов за споделяне с външните екипи (Управление на проекти, Бизнес анализ, разработка, Околна среда, клиент и др.)
Преглед на тестовия план (външен)Ръководител на проекти, бизнес анализатор и разработчик.Официален анализ на документа за тестовия план, за да се уверите, че графикът и други съображения на екипа за осигуряване на качеството са в съответствие с останалите екипи и целия проект.Подписан или одобрен документ за план за изпитване, въз основа на който ще се основава тестовата дейност.
Окончателен преглед на тестовата документацияБизнес анализатор и екип за разработка.Преглед на тестовата документация, за да се увери, че тестовите случаи обхващат всички бизнес условия и функционални елементи на системата.Тестова документация, готова за изпълнение.

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

Какво е валидиране?

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

Валидирането е всички форми на тестване, което включва работа с продукта и пускането му на тест.

По-долу са дадени техниките за валидиране:

Валидирането физически гарантира, че системата работи съгласно план, като изпълнява функциите на системата чрез поредица от тестове, които могат да бъдат наблюдавани и оценени.

Достатъчно честно, нали? Ето моите два цента:

Когато се опитвам да се справя с тази V&V концепция в моя клас, има много объркване около нея. Един прост, дребен пример изглежда решава цялото объркване. Донякъде е глупаво, но наистина работи.

Примери за проверка и проверка

Пример от реалния живот :Представете си, че отивате в ресторант / вечеря и си поръчвате може би палачинки с боровинки. Когато сервитьорът / сервитьорката изведе вашата поръчка, как можете да разберете, че излязлата храна е според вашата поръчка?

Първите неща са, че го разглеждаме и забелязваме следните неща:

най-добрите сайтове за гледане на аниме
  • Прилича ли храната на това, което обикновено изглежда палачинките?
  • Трябва ли да се видят боровинките?
  • Миришат ли добре?

Може би и повече, но разбирате ли същността?

От друга страна, когато трябва да сте абсолютно сигурни дали храната е такава, каквато сте очаквали: ще трябва да я изядете.

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

В този контекст не мога да си помогна, но се връщам към CSTE CBOK справка. Има едно прекрасно изявление, което ни помага да донесем тази концепция у дома.

Проверката отговаря на въпроса „Създадохме ли правилната система?“ докато валидирането се обръща: „Създадохме ли системата правилно?“

V&V в различни фази на жизнения цикъл на разработката

Проверката и валидирането се извършват във всяка от фазите на жизнения цикъл на разработката.

Нека се опитаме да ги разгледаме.

# 1) V & V задачи - Планиране

  • Проверка на договора.
  • Оценка на концепцията.
  • Извършване на анализ на риска.

# 2) V & V задачи - Фаза на изискване

  • Оценка на софтуерните изисквания.
  • Оценка / анализ на интерфейсите.
  • Генериране на план за тестване на системите.
  • Генериране на план за изпитване за приемане.

# 3) V&V задачи - Фаза на проектиране

  • Оценка на софтуерния дизайн.
  • Оценка / анализ на интерфейсите (UI).
  • Генериране на тестов план за интеграция.
  • Генериране на план за изпитване на компоненти.
  • Генериране на тестов дизайн.

# 4) V&V задачи - Фаза на изпълнение

  • Оценка на изходния код.
  • Оценка на документи.
  • Генериране на тестови случаи.
  • Генериране на процедурата за изпитване.
  • Изпълнение на тестови случаи на компоненти.

# 5) V&V задачи - Тестова фаза

  • Изпълнение на тестов случай на системи.
  • Изпълнение на теста за приемане.
  • Актуализиране на показателите за проследяване.
  • Анализ на риска

# 6) V&V задачи - Фаза на инсталиране и плащане

  • Одит на инсталацията и конфигурацията.
  • Последният тест на изграждането на кандидат за инсталация.
  • Генериране на окончателен протокол от изпитването.

# 7) V&V задачи - Фаза на експлоатация

  • Оценка на ново ограничение.
  • Оценка на предложената промяна.

# 8) V&V задачи - Фаза на поддръжка

  • Оценка на аномалиите.
  • Оценка на миграцията.
  • Оценка на характеристиките на повторния процес.
  • Оценка на предложената промяна.
  • Проверка на производствените проблеми.

Разлика между проверка и проверка

Проверка срещу проверка

ПроверкаПроверка
Оценява междинните продукти, за да провери дали отговаря на специфичните изисквания на конкретната фаза.Оценява крайния продукт, за да провери дали отговаря на бизнес нуждите.
Проверява дали продуктът е изграден съгласно определеното изискване и спецификацията на проекта.Той определя дали софтуерът е годен за употреба и отговаря ли на бизнес нуждите.
Проверява „Правилно ли изграждаме продукта“?Проверява „Изграждаме ли правилния продукт“?
Това се прави без изпълнение на софтуера.Приключва с изпълнението на софтуера.
Включва всички техники за статично тестване.Включва всички техники за динамично тестване.
Примерите включват рецензии, проверка и инструкции.Примерът включва всички видове тестове като дим, регресия, функционалност, системи и UAT.

Различни стандарти

ISO / IEC 12207: 2008

Дейности по проверкаДейности по валидиране
Проверката на изискванията включва преглед на изискванията.Подгответе документите за тестовите изисквания, тестовите случаи и други спецификации на теста, за да анализирате резултатите от теста.
Проверката на проекта включва прегледи на всички проектни документи, включително HLD и LDD.Оценете дали тези изисквания за изпитване, тестови случаи и други спецификации отразяват изискванията и са годни за употреба.
Проверката на кода включва преглед на кода.Тест за гранични стойности, напрежение и функционалности.
Проверка на документацията е проверка на ръководства за потребителя и други свързани документи.Тест за съобщения за грешки и в случай на грешка приложението се прекратява изящно. Тества, че софтуерът отговаря на бизнес изискванията и е годен за употреба.

CMMI:

Проверката и валидирането са две различни KPA на ниво зрелост 3

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

IEEE 1012:

Целите на тези тестови дейности са:

  • Улеснява ранното откриване и коригиране на грешки.
  • Насърчава и подобрява управленската намеса в процеса и продуктовите рискове.
  • Осигурява поддържащи мерки за процеса на жизнения цикъл на софтуера, за да се подобри спазването на графика и изискванията за бюджет.

Кога да използвам Проверка и Проверка?

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

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

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

Валидиране или потвърждение на UAT?

UAT (User Acceptance Testing) трябва да се счита за валидиране. Това е валидирането в реално време на системата или приложението, което се извършва от действителните потребители, които валидират дали системата е „годна за употреба“.

Заключение

V&V процесите определят дали продуктите от дадена дейност отговарят на изискванията и годни ли са за неговото използване.

И накрая, следва да отбележим няколко неща:

  1. С много по-прости думи (за да се избегне всякакъв вид объркване), ние просто помним, че Verification означава дейности за преглед или статични техники за тестване, а валидирането означава действителни дейности за изпълнение на теста или техники за динамично тестване.
  2. Проверката може или не може да включва самия продукт. Валидирането определено се нуждае от продукта. Понякога може да се извърши проверка на документите, които представляват окончателната система.
  3. Проверката и валидирането не е задължително да се извършват от тестерите. Както виждате по-горе в тази статия, някои от тях се изпълняват от разработчиците и други екипи.

Това е всичко, което трябва да знаете за проверката и валидирането, за да бъдете МСП (експерти по предмета) по въпроса.

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

^