Showing posts with label Taceability Matrix. Show all posts
Showing posts with label Taceability Matrix. Show all posts

December 3, 2010

Test Matrices sample

December 03, 2010 1
Test Matrices sample
Metrics means measurement. Metrics is just a series of measurements.
Test Matrices Sample ___________________________________
Question:
I need information about Metrics, which is used to find faults. it is something related with measurement. I need to know how it is used in Quality Assurance.

Answer:
You can measure the arrival and departure times of developers, if you have them clock in, but that won't tell you much since not all work is done in the office (and it doesn't mean that they're working when they're in the office). This is, however, still a metric.

The same holds for a true "quality metric". The most familiar one is defects per thousand lines of (uncommented) code. But this metric assumes that:
1) you count the lines of code
2) the complexity of the code isn't an issue
3) the programmers aren't playing games (like using continuance characters
so that what could have been written in one line isn't done in five lines)
4) all defects are uncovered in the code in a single pass
5) each defect discovered is all others
6) defects are uncovered in a linear manner between revisions or builds

The fact is that first you need to know what your goal is. Then you need to
discover or create a metric that will help you achieve that goal. Then you
need to implement it and be prepared to adjust it.

You can't use measurements (metrics) to find faults, at least not in software, so that's not a reasonable goal. You can use metrics to help determine if most of the defects have been discovered already. You can use them to tell you how much longer it will take to uncover a reasonable amount of defects. For either of these metrics you will need to know how previous projects of similar size and complexity (using similar languages, etc.) were done in order to get a reasonable comparison.




Test Case: File Open #
Test
Description
Test Cases/ Samples
Pass/
Fail
No. of
Bugs
Bug#
Comments
N/A
Setup for [Product Name] setup
-
-
-
 
1.1
Test that file types supported by the program can be opened
1.1
P/F
#
#
 
1.2
Verify all the different ways to open file (mouse, keyboard and accelerated keys)
 1.2
 P/F
 #
 #
 
1.3
Verify files can be open from the local drives as well as network
1.3
 P/F
#
#
 




For more information please visit....http://www.sqatester.com/

How to Create a Requirements Traceability Matrix

December 03, 2010 14
How to Create a Requirements Traceability Matrix
A successful project cannot be achieved without the project manager having an excellent organizational skill set. Information must be readily available upon demand. A good project manager will be able to identify what works and what is broken in an instant. Having a requirements traceability matrix is an invaluable tool to accomplish this
.


Instructions

Things You'll Need:

  • Project deliverables
  • Business requirements catalog
  • Use cases
  1. Create a template. There are many on  the web from which to choose. The project manager, sponsor and decision makers will thank you when they are receiving information in a consistent and logical format.

  2. Transfer data from your Business Requirements Catalog. You will need, at bare minimum, the exact requirement identified from the Business Requirements Catalog that you need to have already created.

  3. Identify the requirement with a unique ID. The business requirements document should have already assigned an identifier that you will use in this matrix. If not, you will create one now and insert it next to the applicable requirement.

  4. Copy the Use Case ID into the traceability matrix. You may or may not have used use cases to develop your requirements. If you did, you will have an identifier on your use case. You must transfer the ID to this matrix in order to see out of what data or scenario this requirement was born.

  5. Insert the System Requirements Specification (SRS) ID into the traceability matrix. You might not be the actual author of the SRS, but there must be a line on the matrix to trace the business requirement to the corresponding system requirement needed.

  6. Insert the testing data into the traceability matrix. There are many different testing methods and procedures that can be used in any project. The traceability matrix must account for the types of tests used in this project. This should clearly indicate the specific test type, the date tested and the outcome of pass/fail.

  7. Review your data. Your matrix should now clearly show the specific deliverable requirements from conception clearly through testing. This will ensure that nothing gets moved into production haphazardly and when asked, the Project Manager now has this information at the ready.