Меню

Как да извършите тестване на софтуерни продукти - подробен процес и методи с примери

how perform software product testing detailed process

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

Софтуерните продукти се нуждаят от собствен уникален подход, за да тестват адекватно и правилно. Често пъти екипите ги третират като всеки друг софтуер (т.е. вътрешни приложения, създадени за конкретен клиент или екип; недостъпни за широката публика; не генериращи приходи) и това е началната точка на проблема.

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

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

Как да тествате продукти

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

Предизвикателства при разработването на софтуерни продукти:

Ето някои от предизвикателствата, пред които са изправени екипите за разработка на софтуерни продукти:

# 1)Липса на контрол върху потребителските демографски данни, устройства, среди, платформи и т.н. : Софтуерните продукти, за разлика от софтуера, създаден за конкретни заинтересовани страни, не се използват в контролирани и предвидими ситуации. Има много твърде много фактори, за да се вземат предвид.

# две)Мъглява продуктова визия : Поведението и характеристиките на продукта се променят завинаги и пътят до зрялост не се вижда ясно. Или продуктът расте твърде бързо, че излиза извън контрол, че екипите не знаят какво се случва.

# 3)Агресивни срокове : Поради силната конкуренция на пазара на софтуерни продукти нещата трябва да се развиват с бясна скорост и екипите трябва да останат на крачка пред своите връстници. В противен случай те със сигурност ще загубят от конкуренцията.

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

# 5)Липса на полезна обратна връзка: Тъй като няма заинтересовани страни или бизнес потребители или клиенти, така да се каже, е трудно да се разбере какво може или не може да се хареса на крайния потребител. Компаниите непрекъснато играят игра за отгатване и често имат затруднения да преодолеят разликата между това, което искат за софтуера, и това, което клиентът иска.

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

За да напреднете в играта, този тип тестване трябва да вземе предвид пет ключови точки:

  • Скорост на разработка и издания
  • Краткосрочни и дългосрочни продуктови цели на продукта
  • Обхват и характер на конкуренцията
  • Целева аудитория и тяхната среда
  • Изисквания - Функционалност, производителност, сигурност, използваемост, конфигурация и др.

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

жизнен цикъл на продукта

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

Прочетете също => Как да напиша добър документ за стратегия за тестване

Пример: Продуктът на компанията XYZ е софтуер за проследяване на дефекти, наречен „TrackFast“. Това е нов продукт и първата версия е готова да бъде пусната като облачно и локално решение. TrackFast работи като всяка друга система за управление на дефекти и е създадена както за мобилен, така и за уеб достъп. В момента има 2 до 4-седмични спринтове, при които продуктът се създава на части. Вие сте в екипа за тестване, който тества „TrackFast“, преди да се срещне с клиентите си. Тестването включва проверка на функционалност, производителност и сигурност.

въпроси и отговори за интервю за тестване на etl pdf

За да обобщим, това са параметрите, с които работите. Или ако предпочитате, това е вашият контекст

параметрите

Нека да видим как да тестваме на всеки етап. Това е продукт тест процес, метод или жизнен цикъл на всеки етап.

Етап # 1) Въведение в продукта

Тъй като за първи път TrackFast излиза на пазара, идеята е да се направи добро първо впечатление. Така че не оставяйте камък на камък. Тествайте всичко и от всеки ъгъл. В допълнение към това, поставете основата за бъдещи тестове.

Добрата тестова стратегия в този момент трябва да включва следното:

  • Тестове, които потвърждават краткосрочните цели на TrackFast. „Какво е необходимо, за да бъде изпратен правилно“, трябва да бъде в челните редици на усилията за тестване. Създайте Тестове от край до край (преден край, междинен софтуер и бекенд) за задълбочено тестване на всяка функция
  • Тестове, които сравняват TrackFast с конкуренцията (в идеалния случай това е работа на собствениците на продукти, но като тестер можем да добавим нашите два цента. Също така, тази стъпка е по-лесна, ако софтуерът вече има връстници. Например: Лесно е да сравните TrackFast с Bugzilla или JIRA или други наследени системи . Но нека кажем, че създавам приложение, което прави нещо необичайно, като например да може да се предскаже кога бебето е гладно или капризно :), може да е трудно да се намери приложение, което да използвате като базова линия)
  • Платформа, браузър и устройство тестове за съвместимост
  • Тестове за лесна инсталация , настройка и ускоряване
  • Тестове за производителност, сигурност и използваемост
  • Тестове за интеграция ако има връзка с други системи. Прост пример за интеграция е, че системите за проследяване на дефекти често взаимодействат с имейл клиенти, за да изпращат известия
  • План за регресия - Добра идея е да маркирате или маркирате критични тестове, които смятате, че ще бъдат част от бъдещите цикли на регресия и да помислите за автоматизирането им за бъдещи издания
  • План за известни проблеми (ще ги добавяте ли към изоставането или ще ги обработвате като CR и т.н.)
  • Гъвкавост за промяна, когато продуктът премине към следващия етап от жизнения цикъл.

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

На този етап, въпреки че има част от продукта, готова в края на 2-4 седмични спринтове, най-често всеки спринт не води до изпращане на код. Ето защо, никога не смятайте последното тестване на спринта „готово и доставено“. Повтаряйте критичните тестове с всеки спринт до пускане. С всеки спринт тествайте целия продукт, който имате до този момент.

Етап # 2) Растеж на продукта

След първоначалното въвеждане на проекта, ако всичко върви добре, очаквайте прилив на активност, защото Product Growth е бърза лента. Сега плувате заедно с големите акули и освен ако не продължите, ще се потрошите.

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

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

Те могат да помогнат:

  • Имайте предвид дългосрочните цели на проекта. Не става въпрос за преодоляване с сега. Става въпрос за живот с характеристиките и процъфтяване с тях.
  • Тествайте рано- Помислете за TDD или BDD вместо да отлагате тестването до края с нови изисквания
  • Автоматизирайте регресията и я укрепете - Създайте автоматизиран регресионен пакет на място, за да не останете с непроверени наземни мини във вашата система
  • Ако собствениците на вашия бизнес / продукт искат да се включат в тестването, помислете за инструмент за автоматизация, базиран на бизнес език, като Cucumber.
  • Запазете използваемостта и дизайнът на сайта е от основно значение за вашето тестване. Тъй като колкото повече функции добавяме, толкова по-чист трябва да изглежда сайтът
  • Извършвайте тестване на производителността и сигурността, когато се е случило голямо издание или е направена значителна промяна в архитектурата. (Въведен е нов сървър и т.н.) Повечето софтуерни системи не се нуждаят от това при всяко издание.
  • Поддържайте връзка с конкуренцията и познавайте визията на продукта
  • Адаптирайте тестване на двойки , за незабавна обратна връзка и фиксиране. Включете собственика на продукта, когато е възможно
  • План за промени и известни проблеми
  • Опитайте се да се възползвате от отзивите на клиентите и да проверите дали те могат да бъдат проследени като предложение за подобрение, за да запазите постоянния растеж. (още веднъж, това не е основната отговорност на екипа за осигуряване на качеството, но всички се броят)

Етап # 3) Зрялост на продукта

Поздравления, че вашият продукт стигна дотук. В този момент функциите не се променят толкова често. Екипът на продуктите ще бъде по-фокусиран върху привличането на повече бизнес или техните маркетингови усилия. Разработването и тестването на продукти обаче не е необходимо и често не спира.

Следователно екипът за тестване може:

  • Работете върху съзряването на вашата тестова стратегия. Към този момент вашите пакети за регресия, методи за проектиране на тестове и практики за управление на тестове трябва да работят като добре смазани машини.
  • Съсредоточете се върху по-фините детайли. Тъй като като цяло продуктът работи и се справя добре, но както се казва- „ Бог е в детайлите - намерете дори най-малкия от проблемите, които могат да подобрят качеството на системата
  • Помислете за обратна връзка с клиентите
  • Тествайте периодично производителността и сигурността
  • Вземете под внимание новите устройства, платформи и браузъри, които може да са излезли на пазара от последното тестване
  • Тествайте ръководството за потребителя и страниците с често задавани въпроси, защото вече имате време и можете да си позволите.
  • Експериментирайте с нови инструменти за тестване на продукти, услуги или процес, защото сега можете.
  • Тествайте процеса на инсталиране с всяко издание, колкото и малко да е това, и вземете статистика за това колко лесно или трудно е за крайния потребител.

Каквото и да правите, не се задоволявайте.

Етап # 4) Спад на продукта / Кръг обратно към растежа на продукта

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

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

TrackFast също трябва да се развива. След като докаже, че е надеждна и ефективна система за проследяване на дефекти, тя трябва да се развие или да отпадне. Така че компанията XYZ решава да подобри TrackFast, като го направи обща система за продажба на билети, която може да се използва за проследяване на всякакви инциденти или случаи от страна на бизнеса, различни от ИТ / тестови екипи (нещо като JIRA), а не само за дефекти в процеса на разработване на софтуер .

Колелото направи пълен завой и се озовавате, че третирате системата като чисто нова и следвате стратегията, която обсъдихме в раздела за въвеждане на продукта. Едва сега сте по-опитни и запознати с тренировката. Но помнете, с всеки нов завой идва и ново предизвикателство. Така че останете остри :)

Какво ви прави успешен тестер за продукти?

  • Тестери на продукти трябва да притежава остър бизнес смисъл, разбиране на моделите за бърза доставка и трябва да бъде изпитател на асо които не се страхуват да експериментират с инструменти и да станат малко програмисти, ако е необходимо. Тези неща могат да имат положително въздействие върху всякакъв вид тестване, но са абсолютно необходими при този тип тестване.
  • Друго важно качество е, че a продукт тестер трябва да вярва в продукта и искрено искам да успее. Когато аз като изпитател си мисля, че софтуерът е пълен боклук, малко е надеждата, че ще направя нещо, за да го направя по-добър.
  • Споделете визията на собственика на продукта / бизнеса . Освен ако не знаете къде отива продуктът и как ще се развива, тестването ще бъде супер ограничено.
  • Междуфункционалните умения са от полза - Знаете как да тествате DB, как да вземете критерии за производителност, как да активирате сертификати за сигурност, как да разположите и т.н. Бъдете любопитни и изследвайте .
  • Не задавайте граници - не мислете, че оценяването на ръководството за потребителя или проверката на често задаваните въпроси не е ваша работа и технически писател трябва да се погрижи за това. Е, трябва и ще го направят. Но когато гледате на него като на вътрешен човек като на човек, който познава продукта отвътре, отзивите ви са супер полезни.
  • Потърсете обратна връзка с крайния потребител. Следващият голям набор от хора, които тестват след вас, са потребителите в реално време. Знаете и разбирайте с какви проблеми се сблъскват. Това ви помага да подобрите своя дизайн на теста, така че следващия път да знаете какво да правите, за да ги избегнете тези проблеми.
  • Работете бързо и бъдете взимащи решения
  • Избягвайте технически дълг . В ситуация на бързо разработване и тестване е лесно да се тества изключително експлораторно и да се разхлаби референтната рамка за бъдещите версии. Не позволявайте това да се случи. Поддържайте скелетна документация, за да можете да проследявате, проследявате и измервате

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

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

спокойни уеб услуги интервю въпроси и отговори за опитни в Java

За автора: Тази статия е публикувана от член на екипа на STH Swati S.

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

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

^