Кожен тестувальник так чи інакше знайомий з концепцією випадкових збоїв автоматизованих тестів.

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

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

Але чи це ефективно? Відповідь не така очевидна і зрозуміла, як здається.

Чому тести не проходять: основні причини

• Тестове середовище ненадійне. Зазвичай тестове середовище не має достатніх апаратних системних ресурсів для належної роботи під навантаженням, що генерується автоматизованими тестами. Або воно може бути налаштоване неправильно;
• Очікування не використовуються (якщо ми говоримо про Selenium тести). Сам тест складений некоректно і не може врахувати всі можливі асинхронні події, які відбуваються в інтерфейсі під час тестування частини програмного забезпечення. У деяких випадках використання JS робить тести менш надійними.

Щоб отримати тільки успішні результати після запуску тесту (зелений колір), ми зазвичай використовуємо метод повторних спроб.

Це допомагає запустити невдалі тести ще раз або один раз, або необхідну кількість разів.

Але це може свідчити про те, що тести з якихось причин не проходять і помилка виникає через дефект системи.

Оскільки тести не пройшли з першого разу, але пройшли вдруге, вони можуть містити помилки.

Приклади з них:

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

Окрім того, що тести не можна аналізувати, метод повторних спроб має ще одну особливість: один тест виконується вдвічі довше. Спочатку його запускають, він зазнає невдачі, і його потрібно запустити ще раз (як мінімум).

Чи є альтернатива повторним спробам?

• Якщо використовується повільне або ненадійне середовище, слід відредагувати його. Це допоможе не загубитися серед шляхів тестування. І, безумовно, зробить програмний код зрозумілішим - він не міститиме жодних спроб, повторних спроб тощо;
• Якщо мова йде про тести, ви повинні відредагувати їх або замінити іншими тестами. Члени QA лабораторії повинні створювати найкращу та найнадійнішу версію тесту, а не просто редагувати частини програмного коду та видаляти тести, які здаються їм ненадійними. [highlight dark=”no”]Якщо середовище та вміст тесту не було відредаговано, будь-який запуск тесту має давати однакові результати.[/highlight] І вона має бути виконана в розумні строки, а не вдвічі довше.

Короткий висновок

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

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

Ніхто не буде аналізувати причини.

Тому неважко пропустити помилку, і це призведе до численних приміщень.

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