Test Log - Test Plan and Test Case Management Software

Client Requirements – This will be the list of the requirements developed in conjunction with the client and the developer. This list of requirements will be the “measuring stick” which the designs are to be acceptance tested against. This portion of the acceptance test log would be completed by the developer before the interview.

Design Evidence – This column should outline the evidence on offer to prove the technical and audience standards have been met within the designs. For example, the wireframe documentation could be used as evidence that the webpages adjust themselves to fir the screen size of the user’s device and the client requirement documentation could be used as evidence that the developer intends to create a site using HTML 5 and CSS technologies. This portion of the acceptance test log would be completed by the developer before the interview.

Accepted – This is simply a yes or no column to quickly see whether the particular requirement in question has been verified by the client as an acceptable standard. This portion of the acceptance test log would be completed by the developer during.

Comments – This portion of the table can be used to log the feedback from the client. Hopefully the client will agree with your assessment of the designs and accept their standards are being met, but if not their views can be logged here. Such information can then be used later to assist in re-designs with a view of re-visiting the clients and gaining their approval. This portion of the acceptance test log would be completed by the developer during the interview.

Date and Signature – This should be at the end of the document where the client and the developer can sign that the designs meet the technical and audience standards expected. This will protect the developer from a client who changes their mind and also protect the client from poor workmanship and partially completed projects. This portion of the acceptance test log would be completed by the developer and the client straight after the interview.

With the design documents in hand and the acceptance test log prepared with the columns Client Requirements and Design Evidence completed the developer would then seek a formal interview with the client to validate the standards. This interview should record the client’s response to each of the technical and audience standards outlined in the client requirements.

If the client is unhappy with a particular portion of the design and does not believe the standards would be met this should be logged so that the developers can re-work their designs before returning for further feedback.

If the client is happy that all technical and audience standards would be met, then it would be prudent to have a signed copy of the acceptance log by the client and developer. This protects the developer from a client who changes their mind or disagrees with the standards during the development phase; a prospect which will cost the developer both time and money. Additionally, it would also be prudent to have a legally binding contract signed by developer and client where it is explicit that the design meets the technical and audience standards to protect both parties in the project.

Grey box testing is simply an amalgamation of White and Black Box testing, where a developer can see the inner workings of the system, view the source code and also view the outputs.

Whichever method of testing you choose to employ all tests must be logged to evidence that the website has been verified and is fit for purpose. While testing software is available to buy the simplest method is to create an Excel table with appropriate headings and logging each test as it is completed.

A typical test log would include the following headings:

Date – This is the date the test took place. This is important information as newer versions of the project may not have been tested, so knowing when the test took place can be helpful to a developer.

Test Number – The test number should start at 1 and increment for each NEW test. However, if a particular test fails a re-test must be performed and the test number should show this. Typically, this is done by adding a letter or decimal number after the test number to show it is a retest. For example, if test number 7 failed then the next test, a retest of number 7, should be labelled 7.1, or 7.01, or 7a, something appropriate to show to the reader of the test log that this is a retest, not a different test entirely.

Purpose of Test – The purpose of the test should be explained briefly. For example, “Test index.html hyperlink to contact us page”. This column should be short and sweet with just enough information to inform the reader what is being tested.

Test Data – Some tests may require specific data to be typed in to test the project can handle a variety of data. For example, if a developer created a HTML form to collect someone’s first name they m ay want to run a couple of tests, one with valid test data such as “kelvin” and another with invalid test data such as “y4782oh42nlk-!.” Knowing specifically what test data was used in a specific test can often help a developer in debugging issues in future. Some tests though do not have test data, for example checking a hyperlink works is simply clicking on the hyperlink. In this case a developer can put N/A (not applicable) or give some form of detail such as “mouse click on hyperlink”.

Expected Results – Expected results is where the developer specifies EXACTLY what should occur if the test were to pass. Using my previous example of “Test index.html hyperlink to contact us page” as the purpose of test, a valid expected result would be “contactus.html page loads in the same window”. You should never put “it works”, this is not a valid expected result and comes across as rather lazy.

Actual Results – This is where a developer will have actually tested and is now logging the results of the test. If a test passes, then the actual results should be IDENTICAL to that of the expected result. If the test fails, the developer should log what actually happened. So a valid actual result that passed testing would be “contactus.html page loads in the same window”, which is identical to the expected result. A valid failed test could be “contactus.html page did not load, 404 error displayed on screen”.

Comments – This is where a developer can comment on the test. Usually the comments section is used when a developer has successfully re-tested a failed test and allows them to log what caused the test to fail and how they overcame it.

Different variations of this test plan can be found and a developer can add other columns if they see fit to the test log. For example, some developers like to have an error message column if they are white box testing to log the compiler or error messages which show during the test. As long as the test log is detailed enough to provide evidence of the validity of your site you’ll be fine.

To the question at hand when verifying usability, view ability and browser compatibility a developer would want to be able to prove they have tested the following areas when it comes to a website:

• Do all hyperlinks on all webpages work?
• Do all images on all webpages load?
• Is the content presented in a readable manner?
• Has the content been styled in the correct manner?
• Does the layout of the site work as expected?
• Does the website work on a variety of different browsers?
• Does the website work on different versions of each browser?

When creating a test plan a test should be broken down to a single, testable feature. For example, having a purpose of test such as “Test all hyperlinks work on the index page” would not be a valid test as there could be more than 1 hyperlink on the index page. A good quality test document would test each individual hyperlink as a separate test for each individual page on the site. This can take a considerable amount of time, which is why developing modular, repeatable code is important as it makes testing far easier.