test coverage

Jul 6 2009   10:00AM GMT

Five stages in a project when Software Tester becomes Quality Analyst

Posted by: Jaideep
Quality Assurance, Software tester, software testing, Project Planning, Test Plan, test case, product analysis, customer requirement analysis, product functionality, software functionality, software documentation, software document, test result, test performance, software performance, testing process, quality analyst, QC, QA, quality control, load testing, performance testing, functional testing, security testing, test coverage, software build, software, analysis, functionality

A software tester evaluates software based on certain parameters. These parameters are set as per product, customer and organization requirements. Testing could be just of functional features or include load, performance and security. For any parameters a tester has to work as quality analyst to understand requirements, features and accordingly build test cases and perform test. This is the quality control part. On quality assurance front the quality team has to build standards for requirement freezing, planning, development, implementation and post implementation phases of a project.

A software tester at various stages of a project gets on to the job of a Quality Analyst by performing following tasks:

Analysis of customer requirements: The first and foremost analysis required is that of the customer requirements to ascertain if it is complete, detailed and free from any confusions, ambiguities or equivocalness. Any flaw in requirements will certainly lead to a big disaster at a later stage. Unclear requirements are not difficult to build, but are difficult to manage. Every requirement should be in black and white. Each line should be very clearly documented such there should be nothing hidden between the lines.

Analysis of Product Functionality: Requirements documented and product built has to go hand in hand. It should not happen that requirements and product speak differently even a single line. Usually while testing functionality of a product, tester forgets to refer to requirements documented, or asks developer about the functionality. The developer will certainly explain him the functionality he has built not what exactly has been mentioned in the requirements document. If this happens, it will certainly cause a big blast at implementation or acceptance stage.

Analysis of Product related documents: There are many documents prepared during the project. Some are meant for internal use, some are prepared for customer. All these documents need to be inspected thoroughly and neatly.

Analysis of test results: Test cases are built to perform tests resulting in bugs report or test results report. A thorough scan is must to ensure complete coverage and thorough testing. The report should be detailed in all respects in terms of clarity and coverage.

Analysis of Testing Process: The testing process once establishes need to be revisited again and again to improve further at every go. Once established does not mean it is ultimate and best. Improvement has always a scope howsoever best your process or product is.

Mar 2 2009   9:59AM GMT

10 golden rules for Requirements Based Testing

Posted by: Jaideep
business knowledge, software, tester, test case, test coverage, unit testing, integration testing, change management, test case repository, test metrics

10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.

9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.

8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.

7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.

6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.

5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.

4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.

3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so atleast the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).

2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.

1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.