Меню

Какво е ранно тестване: Тествайте рано, тествайте често НО как? (Практическо ръководство)

what is early testing

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

Какво е ранно тестване?

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

Различните аспекти на Ранно тестване които биха помогнали на QA мениджърите и потенциалните клиенти, докато разработват или разработват документа за тестване на стратегията в SDLC, са обяснени тук.

Приемането на ранен тест ще доведе до изключително успешна доставка на качествен продукт.

ранно тестване (1)

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

въпроси и отговори на интервю за администратор на Salesforce pdf
  • Защо ранното тестване в SDLC (проект или издание на софтуер)?
  • Обхват на усилията за ранно тестване
    • Какво да тествате рано?
    • Старт и изход
  • Предимства и недостатъци

Нека сега разгледаме подробно нюансите !!

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

Принципи на тестване

Фигура 1 - Опростен изглед на принципите на тестване

1. Принципи на тестване

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

  • Какво е тестване?
  • Защо тестване?
  • Какво да тествате?
  • Как да тествате?

Въпреки това, някои от най-продължителните въпроси, които много читатели, тестери, потенциални клиенти и мениджъри на QA биха задали или биха искали да получат повече яснота относно включването (сива зона в Фигура 1 )

  • Кога да започне тестването в издание на софтуер или Кога трябва да започне тестването в проект?
  • Кога да започнем тестването и кога да спрем тестването?
  • Защо тестването трябва да започне рано в SDLC?
  • Какво е ранен тест в разработването на софтуер?

За по-лесно разбиране на публиката, събрах всички въпроси за „сивата зона“ под един чадър, наречен Ранно тестване.

Защо да тествате рано в SDLC?

Нека обсъдим някои събития и дейности, които са част от тестването.

Обикновено екипът за управление на програми назначава програмен мениджър (PM) към дадена версия на софтуер или проект. Премиерът в сътрудничество с всички заинтересовани страни, включително екипите за маркетинг, развитие, осигуряване на качеството и поддръжка, изготвя график за освобождаване

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

График за тестване на изданието на софтуера

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

Преобладаващо моделът Waterfall се използва за изпълнение на такива версии на софтуера. В някои случаи за по-кратък цикъл на освобождаване се възприема Agile / Scrum модел.

Фигура 2 - Типичен тримесечен график за тестване на изданията (не е цялостен график за проект или освобождаване)

Тримесечен график за тестване на изданията

Въздействие на критични или дефекти с висока степен на сериозност

Фигура 3 - Типично въздействие на критични дефекти

Типично въздействие на критични дефекти

Главно , по време на тестването се очаква, че

  • Критични дефекти или дефекти с висока степен на тежест се идентифицират и регистрират от тестерите.
  • Разработчиците ще трябва да отстранят тези дефекти.
  • Впоследствие тестерите ще трябва да проверят корекциите.

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

  • Времеемко
  • Намаляване на ресурсите (човек + машина)
  • Склонни към обезпечение, коригирането на критични грешки докосва предимно голяма част от кода, включително зоните на пресичане.

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

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

Какво ще кажете за другите дефекти?

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

Няма Silver Bullet

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

Обаче от „ Възможност за обслужване От гледна точка на модела на конкурентни и времеви пазари (TTM), е необходимо да се разбие типичното мислене, за да се открият максимални дефекти в началото на цикъла на освобождаване, особено идентифициране на критични и дефекти с висока степен на сериозност.

Всяко или всичко по-горе ще има отрицателно въздействие върху бизнеса на Организацията. В този контекст приемането на „ Ранно тестване 'Имам отделна тестова дейност ще бъде от полза за цялостното управление на SDLC за даден проект или издание.

Обхват на усилията за ранно тестване

След като разбрахте целта на ранното тестване в предишния раздел, озаглавен „ Защо ранното тестване? , Нека сега обсъдим „ Обхват на ранните тестови усилия ' подробно.

Тъй като въвеждаме Тестване на ранен етап като нова дейност, която да се проследява изключително по време на изпълнението на Тестване, препоръчително е да се практикува обхватът на усилията за тестване, както е обяснено по-долу

Предположение:

  • Целият график за издаване на проект или софтуер е одобрен и предоставен на всички заинтересовани страни.
  • Документът за цялостната стратегия за изпитване е разработен, прегледан и одобрен от всички заинтересовани страни.
  • Функциите с висок, среден и нисък приоритет, които ще бъдат тествани, са добре документирани.
  • Тестовите планове и тестовите случаи за всички функции се разработват, преглеждат и одобряват от всички заинтересовани страни.
  • Всички тестови планове и тестови случаи се качват в централно хранилище за проследяване на изпълнението на теста.
  • Всички човешки ресурси, инфраструктурно оборудване и инструменти са на разположение за настройка на тестовия (ите) етап (и) и изпълнение на планове за тестване.

Какво да тествате рано?

Фигура 4 - Цялостен подход към обхвата на ранното тестване

4. Какво да тествате в ранното тестване

Приближаване

  • Нека вземем Пример от версия XYZ с 3 функции с висок приоритет A, B и C, 10 функции със среден приоритет и 15 функции с малък (или нисък приоритет).
  • Характеристики с висок приоритет са тези, които генерират високи приходи и / или спазване на стандартите и / или догонване на конкурента и / или усъвършенстване на конкурента и всички тези.
  • Функциите с висок приоритет обикновено включват сложно кодиране, добавен е голям брой нови редове код.
  • Голям брой нови редове код също може да означава голяма вероятност от области на пресичане.
  • Обикновено функциите с висок приоритет и / или функции, които имат голям брой нови редове код, са най-добрите кандидати за ранно тестване.
  • Не е необходимо да има отделен план за изпитване, разработен за ранна тестова дейност.
  • QA потенциални клиенти или тестери, заедно с потенциалните клиенти за развитие или МСП (експерти по предметни въпроси) трябва да обсъдят и да се споразумеят за обхвата на кода / тестването за тази дейност на тестване.
  • Идентифицирайте подходящи тестови случаи с висок приоритет и дори някои тестови случаи със среден приоритет, ако смятате, че е необходимо от всеки от функциите Тестови планове A, B и C.
  • След като бъдат идентифицирани подходящите характеристики и подгрупа от тестови случаи, уверете се, че те се проследяват с помощта на инструмента за проследяване на тестове, приет от организацията.

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

Старт и изход при ранен тест

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

Критерии за влизане за старт

  • Процент на завършване на теста за интеграция
  • Брой отворени грешки
  • Няма блокери за стартиране на ранен тест

Фаза на активност

  • Проследяване на напредъка
  • Брой падания на кода по време на това тестване
  • Подход за отстраняване на грешки
  • Подход за проверка на грешки
  • Запишете резултатите от това тестване

Критерии за изход

  • Прехвърляне на дейности към следващата фаза на тестване (обикновено тестване на характеристики).
  • Разрешаване на неразрешени грешки, открити по време на ранния тест.
  • Разрешаване на блокери, ако има такива, за следващата фаза на тестване.
  • Публикувайте резултатите от ранното тестване.

Предимства и недостатъци

Всяка нова инициатива или дейност има своите достойнства и недостатъци.

Нека разгледаме плюсовете и минусите на този подход за тестване.

Професионалисти

  • Идеално подходящ за модела Waterfall.
  • Помага за разкриване на критични грешки в началото на тестовия цикъл.
  • Идентифициране на критични грешки в началото на цикъла на издаване.
  • Помага на екипа за разработка да стабилизира кодекса по-рано.
  • Помага за свеждане до минимум на обезпечението поради поправки на грешки.
  • Помага на екипа за разработка да идентифицира подробно уязвимостите в пресечните зони в началото на цикъла на пускане.
  • Мениджърският екип може да взема подходящи бизнес решения с надлежна проверка на неразрешени критични грешки в конкретното издание или проект.
  • Помага за удължаване покритие на теста и цикъл ефективно.
  • Помага за ефективно и ефективно разпределение на ресурсите за разработка и тестване.

Минуси

  • Не е идеално подходящ за Agile / Scrum модел. Такива модели обаче могат да приемат ранен тест в спринтове с подходящо ощипване.
  • Има шанс да се намали Тестване на интеграцията от екипа за разработка.

Заключение

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

Основни компоненти на Принципите на тестване като Защо да тестваме? Какво е тестване? Какво да тествате? Как да тествате? са предимно добре дефинирани и разбрани. Въпреки това, има някои дълготрайни въпроси, които продължават да се подпират в съзнанието на читателите, тестерите, потенциалните клиенти и мениджърите по понятия като Ранно тестване.

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

Осъзнавали ли сте някога важността на ранното тестване в кариерата си? Чувствайте се свободни да споделите вашите мисли и опит в раздела за коментари по-долу !!

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

^