Golden Rules for Software Testing

Is testing always about finding the BUG or is it beyond?
Testing implies the purpose of understanding whether the system fulfils the requirements or not. It helps identify the gaps, errors, or any missing requirements against the defined requirements.
Based on my testing experience, I feel that testing is a basic human nature of examining things before accepting or agreeing upon. In case of software testing, it starts with analysing requirements much before actual software development.
Software testing can be grouped into four major phases:

  1. Unit Testing (by developer or a separate white-box testing team)
  2. Integration Testing (by development team)
  3. System Testing (by professional testing team)
  4. Acceptance Testing (by business users)

The few golden rules of software testing to be considered are:

  • Identifying bugs in the early stages: Ideally, software testing process should start once the testing team gets the requirement specification document from a client or development team. It involves analysing the specified requirement documents prudently, and resolving the questions at the earliest. The issues acknowledged during early stages facilitate the development team to develop the software with correct functionalities.
  • Preparation of Test documents: Once the documents are reviewed, the next step involves planning of test strategies, test scenarios, test cases and respective test data if required.
  • Quality remains the key point: A tester has to stick to the quality and perform quality testing instead of bugs count, complete test cycles on time and perform software/product quality. During testing, the main focus should be based on client business requirements and expectations.
  • Descriptive Bug report: Whenever tester reports a bug, he/she should provide comprehensive document about the bug occurrence with supportive screenshots. Suggest the severity and priority of the bug and mention the expected and actual results to guide the development team for the bug resolution process.
  • Include Regression Testing: After a test cycle completion, the development team fixes logged issues in bug management tool and release the software for testing again. With bug verification, always ask the development team for impact analysis report and perform regression testing to make sure that there is no impact of the bug fixation process.
  • Test with real scenarios and test data: Negative testing should be done to test robustness of the software, however, make sure that prepared test scenarios and test data is quite real as predictable by client end users.
  • Maintain record of change requests: Once the project is completed one or few releases, usually documentation of change requests is not done by the development team. In this situation, as under change request management, testers should maintain test cases based on the changes with the priority status.
  • Don’t fight for bug fixes: Testers need to report all possible bugs in respective bug management tools with the severity and priority of the bug fix. However the bug fixation selection should be decided based on business urgency by the client, business analyst and technical managers. Definitely testers should give inputs to them with the accurate reasons for the necessity of fixing bugs.
  • Bug Leakage analysis: After product release to client and UAT completion, if bugs are raised by client, Tester should do an analysis of bugs and provide inputs on the bug leakage. Also needs to prepare preventive actions for the future quality releases.
  • Focus on the software testing process, not on the tools: There are many free and paid tools available in market for testing and test management to make our tasks easier. However, testers should always focus on core testing processes; the other tools can be used as additional support only.
  • Don’t presume more of automated testing: Automated testing can be beneficial and a time saver, however sometimes it can be expensive and doesn’t provide the required results.

The requirements analysis and accurate testing are the major reasons of software projects delays/ failures. These golden rules would definitely push all testers to hook on to it for the help in testing. Utilising these rules in a testing project will help in delivering quality software products on time.
Image Courtesy: sjsit7solutions.wordpress.comIs testing always about finding the BUG or is it beyond?
Testing implies the purpose of understanding whether the system fulfils the requirements or not. It helps identify the gaps, errors, or any missing requirements against the defined requirements.
Based on my testing experience, I feel that testing is a basic human nature of examining things before accepting or agreeing upon. In case of software testing, it starts with analysing requirements much before actual software development.
Software testing can be grouped into four major phases:

  1. Unit Testing (by developer or a separate white-box testing team)
  2. Integration Testing (by development team)
  3. System Testing (by professional testing team)
  4. Acceptance Testing (by business users)

The few golden rules of software testing to be considered are:

  • Identifying bugs in the early stages: Ideally, software testing process should start once the testing team gets the requirement specification document from a client or development team. It involves analysing the specified requirement documents prudently, and resolving the questions at the earliest. The issues acknowledged during early stages facilitate the development team to develop the software with correct functionalities.
  • Preparation of Test documents: Once the documents are reviewed, the next step involves planning of test strategies, test scenarios, test cases and respective test data if required.
  • Quality remains the key point: A tester has to stick to the quality and perform quality testing instead of bugs count, complete test cycles on time and perform software/product quality. During testing, the main focus should be based on client business requirements and expectations.
  • Descriptive Bug report: Whenever tester reports a bug, he/she should provide comprehensive document about the bug occurrence with supportive screenshots. Suggest the severity and priority of the bug and mention the expected and actual results to guide the development team for the bug resolution process.
  • Include Regression Testing: After a test cycle completion, the development team fixes logged issues in bug management tool and release the software for testing again. With bug verification, always ask the development team for impact analysis report and perform regression testing to make sure that there is no impact of the bug fixation process.
  • Test with real scenarios and test data: Negative testing should be done to test robustness of the software, however, make sure that prepared test scenarios and test data is quite real as predictable by client end users.
  • Maintain record of change requests: Once the project is completed one or few releases, usually documentation of change requests is not done by the development team. In this situation, as under change request management, testers should maintain test cases based on the changes with the priority status.
  • Don’t fight for bug fixes: Testers need to report all possible bugs in respective bug management tools with the severity and priority of the bug fix. However the bug fixation selection should be decided based on business urgency by the client, business analyst and technical managers. Definitely testers should give inputs to them with the accurate reasons for the necessity of fixing bugs.
  • Bug Leakage analysis: After product release to client and UAT completion, if bugs are raised by client, Tester should do an analysis of bugs and provide inputs on the bug leakage. Also needs to prepare preventive actions for the future quality releases.
  • Focus on the software testing process, not on the tools: There are many free and paid tools available in market for testing and test management to make our tasks easier. However, testers should always focus on core testing processes; the other tools can be used as additional support only.
  • Don’t presume more of automated testing: Automated testing can be beneficial and a time saver, however sometimes it can be expensive and doesn’t provide the required results.

The requirements analysis and accurate testing are the major reasons of software projects delays/ failures. These golden rules would definitely push all testers to hook on to it for the help in testing. Utilising these rules in a testing project will help in delivering quality software products on time.
Image Courtesy: sjsit7solutions.wordpress.com[:]