1. Аналіз/Тестування Вимог до Продукту
2. Планування Тестування
3. Дизайн Тестів
4. Розробка Тестової Документації
5. Виконання Тестування
6. Аналіз Результатів та Покращення Тестування
7. Перетестовування
8. Звітування
9. Завершення Тестування
Показ дописів із міткою Тест Звіт. Показати всі дописи
Показ дописів із міткою Тест Звіт. Показати всі дописи
пʼятниця, 26 серпня 2011 р.
понеділок, 2 серпня 2010 р.
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.
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.
четвер, 8 липня 2010 р.
Денний/Тижневий Тест Звіт
Formulating test status reports based on daily status criteria.
Your management or the customer are asking for some very standard test status reports, so the good news is that this is relatively straightforward.
Test execution: The most important metrics in this are total test cases, test cases executed, test cases remaining, test execution rate, and "glidepath execution rate." Total test cases are, obviously, the total number of cases you must execute during this project. Test cases executed is the sum total of cases which have been executed (pass or fail, but NOT including "blocked" cases). Test cases remaining should be the sum of cases not executed plus cases blocked, for this metric represents all the work remaining. Test execution rate should be the average number of cases your team is executing per day. Finally, the glidepath is the rate of execution your team needs to maintain in order to complete the project.
To calculate the execution rate, take the total number of cases executed (passed, failed, but not "blocked") and divide by the number of working days. Note that you also have to communicate the number of cases failed and the time it will take to retest these. Some teams want you to report this as a separate metric, some teams want the "failed" cases to not count as executed, and be counted as remaining test cases.
To calculate the glidepath rate, take the total number of remaining cases divided by the number of days remaining in the project. If you have 100 test cases remaining, and 10 days left, you need to execute 10 test cases per day.
The critical thing to keep in mind here is what your manager or customer care about. They want to know two things, above all else: 1) Are you on track to be done on time, and 2) Is the product in good shape? The way they answer the on track question is simple -- is your average test case execution rate (the average number of cases executed per working day) higher than your glidepath rate? If yes, your project is probably green. If not, your project is yellow or red.
The next metric here is the test case failure rate. This is a strong indicator of product quality, as well as your test execution rate. If you have a 50% failure rate, that means 1 out of 2 test cases are failing. That indicates terrible requirements definition or engineering quality. If your failure rate is significantly less (10%, 5%) it probably means the requirements were well defined and the code quality is high. It could also mean that your test team is overlooking defects -- as project lead, you need to have your pulse on your team's performance, and be able (and willing) to tell management if you think your team is overlooking defects in the project. Failure rate is also helpful in calculating execution rate and glidepaths. Like I said, some teams want all tests executed counted in the execution rate, some only want passes (personally, as a manager I want to see the PASS rate as well as the executed rate). Calculating the failure rate is also simple -- how many test cases in 100 are failing?
Finally, bug rates. The most important bug metric right now is probably how many defects are generated per test case. So if you have executed 100 test cases, how many defects have resulted from those? Coupled with the count of remaining test, it's a good way to get a decent idea of how many defects are still 'lurking' in the product.
Metrics are a funny thing. They can be used for good or warped for bad. It's very important to focus on the metrics themselves, and separate the discussion of what the metrics might mean. Above all, if the metrics indicate a schedule or product risk, don't try to paint an artificially pretty picture. Be forthcoming in the information and help management through the repercussions.
Скопійована відповідь з http://searchsoftwarequality.techtarget.com/
Відповідь експерта John Overbaugh, Director of Quality Assurance, Medicity, Inc.
Your management or the customer are asking for some very standard test status reports, so the good news is that this is relatively straightforward.
Test execution: The most important metrics in this are total test cases, test cases executed, test cases remaining, test execution rate, and "glidepath execution rate." Total test cases are, obviously, the total number of cases you must execute during this project. Test cases executed is the sum total of cases which have been executed (pass or fail, but NOT including "blocked" cases). Test cases remaining should be the sum of cases not executed plus cases blocked, for this metric represents all the work remaining. Test execution rate should be the average number of cases your team is executing per day. Finally, the glidepath is the rate of execution your team needs to maintain in order to complete the project.
To calculate the execution rate, take the total number of cases executed (passed, failed, but not "blocked") and divide by the number of working days. Note that you also have to communicate the number of cases failed and the time it will take to retest these. Some teams want you to report this as a separate metric, some teams want the "failed" cases to not count as executed, and be counted as remaining test cases.
To calculate the glidepath rate, take the total number of remaining cases divided by the number of days remaining in the project. If you have 100 test cases remaining, and 10 days left, you need to execute 10 test cases per day.
The critical thing to keep in mind here is what your manager or customer care about. They want to know two things, above all else: 1) Are you on track to be done on time, and 2) Is the product in good shape? The way they answer the on track question is simple -- is your average test case execution rate (the average number of cases executed per working day) higher than your glidepath rate? If yes, your project is probably green. If not, your project is yellow or red.
The next metric here is the test case failure rate. This is a strong indicator of product quality, as well as your test execution rate. If you have a 50% failure rate, that means 1 out of 2 test cases are failing. That indicates terrible requirements definition or engineering quality. If your failure rate is significantly less (10%, 5%) it probably means the requirements were well defined and the code quality is high. It could also mean that your test team is overlooking defects -- as project lead, you need to have your pulse on your team's performance, and be able (and willing) to tell management if you think your team is overlooking defects in the project. Failure rate is also helpful in calculating execution rate and glidepaths. Like I said, some teams want all tests executed counted in the execution rate, some only want passes (personally, as a manager I want to see the PASS rate as well as the executed rate). Calculating the failure rate is also simple -- how many test cases in 100 are failing?
Finally, bug rates. The most important bug metric right now is probably how many defects are generated per test case. So if you have executed 100 test cases, how many defects have resulted from those? Coupled with the count of remaining test, it's a good way to get a decent idea of how many defects are still 'lurking' in the product.
Metrics are a funny thing. They can be used for good or warped for bad. It's very important to focus on the metrics themselves, and separate the discussion of what the metrics might mean. Above all, if the metrics indicate a schedule or product risk, don't try to paint an artificially pretty picture. Be forthcoming in the information and help management through the repercussions.
Скопійована відповідь з http://searchsoftwarequality.techtarget.com/
Відповідь експерта John Overbaugh, Director of Quality Assurance, Medicity, Inc.
четвер, 9 жовтня 2008 р.
Документація у тестуванні
Документація займає важливе місце у процесі розробки програмного забезпечення. Хоча, варто визнати, що комунікація є кермом ... Гуру бізнес-водіння умудряються розробляти проекти з мінімальною кількістю документів (ідеться про проекти, де задіяно до 5 осіб). Довготривалі проекти з числом виконавців більше трьох осіб прямують до нескінченної кількості непорозумінь і безвихідних ситуацій у випадку відсутності достатньої кількості документації.
Розробка проекту - це реалізація ідей, які умілі техрайтери перевтілюють у документ під скромною назвою Функціональні Вимоги. Досвідчені керівники проекту дають замовнику прочитати цей документ і підтвердити, що виконавець зрозумів усе вірно. Цей крок страхує від ризику витратити час і гроші на розробку продукту, який не є очікуваним замовником. Традиційно замовник отримуючи наступну версію продукту змінює вимоги або у нього появляться нові ідеї. За цим слідує оновлення функціональних вимог, затвердження їх замовником, оновлення усієї поточної документації. Змінюється часова оцінка, графік планування і так далі.
Тестерам варто розпочинати аналіз вимог. Часто це називають тестуванням вимог, яке супроводжується інтенсивною комунікацією між замовником і виконавцем з метою створити єдине узгоджене спільне бачення продукту. Також відповідальний за тестування намагається уявити собі весь процес тестування і занотовує це у Тест План. Важливою частиною цього документу є інформація про те що, як і де буде тестуватися. Детальніше покрокове тестування описується Тест Кейсами так званими тестовими випадками. Тест Кейси можуть групуватися по функціональності або по видах тестування у Тест Дизайни.
З готовою документацією тестувати досить легко і приємно. Такий підхід, як мінімум, запевняє у максимальному тестовому покритті проекту. Також не варто обмежуватися тестовою документацією. Трішки творчого підходу при виконанні будь-якого завдання не завадить ;). Хорошим показником якості роботи тестера є тип і пріоритетність знайдених Багів, котрі також повинні бути задокументовані у зрозумілому стилі.
Кінцевий підсумок про якість продукту, який базується на результатах тестування, тобто знайдених Багах, зображається у Тестовому Звіті.
Найкращим шаблоном документу є той який є зручним для усіх хто його читає :).
Розробка проекту - це реалізація ідей, які умілі техрайтери перевтілюють у документ під скромною назвою Функціональні Вимоги. Досвідчені керівники проекту дають замовнику прочитати цей документ і підтвердити, що виконавець зрозумів усе вірно. Цей крок страхує від ризику витратити час і гроші на розробку продукту, який не є очікуваним замовником. Традиційно замовник отримуючи наступну версію продукту змінює вимоги або у нього появляться нові ідеї. За цим слідує оновлення функціональних вимог, затвердження їх замовником, оновлення усієї поточної документації. Змінюється часова оцінка, графік планування і так далі.
Тестерам варто розпочинати аналіз вимог. Часто це називають тестуванням вимог, яке супроводжується інтенсивною комунікацією між замовником і виконавцем з метою створити єдине узгоджене спільне бачення продукту. Також відповідальний за тестування намагається уявити собі весь процес тестування і занотовує це у Тест План. Важливою частиною цього документу є інформація про те що, як і де буде тестуватися. Детальніше покрокове тестування описується Тест Кейсами так званими тестовими випадками. Тест Кейси можуть групуватися по функціональності або по видах тестування у Тест Дизайни.
З готовою документацією тестувати досить легко і приємно. Такий підхід, як мінімум, запевняє у максимальному тестовому покритті проекту. Також не варто обмежуватися тестовою документацією. Трішки творчого підходу при виконанні будь-якого завдання не завадить ;). Хорошим показником якості роботи тестера є тип і пріоритетність знайдених Багів, котрі також повинні бути задокументовані у зрозумілому стилі.
Кінцевий підсумок про якість продукту, який базується на результатах тестування, тобто знайдених Багах, зображається у Тестовому Звіті.
Найкращим шаблоном документу є той який є зручним для усіх хто його читає :).
Підписатися на:
Коментарі (Atom)
Публікації
