wireframes should they really be tested
На борда се появиха нови обучавани и ние имахме тренировъчен клас научете концепции за тестване на софтуер . След като видях тези ентусиазирани лица с техните почти празни умове (професионално), реших да отклоня рутинното си обучение.
След кратко въведение, вместо да говоря за тестване на софтуер, както обикновено, аз зададох въпрос на свежите умове - „ Някой може ли да ми обясни какво да се каркасът е? '
Отговорът беше пауза и затова решихме да го обсъдим. И така започна - Тестване на каркасни / прототипи :)
Така, какво е каркас? Позволете ми да го обясня с няколко прости аналогии:
- Интериорният декоратор не започва да поставя мебелите и да украсява къщата на случаен принцип. Той поставя плана си на хартия (или софтуер за проектиране), обсъжда го с клиента, пробва и променя плана по най-добрия практически начин и след това го изпълнява.
- За да разберат колко тежко е наранена част от тялото, лекарите разглеждат рентгенова снимка. Рентгеновата снимка е основно скелет на нашето тяло и дава точна информация за костите и ставите.
- Шивач подготвя хартиения плат (отново вид прототип), прави каквито и да са модификации и го използва като базово измерване, докато всичко е точно и той е уверен да продължи с действителното парче, което шие.
Мисля, че тези примери бяха достатъчни, за да може някой да разбере концепцията за каркасна рамка.
Wireframes са видове прототипи:
Те имат ограничен характер, което означава, че могат да съдържат празни HTML страници без работещи елементи или статични екранни снимки, които са представителни за страница / функция / елемент на приложението и може да нямат цвят, графика и други елементи от действителния визуален дизайн.
За да се изгради солидно приложение / уебсайт, е необходима солидна рамка и жичните рамки помагат при предоставянето на рамката, като представят изображение на оформлението на страницата, цялостния интерфейс, навигацията и функционалностите.
Ето няколко примера за телени рамки:
Защо софтуерните компании изграждат телени рамки?
По точно същата причина Шивачът / интериорен дизайнер / Доктор решава първо да изпробва нещата - за да избегне грешки, да елиминира предположенията, да вземе одобрение от клиента, преди да постави всичко в камък. Той помага за ранното идентифициране на проблемите и за поглед върху софтуера, както би изглеждал, когато приключи.
Какво ще научите:
- Значение на телените рамки / тестване на прототип:
- Тестването на Wireframes може да помогне в следното:
- Инструменти за телени рамки:
- Кога може (или може) да се извърши тестване на Wireframes:
- Резултати от тестване на прототип:
- Заключение:
- Препоръчително четене
Значение на телените рамки / тестване на прототип:
И така, защо да тестваме нещо, което е скелет и което няма да се види от потребителя така, както е сега? С други думи - Защо да се занимаваме с посредника, когато той все още е манекен?
Просто - за подпомагане на предотвратяването на дефекти - което е основната програма на екипите за осигуряване на качеството (Осигуряване на качеството = Превенция на дефекти + Идентификация на дефекти ).
Тестването на Wireframes може да помогне в следното:
# 1) Идентифициране на липсващи изисквания:
Нека кажем, ако изискванията посочват, че в a страница за вход трябва да има 2 полета за въвеждане, съответно идентификатор за вход и парола и 3 бутона, OK-Отказ- Нулиране. Ако каркасът е както следва, можем лесно да намерим липсващия бутон Reset рано и да го включим в приложението.
# 2) Идентифициране на допълнителни изисквания:
Обратното на горната ситуация може да бъде, че изискването гласи, че в страницата за вход трябва да има 2 полета за въвеждане, идентификатор за вход и парола съответно и 2 бутона, OK & Cancel. Ако каркасът е както следва, лесно можем да установим, че той има допълнителен бутон Reset и да потърсим потвърждение дали това наистина се изисква или не.
# 3) Използваемост:
Wireframes са един от най-добрите варианти за тестване на използваемостта на продукта / приложението, преди да бъде разработен.
Ето каркаса за една от формите:
На пръв поглед изглежда добре.
Сега мислете като краен потребител, потребителят, който ще попълни информация във формуляра. Мислите ли, че има начин този формуляр да бъде по-лесен за ползване? Е, със сигурност мисля така.
- Предоставете символ на календара и ограничете потребителя да избира дата от календара. Това би било полезно за потребителя, тъй като няма да се бърка кой формат на датата трябва да следва и избирането на дата от календара би било нещо, което всеки потребител би предпочел.
- Подсказка, обясняваща какво означава всяко поле, би била чудесна.
- Името на страницата като заглавие е необходимо, за да се разбере каркасът и да се свържат полетата.
- Задължителните полета трябва да бъдат маркирани със знак * или бележка с надпис „ Всички полета са задължителни ”Трябва да се вижда.
- Етикетът на първото поле трябва да бъде „Име на кампанията“, а не само „Име“, за да се избегне объркване за потребителите.
# 4) Ранно функционално тестване:
номер на char към int c ++
В горния пример от диаграмата можем да предположим начина, по който може да работи функционалността. Ако не, това поне ще доведе до по-нататъшно разкопаване и по-добро разбиране на приложението.
- Например : Ами ако потребителят иска да добави множество идентификатори за резервация? Ще презапише ли приложението предишния запис или ще позволи множество записи? Как ще се справи и управлява?
Както се вижда от горните примери, тестването на телени рамки наистина помага за ранното идентифициране на проблемите чрез статичен каркас и предотвратява проникването на дефектите в действителното приложение. Това е много полезно, тъй като знаем, че дефектите, идентифицирани в началото на процеса на разработване, са по-евтини за отстраняване от тези, открити по-късно.
Инструменти за телени рамки:
На пазара има много инструменти, но човек трябва да използва инструмента според пригодността на контекста. Докато повечето инструменти като Axure, Power mockup, Simulify, Balsamiq и др. Са платени, има някои полезни безплатни инструменти за рамкиране също:
- Какао : Cacoo е лесен за използване онлайн инструмент за рисуване, който позволява на потребителя да създава разнообразни диаграми като карти на сайтове, телени рамки, UML и мрежови диаграми.
- MockupBuilder : MockupBuilder помага на потребителя бързо да изведе идеите си на екран. Това е БЕЗПЛАТНО уеб приложение, задвижвано от Silverlight.
- Проект молив : Pencil Project е безплатен и лесен за научаване. Той може да работи като добавка за Firefox или самостоятелно.
Кога може (или може) да се извърши тестване на Wireframes:
- Преди разработването на продукта: Това може да помогне за идентифициране на пропуски или липсващи изисквания, дизайнерски грешки, проблеми с използваемостта и т.н.- Превенция на дефекти
- Пост разработка: В този случай телените рамки могат да се използват като референции за валидиране на приложението. - Идентификация на дефекти.
В случай на тестване на Wireframe за използваемост, обикновено се извършва ръчно и през повечето време участват потребители в реално време. На тях им се задават или поредица от въпроси, за да разберат техния опит или обратна връзка, или са снабдени с интерактивни рамки за улавяне на обратната връзка.
За да се направи подробен анализ на телените рамки, понякога се включват и експерти по темата.
Услуги като потребителско тестване може да бъде много полезно, където човек може да публикува връзка на телени рамки и след тестване на телени рамки, резултатите се генерират заедно със следното точки за обратна връзка:
- Видео на екрана на всеки потребител, който тества вашата рамка.
- Аудио на разговор на потребителя чрез това как той изпълнява задачите.
- Ценна обратна връзка за това как да подобрите уебсайта си.
Резултати от тестване на прототип:
Резултатите от тестването на телени рамки са много полезни по отношение на разбирането на дизайна, навигацията, удобството за потребителя, цялостния работен поток и функционалностите. По принцип след тестване на телени рамки телните рамки стават по-ясни и изпълними.
Заключение:
За да обобщим, тестването на телени рамки работи като проактивно действие и може да бъде много полезно за намиране на използваемост и дизайн на вратички във фазата на предварителна разработка на приложението.
С това завършвам темата с надеждата, че читателите ще ме изкушат да напиша още една публикация по този въпрос, като задавам въпроси и предоставям обратна връзка.
За автора: Тази статия е написана от член на екипа на STH Bhumika. Тя е ръководител на проекта и има над 10 години опит в софтуерното тестване.
Приятно тестване, както обикновено :)
Препоръчително четене
- Тестване на приложения - в основите на софтуерното тестване!
- Упражнения за софтуерно тестване - Нова платформа за тестване на вашите умения за тестване и споделяне на практически идеи
- Как да тествате приложението за здравни грижи - част 1
- Как да получите бърза работа за мобилно тестване - Ръководство за мобилно тестване за кариера (част 1)
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Кой е най-добрият момент във вашата тестова кариера? - отговори на такива 14 интересни въпроса за интервю за тестване на софтуер
- Разлика между десктоп, тестване на клиентски сървър и уеб тестване
- Как да прегледаме SRS документа и да създадем тестови сценарии - Обучение за тестване на софтуер по проект на живо - Ден 2