Продовжуємо опрацьовувати сілабус, секцію 1.2, а саме:
- важливість тестування; внесок тестування в успіх проєкту
- Quality Assurance (підтвердження якості) та тестування
- Помилки, Дефекти та Збої
- Дефекти, Кореневі причини та Вплив
Чому тестування є важливим? (версія 3.1)
Ретельне тестування компонентів і систем, а також пов’язаної з ними документації може допомогти зменшити ризик збоїв, що виникають під час експлуатації.
Коли дефекти виявлені та згодом усунені, це сприяє підвищенню якості компонентів або систем. Крім того, тестування програмного забезпечення також може знадобитися для відповідності договірним або юридичним вимогам або галузевим стандартам.
Чому тестування є важливим? (версія 4.0)
Тестування, як форма контролю якості, допомагає досягти узгоджених цілей у межах встановленого обсягу, часу, якості та бюджету. Внесок тестування в успіх не повинен обмежуватися діяльністю тестової групи. Будь-яка зацікавлена сторона може використати свої навички тестування, щоб наблизити проєкт до успіху. Тестування компонентів, систем і відповідної документації допомагає виявити дефекти програмного забезпечення.
Внесок тестування в упіх проєкту (версія 3.1)
Протягом всієї історії обчислювальної техніки досить часто програмне забезпечення та системи вводилися в експлуатацію та, через наявність дефектів, згодом викликали збої або іншим чином не відповідали потребам зацікавлених сторін. Однак використання відповідних методів тестування може зменшити частоту таких проблемних випусків програмних продуктів, якщо ці методи застосовуються з належним рівнем досвіду тестування, на відповідних рівнях тестування та у відповідних точках життєвого циклу розробки програмного забезпечення.
Приклади:
- Залучення тестувальників до перегляду вимог або вдосконалення історії користувача може виявити дефекти в цих робочих продуктах. Виявлення та усунення дефектів вимог зменшує ризик розробки неправильних функцій або функцій, які неможливо протестувати.
- Якщо тестувальники тісно співпрацюють із системними архітекторами або дизайнерами під час проектування системи, це може покращити розуміння кожною стороною архітектури або дизайну та способів його тестування. Це покращене розуміння може зменшити ризик фундаментальних дефектів архітектури та дозволить виявити тести на ранній стадії.
- Тісна співпраця тестувальників із розробниками під час розробки коду може покращити розуміння коду кожною стороною та способів його тестування. Це покращене розуміння може зменшити ризик дефектів у коді та тестах.
- Тестери верифікують і валідують програмне забезпечення перед випуском, щоб виявити збої, які інакше могли б бути пропущені, і підтримати процес усунення дефектів, які викликали збої (тобто, налагодження – дебаг). Це підвищує ймовірність того, що програмне забезпечення буде відповідати потребам зацікавлених сторін і вимогам.
На додачу до цих прикладів, досягнення визначених цілей тестування сприяє загальному успіху розробки та обслуговування програмного забезпечення.
Внесок тестування в успіх проєкту (версія 4.0)
Тестування є економічно ефективним засобом виявлення дефектів. Потім ці дефекти можна усунути (шляхом налагодження – нетестової діяльності), тому тестування опосередковано сприяє підвищенню якості тестових об’єктів.
Тестування забезпечує засоби безпосередньої оцінки якості тестового об’єкта на різних етапах SDLC (циклу розробки програмного забезпечення). Ці заходи використовуються як частина більшої діяльності з управління проєктом, сприяючи прийняттю рішень щодо переходу до наступного етапу SDLC, наприклад рішення про випуск.
Тестування надає користувачам непряме уявлення про проєкт розробки. Тестувальники гарантують, що їхнє розуміння потреб користувачів враховується протягом життєвого циклу розробки. Альтернативою є залучення репрезентативного набору користувачів до проєкту розробки, що зазвичай неможливо через високі витрати та відсутність відповідних користувачів. Тестування також може знадобитися для виконання договірних або юридичних вимог або для відповідності нормативним стандартам.
Quality Assurance та тестування (версія 3.1)
Хоча люди часто використовують фразу забезпечення чи підтвердження якості (Quality Assurance) для позначення тестування, забезпечення якості та тестування не те саме, але вони пов’язані. Їх об’єднує ширша концепція – управління якістю. Управління якістю включає всі види діяльності, які спрямовують і контролюють організацію щодо якості.
Серед інших видів діяльності управління якістю включає як забезпечення, так і контроль якості. Забезпечення якості, як правило, зосереджено на дотриманні належних процесів, щоб забезпечити впевненість у тому, що відповідні рівні якості будуть досягнуті. Коли процеси виконуються належним чином, робочі продукти, створені цими процесами, як правило, мають вищу якість, що сприяє запобіганню дефектів. Крім того, використання аналізу першопричин для виявлення та усунення причин дефектів разом із належним застосуванням висновків ретроспективних зустрічей для покращення процесів є важливим для ефективного забезпечення якості.
Контроль якості включає різноманітні види діяльності, у тому числі тестування, які підтримують досягнення відповідних рівнів якості. Тестування є частиною загального процесу розробки або обслуговування програмного забезпечення. Оскільки забезпечення якості стосується належного виконання всього процесу, забезпечення якості підтримує належне тестування. Тестування сприяє досягненню якості різними способами.
Quality Assurance та тестування (версія 4.0)
Хоча люди часто використовують терміни «тестування» та «забезпечення якості» (QA) як синоніми, тестування та QA – це не одне й те саме. Тестування є формою контролю якості (Quality Control).
Контроль якості – це орієнтований на продукт коригувальний підхід, який зосереджується на тих видах діяльності, які підтримують досягнення відповідних рівнів якості. Тестування є основною формою контролю якості, тоді як інші включають формальні методи (перевірка моделі та підтвердження правильності), моделювання та прототипування.
Забезпечення якості (QA) – це процесно-орієнтований превентивний підхід, який зосереджується на впровадженні та вдосконаленні процесів. Це працює на основі того, що якщо хороший процес виконується правильно, він створить хороший продукт. Контроль якості стосується як процесу розробки, так і тестування, і є відповідальністю кожного учасника проєкту.
Результати тестування використовуються QA та QC. У QC вони використовуються для усунення дефектів, тоді як у QA вони забезпечують зворотній зв’язок про те, наскільки добре виконуються процеси розробки та тестування.
Помилки, Дефекти та Збої (версія 3.1)
Людина може зробити помилку, яка може призвести до появи дефекту у програмному коді або в іншому пов’язаному робочому продукті. Помилка, яка призводить до появи дефекту в одному робочому продукті, може викликати помилку, яка призводить до виникнення дефекту в пов’язаному робочому продукті. Наприклад, помилка виявлення вимог може призвести до дефекту вимог, що потім призводить до помилки програмування, яка призводить до дефекту коду.
Якщо код виконується з дефектом, це може спричинити збій, але не обов’язково за всіх обставин. Наприклад, деякі дефекти вимагають дуже конкретних вхідних даних або попередніх умов, щоб викликати збій, який може відбуватися рідко або ніколи.
Помилки можуть виникати з багатьох причин, наприклад:
- Тиск часу
- Схильність людей до помилок
- Недосвідчені або недостатньо кваліфіковані учасники проєкту
- Непорозуміння між учасниками проєкту, в тому числі нерозуміння вимог і дизайну
- Складність коду, дизайну, архітектури, основної проблеми, яку потрібно вирішити, та/або використовуваних технологій
- Непорозуміння щодо внутрішньосистемних і міжсистемних інтерфейсів, особливо коли таких внутрішньосистемних і міжсистемних взаємодій велика кількість
- Нові, незнайомі технології
Окрім збоїв, спричинених дефектами коду, збої також можуть бути спричинені умовами навколишнього середовища. Наприклад, радіація, електромагнітні поля та забруднення можуть спричинити дефекти вбудованого програмного забезпечення або вплинути на виконання програмного забезпечення, змінюючи стан обладнання.
Не всі несподівані результати тестування є невдалими. Помилкові спрацьовування можуть виникнути через помилки у способі виконання тестів або через дефекти тестових даних, тестового середовища чи іншого тестового програмного забезпечення, або з інших причин. помилкові спрацьовування повідомляються як дефекти, але насправді не є дефектами.
Може виникнути й зворотна ситуація, коли подібні помилки чи дефекти призводять до хибно негативних результатів. Хибнонегативні – це тести, які не виявляють дефектів, які вони мали б виявити.
Дефекти, Кореневі причини та Вплив (версія 3.1)
Кореневими причинами дефектів є перші дії або умови, які сприяли виникненню дефектів. Дефекти можна проаналізувати, щоб визначити їх першопричину, щоб зменшити кількість подібних дефектів у майбутньому. Зосереджуючись на найважливіших першопричинах, аналіз першопричин може призвести до вдосконалення процесу, що запобігає появі значної кількості майбутніх дефектів.
Наприклад, припустімо, що неправильні виплати відсотків через один рядок неправильного коду призводять до скарг клієнтів. Несправний код був написаний для історії користувача, яка була неоднозначною через неправильне розуміння власником продукту того, як розраховувати відсотки. Якщо в розрахунках відсотків існує велика частина дефектів, і ці дефекти мають свою першопричину в подібних непорозуміннях, власники продукту можуть пройти навчання з теми розрахунків відсотків, щоб зменшити кількість таких дефектів у майбутньому.
У цьому прикладі скарги клієнтів є наслідками. Неправильні виплати відсотків є збоями. Неправильний розрахунок у коді є дефектом, і він став результатом оригінального дефекту, неоднозначності в історії користувача. Основною причиною початкового дефекту був брак знань з боку власника продукту, що призвело до того, що власник продукту зробив помилку під час написання історії користувача.
Дефекти, Кореневі причини та Вплив (версія 4.0)
Люди роблять помилки (помилки), які породжують дефекти (несправності), які, у свою чергу, можуть призвести до збоїв. Люди роблять помилки з різних причин, таких як нестача часу, складність робочих продуктів, процесів, інфраструктури чи взаємодії, або просто тому, що вони втомилися чи не мають належного навчання.
Дефекти можна знайти в документації, такій як специфікація вимог або тестовий сценарій, у вихідному коді або в супровідному артефакті, наприклад у файлі збірки. Дефекти в артефактах, створених раніше в SDLC, якщо їх не виявити, часто призводять до дефектних артефактів пізніше в життєвому циклі. Якщо код виконується з дефектом, система може не виконувати те, що повинна робити, або робити те, чого вона не повинна робити, що спричинить збій. Деякі дефекти завжди призведуть до збою, якщо їх виконати, тоді як інші призведуть до збою лише за певних обставин, а деякі можуть ніколи не призвести до збою.
Помилки і дефекти – не єдина причина збоїв. Збої також можуть бути спричинені умовами навколишнього середовища, наприклад, коли радіація або електромагнітне поле спричиняють дефекти мікропрограми.
Коренева причина – це основна причина виникнення проблеми (наприклад, ситуація, яка призводить до помилки). Основні причини визначають за допомогою аналізу першопричин, який зазвичай виконується, коли виникає збій або виявляється дефект. Вважається, що можна запобігти подальшим подібним збоям або дефектам або зменшити їх частоту шляхом усунення першопричини, наприклад, її усунення.
В цьому відео починаємо працювати з секцією 1.2.
01:09 Чому тестування є важливим?
04:25 Внесок тестування в успіх проєкту
13:30 Quality Assurance (Підтвердження тестування) та тестування
23:05 Помилки, Дефекти та Збої
33:28 Дефекти, Кореневі причини та Вплив