Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/qalight/qalight.com.ua/lviv/wp-includes/plugin.php on line 601

Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given in /home/qalight/qalight.com.ua/lviv/wp-includes/plugin.php on line 601
Коли починати тестування? - QALight

База знань

Коли починати тестування?

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

Так, в даному випадку, доречно говорити про початок окремих активностей процесу тестування (тестування проектної документації, планування тестування, розробка і виконання тестів). При цьому, для кожної з них необхідно встановити критерій, щоб визначити їх межі та дати оцінку : критерій повинен бути вимірюваною величиною, із зазначенням  її критичного значення (наприклад, починаємо з тестування вимог, коли вони будуть готові на 100%).

Оскільки, критерій завжди унікальний і залежить від кожної конкретної ситуації, позначити точні критерії початку тестування в цілому – неможливо.

Але, при формуванні критеріїв потрібно зрозуміти:

  • що мається на увазі під словом «тестування». Якщо мова йде про динамічне тестування – тобто, контроль якості коду (QC), то очевидно, що тестування почнеться тільки тоді, коли буде готовий код (також – згідно з критеріями його готовності). Якщо говорити про статичне тестування, тобто про сферу забезпечення якості процесу (QA) , тоді тестування починається на стадії проектування, і передбачає тестування вимог;
  • з якого рівня (або – з кого) починається відлік процесу тестування. Якщо це модульне або інтеграційне тестування – його проводить програміст, тестувальник ж тестує ПЗ на Системному рівні. А, наприклад, Бізнес- і Системний аналітики тестують ПЗ вже на етапі Планування – тобто, на рівні Ідеї;
  • особливості використовуваної моделі розробки ПЗ, а також специфіку організації процесів, унікальність команди, і навіть  слід врахувати наявність / відсутність обладнання для тестування. 

У будь-якому з цих випадків, всім, хто причетний до проекту, необхідно керуватися правилами, що:

  • чим раніше дефект буде виявлений, тим дешевше він буде коштувати і тим менше зусиль піде на його виправлення;
  • чим раніше в життєвому циклі ПЗ починається тестування, тим більше з’являється можливостей вплинути на якість майбутнього продукту, адже, більшість фахівців сходяться в думці, що значна кількість багів виникає на етапі складання вимог до системи.
Коли завершувати/закінчувати/зупиняти/призупиняти або продовжувати тестування?

«Тестування програм може використовуватися для демонстрації наявності помилок, але воно ніколи не покаже їх відсутність »- це слова нідерландського вченого-розробника Едсгера Дейкстра, відомі, напевно, всім, хто причетний до розробки ПЗ. Вони означають , що, по крайній мірі на сьогоднішній день, не існує такого методу тестування, який би дозволив виявити повністю всі дефекти досліджуваного продукту. Звичайно, є узагальнюючі рекомендації, наприклад, що ПЗ можна вважати готовим до випуску, коли усунуті абсолютно всі критичні помилки і приблизно 85% некритичних помилок. Однак, навіть з урахуванням заздалегідь встановлених критеріїв, появу нових – і критичних, і некритичних помилок передбачити практично неможливо.

Оскільки, тестування – це етап, за результатами якого, образно кажучи, «виноситься вирок» проекту, то відповідальність за кінцеву якість ПЗ, по суті, лягає на тестувальників. Звичайно, фактично  рішення про фінальну точку проекту приймає Менеджер (або Замовник) проекту, однак, саме тестувальники, будучи ланкою, що завершує розробку, можуть значно вплинути на рішення керівництва. 

Так, від тестувальників залежить, чи буде:

  • проект виконаний (тобто, завершений, як передбачалося);
  • проект закінчений (тобто, зупинений, або перерваний – завершений не так, як передбачалося);
  • проект не закінчений, тобто, тестування триватиме. 

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

Ось перелік таких ситуацій і пов’язані з ними  питання:

  • Час, відведений на проект, вийшов. Чи достатньо у нас інформації про стан продукту на даний момент? Можливо, термін був встановлений штучно або довільно? Які ризики – і в разі зупинки, і в разі продовження? Можливі й виправдані допрацювання, які вимагатимуть подальшого тестування?
  • Виявлена досить серйозна проблема. Чи справді ця проблема сама важлива – єдина, про яку варто турбуватися? Можливо, якщо тестування буде продовжено, будуть знайдені інші – ще більш значущі проблеми? Чи дійсно виявлена проблема важлива?
  • У програмі занадто багато помилок, і має сенс продовження тестування. Чи справді це ситуація максимального згущення багів, або ж можливо продовжити тестування і виявити ще більш важливу проблему?
  • Відповіли на всі, раніше встановлені питання. Які співвідношення між тими проблемами, які були відомі і які були вирішені / тими проблемами, які були відомі, але – не вирішено / і тими проблемами, які ще не відомі, але можуть виникнути? Які проблеми можна передбачити і яке їхнє значення для роботи системи щодо відомих проблем?
  • Замовник відміняє повноваження продовжувати (вичерпано бюджет, проект скасований, або – безліч інших причин, в тому числі – «Час вийшов»). Чи достатньо замовник обізнаний про обсяги продовження, а також – про ризики припинення?

 Ще один варіант скасування повноважень – коли, той, хто проводить тестування сам відмовляється його продовжувати.

  • Є те, що блокує процес (немає інформації, є блокуюча помилка, яка не дає можливості тестувати область, яку потрібно тестувати, немає обладнання, або – інструментів, або – людини, який може провести спеціалізований тест). Чи справді те, що блокує, є нерозв’язною проблемою?

Можливо, мета тестування в тому й полягала, щоб дізнатися, чого бракує?

  • Необхідна пауза. Що йде не так? Що зроблено до сих пір? Які завдання більш пріоритетні?
  • Немає явних змін в поведінці програми. Система крешиться , або стабілізується? Можливо, відсутність результату – це теж результат, чи потрібно з цим щось робити?
  • Загальноприйняте рішення завершити (коли зроблено те, що було заплановано).

Може бути, є щось ще?

  • Немає цікавих питань, вирішення яких виправдовувало б вартість продовження. Що є що? Що потрібно? Які пріоритети? Які ризики?
  • Немає мотивації або переконливих бізнес-причин продовжувати (або виправляти вже відому проблему). Тоді – навіщо було починати?

Набагато більше інформації на курсі базовий модуль тестування