cosmetic functional bugs what has be treated
Винаги има огромни отговорности, наложени на тестера за разкриване на всякакъв вид грешка, която софтуерът има. Независимо от функционалността и потребителския интерфейс, тестерите могат да повдигат грешки навсякъде, където има несъответствие.
Тази статия помага да се разбере значението на функционалните и козметичните грешки. Освен това факторите, които трябва да се вземат предвид при определянето на приоритетите им, също са обяснени тук по разбираем начин с някои живи примери за илюстрации .
какво е тестване за здравословно състояние при тестване на софтуер
Какво ще научите:
Значение на функционалните и козметични бъгове
Грешките са неизбежни при разработването на софтуер. Следователно винаги е много важно да извършите щателно тестване на софтуера, преди да може да се използва на живо. Тестване на софтуер могат да станат по-важни, тъй като помагат при идентифицирането на грешки, пропуснати от разработчиците .
Тези неидентифицирани грешки могат да станат много скъпи на живо. Следователно трябва да се извърши правилен план за тестване и тестване, за да се подобри качеството на софтуера.
Фиг. 1:
Горната фигура трябва да качи файл с изображение, който софтуерът не е успял да покаже. Това е сериозен проблем, който може сериозно да причини бизнес въздействие.
Козметични бъгове и тяхното значително значение
Козметичните изисквания не са нищо друго освен потребителския интерфейс или просто външния вид на софтуера. Повечето пъти се случва да се променя между различните издания.
Това се случва особено в проектите, където се следва гъвкавата методология. Пусканията се появяват тук под формата на спринтове. Следователно те обикновено се наричат Sprint release или просто SR-xx, където ‘xx’ се отнася до номера на изданието.
Всяка версия може да има определен набор от изисквания. Като цяло клиентите се подготвят да искат промени в потребителския интерфейс или просто потребителския интерфейс много често.
Следват няколко примера за козметични изисквания:
- Менютата трябва да са налични с шрифт Calibri и.
- Текстовото поле A трябва да бъде в 1,2 инча
- Всички генерирани отчети трябва да имат заглавие с размер H1 с цвят ‘002522’.
Горните са няколко примера за козметични изисквания, които могат да възникнат. Това са изискванията, насочени главно импровизиране на използваемостта на софтуера . Друга причина за козметичните изисквания е оптимизирането на софтуера и неговия дизайн за бизнес целта.
Фигура 2
В горната фигура има както функционални, така и козметични проблеми. Функционален проблем като квадратчето за отметка не се показва за опция „Използване на DeathByCaptcha“.
Козметичният проблем може да се види тук като не е използван унифициран шрифт.
Приоритетен фактор за козметични грешки или нужди на клиентите
Козметичните нужди са малко важни от клиентите. Това се дължи на загрижеността за необходимостта взаимодействието на софтуера да стане много просто и в същото време ефективно, така че постигането на целите да става лесно. В случай че има проблеми с потребителския интерфейс, клиентите се свързват с доставчиците с грешка с нисък приоритет.
Както обикновено се случва, функционалните аспекти на софтуера са загрижени от разработчиците, отколкото козметичните аспекти, тъй като те са най-вече слабо засегнати области.
Софтуерните тестери искат всички изисквания, споменати от клиентите, да са налични в неизправността на софтуера, което естествено създава грешка. И точно тук всички излитат. Приоритетът, зададен от тестера, възниква като резултат от предложението на клиента. Изгледът на разработчиците е малко по-различен от това, което гледат тестерите. Те винаги гледат дали грешката може да причини прекъсване на функционалността.
Тук идват някои повтарящи се дискусии и резултатът от тях може да доведе до препоръки от екипа за тестване в даден момент. Ако не е в текущата версия, това може да се случи в следващата.
Реален пример # 1)
Клиентът е поискал фирменото лого да се показва на началната страница в рамките на заглавието заедно с функция за бързо зареждане. Доставчикът е доставил софтуера, при който фирменото лого отнема време за зареждане, а клиентите с усещането, че логото не се зарежда, продължават да повдигат проблем на живо за клиентите.
Следователно това е нанесло повече вреди на продавачите. Основната причина за проблема може да бъде размерът на изображението или естеството на изображението или нещо друго. Въпреки че това няма функционални прекъсвания, това беше поставено като проблем на живо.
Функционални грешки - критични и приоритетни фактори
Като цяло грешките се считат за приоритетни въз основа на приоритета, определен от клиентите, и потенциалните въздействия, които те могат да оставят върху бизнеса. Общото мнение на разработчиците е, че над критичните грешки трябва да се работи. Това е по-очевидно, тъй като функционалните грешки са нещо, което потиска работата им.
И въз основа на приоритета, клиентите искат да дадат приоритет на някои от функционалните и козметични грешки в същото издание. Коефициентът на критичност зависи от въздействието или потенциалното въздействие, което бъгът може да му остави. Приоритетният фактор се базира чисто на клиента и неговите нужди.
По отношение на критичността функционалните грешки са много необходими, за да бъдат отстранени без забавяне. За козметичните бъгове те могат да приемат решенията, взети от клиентите
Фигура 3
На горната фигура има функционални проблеми като проблеми с дизайна и припокриване на текст и козметични проблеми като проблема с шрифта.
Реален пример # 2)
Клиентът в пример # 1 имаше няколко издания от един и същ доставчик. Клиентите са доволни от резултатите, предоставени от доставчиците. Сега изведнъж има няколко бизнес сценария, за които клиентите са установили, че не работят, заедно с няколко други списъка с проблеми с дисплея. Тъй като функционално засягащите проблеми се считат за критични за клиентите, те поискаха от доставчиците да ги поправят възможно най-скоро.
И тъй като проблемите с дисплея имаха признаци, че оставят по-малка степен на въздействие, клиентите ги приоритизират в множество версии. Клиентите бяха готови да пуснат на живо с поправки за някои от проблемите с дисплея и повечето функционални проблеми. Това е така, защото всички функции могат да повлияят на бизнеса и малкото проблеми с дисплея имат потенциал да създадат въздействия.
Бизнес въздействия
Всички грешки могат да доведат до някакво несъответствие в софтуера с това на изискванията на клиента. Що се отнася до въздействието върху бизнеса, определено функционалните грешки заслужават да причинят сериозни въздействия върху бизнеса. Тъй като козметичните грешки отговарят на проблема с дизайна и външния вид на потребителския интерфейс, те могат да създадат проблеми с използваемостта и външния вид сред потребителите.
С други думи, те по-добре се наричат козметични подобрения, отколкото бъгове. Въпреки че те не могат да повлияят сериозно на бизнеса в по-голяма степен, те могат да доведат до някои затруднения сред потребителите, докато използват софтуера.
Реален пример # 3)
Доставчиците са доставили нова версия на софтуерното приложение в мобилна версия. Има малко функции в мобилните приложения, които изискват от потребителя да кликва по-често върху някоя връзка. Това създаде усещане за влошена използваемост сред потребителите. Доставчиците трябва да преразгледат дизайна и потока в приложението. След промяна на потока, приложението започна да получава множество потребители, които ги използват.
Използваемостта заема главната роля в много такива приложения. Въпреки че нямаше функционални промени, имаше малко промени в козметиката, които направиха приложенията да станат по-силни
Сравнително проучване между козметичните бъгове и функционалните бъгове
Може да има редица вариации между класификациите на грешки като функционални и козметични в множество аспекти в жизнения цикъл на тестването на софтуера. Малко от тях са формулирани и таблицирани като разлика между двата типа:
| Сравнителна област | Функционални грешки | Козметични бъгове |
|---|---|---|
| Потенциални причини | Може да има няколко причини: 1. Проблеми с кодирането 2. Проблеми със синхронизирането 3. Проблеми със зависими приложения | Следното може да е причина за проблема: 1. Проблеми с дизайна 2. Неподдържан проблем с файл |
| Степен на отдих | Възстановяването на функционалните грешки може да се извърши или от тестерите, или от самите клиенти | Козметичните грешки изискват минимални усилия за отдих, тъй като те се идентифицират най-вече на ниво потребителски интерфейс |
| Критично | Те са най-вече критични, тъй като функционалната повреда може да повлияе на бизнеса в тежка форма | Те могат да станат критични в много малко случаи. |
| Приоритет | Приоритетът е дефиниран от клиентите | Приоритетът е дефиниран от клиентите |
| Потенциално въздействие | Функционалната повреда може да доведе до сериозни проблеми в бизнеса на клиентите | Въпреки че не могат да създадат пряко въздействие, те могат да предприемат и потенциални въздействия. |
| Разглеждане на подобрения | Тези грешки никога не могат да бъдат препоръчани или разглеждани като подобрение | Тези грешки могат да се разглеждат или разглеждат като подобрение |
| Разходи, когато не са фиксирани | Висока цена, когато проблемът е открит в актуален софтуер | Не много разходи |
Козметични илюстрации на бъгове
Козметичната грешка може да причини въздействие на някои места, където върху софтуера има фирмени лога или изображения на партньорства, но не се зарежда правилно. Въпреки че са нефункционални грешки, те могат да станат сериозни. Нека разберем следващите илюстрации, за да разберем значението на козметичните бъгове и тяхната значима роля.
Казус
Софтуерът A се разработва от доставчика B. Режимът на резултатите за клиента е под формата на отпадане на кода веднъж на всеки месец след издаването на основната версия. От доставения продукт клиентите ще изброят всички проблеми, грешки, подобрения въз основа на тяхната критичност и приоритет.
Приоритетът е както P1, P2, P3 и P4.
Критичността е както Тежко, основно, високо и ниско.
Сега клиентите очакват всички сериозни, големи, P1 грешки да бъдат отстранени през седмица 30. По същия начин High, P2 бъгове в седмица 35. Ниски, P3 корекции на грешки се очакват през седмица 40. И накрая, P4 грешки се очакват през седмица 40. Между всички освобождавания на корекциите, клиентът блокира 3-дневен период от буфера.
Сега следното наблюдение става много критично:
- Тъй като е планирано като конвейерен режим, всяко забавяне ще повлияе по-добре на следващите планове.
- Приоритетите се формират от клиентите и следователно те планират да освободят в желания от тях период
- Забавянето при грешки с нисък приоритет има потенциал да надгради техния приоритет от нисък приоритет към по-висок.
- Незначителните закъснения могат да доведат до сериозни въздействия върху бизнеса, оставяйки ниските и малките грешки да станат големи.
Среща на тестери и разработчици
„Не бройте яйцата, преди да се излюпят“ - Този ред е приложим както за разработчиците, така и за тестерите. Когато софтуерът е разработен и готов за тестване, тестерите са склонни да мислят за горните редове. След тестване, сега е ред на разработчиците да изписват линиите към тестерите. Следват мислите, които текат помежду им:
- Тестерите казват, че разработчиците имат толкова много грешки, които можем да хванем във вашия софтуер. Следователно работата ви не е приключила.
- След като фазата на тестване приключи и след много грешки, разработчиците казват, че не смятате, че сте повдигнали повече грешки, ние ще намерим подходящата причина да отхвърлим повечето от грешките, които сте създали, които не са истински.
Следователно това винаги е един вид аргументиран подход, който протича между тестерите и разработчиците. За да сте сигурни, че цялостните резултати от проекта са синхронизирани, е от съществено значение междинно лице (мениджър на проекта), което може да разреши противоречията, така че резултатите да бъдат оптимизирани и абсолютни, без изтичане на дефекти.
Заключение
Горните статии трябва да са обяснили всички неизбежни и важни аспекти на козметичните бъгове и как може да се сравни с функционалните бъгове . Горната статия също обяснява как козметичните грешки могат да бъдат лекувани в сравнение с функционалните грешки.
qa въпроси и отговори за интервю за анализатор
Въпреки че критичността на функционалните грешки е по-висока от тази на козметичните грешки, последните запазват своето място за получаване на приоритети от клиентите. За да балансирате софтуера с резолюции за всички грешки, обикновено се препоръчва да се лекуват грешките, разбирайки критичността, приоритета и препоръката на клиента.
За автора: Това е статия, написана от Nagarajan. Той работи като тестов ръководител с над 6 години опит в различни функционални области като банкиране, авиолинии, телеком по отношение на ръчно и автоматизирано.
Какво е мнението ви относно козметичните и функционалните грешки? Бих искал да видя вашите мисли по-долу.
Препоръчително четене
- Когнитивно пристрастие при тестване на софтуер: Защо тестерите пропускат грешки?
- Защо софтуерът има грешки?
- Как да разрешите всички грешки без етикет „Невалидна грешка“?
- Функционално тестване срещу тестване на производителността: Трябва ли да се прави едновременно?
- 10 причини, поради които вашите грешки се отхвърлят и какво можете да направите като тестер!
- Какво е тестване за дълголетие? Как да уловим грешките, преди клиентът да го намери
- Изкуството на докладването на грешки: Как да предлагаме на пазара и да коригираме грешките си?
- Топ 30 функционални инструмента за тестване през 2021 г.