Тестування. Фундаментальна теорія

Доброго часу доби!

Хочу зібрати всю найнеобхіднішу теорію тестирвоанию, яку запитують на співбесідах у trainee, junior і трошки middle. Власне, я зібрав вже не мало. Мета цього посту в тому, щоб спільно додати згаяне і виправити/перефразувати/додати/сделатьЧтоТоЕще з тим, що вже є, щоб стало добре і можна було взяти все це і повторити перед черговим співбесідою про всяк випадок. Вообщем, колеги, прошу під кат, кому почерпнути щось нове, кому систематизувати старе, а кому внести свою лепту.

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

В темі: визначення тестування, якість, верифікація / валідація, цілі, етапи, тест план, пункти тест плану, тест дизайн, техніки тест дизайну, traceability matrix, tets case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне і динамічне тестування, дослідне / ad-hoc тестування, вимоги, життєвий цикл бага стадії розробки ПО, decision table, qa/qc/test engineer, діаграма зв'язків.

Поїхали!

Тестування програмного забезпечення — перевірка відповідності між реальним і очікуваною поведінкою програми, здійснювана на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування — це одна з технік контролю якості, що включає в себе активності по плануванню робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) та аналізу отриманих результатів (Test Analysis).



Якість програмного забезпечення (Software Quality) — це сукупність характеристик програмного забезпечення, що відносяться до його здатності задовольняти встановлені і передбачувані потреби. [ISO 8402:1994 Quality management and quality assurance]



Верифікація (verification) — це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованим на початку цього етапу[IEEE]. Тобто виконуються наші цілі, терміни, завдання щодо розроблення проекту, визначені на початку поточної фази.
Валідація (validation) — це визначення відповідності розробляється З очікуванням і потребам користувача, вимогам до системи [BS7925-1].
Також можна зустріти іншу інтерпретацію:
Процес оцінки відповідності продукту явним вимогам (специфікацій) і є верифікація (verification), в той же час оцінка відповідності продукту очікуванням і вимогам користувачів — є валідація (validation). Також часто можна зустріти наступне визначення цих понять:
Validation — 'is this the right specification?'.
Verification — 'is correct the system 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 вимога;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.



Тест дизайн — це етап процесу тестування ПЗ, на якому проектуються і створюються тестові випадки (тест кейси), у відповідності з визначеними раніше критеріями якості і цілями тестування.
Ролі, відповідальні за тест дизайн:
• Тест аналітик — визначає «ЩО тестувати?»
• Тест дизайнер — визначає «ЯК тестувати?»



Техніки тест дизайну

Еквівалентне Поділ (Equivalence Partitioning — EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне вірне значення всередині інтервалу, скажімо, 5, і одне невірне значення поза інтервалу — 0.

Аналіз Граничних Значень (Boundary Value Analysis — BVA). Якщо взяти приклад вище, в якості значень для позитивного тестування виберемо мінімальну та максимальну межу (1 і 10), і значення, більше і менше кордонів (0 і 11). Граничний аналіз значень може бути застосований до полів записів, файлів, або до будь-якого роду сутностей мають обмеження.

Причина / Наслідок (Cause/Effect — CE). Це, як правило, введення комбінацій умов (причин), для отримання відповіді від системи (Наслідок). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як «Ім'я», «Адреса», «Номер Телефону» а потім, натиснути кнопку «Додати» — ця «Причина». Після натискання кнопки «Додати», система додає клієнта в базу даних і показує його на екрані — це «Наслідок».

Передбачення помилки (Error Guessing — EG). Це коли тест аналітик використовує свої знання системи і здатність до інтерпретації специфікації на предмет того, щоб «вгадати» при яких вхідних умов система може видати помилку. Наприклад, специфікація каже: «користувач повинен ввести код». Тест аналітик, буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? », і так далі. Це і є передбачення помилки.

Вичерпне тестування (Exhaustive Testing — ET) — це крайній випадок. В межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі, це повинно знайти всі проблеми. На практиці застосування цього методу не представляється можливим, з-за величезної кількості вхідних значень.



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 — менеджером, тимлидом або замовником

Градація Серйозності дефекту (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. Системне тестування (Testing System)
Основним завданням системного тестування є перевірка як функціональних, так і не функціональних вимог у системі в цілому. При цьому виявляються дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних користувацького рівня, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т. д.

4. Операційне тестування (Release Testing).
Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потреб користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено в бізнес моделі системи. Слід врахувати, що і бізнес модель може містити помилки. Тому так важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в області бізнесу або в програмних та електронних середовищах; недостатня продуктивність системи в середовищі експлуатації та ін. Очевидно, що знаходження подібних речей на стадії впровадження — критична і дорога проблема. Тому так важливо проводити не тільки верифікації, але і валідації, з самих ранніх етапів розробки ПЗ.

5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться з метою:
• визначення задовольняє система приймальним критеріям;
• винесення рішення замовником або іншою уповноваженою особою приймається додаток чи ні.



Види / типи тестування

Функціональні види тестування
• Функціональне тестування (Functional 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)

Функціональне тестування розглядає заздалегідь зазначене поведінка і ґрунтується на аналізі специфікацій функціональності компонента або системи в цілому.

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

Тестування взаємодії (Interoperability Testing) — це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає в себе тестування сумісності (compatibility testing) і інтеграційне тестування

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

Стресове тестування (Stress Testing) дозволяє перевірити наскільки додаток і система в цілому працездатні в умовах стресу і також оцінити здатність системи до регенерації, тобто до повернення до нормального стану після припинення дії стресу. Стресом у даному контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень або аварійне зміна конфігурації сервера. Також одним із завдань при стресовому тестуванні може бути оцінка деградації продуктивності, таким чином цілі стресового тестування можуть перетинатися з цілями тестування продуктивності.

Об'ємне тестування (Volume Testing). Завданням об'ємного тестування є отримання оцінки продуктивності при збільшенні обсягів даних в базі даних програми

Тестування стабільності та надійності (Stability / Reliability Testing). Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні з середнім рівнем навантаження.

Тестування установки направлено на перевірку успішної інсталяції та налаштування, а також оновлення або видалення програмного забезпечення.

Тестування зручності користування — це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості і привабливості для користувачів розроблюваного продукту в контексті заданих умов. Сюди також входить:
Тестування користувальницького інтерфейсу (англ. UI Testing) — це вид тестування дослідження, що виконується з метою визначення, чи зручний певний штучний об'єкт (такий як веб-сторінка, інтерфейс або пристрій) для його передбачуваного застосування.
User eXperience (UX) — відчуття, що випробовується користувачем під час використання цифрового продукту, в той час як User interface — це інструмент, що дозволяє здійснювати інтеракцію «користувач — веб-ресурс».

Тестування на відмову і відновлення (Failover and Recovery Testing) перевіряє досліджуваний продукт з точки зору здатності протистояти і успішно відновлюватися після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмовами обладнання або проблемами зв'язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублюючих основний функціонал систем), які, у разі виникнення збоїв, забезпечать збереження і цілісність даних досліджуваного продукту.

Конфігураційне тестування (Configuration Testing) — спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, підтримуваних драйвери, при різних конфігураціях комп'ютерів і т. д.)

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

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

Повторне тестування — тестування, під час якого виконуються тестові сценарії, які виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.
У чому різниця між regression testing і re-testing?
Re-testing — перевіряється виправлення багів
Regression testing — перевіряється те, що виправлення багів не вплинуло на інші модулі і не викликало нових багів.

Тестування складання або Build Verification Test — тестування спрямоване на визначення відповідності, випущеної версії, критеріям якості для початку тестування. По своїм цілям є аналогом Димового Тестування, спрямованого на прийняття нової версії подальше тестування або експлуатацію. Вглиб воно може проникати далі, в залежності від вимог до якості випущеної версії.

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

Передбачення помилки (Error Guessing — EG). Це коли тест аналітик використовує свої знання системи і здатність до інтерпретації специфікації на предмет того, щоб «вгадати» при яких вхідних умов система може видати помилку. Наприклад, специфікація каже: «користувач повинен ввести код». Тест аналітик, буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? », і так далі. Це і є передбачення помилки.

image



Підходи до інтеграційного тестування:

Знизу вгору " (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 необхідно майстерність і володіння певними техніками. Зверніть увагу, що певні техніки це не тільки техніки тестування.



Вимоги — це специфікація (опис) того, що повинно бути реалізовано.
Вимоги описують те, що необхідно реалізувати, без деталізації технічної сторони рішення. — Що, а не як.

Вимоги до вимог:
• Коректність
• Недвусмысленность
• Повнота набору вимог
• Несуперечність набору вимог
• Проверяемость (тестопригодность)
• Трассируемость
• Понимаемость



Життєвий цикл бага
image



Стадії розробки — це етапи, які проходять команди розробників ПЗ, перш ніж програма стане доступною для широко кола користувачів. Розробка ЗА починається з початкового етапу розробки (стадія «пре-альфа») і триває стадіями, на яких продукт допрацьовується і модернізується. Фінальним етапом цього процесу стає випуск на ринок остаточної версії програмного забезпечення («загальнодоступного релізу»).

Програмний продукт проходить наступні стадії:
• аналіз вимог до проекту;
• проектування;
• реалізація;
• тестування продукту;
• впровадження та підтримка.

Кожній стадії розробки ПО присвоюється певний порядковий номер. Також кожен етап має свою власну назву, яка характеризує готовність продукту на цій стадії.



Життєвий цикл розробки ПЗ:
• Пре-альфа
• Альфа
• Бета
• Реліз-кандидат
• Реліз
• Пост-реліз



Таблиця прийняття рішень (decision table) — чудовий інструмент для впорядкування складних бізнес вимог, які повинні бути реалізовані в продукті. У таблицях рішень представлений набір умов, одночасне виконання яких має призвести до певної дії.
image



QA/QC/Test Engineer
image
Таким чином, ми можемо побудувати модель ієрархії процесів забезпечення якості: Тестування — частина QC. QC — частина QA.



Діаграма зв'язків — це інструмент управління якістю, заснований на визначенні логічних взаємозв'язків між різними даними. Застосовується цей інструмент для зіставлення причин і наслідків з досліджуваної проблеми.
image



Джерела: www.protesting.ru, www.bugscatcher.net, www.qalight.com.ua, www.thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, www.bugsclock.blogspot.com www.zeelabs.com, www.devopswiki.net, www.hvorostovoz.blogspot.com.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.