Чому потрібне тестування?

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

• особи, які приймають рішення, запитують інформацію про показники якості елемента тестування;

• елемент, що перевіряється (і) тестування не завжди робить те, що від нього (їх) очікується;

• необхідно провести верифікацію елемента(ів) тестування, що перевіряється(их);

• необхідно провести валідацію елементу(ів) тестування, що перевіряється(их), та/або

• необхідно провести оцінку елемента тестування по всьому життєвому циклу розробки програмного забезпечення та систем.

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

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

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

Джерело:

• ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013

Дод. матеріал:

• Світ без QA

• Продукт без тестування

• «Відповідальність має бути на інженерах, які пишуть код». Чому у People.ai відмовилися від QA-команди і що це дало

• Чужі помилки та успіхи: Космічні уроки для QA (частина 2)

• Why is software testing necessary?

• Що робити без тестувальника

• 7 епічних багів в історії людства

• Епічні баги минулого

• Гей, QA! Чому ви не знайшли цей баг?

• Blog: “Why Didn't We Catch This in QA?”

• Blog: Testers: Get Out of the Quality Assurance Business

• Бути чи не бути: дискусії про тестування у мобільній розробці

• Чи потрібні у команді виділені тестувальники?