Presentation created by me on \'Testing Intelligence\' on the grounds of QA Blog written by Mr. Joel Montvelisky

1. Testing Intelligence How to become an Intelligent Tester…

2. What is Testing-Intelligence? Testing is not only about coverage, bugs, and UAT/BATs; but about information, stakeholders, and working within a team focused on developing a product/project. “It is an art to provide correct and timely visibility into the product and process, that helps your Organization’s Stakeholders to make the correct tactical and strategic decisions..!!”

3. Testing Intelligence deals with… Test Process & Req. Gathering Phase Test Planning and Scripting Bug Reporting UAT/BAT Best Practices & Testing Professionalism On-Going Improvement

4. Test Process Most if not all development projects are short on time, resources and tests. This means that we as QA Professionals will be asked to cut our testing operations in order to accommodate for the delays of all the other project teams. “So how can we manage to test less and assure we provide maximum value to our process and stakeholders?”

5. For this we will need to rely on Prioritization & Intelligent Testing … We can do this by providing Relevant and timely information, captured from multiple sources and using many disciplines, that will help the project stakeholders make their tactical and strategic decisions.

6. We should ask ourselves 2 things Who are the stakeholders who need this information? What information does each stakeholder need to make her/his tactical and strategic decisions?

7. Only QA can answer these questions since they are directly related to the nature of the product, the team, the end-users, and many additional constraints that define our project. Once we answer them, we will be able to change our mind-set and plan our testing process based on the information you’ll need to provide and the data needed for it. Maybe most importantly, we will be able to decide how to reshape our Test plans when they need some trimming or remolding.

8. Requirement Gathering Phase Thorough understanding of the requirement provided Review Sessions Testability and concreteness of a requirement Less dependency on FS/FRD

9. Our Deliverable and Product as a QA Professional: Many Testers feel frustrated when they are asked what is their Job, and specially about what do they contribute to the overall development of the project ? We must think ..What QA is expected to contribute in the scheme of Product Development Project? Are we supposed to catch all bugs before releasing the product to the world?NO..!!! It is exuberantly expensive to reach this level of bug-free-environment, and 99% of the projects don’t need it anyway. Do we need to run as many tests as possible?The answer again is NO! If we can get the same information (or confidence level) about the product without running a single test we would still be doing our Job – maybe even in a better way!

10. Test Planning and Scripting Strategy Preparation and analysis Test Data preparation Good Test Plan (which covers all the necessary information of the events occurring, the days and sequence of the various stages in test cycle like Test case sign off, Smoke Test, UAT/BAT etc.)

11. Bug Reporting Bug Classification Severity vs. Priority of a Bug Principles of Good Bug Reporting Components of a Good Bug

12. Bug Classification Talking in general, there are 2 ways to set the priority of each bug correctly, the Hard way and the Easy way The hard way: To define the Severity each time from scratch Severity is set based on a scale (of either 3 or 5 levels) according to tester’s objective understanding of the harm the bug causes the system or end-user. But It’s not objective, as two people may look at the same bug and set 2 different severities

13. The easy way: create a Severity Look-up Table S1 – CriticalDefect causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround.Additional specific bugs:- Spelling or Grammar Mistakes- Important bugs that were reported from customers and we assured them will be fixed. S2 – HighThe defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users.Additional specific bugs:- High visibility GUI issues. S3 – MediumThe defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users. S4 – LowThe defect causes no dysfunctions to the system and may even be unnoticed by most users . The bug has an easy workaround or may not even require a workaround at all. S5 – Enhancement Request or Suggestion

14. Severity vs. Priority of a Bug I look only at the Priority field and so QA shouldn’t waste time writing down the Severity Yaa…90% of the time Priority and Severity have the same value I think..QA just wants to exaggerate the severity of some Bugs DEVELOPERS

15. Priority Severity Priority refers to the Project and how urgentit is to solve the Bug. Priority is set based on changing project factors eg. Status of the bug, its importance from customer side. Priority is a dynamic field, should be revised and updated as the project progresses. Severity refers to the Bug and how it affectsthe User’s interaction with the Application Severity is objectivelyset based on the direct and indirect impact of the bug and its probability of occurrence. Severity is usually a staticfield. (the only reason to modify it would be if we learn something new about the bug. )

16. His bugs are always URGENT...!!! Bugs are never correctly prioritized ..$$...### Am annoyed by this LOW LEVEL PROFESSIONALISM DEVELOPERS

18. Don’t waste the time of the other people reviewing the bug and trying to make sense of what you wrote.

20. Root Cause Analysis QA professional must be able to analyze the root cause in order to support/justify the defect raised by him. Some of the possible root causes are: Not a Defect New Requirement Design Code related System/Backend Data

21. METRICS AND STATISTICS Can Metrics be EVIL? (No, but the people who misuse them can…  )

23. Metrics need to be balanced.

24. Metrics need to be normalized.

25. Metrics need to be comparable.

26. Don’t make Metrics personal.

27. What we want to communicate by publishing our metrics?

29. Best Practices Never stop learning new stuff : Make a list of sites and blogs that regularly post the important stuff, if possible subscribe to their daily letter or news feed. Whenever you have some free time, or when you need a break of what you are doing, go over these sites and mails making notes of the stuff that sounds interesting or important. Download and play with the new software, or simply think about how you can use the information you just read in your day-to-day work.

30. 7 habits of highly effective testers Context awareness: always understand the higher objective of what you are doing Self awareness: realize your personal advantages and limitations Hands on attitude: a need to stay connected with the concrete tasks taking place Value of communication: explain simply and correctly Teamwork: collaborate to achieve synergies On-Going Improvement: self & external criticism to keep-on growing Urge to learn: thirst for the expansion of knowledge

31. On-Going Improvement Does anybody know what is …. hitting a brick wall?

32. This means the all-too-familiar feeling that “Regardless of how much you raise your voice and warn all the project stakeholders about the imminent danger of following a certain path, they decide against your advice and follow it anyway…” Who hasn’t gone through this before?

33. Make your homework before the meetings Make your objective to become the Trusted Adviser of your project Heavy-Weights: you need to create a reputation for yourself that will make people listen whenever you speak your mind. Be open to change your mind when you understand new things about the problem at hand Learn to pick your fights Learn how to communicate You need to become a Project Trusted Adviser!

34. Reference “Testing Intelligence” - Mr. Joel Montvelisky http://qablog.practitest.com/

35. All The Best & Thank You.