Великі і малі баги, та їхня роль у вашому веб-проекті

25.07.2018
Bugs in web development
Автор:

З цілого ряду причин навіть в коді найдосвідченіших розробників можуть знаходитись баги. Це — помилки або неточності, що призводять до такої роботи сайту, яка не відповідає очікуванням. Ось чому забезпечення якості таке важливе — QA-інженер на варті точного втілення ваших очікувань! Однак, не всі баги однаково шкідливі. «Укуси» деяких із цих «жучків» майже не відчутні в роботі сайту. А інші баги можуть відкусити і прожувати великий шматок вашого бізнесу. Давайте подивимось, як класифікуються баги за важливістю в практиці QA, чому все не завжди однозначно, і що з цим зазвичай роблять.

Баги у веб-розробці: від великих до маленьких

Зазвичай баги класифікуються за двома аспектами: критичність та пріоритетність Критичність — це ступінь негативного ефекту багу на роботу сайту. Пріоритетність — це порядок, в якому цей баг потрібно буде пофіксити порівняно з іншими. Більше деталей — просто зараз.

Баги за критичністю

Це може відрізнятись в різних організаціях та на різних проектах, але найпоширеніша градація — від “Critical” до “Minor”. Багато хто додатково використовує ступінь критичності “Блокуюча”, яка означає, що тестування неможливе.

  • Критичні (S1): Баг блокує критичний функціонал або навіть унеможливлює роботу сайту. Немає жодного шансу обійти цей баг.
  • Важливі (S2): Баг створює перешкоди в роботі менш критичного, але важливого функціоналу. Існують певні можливості обійти цей баг.
  • Незначні (S3): Баг створює перешкоди в роботі не дуже важливого функціоналу. Цей баг нескладно обійти.
  • Тривіальні (S4): Баг не торкається функціоналу, лише спричиняє певні незручності.

Баги за пріоритетністю

Пріоритетність багів може розрізнятися в такому діапазоні:

  • Висока. Баг необхідно пофіксити якнайшвидше.
  • Середня. Пофікшення багу може зачекати певний час.
  • Низька. Баг може зачекати й довше.

Багато QA-інженерів використовують додатковий рівень пріоритетності понад усіма іншими — «Негайна».

Критичність та пріоритетність багів: як вони співвідносяться

На перший погляд, можна поставити знак рівності між критичністю та пріоритетністю багів. Однак, ці поняття не взаємозамінні.

Критичність визначається QA-інженером, і це більш об’єктивний фактор. Хоча розробники могли б із цим посперечатись :) Критичність бага має чіткі технічні пояснення. Вони керуються стандартами веб-розробки та очевидними аспектами поведінки сайту.

Пріоритетність вирішується власником продукту або проект-менеджером. Вона несе в собі сильний відтінок суб’єктивності і часто пов’язана з поточними обставинами, бюджетом проекту, вимогами та очікуваннями клієнта.

Давайте розглянемо приклад: веб-сторінка з орфографічною помилкою. Об’єктивно, це незначний баг. Однак, клієнт готується наступного дня робити презентацію сайту, і йому не подобається помилка. В цьому випадку, незначний баг потрібно пофіксити терміново. Це яскраво ілюструє нерівність між критичністю та пріоритетністю.

Протилежним прикладом можна вважати критичний баг в системі оплати сайту. Попри всю свою важливість, він може і не з’явитися в термінових задачах розробника — просто тому, що система оплати все одно поки що не доступна на «живому» сайті.

Чи завжди необхідно фіксити маленькі баги?

Є ще один аспект роботи з маленькими багами. Інколи трапляється, що пофікшення маленького багу ламає важливий функціонал.

Думка з цього приводу поділяє QA-інженерів на дві категорії, які можна було б назвати перфекціоністами і раціоналістами. Перші наполягають на тому, щоб фіксити найбільш мікроскопічні баги за будь-яких обставин. Другі радять не чіпати їх в певні моменти. Але, врешті-решт, останнє слово за клієнтом.

В будь-якому випадку, відомий факт у практиці QA — це те, що «боротися зі злом» краще, поки воно ще маленьке. Чим швидше фіксити баг, тим менше часу в нього є, щоб наробити шкоди, і тим менше витрат це може викликати.

Наостанок

Тонкощі багів та їхнього впливу на проект — це навичка, яку QA-інженери здобувають все своє життя. Досвід та професійна інтуїція допомагає їм вирішити щодо критичності бага, а також порадити проект-менеджеру або клієнту щодо пріоритетності бага. Винайміть досвідчених QA-інженерів у InternetDevels, і вони допоможуть зробити ваш сайт, а також репутацію, кришталево чистими.

Голосів: 1 Рейтинг: 5

Також по темі

1

Ще з часів винайдення колеса людство почало цінувати переваги автоматизації. Автоматизація здатна в буквальному сенсі слова врятувати вашу репутацію, суттєво заощадити час і дати вам те, що було...

2

Якісно проведена робота фахівців QA вкрай важлива, оскільки вона дозволяє вам бути впевненим, що ваш веб-сайт буде мати такий функціонал, яким ви його задумали. Хочете дізнатися більше про роботу...

3

Місія QA-тестувальника найвідповідальніша на проекті, адже від нього залежить бездоганна якість сайту. А сьогодні у одного з наших тестувальників є ще одна місія, адже ми попросили його розповісти...

4

Важливими складовими якості веб-продукту є його кросбраузерність та кросплатформенність. Тестування того, як сторінки вашого продукту відображаються на різних десктопних браузерах та мобільних...

5

Як забезпечити себе стабільною автоматизованою системою тестування на базі Jenkins i Selenium.

Subscribe to our blog updates