Requirements Traceability Matrix !!!

Ideally each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. Refer the following sample table which describes Requirements Traceability Matrix process. In this matrix, the rows will have the requirements. For every document {HLD, LLD etc}, there will be a separate column. So, in every cell, we need to state, what section in HLD addresses a particular requirement. Ideally, if every requirement is addressed in every single document, all the individual cells must have valid section ids or names filled in. Then we know that every requirement is addressed. In case of any missing of requirement, we need to go back to the document and correct it, so that it addressed the requirement.

For testing at each level, we may have to address the requirements. One integration and the system test case may address multiple requirements.

Installation Testing !!!

Installation testing is often the most under tested area in testing. This type of testing is performed to ensure that all Installed features and options function properly. It is also performed to verify that all necessary components of the application are, indeed, installed.

Installation testing should take care of the following points: -
1.To check if while installing product checks for the dependent software / patches say Service pack3.
2.The product should check for the version of the same product on the target machine, say the previous version should not be over installed on the newer version.
3.Installer should give a default installation path say “C:\programs\.”
4.Installer should allow user to install at location other then the default installation path.
5.Check if the product can be installed “Over the Network”
6.Installation should start automatically when the CD is inserted.
7.Installer should give the remove / Repair options.
8.When uninstalling, check that all the registry keys, files, Dll, shortcuts, active X components are removed from the system.
9.Try to install the software without administrative privileges (login as guest).
10.Try installing on different operating system.
11.Try installing on system having non-compliant configuration such as less memory / RAM / HDD.

Content Management Testing !!!

‘Content Management’ has gained a predominant importance after the Web applications took a major part of our lives. What is Content Management? As the name denotes, it is managing the content. How do they work? Let us take a common example. You are in China and you wanted to open the Yahoo! Chinese version. When you choose Chinese version on the main page of Yahoo! You get to see the entire content in Chinese. Yahoo! Would strategically plan and have various servers for various languages. When you choose a particular version of the page, the request is redirected to the server which manages the Chinese content page. The Content Management systems help is placing content for various purposes and also help in displaying when the request comes in.

Content Management Testing involves:
1. Testing the distribution of the content.
2. Request, Response Time’s.
3. Content display on various browsers and operating systems.
4. Load distribution on the servers.

In fact all the performance related testing should be performed for each version of the web application which uses the content management servers.

Unit Test Cases !!!

It must be clear by now that preparing Unit Test Cases document (referred to as UTC hereafter) is an important task in Unit Testing activity. Having an UTC, which is complete with every possible test case, leads to complete Unit Testing and thus gives an assurance of defect-free Unit at the end of Unit Testing stage.

Think of following aspects while preparing Unit Test Cases:

* Expected Functionality
Write test cases against each functionality that is expected to be provided from the Unit being developed.

* Input values
Write test cases for each of the inputs accepted by the Unit.

* Output values
Write test cases to generate scenarios, which will produce all types of output values that are expected from the Unit.

* Screen / Report Layout
Screen Layout or web page layout and Report layout must be tested against the requirements. It should not happen that the screen or the report looks beautiful and perfect, but user wanted something entirely different! It should ensure that pages and screens are consistent.

* Path coverage
A Unit may have conditional processing which results in various paths the control can traverse through. Test case must be written for each of these paths.

* Assumptions
A Unit may assume certain things for it to function. For example, a Unit may need a database to be open. Then test case must be written to check that the Unit reports error if such assumptions are not met.

* Transactions:
In case of database applications, it is important to make sure that transactions are properly designed and no way inconsistent data gets saved in the database.

* Abnormal terminations:
Behavior of the Unit in case of abnormal termination should be tested.

* Error messages
Error messages should be short, precise and self-explanatory. They should be properly phrased and should be free of grammatical mistakes.

UTC Document Format

Defect Recording !!!

* Defect Recording can be done on the same document of UTC, in the column of ‘Expected Results’. This column can be duplicated for the next iterations of Unit Testing.

* Defect Recording can also be done using some tools like Bugzilla, in which defects are stored in the database.

* Defect Recording needs to be done with care. It should be able to indicate the problem in clear, unambiguous manner, and reproducing of the defects should be easily possible from the defect information.