Testing Rules… | Conditions applied ***

My professional life has been really crazier if I compare to others, I was working more than 280 hours/month. You believe me or not … I was reached office 8.AM and technically closed my laptop around 11 PM on next day and in-between 2 to 3 hours nap and of course weekend also work. This scenario like more than 6 months reason behind was 3 times my project release date was postponed.

So lot of learning from different failure projects, how I should not Test any product.

Rule 1: Never create a defect just for request (Business, UAT, Developer, another team )

Rule 2: I never forgot the rule 1.  Which means that create a defect unless impacting the test execution plan or impacting quality, the reason behind was more 7000 Defects were opened status and 2000+ defects opened by other than QA team. The real challenge was how to close the defect(s)/Map to test cases, 80% Test cases were unable to execute due to open defects, an everyday plan was just blocked the test cases with the critical defect(s).  Yes, it’s a true story…



Rule 3: Test execution is everything, An initial plan is always failed 99.99%, So start the execution “Yes”. execution is everything. Show some progress to our customer, Example: if your interface system is not ready then push the file manually, Ex: the third-party system is ready but your Or interface system not ready so DON’T WAIT … we need input data that’it (like XML, JSON, or Flatfile) drop it the Q/Services and get the response.  DON’T WAIT for approval.Show the progress. Never stop the testing!

Rule 4: Quality = On Time Delivery

My most of the projects are a failure, tester(s) never high light the issue on time, Everyone ready to do testing, then if the issue occurs they were escaped. As we are a testing team as long as billable, we have to send the status report until the project complete. It does not matter how many test cases are pass or fail, communicate through email on daily share the testing status report right audience, highlight the risk in advance, most of the tester never speak or fight for quality. we have to raise the product risk and show the red-Alert. All the priority defect should be retested and closed as per the TSLA.[ Testing Service Level Agreement]

example :

Priority 1 defect should be fixed, retested and closed within 2 hours [ depends on business/users] if you provide a testing support for production, that issue should be retested and closed -ASAP.

PS: Testing is not finding the defect(s), need to communicate to right team on time, report the defect, retest and close the defect then move to production on time, meet the customer and market demands.

Rule 5: Tester is not headcounts or resource, not a PPT show.

Everyone thinking that, Testing is simple. may be simple but not an easy, We have challenges we need a tester(s) urgent for our project if you fill the headcounts Guess what? real outcome will be a delay and don’t fill headcounts for the budget approval. Another one was 100% of test cases will be automated and we have the framework already in place.  This is a ####. who will do the automation is that automation tester or PPT.

Plan on daily goals for 1,2,3 mode. This means that 30,60 and 90 days then keep move on.   Ex: To complete the quality assessment,  the POC takes 30 days and show the progress on daily basis and share the challenges as much early, the second plan on improvement on test reports and last 30 days for open items and plan to next testing move.

Rule 6: Testing is a business relationship.

Tester roles is a unique role, compared to Business Analyst, Project Manager, Scrum master, developer, and Business Users. We(testers) have the challenges with a building relationship/communicate with different stakeholders. if you work with multivendor management we must be transparency mode, this is always to improve the business relationship and trustworthy.

Rule 7Actual testing effort should come up from the testing report.

When you start the test execution, the testing report has to speak about tester(s) effort and product quality. This report should go to the right audience on right time. Most of the time when we have to communicate the problem in the right manner, ex. The Critical bug report looks like a medium priority bug based on bug description, so as a tester should always say as a critical bug.

Rule 8: Testing is not a 9 to 5 Jobs 

Software testing quite challenges nowadays, Tester effort not just find a bug and report to the developer, Tester(s) must care about the quality of product and meet the market demands.

which means.

  • When the deployment is completed ensure that product is up and running.
  • Provide the support to developer for identifying the root cause during the deployment
  • Any production issue occurs, connects the call and ensure that application up and running.
  • User experience/Usability issue should be communicated to right audience [ BA, Product owner]

Rule 9 Fail faster and choose a right defect management tool : 

Find the defect as early, is it not easy but really worth, So defect management and test-management tools helping to improve the software quality.

Few sample defect category ++

  1. Accessibility / Usability  issue
  2. Business requirement error
  3. Coding/Program error
  4. Content issue
  5. Data error
  6. Environment error [ Database, Infrastructure issue, System Access and more…]
  7. Functionality issue
  8. Interface error [ when we  integrate into third-party system]
  9. Requirement error/Functionality Gap
  10. Security issue
  11. Performance issue
  12. UI Issue
  13. OS Specific error [ Browser specific, Operating system specific ]
  14. Understanding error /Clarifications
  15. Tester error [ During the execution, Test cases error or Input data error ]
  16. Out of Box functionality  [ Product specific or Enhancement ]

So choose the right defect management tools, My favourites tools are HP-ALM and Jira, tool(s) will be helping to improve your product and process. Never use the XL sheet version[s].

Source  HP –  Sample report dashboard.


Rule 10: My favorite rule 

“As long as people need information they can trust, there will be a need for skilled testers” —

& & &  more…

Leave a Reply

Your email address will not be published. Required fields are marked *