what do clients really expect from software testers
У данашњем чланку поделићу неке мисли о ономе што верујем да клијенти заиста очекују од нас на основу мог искуства из прве руке радећи на клијентским локацијама уз свакодневне интеракције лицем у лице и сарађује у мору путем е-поште или телефонских позива.
ИТ услуге су важан и саставни део софтверске индустрије и задовољство купаца је важно за успех. Сваки клијент / организација може бити другачији у свом процесу, може следити другачији протокол и може се бавити различитим врстама предузећа.
Али, следећи фактори су заједнички и важни су за све.
(слика срц )
Шта ћете научити:
- 5 ствари које клијент очекује од софтверских тестера:
- # 1) Трошковна корист
- # 2) Квалитет рада
- # 3) Разумевање посла
- # 4) Доступност
- # 5) Обим побољшања
- Закључак
- Препоручено читање
5 ствари које клијент очекује од софтверских тестера:
# 1) Трошковна корист
Када размишљате о продаји или куповини нечега, трошкови играју главну улогу и често су један од важних фактора одлучивања. Не чекамо ли сви са нестрпљењем Црни петак, распродају Флипкарт Биллион Даи или сјајни Амазонов шопинг фестивал? Постајемо луди купци током времена продаје. Једноставно је људско понашање очекивати праву или додатну вредност за наш новац.
Компаније и купци се не разликују. Трошковне користи појачавају односе са купцима и услугама и није ретко да сервисне компаније губе понуде због нижег цитирања конкурената.
ВЕЛИКО питање је сада: Како можемо својим купцима показати трошковне користи?
Ове тачке могу помоћи:
- Покажите им вредност новца . Оправдајте и пружите додатне доказе за своје Процене .
- Замислите креативне начине како уштедети на трошковима.
- Прилагодите своју понуду. Уместо да се придржавате свог стандардног процеса који кошта Кс износ новца, пружите јефтиније алтернативе. На пример : Предложите тестирање критичне путање уместо комплетног тестирања система.
- Знајте своју конкуренцију . Брза провера стварности шта друге услужне компаније нуде својим клијентима по којим трошковима је важна како би ваше тржиште модела цена било релевантно.
# 2) Квалитет рада
Квалитет и количина посла су две веома различите ствари.
Прошли су дани када се број створених тест случајева или пријављених недостатака користио у показатељима продуктивности или квалитета. Не више.
Ситуација је више слична слици испод:
А) Знајте када треба рећи „НЕ“
Сви смо били на местима где смо радили прековремено, дежурали преко викенда, присуствовали касним вечерњим или раним јутарњим позивима итд. Међутим, оно што не схватамо је да можемо рећи НЕ ако се ствари погоршавају. Реци НЕ је једини начин на који можемо одржати квалитет рада и здрав разум.
При томе унапред поднесите своју забринутост и заговарајте квалитет.
Ево ситуације у којој сам био и ово би вам могло дати бољу представу о чему говорим:
Моја компанија је освојила нови логотип и као део миграције са старе компаније на моју компанију планиране су сесије преноса знања. Ми, тим од 6 чланова, путовали смо на страницу клијента. Првог дана након увођења, поделили смо КТ план. Открио сам да је моје име означено са више модула. Један од тих модула требао је бити потпуно изван мог опсега, јер нисам ни био свестан те технологије; то се никако није поклапало са мојим вештинама.
Отишао сам до водича за прелазак знања и рекао му ситуацију -
- Додељено ми је превише радних предмета, што ће заузврат нарушити квалитет и моју способност да 100% забележим у сесијама.
- Планирани предмети су имали подручја у којима се моје вештине нису поклапале, а пошто нисам био у доброј форми, можда нисам разумео 100% током транзиције.
Водећи разумео проблем и ревидирао план КТ.
питања за интервју за посао аналитичара осигурања квалитета
Надам се да ово помаже у потврђивању следећег: Ако је нешто на нашем тањиру, то не значи да морамо све то да поједемо. Поготово не ако то значи компромитовање у погледу квалитета.
Б) Комплетност тест случаја
Колико се вас слаже са мном ако то покушамо побољшати начин писања тест случајева , води ка бољем квалитету?
Испод су неке уобичајене грешке које су честе у већини тест случајева:
Компоненте тест примера | Тренутни проблем | Решење |
---|---|---|
објективан | Циљ је најважнији део сваког тест случаја, то је оно што све тест случајеве чини различитим. Уобичајене грешке у објективу недостају јасноћа. Као и сви тест случајеви створени за једну функционалност имају један циљ без показивања како се сваки тест случај разликује. | Циљ / сврха сваког тест случаја треба да буде јасна да би се објаснило која функционалност и који услови теста ће се тестирати као део тог тест случаја. Иста функционалност може имати позитивне и негативне тест случајеве, тако да објектив мора бити довољно јасан да покаже разлику. Добра идеја је упутити тест сценарио за дефинисање циља. |
Предуслови | Многи тестери потпуно пропусте да помену предуслов или ће многи једноставно копирати и налепити. Лепљење копија доводи до грешака, јер се сваки тестни случај може потпуно разликовати од другог. | Избегавајте грешке при копирању и лепљењу и обратите пажњу на детаље. |
Тест подаци | Ово је вероватно највише превиђено поље и у већини тест случајева ће бити празно или му недостаје прецизна дефиниција | Наведите одговарајуће податке које треба унети. Понекад не мора бити тачно. На пример: Регистрација корисника може да региструје корисника Ану или Џона и то не би било важно. Али дефинисање да ваљано име које има све знакове и треба да буде дугачко 4-10 може помоћи у разјашњавању многих ствари. |
ИД тест случаја | Преко поједностављене конвенције именовања или нумерисања. Рецимо, тестирате дугме за пријаву. ИД су често: ТЦ_1_Логин ТЦ_2_Логин | Учините их описнијима: ТЦ_1_Логин_Инвалид_Усер ТЦ_2_Логин_Валид_Усер |
Референтни документи | Недоследно копирање-лепљење из референтних докумената или још горе, коришћење нетачног. | Увек је пожељно споменути тачан референтни документ са тачним бројем верзије, рецимо да би за неке тест случајеве били препоручени ФРС и Тецх Спецс, тако да би тест случај у референтном одељку требало да помене оба. |
Кораци за тест случајеве | Недостају кораци, углавном тестера који врло добро познају апликацију. Могли су да претпоставе ствари и прескоче помињање корака. То ствара проблеме предузећу, рецензентима и новим тестерима. | Треба користити одговарајуће кораке и редослед. |
Да резимирамо, ако се у фази дизајнирања узму у обзир мали детаљи, квалитет излазног теста биће много супериорнији.
# 3) Разумевање посла
Ово је један од најважнијих фактора који купци траже у тестерима. Међутим, тужно је што неки тестери верују да је њихов посао писање тест случајева на основу ФРС и не труде се да разумеју посао.
Покушајте прво да упознате посао, а затим погледајте функционалност; можете замислите потребе свог клијента више и тестирајте у складу с тим.
Ево примера- ФРС наводи да „КСИЗ извештај треба генерисати са 3 колоне као датум, име и статус“. Следе примери испитивања са којима ћете завршити када прихватите овај захтев као номиналну вредност:
- Генерише се извештај о потврди КСИЗ
- Извештај о потврди има 3 колоне као Датум, Име, Статус
- Потврдите податке у 3 колоне.
Али, ако имате на уму пословну применљивост овог извештаја, можда ћете морати да тестирате:
- Која је пословна сврха овог извештаја?
- Да ли се овај извештај генерише сваки дан?
- Ко су пословни корисници који гледају овај извештај?
- Који је извор података за овај извештај?
- Да ли треба да се генерише извештај ако нема података?
Ово је само један пример, али претпостављам да се сви слажемо да се боља тестирања могу постићи стицањем пословне свести и стручности.
# 4) Доступност
Без обзира да ли сте појединац који подржава купца или тим, увек треба проверити вашу доступност ( ).
Под доступношћу, то не значи 24/7 подршку. То само значи јасну и непосредну комуникацију о слободним временима, алтернативним плановима и недоступности и одласку у МУП.
Испод су неки од модела које индустрија услуга следи:
- Модел увећања особља - Ако радите на моделу повећања броја запослених и једини сте представник ваше компаније, саветује се да се купац упозна са вашим временима рада и планираним изостанцима како би се могли предузети неопходни договори.
- Модел управљаних пројеката - У управљаном пројектном моделу у којем се формирају велики пројектни тимови и којима руководе руководиоци испорука / пројеката, израда резервног плана ресурса више не остаје одговорност купаца. Потреба ПМ-а да управља и планирано и непланирано слободно време. У овом моделу је препоручљиво да премијер покуша да прикупи планиране податке о одсуству од свог тима пре времена и да се снађе у складу са тим. Постоје случајеви када купци захтевају подршку током викенда или продужено радно време. Такве случајеве такође треба планирати ротирањем ресурса. Тим би требало да се састоји од чланова који могу међусобно да праве резервне копије ако је потребно. Планиране детаље треба поделити са купцем.
# 5) Обим побољшања
Ово није пожељно само у софтверској индустрији већ и свуда. Доношење побољшања није једнодневни посао. На обиму побољшања мора се континуирано радити и може се поделити на 3 корака -
Такође прочитајте=> Како побољшати своје вештине тестирања и победити конкуренцију
Корак # 1: Идентификујте
Направите темељну студију и идентификујте подручја / опсег за побољшања. Рецимо, када се од вас затражи да исте функције тестирате неколико пута користећи исти поступак, доћи ће тренутак када ћете осетити да или желите да се иселите из пројекта или промените начин на који је тестиран. Тако се уводе побољшања када нам досаде наше постојеће методе, мислимо да се променимо и побољшамо .
Корак 2: Донесите побољшања
Да се ствари раде ручно, могли бисте покушајте да аутоматизујете неколико ствари . Кад кажем аутоматизација, то не значи увек куповину аутоматизованог алата.
Цитираћу ситуацију:
Био сам део тима за тестирање базе података. Наш свакодневни рад подразумевао је покретање истих СКЛ скрипти више пута дневно са различитим скупом параметара. Када смо започели пројекат, били смо добро са овим корацима, али на крају смо боље разумели систем и мислили смо да се исте СКЛ скрипте могу покретати као део ускладиштених процедура уместо да неко ручно ажурира параметре и извршава.
Корак # 3: Процените побољшање
Кад год се примени нови процес, мораћете да осигурате да функционише како се очекивало и да нема нежељених ефеката. Проширујући ранији пример, увођењем ускладиштених процедура, проверите да ли су излази из новоствореног аутоматизованог начина и излази са ручног начина исти.
Други део је надгледање користи током одређеног временског периода како бисте били потпуно сигурни и представили резултате својим клијентима. У нашем пројекту смо клијентима показали смањење времена извођења теста за 30% што је заузврат смањило трошкове.
Закључак
У закључку, само сам желео да напоменем да свако од нас има урођене таленте и да сви имамо своје јединствене стилове рада и ово су били само неки савети за које верујем да нашим клијентима могу понудити боље услужно искуство.
О аутору: Овај сјајни чланак написала је чланица СТХ тима Прииа Р. Ако желите да пишете за нас и поделите своје искуство, молимо вас обавестите нас овде .
иоутубе видео довнлоадер апликација за рачунаре
Надам се да сте уживали читајући овај чланак и да вам је информативан! Јавите нам ако имате другачије искуство за дељење.
Препоручено читање
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Глобално предузеће за тестирање софтвера ускоро ће достићи 28,8 милијарди долара
- Савети за тестирање софтвера за тестере почетнике
- Посао за КА помоћника за тестирање софтвера
- Како одржати мотивацију живом у тестерима софтвера?
- Зен и уметност тестирања софтвера
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Одабир тестирања софтвера за вашу каријеру