Матриця Прослідковування планування розробки Тест Кейсів

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

Методи Дизайну Тестів

Test Design Techniques

Specification-based or Black-box Techniques:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Table Testing
- State Transition Testing
- Use Case Testing

Structure-based or White-box Techniques:
- Statement Testing and Coverage
- Decision Testing and Coverage
- Condition coverage and multiple condition coverage

Experience-based techniques:
- Error guessing
- Exploratory testing

*ISTQB Foundation Level Syllabus

Методи Тестування

Test Techniques

1. Based on the software engineer’s intuition and experience
1.1. Ad-hoc testing
1.2. Exploratory testing

2. Specification-based techniques
2.1. Equivalence partitioning
2.2. Boundary-value analysis
2.3. Decision table
2.4. Finite-state machine-based
2.5. Testing from formal specifications
2.6. Random testing

3. Code-based techniques
3.1. Control-flow-based criteria
3.2. Data flow-based criteria
3.3. Reference models for code-based testing

4. Fault-based techniques
4.1. Error guessing
4.2. Mutation testing

5. Usage-based techniques
5.1. Operational profile
5.2. Software Reliability Engineered Testing

6. Techniques based on the nature of the application
6.1. Object-oriented testing
6.2. Component-based testing
6.3. Web-based testing
6.4. GUI testing
6.5. Testing of concurrent programs
6.6. Protocol conformance testing
6.7. Testing of real-time systems
6.8. Testing of safety-critical systems

7. Selecting and combining techniques
7.1. Functional and structural
7.2. Deterministic vs. random

*Guide to the Software Engineering Body of Knowledge (IEEE -Computer Society)

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

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

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

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

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