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

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

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

Requirements Traceability Matrix

7 Принципів Тестування

Принцип 1. Тестування виявляє присутність дефектів.
Тестування виявляє, що дефекти присутні, але не може запевнити, що дефекти відсутні. Тестування зменшує ймовірну кількість незнайдених дефектів, та якщо дефектів не знайдено, це не гарантує їхньої відсутності.

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

Принцип 3. Раннє тестування.
Тестування розпочинається так швидко як це можливо і фокусується на визначенні цілей.

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

Принцип 5. Парадокс пестицидів.
Якщо тестування повторюється, то один набір тест кейсів не буде знаходити нові дефекти. Уникнути "парадокс пестицидів" можна регулярною перевіркою, оновленням, та дописуванням нових тестів.

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

Принцип 7. Відсутність дефектів оманлива.
Знаходження та виправлення дефектів не допомагає, якщо система непридатна і не задовільняє потреб та очікувань користувача.

*ISTQB Foundation Level Syllabus

QA Management tool - QMetry

QMetry

1. Requirements -
* manage your test requirements,
* provides complete traceability from requriements - testcases - defects
* can import your requirement from xls/.csv to QMetry

2. Test Plan -
* Manage your testplan according to the IEEE standandard
* Customize it to match you requirement

3. Test cases/Suites/Status
* Define test cases
* Link them to requirements / defects
* Create test suite and bundle test cases to them
* Create environments/platforms to record your test case run results again
* Attach test logs and write comments for collaborative mode
* Record your run results for later comparison

4. Bugs:
QMetry is integrated with tools across testing lifecycle due to its strong web based API:
* Test Automation tools like - QTP, Selenium, Silk test
* Bug tracking tool - JIRA, Bugzilla, Mantis
* Other tools - Elementool, Targetprocess

5. Test Reports:
* We have exhaustive reports for traceability, testcases, defects at project level, across releases, across builds
* We also have standard queries & we publish our Read only database schema using which you can write your own custom queries and pull out almost anything from QMetry

6. Test Metrics:
* QMetry dashboard has 30+ metrics with pie charts/line graphs/bar charts
* Graphs have complete drill down
* Metrics can be downloaded in pdf and mailed across to team members
* view data in graphical format or tabular/data grid view
* Add the graphs important to you to your favorite for ease of navigation

7. Others:
* Version control - change management across QMetry, smallest of the change recorded by which field changed, who made the change, when was the change made etc.
* Sort, search, filter option
* Email notification for geographically distribute team to function in tandem
*Role based security - create your own roles and define access rights
* Can add User defined fields and modify the custom lists
* Import to and export from xls/.csv requirements, test cases, test suite run results
* Extensive release & build management
* copy testcases/requirements/testsuite from one build/release/project to another.

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

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

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

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

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