Чи замислювалися ви коли-небудь над тим, чому баг може бути пропущений і як реагувати на таку ситуацію? Прочитайте нижче, щоб знайти відповіді на це питання.

1. Він просто захований у всіх на виду.

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

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

Як з цим боротися: Такі помилки типу “D’oh!” хороші тим, що вони нагадують нам про те, що новий погляд на наш додаток дуже важливий. Виконуючи тести, не дозволяйте собі дивитися на щось за звичкою. Будьте уважні до деталей і спробуйте поставити себе на місце нового користувача.

2. Для тестування було недостатньо часу, що призвело до навмисного пропуску ділянки.

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

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

Як з цим боротися: якщо цей розділ програми пропущено свідомо, з урахуванням усіх можливих ризиків, то все, що ви зробили, - правильно! Виявивши проблему, вам потрібно створити баг-звіт і продовжувати роботу.

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

3. Було недостатньо часу для тестування, що призвело до випадкового пропуску ділянки.

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

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

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

4. Незважаючи на те, що відкриття було зроблено, виправити його тут і зараз було дуже дорого.

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

Як з цим боротися: ви повинні надавати якомога кращий зворотній зв’язок під час процесу тестування і ділитися ним часто і на ранніх етапах. Ваші тестові нотатки повинні бути стислими і чіткими, але ваші звіти про помилки повинні бути зроблені так, щоб дозволити розробнику вирішити решту проблем, якщо остаточне рішення полягає у випуску з помилками.

[highlight dark=”no”]NB. Забезпечення якості розробки програмного забезпечення необхідне для забезпечення поглибленого висвітлення найважливіших питань, концепцій, технологій у програмному забезпеченні. Зазвичай виконується під керівництвом тестувальників, менеджерів продуктів та розробників. [/highlight]