MANUAL TESTING

We always like to follow the best practices in the industry. When it comes to software testing, the best practice is to start testing cycle at the beginning of the Software Development Life Cycle (SDLC).

The first step we do is the inspection of documentation starting with Customer Requirements Specification document (CRS). Apart from ensuring that the documentation is according to the prescribed industry standards, the test team needs to confirm that the identified customer requirements are testable. Identifying any problems at this stage is inexpensive as opposed to encountering problems later in the SDLC.

One of the most important reasons to start testing cycle at the beginning of the SDLC is to be able to begin identifying test requirements as soon as possible. As soon as we have a set of test requirements identified using the first project document (CRS), we can immediately start writing our manual test cases based on identified test requirements.

This is done long time before the first version of the software application is available for testing. This way, we have our manual test cases ready, as soon as the first version of software application is available to the test team.

As project documentation is being developed, test team performs the same inspection with every new document: Software Requirements Specification, Functional Specifications, Use Cases, or any other available project document. During this inspection of newly available documentation, we also identify new test requirements, add them to the ones identified earlier in the cycle, and write more test cases based on the new requirements. Following this process, all documented aspects of an application under development are covered in test cases even before the application is available for testing.

Over the time, we have developed a style of writing well structured manual test cases. Most importantly, they are based on test requirements identified prior to writing a test case. Test requirements are specific, smallest identifiable units for testing. Identifying test requirements prior to writing a test case, and then using test requirements to write a test case ensures that the application is tested in a structured, controlled, and the most extensive way.

Our principles and guidelines in writing test cases enable us to:

• Test the maximum number of test requirements with the minimum number of steps, reducing overhead in writing and executing tests
• Have tests written in a structured way, which is easier and faster to write
• Have readable tests that could be effectively run by inexperienced testers or testers not familiar with the application under testing
• Have sets of test cases which is not difficult to update and maintain
• Have efficient and traceable reporting of software defects identified using manual testing

We carefully plan our testing using the following cascade of test documentation: Project Plan, Master Test Plan, Integration Test Plan, System Test Plan and User Acceptance Test Plan. Our overall test strategy, principles and methodology are covered in Master Test Plan, while the specifics needed by the test team to perform an iteration of System Test are well defined in our iteration System Test Plan.

We effectively track software defects using defect management tools Test Director, Gemini and iNav. Our accurate data enables us to extract statistics needed to report on our project situation in any given moment, and to plan and estimate testing efforts and complete projects on time.

Manual testing in Soprex is well structured, flexible and controlled process based on best practices and prescribed industry standards. Our test methodology is designed to enable us to as quickly as possible progress from a document to a test case, allowing us to complete our testing in a shortest possible and the most efficient way.