When testing a software product the testers need access to some amount of information. The can be given access to just the finished product, just the code, or both. In each case the type of testing can vary.

Black-box testing refers to testing software where you have not been given the source code. In most cases the tested would be given a set of specifications. The tested the preform test on the  product and ensure it complies with the specifications. The main way in which black box testing works is by providing input and verifying the output is what is expected.

With white-box testing the testers have access to the source code. This means the they can examine how the code works. This can prove to be more complex but allows for much more thorough testing. This is where unit testing can really work and test cases can be written to test the code. Metrics can also be generated to show how much of the code was actually covered by test.

The third options involves a little of both categories, this is known as gray-box testing. In most cases involving gray-box testing the tested don’t have access to the source code but do have some knowledge of the inner workings of the program. One example of this would be a team that understands the formulas and methods used by software. This allows them to create more specific test than black-box testing that can target areas that are more likely to have issues. This is a good place for boundary value testing.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

One way of ensuring good quality is by creating a test suit that actively test the code to fine flaws. Another way is to comb through the code and verify there are no errors in the logic. This process in known as a software technical review.

A software technical review consists of 4 parties, the producer, the recorder, the review leader, and the reviewers.

The producer is the entity that develops the code this could be a single developer and development team or an outside company. They are responsible for providing a frozen copy of the code and a set of requirements and expectations. It is important that the code does not change during the technical review process.

The recorder is responsible for taking notes and documenting what takes place during the review.

The review leader is responsible for scheduling the review, suppling what is necessary for the review, as well as producing the final report and sharing the findings.

The code reviewers as well as the leader and the reported are responsible for looking through the code before the meeting and documenting all errors of other issues found in the code.

During the review each member shares what they found and compares it to the others. As a group the determine if what is found is actually an issue that needs to be fixed. The team does not make suggestions to how the issues can be resolved.

The review leader then takes the information from the review session and generates a final report to be shared with the producer.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.