T Ashok @ash_thiru on Twitter
Summary
What does it take to do SmartQA? Thoughtful pause, multidimensional thinking, sensitivity and awareness and designing for robustness & testability. A short crisp article continuing from the previous article outlining FIVE MORE thoughts, on what it takes to do SmartQA.
It is about pausing to speed up, it is about thinking multidimensionally, it is about being sensitive and aware, it is about designing for robustness and testability to doing SmartQA.
Doing SmartQA is about visualising the act in one’s mind and taking steps to being robust and enabling rapid and easy validation.
1. Pause to speed up
Before you test, pause; ask what are you testing, for-what and for-where(environment). If you are not very clear, explore rapidly to dig in and understand from users’ POV and architecture/construction. Pause to collect your thoughts as to what issues to go after and how, then uncover exploiting using tools as needed.
After all, doing SmartQA is about enabling clarity to visualise potential issues before evaluating rapidly. Pause to speed up.
2. Multidimensional thinking
Yesterday a good friend of mine told me about his recent conversation with a senior engineering manager in a product dev org. The Sr Engr Manager, a great believer in code coverage told him that he just focuses on covering close to 100% code as the only measure to ensure quality, and as a means to implement shift-left. Absolutely right, isn’t it? After all, ensuring all code written is at least executed once & validated is logical and necessary.
What is/are the fallacy in this? (1) Well you have assumed that all code needed has been written (2) Well, non-functional aspects of code cannot be completely validated (3)Well, it assuming that this is what users really wanted, even if code is working flawlessly (4) Well, the number of paths to cover at the highest level of user oriented validation is just to many to cover, next to impossible! Code coverage is a necessary condition but simply not sufficient.
Doing SmartQA requires multidimensional thinking, of looking of the system from various angles both internal in terms of code, architecture and technology and external in terms of behaviour, end users, environment & usage and then making appropriate choices of what to validate later or earlier and what to prevent or detect statically.
3. Sensitivity and awareness
Being sensitive and aware to the causes of errors is useful in doing SmartQA and delivering clean code.
- At large, errors creep in due to these :
- Untold expectation – Did not know they wanted these, as they did not communicate it to me.
- Accidental omission – They missed stating it clearly to me.
- Quiet assumptions -Filling in the gaps quietly, without confirming.
- Incorrect implementation – Mistakes made during transformation to code.
- Inappropriate modifications – Making fixes without fully appreciating the larger context.
- Interesting side effects – Innocuously affecting others, without appreciating that they are coupled.
- Deliberate abuse – Wantonly use it incorrectly to push it beyond and break it.
- Innovative usage – Used in a very different context that I never thought about.
Appreciate that these may occur anytime, a heightened sensitivity enables us to question, analyse, clarify and validate.
Doing SmartQA is not just finding issues, but sharpening one’s senses to be able to smell these and spot them from afar or near before they hit us. It is about elevating QA to be far more valuable to business success.
4. Designing for robustness
Doing SmartQA is not just evaluation. It is about enabling code that is being built to be robust. To resist errors creeping in, to code-in firewalls. To ensure that I have all I need in good condition before I consume it. This implies that data (inputs) process are clean, the environment I operate in is clean and the resources I need are indeed available, and the dependencies that I have on others are indeed working well.
All I do is to protect myself. How can I handle when irritants are hurled at me? Well I have three choices :
(a) reject them and not do what I am supposed to do (b) flag them (log) and not do what I am supposed to do (c) intelligently scale down and do lesser.
The key focus is be robust, to be disaffected by inputs, configuration/settings, resources or dependent code. The act of designing for robustness makes one sensitive to potential issues that may arise and ensuring we are edged into a corner.
5. Design for testability
Not only is it necessary to design the ‘how-to-do’, enabling ‘how-to-examine-the-doing’ is doing SmartQA. Enabling the ability to test the code easily and ascertain what went wrong to speed up debugging.
Hooking in code to enable the ability to inject inputs to stimulate and the ability to ascertain the correctness of outcomes is doing SmartQA. Putting in traces that can be logged and turned on doing test/debug and off doing production is indeed SmartQA. Embedding ‘self-test code’ is possibly the highest forms of testability.
Ding SmartQA is about enabling the ability to validate too!
You may find the prior article on this “FIVE thoughts on doing SmartQA” interesting. Check it out!