what do clients really expect from software testers
В днешната статия ще споделя някои мисли за това, което вярвам, че клиентите ИСТИНСКО очакват от нас въз основа на моя опит от първа ръка, работещ в клиентски локации с ежедневни взаимодействия лице в лице и сътрудничи офшорни чрез имейли или телефонни обаждания.
ИТ услугите са важна и неразделна част от софтуерната индустрия и удовлетвореността на клиентите е важна за успеха. Всеки клиент / организация може да е различен в процеса си, може да следва различен протокол и може да се занимава с различен тип бизнес.
Но следните фактори са общи и имат значение за всички като цяло.
[изображение src ]
Какво ще научите:
- 5 неща, които клиентът очаква от софтуерните тестери:
- # 1) Полза от разходите
- # 2) Качество на работа
- # 3) Разбиране на бизнеса
- # 4) Наличност
- # 5) Обхват на подобрението
- Заключение
- Препоръчително четене
5 неща, които клиентът очаква от софтуерните тестери:
# 1) Полза от разходите
Когато мислите да продадете или купите нещо, цената играе важна роля и често е един от важните решаващи фактори. Не чакаме ли всички с нетърпение Черния петък, продажбата на Flipkart Billion Day или страхотния фестивал за пазаруване на Amazon? Ставаме луди купувачи по време на разпродажба. Това е просто човешко поведение да очакваме правилната или допълнителна стойност за нашите пари.
Компаниите и клиентите не са различни. Ползите от разходите засилват отношенията между клиентите и обслужването и не е необичайно сервизните компании да губят оферти поради по-ниско котиране на конкуренти.
ГОЛЕМИЯТ въпрос сега е: Как можем да покажем ползи за разходите на нашите клиенти?
Тези точки могат да помогнат:
- Покажете им стойността на парите им . Обосновете и предоставете подкрепящи доказателства за вашия оценки .
- Помислете за креативни начини да спестите от разходи.
- Приспособете вашата оферта. Вместо да се придържате към стандартния си процес, който струва X пари, предоставете по-евтини алтернативи. Например : Предложете тестване на критичен път вместо цялостно тестване на системата.
- Познайте конкуренцията си . Бърза проверка на реалността на това, което други сервизни компании предлагат на своите клиенти на какви разходи е важно, за да запазите пазара на вашия модел на ценообразуване актуален.
# 2) Качество на работа
Качеството и количеството работа са две много различни неща.
Отминаха дните, когато броят на създадените тестови случаи или докладвани дефекти, използвани за показатели за производителност или качество. Вече не.
Ситуацията е по-скоро като изображението по-долу:
А) Знайте кога да кажете „НЕ“
Всички сме били на места, където сме работили извънредно, дежурили сме през почивните дни, присъствали сме късно вечер или рано сутрин и т.н. Обаче това, което не осъзнаваме, е, че можем да кажем НЕ, ако нещата продължават да се влошават. Казвайки НЕ е единственият начин да запазим качеството на работата и здравия си разум непокътнати.
Когато правите това, предварително изразете загрижеността си и се застъпвайте за качеството.
Ето ситуация, в която попаднах и това може да ви даде по-добра представа за какво говоря:
Моята компания спечели ново лого и като част от миграцията от стара компания към моята компания бяха планирани сесии за трансфер на знания. Ние, екип от 6 членове, пътувахме до сайта на клиента. Още първия ден след въвеждането ни споделихме плана KT. Открих, че името ми е маркирано срещу множество модули. Един от тези модули трябваше да е напълно извън обхвата ми, защото дори не бях наясно с тази технология; това по никакъв начин не съвпадаше с моите умения.
Отидох до ръководството за преход на знанието и му казах ситуацията -
- Бяха ми възложени твърде много работни елементи, което от своя страна ще попречи на качеството и способността ми да улавя 100% в сесиите.
- Планираните елементи имаха области, в които уменията ми няма да съвпадат и тъй като не бях подходяща, може да не разбера 100% по време на прехода.
Оловото разбра проблема и преразгледа плана на КТ.
безплатна проверка на граматиката по-добре от граматиката
Надявам се, че това помага да се потвърди, че: Ако нещо е в нашата чиния, това не означава, че трябва да ядем всичко. Особено не, ако това означава компромис с качеството.
Б) Пълнота на тестовия случай
Колко от вас са съгласни с мен, че ако се опитаме подобряване на начина, по който пишем тестови случаи , води до по-добро качество?
По-долу са дадени някои често срещани грешки, които са често срещани в повечето тестови случаи:
Компоненти за тестови случаи | Текущ проблем | Решение |
---|---|---|
Обективен | Целта е най-важната част от всеки тестов случай, това е, което прави всички тестови случаи различни. Често срещаните грешки на Objective липсват яснота. Както всички тестови случаи, създадени за една функционалност, имат една цел, без да показват как се различава всеки тестов случай. | Цел / Цел на всеки тестов случай трябва да бъде ясен, за да се обясни каква функционалност и какво условие на теста ще бъдат тествани като част от този тестов случай. Една и съща функционалност може да има положителни и отрицателни тестови случаи, така че целта трябва да е достатъчно ясна, за да покаже разликата. Добра идея е да се отнесе тестовият сценарий за определяне на целта. |
Предварителни условия | Много тестери напълно пропускат да споменат предварителното условие или много просто ще копират и поставят. Копирането поставя води до грешки, тъй като всеки тестов случай може да е напълно различен от друг. | Избягвайте грешки при копиране и поставяне и обърнете внимание на детайлите. |
Данни от теста | Това е може би най-пренебрегваното поле и в повечето тестови случаи ще бъде празно или липсва точна дефиниция | Споменете подходящите данни, които трябва да въведете. Понякога не е необходимо да е точно. Например: Потребителската регистрация може да регистрира потребител Анна или Джон и няма значение. Но определянето, че валидно име, което има всички знаци и трябва да е с дължина 4-10, може да помогне за изясняването на много неща. |
Идент. № на тестовия случай | Над опростената конвенция за именуване или номериране. Кажете, че тествате бутон за вход. Често идентификационните номера са: TC_1_Login TC_2_Login | Направете ги по-описателни: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Справочни документи | Несъвместимо копиране-поставяне от референтни документи или по-лошо, като се използва неправилен. | Винаги е препоръчително да се спомене правилният референтен документ с правилен номер на версията, да речем, че за някои тестови случаи биха били посочени FRS и Tech Specs, така че тестовият случай в справочния раздел трябва да споменава и двете. |
Стъпки на тестовия случай | Липсващи стъпки, най-вече от тестери, които познават приложението много добре. Те можеха да поемат нещата и да пропуснат да споменават стъпките. Това създава проблеми на бизнеса, рецензенти и нови тестери. | Трябва да се използват правилни стъпки и последователност. |
За да обобщим, ако малките детайли са взети под внимание във фазата на проектиране, тестовото качество на продукцията ще бъде много по-високо.
# 3) Разбиране на бизнеса
Това е един от най-важните фактори, които клиентите търсят в тестерите. Тъжно е обаче, че някои тестери вярват, че тяхната работа е да пишат тестови казуси въз основа на FRS и не полагат усилия да разберат бизнеса.
Опитайте се първо да познаете бизнеса и след това да разгледате функционалността; можеш представете нуждите на вашия клиент повече и тествайте съответно.
Ето пример- FRS гласи „XYZ доклад трябва да се генерира с 3 колони като Дата, Име и Състояние“. По-долу са тестовите случаи, с които ще се сблъскате, когато вземете това изискване по номинална стойност:
- Генерира се валидиращ отчет XYZ
- Отчетът за потвърждаване има 3 колони като Дата, Име, Състояние
- Проверете данните в 3 колони.
Но когато имате предвид бизнес приложимостта на този отчет, може да се наложи да тествате:
- Каква е бизнес целта на този доклад?
- Този отчет генерира ли се всеки ден?
- Кои са бизнес потребителите, които разглеждат този отчет?
- Какъв е източникът на данни за този отчет?
- Трябва ли отчетът да се генерира, ако няма налични данни?
Това е само един пример, но предполагам, че всички сме съгласни, че може да се постигне по-добро тестване чрез придобиване на бизнес информираност и опит.
# 4) Наличност
Независимо дали сте едно лице, което подкрепяте клиента или екип, наличността ви винаги трябва да се проверява ( ).
Под наличност това не означава денонощна поддръжка. Това просто означава ясна и предварителна комуникация за почивките, алтернативните планове и достъпа и липсата на МВР.
въпрос за интервю за тестване на софтуер и отговори за опитни
По-долу са някои от моделите, които индустрията на услугите следва:
- Модел за увеличаване на персонала - Ако работите по модел за увеличаване на персонала и сте единствен представител на вашата компания, препоръчително е клиентът да бъде информиран за вашите срокове на работа и планираните отсъствия, за да могат да се направят необходимите мерки.
- Модел на управлявани проекти - В модела на управляван проект, при който се сформират големи екипи от проекти и се оглавяват от ръководители на доставки / проекти, наличието на резервен план за ресурси вече не остава отговорност на клиентите. Нуждата на PM да управлява както планирани, така и непланирани почивки. В този модел е препоръчително премиерът да се опита да събере планираните данни за отсъствие от екипа си преди време и да се управлява по съответния начин. Има случаи, при които клиентите искат поддръжка през уикенда или удължено работно време. Такива случаи също трябва да се планират чрез ротация на ресурси. Екипът трябва да се състои от членове, които могат да си правят резервни копия, ако е необходимо. Планираните подробности трябва да бъдат споделени с клиента.
# 5) Обхват на подобрението
Това е желателно не само в софтуерната индустрия, но и навсякъде. Подобряването не е еднодневна работа. По обхвата на подобрението трябва да се работи непрекъснато и може да се раздели на 3 стъпки -
Прочетете също=> Как да подобрите своите умения за тестване и да победите конкуренцията
Стъпка 1: Идентифицирайте
Направете задълбочено проучване и идентифицирайте областите / обхвата за подобрения. Да речем, когато бъдете помолени да тествате една и съща функционалност няколко пъти, използвайки един и същ процес, ще дойде момент, в който ще почувствате, че или искате да излезете от проекта, или да промените начина, по който той е тестван. Ето как се внасят подобрения, когато ни отегчават съществуващите методи, мислим да се променяме и подобряваме .
Стъпка 2: Внесете подобрения
Ако нещата се правеха ръчно, можехте опитайте се да автоматизирате няколко неща . Когато казвам автоматизация, не винаги означава закупуване на автоматизиран инструмент.
Ще цитирам ситуация:
Бях част от екип за тестване на база данни. Ежедневната ни работа включваше стартиране на едни и същи SQL скриптове по няколко пъти на ден с различен набор от параметри. Когато стартирахме проекта, бяхме добре с тези стъпки, но в крайна сметка разбрахме системата по-добре и мислехме, че същите SQL скриптове могат да се изпълняват като част от съхранени процедури, вместо някой да актуализира ръчно параметрите и да изпълнява.
Стъпка # 3: Оценете подобрението
Всеки път, когато се приложи нов процес, ще трябва да се уверите, че той работи както се очаква и няма странични ефекти. Разширявайки по-ранния пример, въвеждане на съхранени процедури, проверете дали изходът от новосъздадения автоматизиран начин и изходът от ръчния начин са еднакви.
Другата част е да наблюдавате предимствата за определен период от време, за да сте абсолютно сигурни и да представите резултатите на клиентите си. В нашия проект показахме на клиентите намаляване на времето за изпълнение на теста с 30%, което от своя страна намали разходите.
Заключение
В заключение просто исках да спомена, че всеки от нас има вродени таланти и всички ние имаме свои уникални стилове на работа и това бяха само някои съвети, които според мен могат да предложат на нашите клиенти по-добро обслужване.
За автора: Тази страхотна статия е написана от член на екипа на STH Прия Р. Ако искате да пишете за нас и да споделите своя опит, моля уведомете ни тук .
Надявам се, че сте се насладили на четенето на тази статия и сте я намерили за информативна! Уведомете ни, ако имате различен опит, който да споделите.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Глобалният бизнес за тестване на софтуер скоро ще достигне $ 28,8 милиарда
- Съвети за тестване на софтуер за начинаещи тестери
- Тестване на софтуер QA Assistant Job
- Как да запазите мотивацията жива в софтуерните тестери?
- Дзен и изкуството на софтуерното тестване
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера