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. Непідтримувана проблема з файлом |
| Ступінь відпочинку | Відтворенням функціональних помилок можуть займатися тестери або самі клієнти | Косметичні помилки вимагають мінімальних зусиль для відпочинку, оскільки їх ідентифікують здебільшого на рівні інтерфейсу користувача |
| Критичність | Вони в основному є критичними, оскільки функціональний збій може вплинути на бізнес у важкій формі | Вони можуть стати критичними дуже рідко. |
| Пріоритет | Пріоритет визначається клієнтами | Пріоритет визначається клієнтами |
| Потенційний вплив | Функціональний збій може спричинити серйозні проблеми у бізнесі клієнтів | Хоча вони не можуть створити прямий вплив, вони також можуть взяти на себе потенційні наслідки. |
| Розгляд удосконалень | Ці помилки ніколи не можна рекомендувати або розглядати як покращення | Ці помилки можна розглядати або розглядати як покращення |
| Витрати, коли вони не фіксовані | Висока вартість, коли проблема виявляється в активному програмному забезпеченні | Не багато витрат |
Ілюстрації косметичних помилок
Косметична помилка може спричинити вплив в деяких місцях, де на програмному забезпеченні є логотипи компаній або зображення партнерських відносин, але воно не завантажується належним чином. Хоча вони є нефункціональними помилками, вони можуть стати серйозними. Давайте зрозуміємо наступні ілюстрації, щоб зрозуміти важливість косметичних помилок та їх важливу роль.
Приклад
Постачальник В. розробляє програмне забезпечення А. Режим кінцевих результатів для клієнта має форму падіння коду один раз на місяць після випуску базової версії. З поставленого продукту клієнти перелічують усі проблеми, помилки, вдосконалення, виходячи з їх критичності та пріоритетності.
Пріоритет виглядає як P1, P2, P3 та P4.
Критичність йде як Важкий, основний, високий і низький.
Тепер клієнти очікують, що всі серйозні, основні помилки P1 будуть виправлені на 30 тижні. Аналогічно високі, P2 помилки на тижні 35. Низькі виправлення помилок P3 очікуються на 40 тижні. Нарешті, помилки P4 очікуються на тиждень 40. Протягом усього випуску виправлень клієнт блокує 3-денний період буфера.
Тепер наступне спостереження стає дуже критичним:
- Оскільки це було заплановано як конвеєрний режим, будь-яка затримка більше вплине на подальші плани.
- Клієнти формують пріоритети, і, отже, вони планують звільнити їх у бажаний період
- Затримка помилок з низьким пріоритетом може підвищити їх пріоритет з низького пріоритету на вищий.
- Невеликі затримки можуть призвести до серйозних наслідків для бізнесу, через що низькі та незначні помилки стануть основними.
Зустріч тестувальників та розробників
«Не рахуйте яйця до того, як вони вилупляться» - цей рядок стосується розробників, а також тестувальників. Коли програмне забезпечення було розроблене і готове до тестування, тестери, як правило, думають про вищезазначені рядки. Після тестування тепер черга розробників писати рядки тестувальникам. Нижче наведені думки, що протікають між ними:
- Тестери кажуть розробникам, що у вашому програмному забезпеченні так багато помилок. Отже, ваша робота ще не закінчена.
- Після завершення етапу тестування та після багатьох помилок розробники заявляють, що не вважають, що ви викликали більше помилок, ми знайдемо відповідну причину для відхилення більшості вилучених вами помилок, які не є справжніми.
Отже, це завжди якийсь аргументований підхід, який проходить між тестувальниками та розробниками. Щоб переконатися, що всі результати проекту синхронізовані, важливо, щоб проміжна особа (менеджер проекту), яка може вирішувати суперечки, забезпечувала оптимізацію результатів та абсолютну без витоків дефектів.
Висновок
Вищезазначені статті, мабуть, пояснювали все неминучі та важливі аспекти косметичних помилок та те, як їх можна порівняти з функціональними помилками . У наведеній вище статті також пояснюється, як можна лікувати косметичні помилки у порівнянні з функціональними помилками.
Незважаючи на те, що критичність функціональних помилок вище, ніж у косметичних помилок, останні залишають своє місце в отриманні пріоритетів від клієнтів. Щоб збалансувати програмне забезпечення з дозволами для всіх помилок, зазвичай рекомендується лікувати помилки, розуміючи критичність, пріоритетність та рекомендації клієнта.
Про автора: Це стаття, написана Нагараджаном. Він працює випробувальним керівником з більш ніж 6-річним досвідом тестування в різних функціональних сферах, таких як банківська справа, авіалінії, телекомунікації, як з точки зору ручного, так і автоматичного управління.
Що ви думаєте про косметичні та функціональні помилки? Я хотів би побачити ваші думки нижче.
Рекомендована література
- Когнітивні упередження при тестуванні програмного забезпечення: чому тестувальники сумують за помилками?
- Чому програмне забезпечення має помилки?
- Як вирішити всі помилки без позначки 'Недійсна помилка'?
- Функціональне тестування проти тестування продуктивності: чи слід це робити одночасно?
- 10 причин, чому ваші помилки відхиляються, і що ви можете зробити для цього як тестер!
- Що таке тестування на довговічність? Як зловити помилки, перш ніж клієнт знайде їх
- Мистецтво повідомлення про помилки: як продати на ринок та виправити помилки?
- 30 найкращих інструментів функціонального тестування в 2021 році