how tester can think
Сцена : До ресторану прибула сім’я з трьох осіб - батьки та малюк. Після замовлення найулюбленішої піци сім'я відпочивала, і малюк почав грати паличками, покладеними на стіл. Він йому сподобався і вирішив вечеряти лише паличками.
Він оголосив про своє бажання, і батьки, зайняті розмовою, погодились з цим. Коли подавали піцу, малюк почав користуватися паличками для їжі і кілька разів не міг отримати піцу в рот. Раптом батьки це помітили і наказали малюкові не користуватися паличками. Малюк не переконав, оскільки батьки вже домовились про його бажання раніше.Коли батьки почали навчати їсти піцу лише ножем та виделкою, малюк сумнівався у цій вірі, але я хочу їсти її лише паличками для їжі і чому це неправильно? І, використовуючи палички для їжі, коли він не зміг з’їсти свою улюблену піцу, він знервувався і, зрештою, викинув палички і вирішив також не їсти піцу. Батьки, також розчаровані, нічого не могли зробити, і час сімейної вечері виявився найгіршим часом доби.
Тепер замініть кілька слів у наведеному вище параграфі наступними та передумайте:
Батьки: Команда управління проектами, що включає бізнес-аналітика, продавця, менеджера з розробки та архітектурну команду.
Малюк: Клієнт / кінцевий користувач
Піца: продукт / застосування
Палички для їжі: помилка
Найулюбленіша програма є лише улюбленою, доки користувач не помилиться і не побачить найгіршої поведінки програми. Отримавши досвід, користувач більше не повертається до програми. І тому, як тестувальник, дуже важливо це зрозуміти мислення користувача , як він повинен поводитися, що неправильно він може зробити з додатком, що може бути найгіршою помилкою та багато іншого.
Здебільшого мене на форумах, а також внутрішніх членів команди запитували про те, як відтворити досвід користувача під час тестування. Моя відповідь завжди була проста - Будьте користувачем :)
Незважаючи на те, що це просто сказати, ніж впровадити, настав час для індустрії тестування програмного забезпечення перейти у той бік революції, де досвід користувачів та відгуки важливіші за все інше.
Як тестер може мислити як Кінцевий користувач?
Представляючи цим деякі типові приклади поведінки як кінцевого користувача та пошуку сюрпризів , Я спостерігав протягом останніх кількох днів:
# 1) Під час тестування поля дати, коли користувач вибрав або вручну ввів правильне значення дати, воно спрацювало нормально. Але коли користувач в кінцевому підсумку ввів абсолютно неправильне значення, наприклад 12/00 //, і натиснув кнопку «ОК», він отримав повідомлення про помилку про недійсне значення дати.
Тепер користувач не виправляє дату, а оновлює сторінку. Що має статися? Ну, багато з вас здогадуються, що має статися, але чи можете ви подумати, що сталося з додатком? Після оновлення сторінки користувачеві було представлено наступне, і те саме значення було також збережено в базі даних.

Отже ... тестер повторив користувача тут, погодились?
# два) Під час тестування програми, де робочий процес повинен подавати різні форми в особливій послідовності, якщо дотримуватися порядку, він працював нормально. Але що, якби користувач спробував повернутися до форми №3 із форми №5?
Знову ж таки, замість того, щоб думати про те, що має статися, давайте подивимось, що сталося ...

Тестер був здивований, але відчував гордість за те, що виявив себе користувачем ... ..Погодився?
# 3) Після успішного входу користувач натискає кнопку повернення браузера. Знову подивимось, що сталося ...

Повноваження слід було очистити, але це не так. Просуваючись далі, на цій сторінці входу користувач натискає посилання Забули пароль. Будьте зрозумілі, що користувач вже ввійшов у систему та був на сторінці входу, натиснувши кнопку 'Назад' у браузері. Натискання кнопки «Забули пароль» перевело користувача на домашню сторінку програми.
Тестер звернувся до користувача… ..Погодився?
# 4) Переглянувши URL-адресу сторінки пошуку (http: //x.x.x.x: y / # / Search) програми, тестер змінив URL-адресу як http: //x.x.x.x: y / # / Search / test? і ви можете подумати, що могло б статися?
Ну, програма розбилася і знову тестер звернувся до користувача ... .. Сподіваюся, ви не погодитесь.
Висновок
Думаю, на цих прикладах я передав достатньо того, що хотів.
Справді, тестування не означає перевірити робочий процес програми, а також не означає зламати програму, але це, безумовно, означає перевірити досвід користувача навіть коли він робить помилки.
Про автора: Цей допис написаний членом команди STH Бхумікою Мехтою. Вона є керівником проекту, що має 10+ років досвіду у тестуванні програмного забезпечення. Вона також цінує хороші ідеї та інновації та ризики. І, звичайно, ненавидить монотонну роботу, людей та довкілля.
І так, давайте перетворимо тестер в собі на кінцевого користувача .... :)
Тож ... .. ми хотіли б почути від вас більше подібних прикладів і хотіли б також мати вашу думку.
c проти синтаксису c ++
Рекомендована література
- Підручник з тестування графічного інтерфейсу: Повна інструкція з тестування інтерфейсу користувача (UI)
- Тестування файлів cookie веб-сайту та тестові кейси для тестування файлів cookie веб-додатків
- Аутентифікація користувача в MongoDB
- Тестування перевірки електронної пошти: Як перевірити функціональність електронної пошти програми
- Заробляння грошей, кар’єра тестування програмного забезпечення та секрети найбагатшого тестувальника
- 5 речей, які повинен знати розробник (і тестувальник) про тестування програмного забезпечення
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
- Спеціальне тестування: Як знайти дефекти без формального процесу тестування