how tester can think
Сцена : В ресторант пристигна 3-членно семейство - родители и малко дете. След като поръча най-любимата пица, семейството се отпускаше и малкото дете започна да си играе с клечките, положени на масата. Хареса ги и реши да яде вечерята си само с клечки.
Той обяви желанието си и родителите, заети с разговори, се съгласиха. Когато пицата беше поднесена, малчуганът започна да използва пръчици за хранене и няколко пъти не успяваше да вземе пицата в устата си. Изведнъж родителите го забелязаха и наредиха на малкото дете да не използва клечки. Малкото дете не убеждава, тъй като родителите вече са се съгласили по-рано с желанието му.Когато родителите започнаха да учат за ядене на пица само с нож и вилица, малкото дете постави под съмнение вярата, но аз искам да я ям само с клечки и защо не е наред? И докато използваше пръчици, когато не можеше да яде любимата си пица, той нетърпеше и в крайна сметка изхвърли клечките и реши да не яде и пица. Родителите, също разочаровани, не можеха да направят нищо и времето за семейна вечеря се оказа най-лошото време за деня.
Сега заменете някои думи в горния параграф, както следва, и премислете отново:
Родители: Екип за управление на проекти, включващ бизнес анализатор, продавач, мениджър разработки и архитектурен екип.
Малко дете: Клиент / краен потребител
Пица: продукт / приложение
Клечки: грешка
Най-любимото приложение е само любимо, докато потребителят не направи грешка и не види най-лошото поведение на приложението. Веднъж опитен, потребителят никога не се връща към приложението. И затова като тестер е много необходимо да се разбере мислене на потребителя , как се очаква да се държи, какво грешно може да направи с приложението, каква може да е най-лошата грешка и много други.
Повечето пъти ме питаха във форуми, както и от вътрешни членове на екипа за това как да възпроизведа потребителския опит при тестване. Моят отговор винаги е бил прост - Бъдете потребител :)
Въпреки че е лесно да се каже, отколкото да се внедри, е подходящият момент индустрията за тестване на софтуер да премине в посоката на революцията, където потребителският опит и обратната връзка са по-важни от всичко друго.
Как изпитателят може да мисли като краен потребител?
Представям тук някои типични примери за поведение като краен потребител и намиране на изненади , Наблюдавах през последните няколко дни:
# 1) Докато тестваше поле за дата, когато потребителят избра или въведе ръчно стойността на датата, то работи добре. Но когато потребителят в крайна сметка въведе напълно неправилна стойност като 12/00 // и щракна върху OK, той получи съобщение за грешка относно невалидна стойност на датата.
Сега потребителят не коригира датата, но опреснява страницата. Какво трябва да се случи? Е, много от вас могат да познаят какво трябва да се случи, но можете ли да се сетите какво се е случило с приложението? След опресняване на страницата на потребител беше представено следното и същата стойност беше запазена и в база данни.
И така ... тестерът е копирал потребителя тук, съгласен ли сте?
# две) Докато тестваше приложение, където работният поток е да подава различни формуляри в специална последователност, ако се следваше реда, той работи добре. Но какво, ако потребителят се опита да се върне към формуляр №3 от формуляр №5?
Отново, вместо да мислим какво трябва да се случи, нека да видим какво се е случило ...
Тестър беше онемял, но изпитваше гордост, че се появи като потребител ... .. Съгласен ли си?
# 3) След успешно влизане потребителят щраква върху бутона за връщане назад в браузъра. Отново да видим какво се случи ...
Идентификационните данни трябваше да бъдат почистени, но не. Придвижвайки се по-нататък, на тази страница за вход потребителят кликва върху връзката Забравена парола. Бъдете ясни, че потребителят вече е влязъл и е бил на страницата за вход, като е щракнал бутона за връщане назад в браузъра. Кликването върху Забравена парола насочи потребителя към началната страница на приложението.
Тестерът се обърна към потребителя ... .. Съгласен ли си?
какъв е ключът за мрежова защита на рутера
# 4) След като наблюдава URL адреса на страницата за търсене (http: //x.x.x.x: y / # / Search) на приложението, тестерът промени URL адреса като http: //x.x.x.x: y / # / Search / test? и можеш ли да мислиш какво би станало?
Е, приложението се срина и тестерът отново се обърна към потребител ... Надявам се, че няма да се съгласите.
Заключение
Предполагам, че чрез тези примери съм предал достатъчно от това, което исках.
Наистина тестването не означава да се провери работния поток на приложението, нито пък да се прекъсне приложението, но със сигурност означава проверете опита на потребителя дори когато прави грешките.
За автора: Тази публикация е написана от члена на екипа на STH Bhumika Mehta. Тя е ръководител на проект, имащ 10+ години опит в тестването на софтуер. Тя също оценява добрите идеи и иновации и рискове. И разбира се мрази монотонната работа, хората и околната среда.
И да, нека превърнем тестера в себе си към краен потребител ... Разбирате ли се? :)
Така че ... ..искаме да чуем повече примери като тези от вас и бихме искали да имаме и вашите мнения.
Препоръчително четене
- Урок за тестване на GUI: Пълно ръководство за тестване на потребителския интерфейс (UI)
- Тестване на бисквитки на уебсайтове и тестови случаи за тестване на бисквитки на уеб приложения
- Удостоверяване на потребителя в MongoDB
- Тестване за проверка на имейл: Как да тествате функционалността на електронната поща на приложение
- Печелене на пари, кариера на тестване на софтуер и тайни на най-богатия тестер
- 5 неща, които начинаещият разработчик (и тестер) трябва да знае за тестването на софтуер
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Ad-hoc тестване: Как да открием дефекти без официален процес на тестване