Теорія тестування. теорія. Тестування програмного забезпечення
 Скачать 476.1 Kb.
|
|
Тестування програмного забезпечення — перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування - це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis). Якість програмного забезпечення (Software Quality) - це сукупність параметрів програмного забезпечення, що належать до його здатності задовольняти встановлені та передбачувані потреби. [Quality management and quality assurance] Верифікація (verification) - це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованих на початку цього етапу [IEEE]. Тобто. чи виконуються наші цілі, терміни, завдання розробки проекту, визначені на початку поточної фази. Валідація ( validation) - це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи [BS7925-1]. Також можна зустріти іншу інтерпретацію: Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification), водночас оцінка відповідності продукту очікуванням та вимогам користувачів є валідація (validation). Також часто можна зустріти таке визначення цих понять: Validation - 'is this the right specification?'. Verification - 'is the system correct to specification?'. Цілі тестування Підвищити ймовірність того, що програма, призначена для тестування, буде працювати правильно за будь-яких обставин. Підвищити ймовірність того, що програма, призначена для тестування, буде відповідати всім описаним вимогам. Надання актуальної інформації про стан продукту зараз. Етапи тестування: 1. Аналіз продукту 2. Робота з вимогами 3. Розробка стратегії тестування та планування процедур контролю якості 4. Створення тестової документації 5. Тестування прототипу 6. Основне тестування 7. Стабілізація 8. Експлуатація Тест план (Test Plan) - це документ, що описує весь обсяг робіт з тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення . Відповідає на запитання: Що треба випробувати? Що тестуватимете? Як тестуватимете? Коли тестуватимете? Критерії початку тестування. Критерії закінчення тестування. Основні пункти тест плану У стандарті IEEE 829 перераховані пункти, з яких повинен (нехай може) складатися тест-план: a) Test plan identifier; b) Introduction; c) Test items; d) Features to be tested; e) Features not to be tested; f) Approach; g) Item pass/fail criteria; h) Suspension criteria and resumption requirements; i) Test deliverables; j) Testing tasks; k) Економічні потреби; l) Responsibilities; m) Staffing and training needs; n) Schedule; o) Risks and contingencies; p) Approvals. Вступ; в) Тестові завдання; d) характеристики, що підлягають перевірці; e) характеристики, які не підлягають перевірці; е) Підхід; g) критерії відповідності/невідповідності предмету; h) критерії призупинення та вимоги щодо відновлення; i) результати тестування; j) Тестові завдання; k) Економічні потреби; л) Обов'язки; m) потреби в кадрах та навчанні; n) Розклад; o) Ризики та непередбачені обставини; р) Погодження. Тест дизайн - це етап процесу тестування ПЗ, на якому проектуються та створюються тестові сценарії (тест кейси), відповідно до визначених раніше критеріїв якості та цілей тестування. Ролі, відповідальні за тест дизайн: • Тест аналітик – визначає «ЩО тестувати?» • Тест дизайнер – визначає «ЯК тестувати?» Техніки тест дизайну • Еквівалентний Поділ (Equivalence Partitioning – EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині інтервалу, скажімо, 5, і одне неправильне значення поза інтервалом - 0. • Аналіз межових значень (Boundary Value Analysis - BVA). Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше меж (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження. • Причина / Наслідок (Cause/Effect - CE). Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (Слідство). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як "Ім'я", "Адреса", "Номер Телефону", а потім, натиснути кнопку "Додати" - це "Причина". Після натискання кнопки «Додати» система додає клієнта в базу даних і показує його номер на екрані - це «Слідство». • Передбачити помилку (Error Guessing — EG). Це коли тестувальник використовує свої знання системи та здатність до інтерпретації специфікації на предмет того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести код". Тестувальник думатиме: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбаченням помилки. • Вичерпне тестування (Exhaustive Testing – ET) – це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. Насправді застосування цього методу неможливо, через величезної кількості вхідних значень. • Попарне тестування (Pairwise Testing) – це техніка формування наборів тестових даних. Сформулювати суть можна, наприклад, ось так: формування таких наборів даних, в яких кожне тестове значення кожного з параметрів, що перевіряються хоча б один раз поєднується з кожним тестованим значенням всіх інших параметрів, що перевіряються. Допустимо, якесь значень (податок) для людини розраховується на підставі її статі, віку та наявності дітей – отримуємо три вхідні параметри, для кожного з яких для тестів вибираємо якимось чином значення. Наприклад: стать - чоловіча або жіноча; вік - до 25, від 25 до 60, понад 60; наявність дітей - так чи ні. Для перевірки правильності розрахунків можна, звичайно, перебрати всі комбінації значень всіх параметрів: № 1 чоловік до 25 дітей немає 2 жінки до 25 дітей немає 3 чоловік 25-60 дітей немає 4 жінка 25-60 дітей немає 5 чоловік старше 60 дітей немає 6 жінок старших 60 дітей немає 7 чоловік до 25 дітей є 8 жінка до 25 дітей є 9 чоловік 25-60 діти є 10 жінка 25-60 діти є 11 чоловік старше 60 дітей є 12 жінка старша 60 дітей є А можна вирішити, що нам не потрібні поєднання значень всіх параметрів з усіма, а хочемо тільки переконатися, що ми перевіримо всі унікальні пари значень параметрів. Тобто, наприклад, з точки зору параметрів статі та віку ми хочемо переконатися, що ми точно перевіримо чоловіка до 25, чоловіка між 25 та 60, чоловіка після 60, а також жінку до 25, жінку між 25 та 60, ну і жінку після 60. І так само для всіх інших пар параметрів. І таким чином ми можемо отримати набагато менше наборів значень (у них є всі пари значень, правда деякі двічі): № підлога вік діти 1 чоловік до 25 дітей немає 2 жінки до 25 діти є 3 чоловік 25-60 діти є 4 жінка 25-60 дітей нeмає Traceability matrix - Матриця відповідності вимог - це двовимірна таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а заголовки рядків — тестові сценарії. На перетині - позначка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка. Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МСТ є невід'ємною частиною тест-плану. Тестовий сценарій (Test Case) - це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується. Приклад: Action Expected Result Test Result (passed/failed/blocked) Open page «login» Login page is opened Passed Кожен тест кейс повинен мати 3 частини: PreConditions Перелік дій, що призводять систему до стану придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить, що система перебуває у придатному щодо основного тест стану. Test Case Description Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про задоволення реалізації, поставлене вимогам PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту - initial state) Тест кейси поділяються за очікуваним результатом на позитивні та негативні: • Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається. • Негативний тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція, що викликається додатком, не виконується при спрацьовуванні валідатора. Чек-лист (check list) - це документ, що описує, що має бути протестовано. При цьому чек-аркуш може бути абсолютно різного рівня деталізації. Наскільки детальним буде чек-лист залежить від вимог до звітності, рівня знання продукту співробітниками та складності продукту. Як правило, чек-лист містить лише дії (кроки), без очікуваного результату. Чек-лист менш формалізований, ніж тестовий сценарій. Його доречно використовувати тоді, коли тестові сценарії будуть надмірними. Також чек-лист асоціюються із гнучкими підходами у тестуванні. Дефект (він же баг) - це невідповідність фактичного результату виконання програми очікуваного результату. Дефекти виявляються на етапі тестування програмного забезпечення, коли тестувальник проводить порівняння отриманих результатів роботи програми (компонента або дизайну) з очікуваним результатом, описаним у специфікації вимог. Error – помилка користувача, тобто він намагається використовувати програму іншим способом. Приклад - вводить літери в поля, де потрібно вводити цифри (вік, кількість товару тощо). У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message), з червоним хрестиком. Bug (defect) - помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли ніяк не контролюється введення користувача, в результаті неправильні дані викликають краші або інші "радості" у роботі програми. Або всередині програма побудована так, що спочатку не відповідає тому, що від неї очікується. Failure - Збій (причому не обов'язково апаратний) у роботі компонента, всієї програми чи системи. Тобто є такі дефекти, які призводять до збоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, ніяк не пов'язаний із software, теж є failure. Баг Репорт (Bug Report) – це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату. Шапка Короткий опис (Summary) Короткий опис проблеми, що явно вказує на причину та тип помилкової ситуації. Проект (Project) Назва тестованого проекту Компонент програми (Component) Назва частини або функції продукту, що тестується Номер версії (Version) Версія на якій була знайдена помилка Серйозність (Severity) Найбільш поширена п'ятирівнева система градації серйозності дефекту: • S1 Блокуючий (Blocker) • S2 Критичний (Critical) • S3 Значний (Major) • S4 Незначний (Minor) • S5 Тривіальний (Trivial) Пріоритет (Priority) Пріоритет дефекту: • P1 Високий (High) • P2 Середній (Medium) • P3 Низький (Low) Статус (Status) Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle) Автор (Author) Автор баг репорта Призначений на (Assigned To) Ім'я співробітника, призначеного на вирішення проблеми Оточення ОС / Сервіс Пак і т.д. / Браузера + версія / ... Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера тощо. ... Опис Кроки відтворення (Steps to Reproduce) Кроки, за якими можна легко відтворити ситуацію, що призвела до помилки. Фактичний Результат (Result) Результат, отриманий після проходження кроків до відтворення Очікуваний результат (Expected Result) Очікуваний правильний результат Додатки Прикріплений файл (Attachment) Файл з логами, скріншот або будь-який інший документ, який може допомогти пояснити причину помилки або вказати спосіб вирішення проблеми Severity vs Priority Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми. Пріоритет (Priority) – це атрибут, який вказує на черговість виконання завдання або усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що вищий пріоритет, то швидше потрібно виправити дефект. Severity виставляється тестувальником Priority - менеджером, тiмлідом або замовником Градація Серйозності дефе/кту (Severity) S1 Блокуюча (Blocker) Блокуюча помилка, що приводить додаток у неробочий стан, в результаті якого подальша робота з системою, що тестується, або її ключовими функціями стає неможлива. Вирішення проблеми необхідне для подальшого функціонування системи. S2 Критична (Critical) Критична помилка, неправильно працююча ключова бізнес логіка, дірка в системі безпеки, проблема, що призвела до тимчасового падіння сервера або приводить в неробочий стан деяку частину системи, без можливості вирішення проблеми, використовуючи інші вхідні точки. Вирішення проблеми необхідне для подальшої роботи з ключовими функціями системою, що тестується. S3 Значна (Major) Значна помилка, частина основної бізнес-логіки працює некоректно. Помилка не критична або є можливість для роботи з функцією, що тестується, використовуючи інші вхідні точки. S4 Незначна (Minor) Незначна помилка, що не порушує бізнес логіку частини програми, що тестується, очевидна проблема інтерфейсу користувача. S5 Тривіальна (Trivial) Тривіальна помилка, що не стосується бізнес логіки програми, погано відтворювана проблема, малопомітна за допомогою інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не впливає на загальну якість продукту. Градація Пріоритету дефекту (Priority) P1 Високий (High) Помилка має бути виправлена якнайшвидше, т.к. її наявність є критичною для проекту. P2 Середній (Medium) Помилка повинна бути виправлена, її наявність не критична, але вимагає обов'язкового рішення. P3 Низький (Low) Помилка повинна бути виправлена, її наявність не критична, і не вимагає термінового вирішення. Рівні Тестування 1. Модульне тестування (Unit Testing) Компонентне (модульне) тестування перевіряє функціональність та шукає дефекти в частинах програми, які доступні та можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо). 2. Інтеграційне тестування (Integration Testing) Перевіряється взаємодія між компонентами системи після проведення компонентного тестування. 3. Системне тестування (System Testing) Основним завданням системного тестування є перевірка як функціональних, і функціональних вимог у системі загалом. При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т.д. 4. Операційне тестування (Release Testing). Навіть якщо система відповідає всім вимогам, важливо переконатися в тому, що вона відповідає потребам користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено в бізнес-моделі системи. Слід врахувати, що бізнес модель може містити помилки. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або програмних та електронних оточення; недостатня продуктивність системи серед експлуатації та інших. Вочевидь, що перебування подібних речей на стадії впровадження — критична і дорога проблема. Тому так важливо проведення не тільки верифікації, а й валідації з ранніх етапів розробки ПЗ. 5. Приймальне тестування (Acceptance Testing) Формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться з метою: • визначення, чи задовольняє система приймальним критеріям; • винесення рішення замовником або іншою уповноваженою особою приймається додатком чи ні. Види / типи тестування Функціональні види тестування • Функціональне тестування (Functional testing) • Тестування інтерфейсу користувача (GUI Testing) • Тестування безпеки (Security and Access Control Testing) • Тестування взаємодії (Interoperability Testing) Нефункціональні види тестування • Всі види тестування продуктивності: o навантажувальне тестування (Performance and Load Testing) o стресове тестування (Stress Testing) o тестування стабільності або надійності (Stability / Reliability Testing) o об'ємне тестування (Volume Testing) • Тестування установки (Installation testing) • Тестування зручності користування (Usability Testing) • Тестування на відмовлення та відновлення (Failover and Recovery Testing) • Конфігураційне тестування (Configuration Testing) Пов'язані зі змінами види тестування • Димове тестування (Smoke Testing) • Регресійне тестування (Regression Testing) • Повторне тестування (Re-testing) • Тестування складання (Build Verification Test) • Санітарне тестування або перевірка узгодженості/справності (Sanity Testing) Функціональне тестування розглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента чи системи загалом. Тестування інтерфейсу користувача (GUI Testing) - функціональна перевірка інтерфейсу на відповідність вимогам - розмір, шрифт, колір, consistent behavior. Тестування безпеки - це стратегія тестування, яка використовується для перевірки безпеки системи, а також для аналізу ризиків, пов'язаних із забезпеченням цілісного підходу до захисту додатків, хакерів, вірусів, несанкціонованого доступу до конфіденційних даних. Тестування взаємодії (Interoperability Testing) — це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає тестування сумісності (compatibility testing) та інтеграційне тестування Навантажувальне тестування — це автоматизоване тестування, що імітує роботу певної кількості бізнес-користувачів на якомусь загальному (розділеному ними) ресурсі. Стресове тестування (Stress Testing) дозволяє перевірити наскільки додаток і система загалом працездатні за умов стресу і оцінити здатність системи до регенерації, тобто. до повернення до нормального стану після припинення дії стресу. Стресом у цьому контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень чи аварійне зміна конфігурації сервера. Також одним із завдань при стресовому тестуванні може бути оцінка деградації продуктивності, таким чином цілі стресового тестування можуть перетинатися з метою тестування продуктивності. Об'ємне тестування (Volume Testing). Завданням об'ємного тестування є отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних програми Тестування стабільності або надійності (Stability/Reliability Testing). Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження. Тестування установки спрямоване на перевірку успішної інсталяції та налаштування, а також оновлення або видалення програмного забезпечення. Тестування зручності користування - це метод тестування, спрямований на встановлення ступеня зручності використання, навчання, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить: User eXperience (UX) – відчуття, яке випробовує користувач під час використання цифрового продукту, у той час як User interface – це інструмент, що дозволяє здійснювати інтеракцію «користувач – веб-ресурс». Тестування на відмовлення та відновлення (Failover and Recovery Testing) перевіряє тестований продукт з точки зору здатності протистояти та успішно відновлюватися після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмови обладнання або проблемами зв'язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублюючих основний функціонал систем), які, у разі виникнення збоїв, забезпечать безпеку та цілісність даних тестованого продукту. Конфігураційне тестування (Configuration Testing) - спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.) Димове (Smoke) тестування розглядається як короткий цикл тестів, що виконується для підтвердження того, що після складання коду (нового або виправленого) додаток, що встановлюється, стартує і виконує основні функції. Регресійне тестування - це вид тестування спрямований на перевірку змін, зроблених у додатку або навколишньому середовищі (лагодження дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб-сервер або сервер програми), для підтвердження того факту, що існуюча раніше функціональність працює як і раніше. Регресійними можуть бути як функціональні, і дисфункції тести. Повторне тестування – тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок. У чому різниця між regression testing та re-testing? Re-testing - перевіряється виправлення багів Regression testing - перевіряється те, що виправлення багів, а також будь-які зміни в коді програми не вплинули на інші модулі ПЗ і не викликало нових багів. Тестування складання або Build Verification Test — тестування, спрямоване на визначення відповідності, випущеної версії, критеріїв якості для початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на прийняття нової версії в подальше тестування або експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії. Санітарне тестування — це вузькоспрямоване тестування, достатнє для доказу того, що конкретна функція працює відповідно до заявлених у специфікації вимог. Є підмножиною регресійного тестування. Використовується для визначення працездатності певної частини програми після змін вироблених у ній чи навколишньому середовищі. Зазвичай виконується вручну. Підходи до інтеграційного тестування: • Знизу вгору (Bottom Up Integration) Усі низькорівневі модулі, процедури або функції збираються докупи і потім тестуються. Після чого збирається наступний рівень модулів щодо інтеграційного тестування. Цей підхід вважається корисним, якщо всі або практично всі модулі, що розробляються, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми. • Зверху донизу (Top Down Integration) Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Таким чином, ми проводимо тестування зверху вниз. • Великий вибух («Big Bang» Integration) Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то процес інтеграції сильно ускладниться, що стане перешкодою для команди тестування при досягненні основної мети інтеграційного тестування. Принципи тестування Принцип 1 — Тестування демонструє наявність дефектів (Testing shows presence of defects) Тестування може показати, що дефекти є, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що у програмному забезпеченні, але, навіть якщо дефекти були виявлено, це доводить його коректності. Принцип 2 — Вичерпне тестування є недосяжним (Exhaustive testing is impossible) Повне тестування з використанням усіх комбінацій вводів та передумов фізично нездійсненне, за винятком тривіальних випадків. Замість вичерпного тестування слід використовувати аналіз ризиків та розстановку пріоритетів, щоб точніше сфокусувати зусилля з тестування. Принцип 3 — Ранне тестування (Early testing) Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинні бути сфокусовані на певних цілях. Принцип 4 — Накопичення дефектів (Defects clustering) Зусилля тестування мають бути зосереджені пропорційно очікуваної, а пізніше реальної щільності дефектів за модулями. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили основну кількість збоїв системи, міститься в невеликій кількості модулів. Принцип 5 — Парадокс пестициду (Pesticide paradox) Якщо одні й ті самі тести проганятимуться багато разів, зрештою цей набір тестових сценаріїв більше не знаходитиме нових дефектів. Щоб подолати цей «парадокс пестициду», тестові сценарії повинні регулярно рецензуватися та коригуватися, нові тести мають бути різнобічними, щоб охопити всі компоненти програмного забезпечення, або системи, та знайти якнайбільше дефектів. Принцип 6 - Тестування залежить від контексту (Testing is concept depending) Тестування виконується по-різному залежно від контексту. Наприклад, програмне забезпечення, де критично важлива безпека, тестується інакше, ніж сайт електронної комерції. Принцип 7 — Помилка про відсутність помилок (Absence-of-errors fallacy) Виявлення та виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві та не задовольняє його очікуванням та потребам. Статичне та динамічне тестування Статичне тестування відрізняється від динамічного тим, що виконується без запуску програмного коду продукту. Тестування здійснюється шляхом аналізу програмного коду (code review) або скомпільованого коду. Аналіз може проводитись як вручну, так і за допомогою спеціальних інструментальних засобів. Метою аналізу є раннє виявлення помилок та потенційних проблем у продукті. Також до статичного тестування відноситься тестування специфікації та іншої документації. Дослідницьке / ad-hoc тестування Найпростіше визначення дослідницького тестування - це розробка та виконання тестів в один і той же час. Що є протилежністю сценарного підходу (з його наперед визначеними процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються точно відповідно до плану. Різниця між ad hoc та exploratory testing у тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідна майстерність та володіння певними техніками. Зверніть увагу, що певні техніки - це не тільки техніки тестування. Вимоги — це специфікація (опис) те, що має бути реалізовано. Вимоги описують те, що потрібно реалізувати, без деталізації технічного боку рішення. Що, а не як. Вимоги до вимог: • Коректність • Недвозначність • Повнота набору вимог • Несуперечність набору вимог • Перевірюваність (тестопридатність) • Трасування • Розумість Життєвий цикл бага Стадії розробки програмного забезпечення — це етапи, які проходять команди розробників програмного забезпечення, перш ніж програма стане доступною для широкого кола користувачів. Розробка ПЗ починається з початкового етапу розробки (стадія «пре-альфа») і продовжується стадіями, на яких продукт доопрацьовується та модернізується. Фінальним етапом цього процесу стає випуск ринку остаточної версії програмного забезпечення («загальнодоступного релізу»). Програмний продукт проходить такі стадії: аналіз вимог до проекту; • проектування; • реалізація; • тестування продукту; • використання та підтримка. Кожній стадії розробки програмного забезпечення присвоюється певний порядковий номер. Також кожен етап має власну назву, яка характеризує готовність продукту на цій стадії. Життєвий цикл розробки програмного забезпечення: • Пре-альфа • Альфа • Бета • Реліз-кандидат • Реліз • Пост-реліз Таблиця прийняття рішень (decision table) - чудовий інструмент для впорядкування складних бізнес-вимог, які повинні бути реалізовані в продукті. У таблицях рішень представлений набір умов, одночасне виконання яких має призвести до певної дії. QA/QC/Test Engineer Таким чином, ми можемо побудувати модель ієрархії процесів забезпечення якості: Тестування є частиною QC. QC – частина QA. Діаграма зв'язків — інструмент управління якістю, заснований на визначенні логічних взаємозв'язків між різними даними. Застосовується цей інструмент для зіставлення причин та наслідків із досліджуваної проблеми. |