With a view to provide assurance of their software quality, organisations often engage in White Box testing. According to the Institute of Electrical and Electronics Engineering, white box testing is 'testing that takes into account the internal mechanism of a system or component'(IEEE,1990), explaining also the provenance of other names like clear box, or glass box testing implying full visibility of the internal systems of a software.
Unlike black box testing (covered in the next section), which takes into consideration only input and corresponding output of the software to conclude whether it is working or not, white box testing needs the tester to go into depth of the application to verify each internal connection, path and branch. An example will be in-circuit testing where interconnection between each component is looked at and verification of whether each internal connection is working suitably is carried out. A non software related example will be a mechanic checking the internal connections of a car to test whether it will work properly.
The program source code is used as a basis for writing the test cases, which will be used by the tester to run the codes with predetermined inputs to make sure that predetermined outputs are produced.
White box testing is often associated with the following types of testing :
Unit Testing [1]
Software Engineers will use white box testing by writing test cases which will test whether each unit is coded properly before it is integrated with some other code, where then it will be rather difficult to detect the source of any anomaly caused.
Integration Testing
Instead of testing individual units, software are combined to test interaction among them
Regression Testing
Software engineers use white box testing in instances where they have to test whether the system as a whole has not been damaged by any modification. It is a sort of retesting to guarantee that the system still meets its intended requirements.
As detailed, concise, introspective [2] , and stable white box testing may seem, there are certain limitations to it that make businesses choose other types of testing, notably black box. Below are certain prominent disadvantages of this type of testing :
Clear box testing is complex. It requires high programmatic knowledge of the software engineer because of the in depth procedures that have to be carried out to test whether the software meets all the requirements.
Chance of error is increased as there is the risk of not testing all the paths because of the huge quantity of those that some applications might have.
2. Capability Maturity model (CMM)
The Capability Maturity Model was originally designed by the Carnegie Mellon's Software Engineering Institute (SEI), when the field of software development was still new and there was no established framework. It was at first created for the military department to eradicate issues of slow work and high costs. Over time, it became very common among organizations. It represents the merging of two frameworks, namely the 'Process Maturity Framework' of Watts Humphrey and the 'Quality Management Maturity Grid' of Philip B. Crosby.
CMM [3] is a model that basically prescribes how software development must be carried out. It provides guidance and standards for developing software. It does so by attempting to assign maturity levels to an organization. Each maturity level defines Key Process Areas (KPAs) which represent groups of software practices. Each KPA has goals (usually 2 to 4), all of which must be achieved in order to satisfy the objectives of that KPA. Each level's KPAs' goals must be satisfied for the organization to attain that particular level. This mature model has in place set strategies which allow the software development process to run smoothly.
The quality of th software will be highly influenced by the quality of processes used to develop and maintain it.
The 5 maturity levels are as follows :
The Initial Level
This level, also referred to as level 1, represents an unorganised system, where software quality is only a matter of chance. At this level there are no recommended Key Process Areas and success of software depends on the competencies and capabilities of individuals within the organization.
The Repeatable level
In this level (level 2), processes are of the repeatable nature, that is, they will produce consistent results. To achieve this level, organizations will have to abide by the specific KPAs (for example, project planning, monitoring and control of project, measurement and analysis, process and quality assurance). This level needs the engineers to be able to estimate the size of the software under production, estimate the resources needed, and compare actual results with estimates.
The Defined level
At this level, the software developers have already established the software development and maintenance practices necessary specific for the applications they usually produce. The organization will consistently follow these standards and practices, and usually training is required. Some KPAs for this level are verification and validation, process focus, process definition, process training, peer reviews, and product integration.
The Managed Level
At this level, as the name suggests, the standards and practices identified in level 3 are monitored and managed. Emphasis is more on processes, that is whether they are functioning properly and what are the corrective measures that can be taken.
The Optimising level
When an organisation is at this level, it implies that it has passed all the previous levels and is now abiding by most of the KPAs. It can then use measures prescribed for this level not only for improving existing measures but to introduce new ones also.
Introduction of CMMI
Read more: http://www.brighthub.com/office/project-management/articles/56412.aspx#ixzz1D7QN8bzp
http://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model http://isb.wa.gov/policies/capmatmodel/tr25_l2e.html
http://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model
http://www.brighthub.com/office/project-management/articles/69744.aspx
http://www.sqa.net/cmmi-overview.html
http://www.sei.cmu.edu/solutions/softwaredev/
