Діаграми Прецедентів (Use Case UML Diagram)

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

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

Елементи Діаграми Прецедентів:
o Актор – користувач.
o Прецедент – випадок використання, дія. Позначається овалом.
o Граничні межі системи охоплюють усі випадки використання у системі.
Позначається прямокутником.

Елементи взаємодії Діаграми Прецедентів:
o Використовує – користувач виконує дію.
o Включає – один прецедент використовує іншого.
o Розширює – представлення дочірніх прецедентів.
o Вимагає – наступний прецедент вимагає виконання попереднього.
o Схожий – прецеденти подібні, але описують різну функціональність.
o Рівнозначний - подібна функціональність, але користувач сприймає, як різну.

Тестування Функціональних Вимог

1. Визначити цілі проекту та їх пріоритетність
Виписати основні цілі проекту. Обговорити із замовником необхідність розробки не важливих та сумнівних цілей. Визначити їх пріоритетність.

2. Перевірити цілісність і прозорість функціональних вимог.
Чітко визначити які функції система повинна і не повинна виконувати.

3. Виявити неоднозначні вирази.
Створити тлумачний словник для чіткого визначення неоднозначних термінів. Уточнити у замовника визначення кожного з них.

Перелік основних пунктів Функціональних Вимог:

-Назва
-Короткий опис
-Актори
-Основний потік
-Альтернативний потік
-Передумови
-Післяумови
-Особливі вимоги
-Залежності

Тест План

1. Вступ (Introduction)
Коротко, але зрозуміло і достатньо про продукт

2. Джерельні Документи (Related Documents)
Список джерел інформації

3. Пункти Тестування (Test Items)
Що буде тестуватися

4. Функціональність буде/не буде Тестуватися (Feature to be/not to be Tested)
Функціональність, яка буде/не буде тестуватися

5. Тест Підхід/ Тест Дизайн/ Тест Випадки (Test Approach/Test Design/Test Cases)
Як це буде тестуватися

6. Критеріїї Успішного/Неуспішного Результату ( Pass/Fail Criteria)
Критерії успішного/неуспішного результату

7. Оцінка (Estimations)
Скільки часу необхідно затратити на тестування

8. Середовище (Environment)
У якому середовищі необхідно тестувати

9. Відповідальність (Resource Responsibilities)
Скільки працівників і хто за що відповідальний

10. Ризики і Наслідки (Risks and Contingencies)
Які проблеми можуть виникнути під час тестування і потенційні рішення

11. Графік Тестування (Scheduler)
Як і коли буде відбуватися інформування, відповідальних осіб за проект, про результати тестування

12. Тестові Результати (Test Deliverables)
Що (дані, документи, інше..) буде створено під час тестування і доставлено разом з продуктом

Функціональні та Не Функціональні Вимоги

1. Функціональні Вимоги (Functional Requirements)

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

2. Не Функціональні Вимоги (Non-Functional Requirements)

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

2.1. Вимоги до Інтерфейсу (Interface Requirements)

2.1.1. Апаратні Інтерфейси (Hardware Interfaces)
Апаратні інтерфейси необхідні для підтримки системи, включаючи логічну структуру, фізичні адреси і очікувану поведінку.

2.1.2. Інтерфейси ПЗ (Software Interfaces)
Назви Інтерфейсів програмного забезпечення з якими аплікація повинна взаємодіяти.

2.1.3. Звязки Інтерфейсів (Communications Interfaces)
Звязки інтерфейсу з іншими системами або приладами.

2.2. Апаратні та Програмні Вимоги (Hardware/Software Requirements)
Опис апаратної та програмної платформ, необхідних для підтримки системи.

2.3. Operational Requirements

2.3.1. Безпека та Конфіденційність (Security and Privacy)

2.3.2. Надійність (Reliability)

2.3.3. Відновлювальність (Recoverability)

2.3.4. Продуктивність (Performance)

2.3.5. Потенціал (Capacity)

2.3.6. Збереження даних (Data Retention)

2.3.7. Керування помилками (Error Handling)

2.3.8. Правила Перевірки (Validation Rules)

2.3.9. Узгоджені стандарти (Convention Standards)

Баґ

Основи теорії Баґу (Bug) на Lviv Software Developers Community.

Документація у тестуванні

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

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

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

З готовою документацією тестувати досить легко і приємно. Такий підхід, як мінімум, запевняє у максимальному тестовому покритті проекту. Також не варто обмежуватися тестовою документацією. Трішки творчого підходу при виконанні будь-якого завдання не завадить ;). Хорошим показником якості роботи тестера є тип і пріоритетність знайдених Багів, котрі також повинні бути задокументовані у зрозумілому стилі.
Кінцевий підсумок про якість продукту, який базується на результатах тестування, тобто знайдених Багах, зображається у Тестовому Звіті.
Найкращим шаблоном документу є той який є зручним для усіх хто його читає :).

UML Діаграми

UML - (англ. Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання. Вона є невід'ємною частиною процесу розробки програмного забезпечення.
UML Diagrams – діаграми написані (намальовані) мовою UML.

UML діаграми поділяються на типи:
• Структурні
o Діаграма класів (Class Diagram)
o Діаграма об’єктів (Object Diagram)
o Діаграма компонентів (Component Diagram)
o Діаграма композитів (Composite Structural Diagram)
oo Діаграма кооперацій (Collaboration)
o Діаграма розгортання (Deployment Diagram)
o Діаграма пакетів (Package Diagram)

• Поведінкові
o Діаграми взаємодії (Interaction Diagram)
oo Діаграма послідовності (Sequence Diagram)
oo Діаграма комунікації (Communication Diagram)
oo Діаграма огляду взаємодії (Interaction Overview Diagram)
oo Діаграма синхронізації (Timing Diagram)
o Діаграма діяльності (Activity Diagram)
o Діаграма прецедентів (Use case diagram)
o Діаграма станів (State Machine diagram)

Планування тестування малих проектів

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

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