İstanbul evden eve nakliyat Beylikd¨¹z¨¹ evden eve nakliyat Tuzla evden eve nakliyat
Responsibility Matrix for Performing Different Type of Software Testing
Delicious Bookmark this on Delicious
software testing genius

Responsibility Matrix for Performing Different Type of Software Testing

Welcome to “Software Testing Genius”. Subscribe to my RSS feed for latest content on Software Testing.

Responsibility Matrix for Performing Different Type of Software Testing

As a general practice in the IT industry, preference for the software testing activity is given to some independent testers or organization. While this is greatly valid in some very critical software situations, the definition of independent has been varying from application to application.

On the basis of the concept that everyone is responsible for their own work and that this responsibility also applies to groups, the task of testing is being returned to the developers. This is not to say that programmers should test all their own work, but that the development group is responsible for the quality of the software that they deliver.

Following table describes appropriate testers for each type of testing described above. As each organization's test program matures, the identification of the testers for each type of test will be based on the organization's experience and testing approach.

Responsibility of Performing Different Type of Software Testing

color=#000080 size=2>

Sr.

Type of Software Testing

Responsibility of Testing

1

Debugging

Programmer

2

Unit testing

Programmer

3

Module or object testing

Programmer

4

Module or object integration testing

Third party

5

Subsystem and system integration testing

Third party

6

System testing

Developer test team

7

User / acceptance testing

User test team

A programmer should test only that software for which he or she has sole responsibility. Once the work of more than one person is to be tested, an independent tester, that is someone other than the persons involved, should carry out the testing. Even at this level, though, the testers should come from within the development group responsible for the full set of software. Outside software testing engineers are only necessary at the full software system test level when all the developers have an investment in the software.

Unit, module, and most integration testing are the proper tasks of the development organization. This is consistent with total quality concepts and the idea that every person or organization is responsible for the quality of his or her own work. The very early testing is in the form of debugging, and as the unit tests cover more of the software, they flow into module tests. Module tests, too, are primarily debugging in nature. Even the initial integration tests can be thought of as advanced debugging, although this is more of an organizational decision than an industry-wide convention.

The characteristic of debugging that separates it from rigorous testing is that defects are generally fixed on the spot without much formal change control. At whatever time the organization institutes some level of change control, the testing is usually considered out of the debugging process and into rigorous testing. This is not to say that there is no configuration control up to this point. Configuration control is already in effect on the documentation. Any change that affects the requirements or design must be processed formally to maintain the integrity of the documentation and the system as a whole. Changes that merely fix mistakes in the code can be made with minimum control at this stage, since the only elements involved are individual units or modules, or small groups of two or three closely interfacing modules prior to actual integration.

There should, however, be at least an audit trail of the changes properly maintained. This will be used for error and defect history analysis as the development proceeds. Software quality practitioners should monitor the testing at the unit and module level to be sure that such an audit trail is provided. Software quality practitioners are also an appropriate resource for the error and defect history analysis. Conclusions reached as a result of the analysis should be fed back, as improvements, into the development process.

As the time for full-scale integration and system testing arrives, a test team that is organizationally independent from the producers should take over the testing. Because the goal of the test program is to find defects, the objectivity of an independent test team greatly enhances the quality of the testing. The independent testers will perform the testing tasks all the way to user or acceptance testing. This team is probably the group that produced the formal test program documents. User or acceptance testing should be performed by the users themselves, preferably in the user's environment, to help ensure that the software meets the user's expectations, as well as the officially approved requirements. Regression tests are conducted by many different persons involved in the software life cycle. The developers will regressively test changes to modules and subsystems as they make changes in response to trouble reports generated during formal testing or maintenance. The test team will also have occasion to use regression testing as they verify that new modules or subsystems do not adversely affect the system as a whole. Software quality practitioners can even use regressive testing techniques as they perform some of their audit and review tasks.

The software quality practitioner's primary role in the testing process, aside from reviewing and approving the test documents, is to monitor the testing as it progresses. The software quality practitioner will audit the tests against their plans and procedures and report the status of the test program to management. There are added benefits if software quality practitioners have been doing more than just cursory reviews of the documentation as it has been produced. The cross-fertilization of the technical knowledge of the system and the test planning for the system can produce better results in both areas.

Many More Articles in Startup Kit for Software Testing 

Largest Database of Sample Papers - 1000+ Unique Questions for ISTQB Foundation Exam


ISTQB Foundation Exam - Full Crash Course for Download

ISTQB Advanced CTAL Test Analysts Exam - Full Crash Course for Download


ISTQB Advanced CTAL Test Manager Exam - Full Crash Course for Download


Consolidated Study Material - All ISTQB Certification Exams


What Successful Testers say about the Quality of this website

If you want to keep track of further articles on Software Testing,
I suggest you to subscribe my
RSS feed
.

You can also Subscribe by E-mail
and get All New articles delivered directly to your Inbox.


Quick Navigation of Software Testing Genius

Get your Absolutely Free Copy of Several MS PowerPoint Presentations & E-Books related to ISTQB, HP Load Runner, IBM RFT, HP QTP & QC Certification Exams, prepared by Popular Writers & Trainers, by writing to: Software.testing.genius@gmail.com

Study Material for Certification Exams on Other Automation Tools:

Download Full Study Material - HP QTP & QC Certification Exams

Practical Roadmap to QTP Certification

Rehearsal of QTP in 1 Hr. -  Interview Questions

Study Material - HP LoadRunner Certification Exams for All Modules

Rehearsal of LoadRunner in 1 Hr. -  Interview Questions

Study Material - IBM RFT Certification Exam

Study Material to prepare for Manual Testing & QA:

Practical Roadmap to CSTE Certification

Consolidated Study Material - Testing & QA

 

Comments :

comments ↓


Leave Your Comments: (*) Marked Fields are Mandatory

You can apply basic formatting to the text

Name *
 
Email Address *
 
Website
 
Speak your mind
characters
sex hikayeleri