I offer services in the area of software test.
Software Requirements Based Testing
I offer services in the area of software Requirements Based Testing.
Often the customer’s requirements are in an application such as DOORS or simply in Microsoft Word or Excel.
Requirements based testing ensures that all of the requirements are implemented and that the implementation corresponds to the specification.
I can derive test cases from the software requirements and then implement the tests. There must be at least one test case per software requirement.
There are basically three types of requirement:
- system requirements
- high level requirements
- low level requirements
Another important issue I can help with is traceability, which links requirements to the design to the implementation, to the test cases, the test code and to the test results.
With requirements based test it’s also necessary to ensure that only what was specified in the requirements has been implemented and not more. It often shows up in the code coverage results if unspecified code has been implemented. Software developers have a tendency to write more code than is required.
Often it is only when requirements based test is started is it noticed that the requirements are not as good as they could be.
I can help in the area of improving your software requirements.
Some of the issues with software requirements are as follows:
- particular requirements are not testable
- the requirements are incomplete
- the requirements are unclear
- requirements are missing
- requirements are duplicated
One issue that occurs frequently is that a single requirement is too long and should have been written as several separate requirements. This makes testing more difficult and traceability more complex.
I can write your requirements based test specifications.
I can document your tests and test results.
Just let me know how I can help.
Software Unit Test
I offer services in the area of software unit testing.
This is the lowest level of testing, for example for the testing of individual classes.
I have expertise in the use of unit testing tools, such as CPP-Unit, NUnit, etc.
Often a class will call other classes. It is important to decide whether the class should be tested in complete isolation or whether some of the called functions can be kept in. The called functions can be replaced by stubs, which are dummy code to replace the original code. Stubs can be created manually or using tools.
Final unit testing of embedded systems has to be performed on the real hardware, otherwise it is not proven that software which runs on the host computer is verified on the target computer. To perform target testing it is necessary to use products such as Lauterbach, which we have experience with, but I suggest that I develop tests for the host computer, which can be run later on the target computer.
One of the most important aspects of unit testing is determining the test cases. It’s important to have sufficient test cases so that all of the code is covered. I can also use tools to measure the ‘code coverage’ to ensure that all of the lines of code have run.
There are two types of input values which need to be considered:
- in range
- out of range
The in-range values are the ones that are normal inputs to the functions to be tested. These should be tested for at least the minimum, mid-range and maximum values.
Out of range values are outside the range of normal inputs. For example, an input parameter to a function may be of type integer, but the in-range values are just values up to 100 and values above that are out of range. It is important to check how the software reacts to out of range input values. The unit testing can also test the error handling of the software under test.
I can also perform the following:
- stress testing
- performance testing
- suggestions for improvements to the code
- improved documentation of the code
- writing test specifications
If you supply me with a few of your files to be tested, I can get down to doing some intensive testing and I will find the bugs !