10 Simple Tips to Clean Code

by T Ashok @ash_thiru on Twitter

Summary
As much as testing is seen as a key activity to deliver quality, there are simple practices that can ensure that code developed is constantly cleansed. In current times where code is churned out at a rapid pace, it makes great business sense to contain the entropy continually. This article outlines ten simple tips to help produce clean code continually.


“Great quality code is not the result of intense system testing, it is result of well structured filtration of issues from the early stages. A compromised ‘unit test’ puts unnecessary strain on the QA folks who seem to be compelled to go after these issues at the expense of system test.”

Developers do not deliberately write bad code, it is just that accidents happen. Accidents happen due to a variety of reasons – unclear requirements and therefore making assumptions, just sloppy coding, brute force push of unit testing without it being simple and practical, over reliance of testing rather than prevention, not enough refactoring, not enough focus on non-functional requirements(NFR).

Here is  how I feel as a developer as a poem titled “Hug each bug”

On a quiet  night
I sat down to code
Happiness in every byte
On the keyboard, it just flowed

Sheer poetry it was
But quietly slipped in tiny flaws
Silly it was, what I found
When the code ran aground

An exception I missed
And the code really pissed
Forgot to catch the ball
The system had a mighty fall

Bugs are uninvited guests
Makes you beat your breasts
That is why you need to test
So that you deliver your best 

I say Hi to every bug
From each one I learn
Embrace with a warm hug
For perfection is what I yearn

If you want a lovely poster version of this, click here.

What may be some tips that I as a developer can follow to write clean code?

  1. “Never assume, ask, question”
    Requirements are never complete, it just gets refined with time. Don’t assume when something is unclear.
  2. “Think of behaviour in terms of conditions”
    Good behavior is about compliance to conditions
    ,ensure combinations are well taken care.
  3. Be friends with bug(s)”
    Do not hate bugs, for they are the ones from who teach you constantly to do better. Learn from each, so that you find it and not others.
  4. “Use smart checklists”
    While coding, be sensitive as what issues can occur. Sensitise & prevent rather than rely only on test to find issues.
  5. “Treat code as a living entity”
    Nothing is frozen. Refactor, refactor constantly to simplify. Clean code is really never done, how much you can do is simply limited by time.
  6. “Be sensitive to NFRs”
    Non-functional requirements cannot be ‘fitted’ in later, so pay attention to load, performance, usability scaling, security, maintainability etc. always.
  7. “Don’t be scared to inject bad inputs”
    Checking correctness with good inputs are fine, but it is incorrect inputs/settings that create unwanted technical debt. Get these out of way early, by ensuring robustness at early stage.
  8. “Be purposeful of issues to find via unit test”
    There are different types of issues that may be there, be clear as to what to strive to prevent, what to go after via unit test and what at higher levels of testing. Ensure clarity of what you are going after.
  9. “Strive to understand how your code will be consumed
    It is not meeting a spec, it is not working in isolation, it is about visualising who (i.e other code) will use/consume my code so it can take care of the situations in future.
  10. “Unit test is not an after thought or compliance”
    The act of unit testing is not a chore or compliance to satisfy someone, it should be natural thing that we do to ensure our code does not stray. Treat this as part of coding, not as another activity post code. Write a script while doing this or jot down stuff to perform this manually. Stay lightweight so that you can repeat this continually. After all, development should be friction-less.

About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

12 tips to reinvent yourself in testing 

T Ashok (ash_thiru on Twitter)

Summary
The way we build systems has changed, both in terms of technology and the process. The expectations of end users/businesses have changed in terms of speed of delivery and in terms of expectations.  In this article are outlined 12 tips to morph and reinvent oneself to become a modern smart tester.


1.Become tech savvy. Know the insides.
Understand what happens behind the hood. Know what your system is composed of. Learn to think of issues resulting from integration of various technologies, of different systems that make your solution.

2.It is ‘-ities’ that is key. Go beyond functionality.
Yes, correctness of functionality is important. But in these times, it is ‘-ities’ that are key to success. Well we know for sure how usability has become mainstream. We also know ‘compatibility’ is critical especially device compatibility of mobiles/tablets. Performance, security, error recovery is  now a given. So it is necessary to become adept in evaluating ‘-ities’ too.

3.Focus on value. It is not about activities.
What matters now is not how-many, it is really how-valuable. End users are keen on the value-offering i.e. how does it help me do better, how does it ease my life..?

4.Automated test is basic hygiene now. Become comfortable with tooling.
Well it is expected that you exploit technology/tools to accelerate what you do and replace what you do. So being comfortable with tools and rapidly able to exploit other tools/languages to getting things done is expected. Tooling is no more an esoteric skill. Remember it is not about ‘big’ tools, it is about also having a a nice ‘SwissKnife’ tool set to enable you to do faster/better/smarter.

5.Be Agile. Respond quickly.
It is no more about days, it is about hours. Change your mental model to test in short sessions, change your mental model to re-test far more efficiently, change your mental model to focus on impact far sharper.

6.Test is no more just an activity. Make it a mindset.
As we morph to deliver clear code faster, it may not always be an explicit activity. It is about having a ‘test/perfection mindset’ so that we built/craft code quicker and cleaner. 

7.Go beyond our discipline. Copy from others.
Stay sharp and wide open to see how great quality/perfection happens in other disciplines.Unabashedly copy and adapt. It is necessary to be non-linear. Be inspired from lateral disciplines and humanities/social, nature, arts etc.  to evaluate, to prevent, to build better.

8.Don’t just do. Enable ‘how not to do’.
It is not just about evaluation anymore, it is about how we can prevent evaluation. Enable building robust code. Enable better sensitisation of issues early. Do more ‘what-if’ to build better code. 

9.Go beyond software metrics. Measure in business context.
It is great to use measures of testing to guide the act of testing. Given that we are in the age of speed and instant gratification, it is is very necessary to relate the software measures to business & end user context to ensure success. For example (1) it is no more just a performance metric, it is about how (say) response time affects the business(end-users) positively (2) it is not about overall coverage alone, but about what it means to the risk of the immediate releases. 

10.Constantly unlearn.
Unlearning is a skill. The ability to constantly question if what we know is relevant and drop it to make way for newer skills is paramount. 

11.Abstract well. Visualise better.
Today the act of building systems is brilliant with excellent abstractions facilitated by frameworks. The focus is on great clarity and the ability to reassemble/morph quickly, much like ‘Lego’ bricks. The same is applicable for us test folks too. Abstract well (1) the system and how it is composed (2) the issues you are going after and therefore the strategy (3) test assets to facilitate continual adjustment (4)automated suites so that you can flex it to suit the changing needs (5) test data so that it can be relevant for a longer time.

12.Get out of the well. Be able to scale across.
What we do now is no more a silo related to evaluation. It is imperative to build/tweak code, setup environments, deploy, assist in debug, help ideate features to improve value, in addition to testing. Be able to do ‘everything’ to scale across.


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

How do I grow in my QA career?

T Ashok, @ash_thiru

Summary:
What is growth? Is it money, position, power or the confidence to get anything done? Growth is not just knowing more, it is about deep understanding aided by reflection that allows us to assimilate. Growth is not merely external, it is building inner strength, to influence positively.


In conversations with test professionals I come across questions that relate to career growth – “How do I grow in testing? What should I do to grow? What areas in testing should I pursue to grow quickly? …”. These are interesting conversations as there are no specific answers.

Let us dig a little deeper to understand what career growth may mean. Is growth about earning more money? About better designation? Or more ‘power’ in terms of larger project/team size…? I bet your answer will be “All of these”. Hmmm, these are outcomes of growth, but the question still remains – “What is growth?”. Is it deeper knowledge? Or skills/abilities? Or is it the confidence to get anything done?

I would like to believe that the last one is most appropriate. It is about having the confidence of getting anything done. If you can handle stuff that is more fuzzy, difficult, constrained, large, with huge expectations, then you grow faster and higher.

It is not just doing work, it is about getting work done. It is about being a leader. Take a minute and reflect. A young baby needs support to get things done, as he grows, he manages to be self-sufficient. As he becomes a young adult, he is able to manage others and later as an adult when he establishes his family, he leads, not just manage.

As you grow this is what happens : Managing yourself –> Managing others(or things) –> Leading (others/things). The ability to “do”, “manage doers” to “leading doers” is what defines growth. Initially it is about managing, later evolving into leadership.

Leadership is about influencing others. It is about believing in yourself and not really care about what others think. A far cry from being dependent on what others think about you to figure out if you are good. It is about having belief and confidence in yourself. It is not about ‘toeing’ the line, it is about leading. It is not just agreeing to other’s view, it is about having healthy arguments to put forth your views/thoughts.

Bodily growth cannot happen when you just eat more, it happens only when the food is digested and assimilated. Likewise, it is not about just knowing more, it is about deep understanding aided by reflection that allows us to assimilate. This results in more than just knowing, it is about forming heuristics as when to/not-to apply, akin to absorbing and purging, resulting in one to becoming confident in the application of knowledge.

Growth is evolution and evolution is “Add/Modify/Delete”. Visible external growth is “Add”, the accumulation of mere knowledge. Real ‘internal’ growth is “Modify/Delete”, the assimilation that changes the internals, and purgation, the “Delete” that discards old views/ideas, strengthening you from inside. Growth is not merely external, it is building inner strength.

With inner strength comes confidence and the power to influence. To influence the project team we work with. To influence the product we are building. To influence the company where we work. To influence the customer who uses our product. To influence the test & software engineering community.

The expanding spheres of influence :
Individual “I” –> Project team “US” –> Product “OURS” –> Company “US & OURS” –> Customer “THEM” –> Community “WE”.

Now you do not care about what others think. You have grown. Stuff happens. You do not ‘just do actions and get things done’. You deliver ‘business value’. You feel good. And possibly get noticed. Anyways you enjoy what you have done. And the wonderful outcomes of growth happen.


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

10 Habits to Help You Speed Up Testing

by T Ashok @ash_thiru on Twitter

Summary
In today’s age of speed, technology/ automation is seen as the key enabler for rapid QA. Yes, it is indeed, but the limiting function to speed is one’s skills. And this is where good habits come in. Here are TEN good habits for QA that can help you speed up significantly.


Habit #1  Practice… Practice… Practice..
Practice exploration. Practice looking for bugs. Practice modelling behaviour. Practice writing tersely. Practice scripting. Practice observation. Practice.. Practice.. so that you can unconsciously do, speedily and well.

Habit #2  Focus… Focus…
Focus on the who. Focus on the what. Focus on the where. 
Focus on the what-for. Focus on value. 
Relentlessly discard the noise, the unnecessary.

Habit #3 Analyse… Analyse…
Should I regress this? Should I look for this issue? 
Should I test on this environment? Should I document so much?
Should I really do? How much should I do? Can I do lesser?
Constantly analyse as to how to do less.

Habit #4 Steer… Constantly steer…
Course correct. Adjust. Revise Improvise. Adapt. Repeat.
As you do, continually revise becoming quicker and better.

Habit #5 Immerse… 
Be aware of the act now. Stay in the present. Be mindful.
Immerse yourself ‘stopping’ time, accomplishing more.
Explore immersively, centering to see everything.   

Habit #6 Sharpen…
What issues matter for who, where and why? What is the business benefit? What is the user experience? What may be the potential impact?
Stay purposeful. Sharpen the objective.  Setup the route. Stay on it.

Habit #7 Simplify… Simplify…
Too complex to understand. Break it down. To complicated to execute. Decompose.
Relentlessly simplify. Never muddle the clarity. 

Habit #8 Discard… 
Learnt that this is not working? Discard. 
Figured you were wrong? Discard.
Saw something better? Discard what you did.
Metamorphose all the time.

Habit #9 Organise… 
Setup goal. Plan. Do. Observe. Take notes. 
Distractions happen. Problems surface. Chaos threatens. 
Yes, that is natural law. Stay organised, in the mind. 
Discipline, structure smoothens disruptions, in the mind.

Habit #10 Leverage… 
See patterns and exploit it. Observe others work and improvise on it. 
See parallel in other disciplines and apply it. 
Use smart checklists.  Use tools. Reuse strategy, scenarios, scripts.


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high-quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

50+ Software Testing Terms that are most often abused!

by T Ashok

Summary 
Terms used in the software testing discipline are often confusing leading to them being abused. Most of the phrases seem to have appendage of ‘testing’ like a surname that seems to make it belong to a family. Some terms are test types while some are approaches, and some practices and so on. This article partitions 50+ software testing terms into cohesive groups to sharpen the clarity depicting it as simple mind map and then giving a clear definition to each one.


Jargons abound in software, only to be misused most often! And I think in our discipline of testing,  they are abused even more! In the testing discipline, most of the terms seem to have an appendage of ‘testing’ making it far more confusing. 

In this article I have attempted to put together a mind map
attempting to group terms cohesively based on a phrase
to minimise confusion and sharpen clarity.

50+ software testing terms grouped cohesively to enhance clarity of understanding

Here are quick explanation of these terms with details in the associated link after the terms. 

Levels of testing
Unit, Integration, System, Acceptance refer to the levels of the testing, implying as when in the SDLC, the earliest being the Unit testing.

Types of Testing
Functional, Performance,Load, Security, Reliability, Stress, Volume and others are really specific types of tests designed to uncover specific types of issues, the functional being the behaviour while the others are about the various attributes.

Test Techniques
Black, box, White box are really test techniques that use external behavioural information to design test cases whilst white box uses internal structural information to design test cases. Pair-wise(All-pairs)  Orthogonal array are specific techniques to combine of test inputs to generate optimal number of test cases.

All pairs testing
… is a combinatorial method of software testing that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by “parallelizing” the tests of parameter pairs. (From Wikipedia )
Click here to read in detail.

Orthogonal array testing 
… is a black box testing technique that is a systematic, statistical way of software testing. It is used when the number of inputs to the system is relatively small, but too large to allow for exhaustive testing of every possible input to the systems. It is particularly effective in finding errors associated with faulty logic within computer software systems.Orthogonal arrays can be applied in user interface testing, system testing, regression testing, configuration testing and performance testing. The permutations of factor levels comprising a single treatment are so chosen that their responses are uncorrelated and therefore each treatment gives a unique piece of information. The net effects of organizing the experiment in such treatments is that the same piece of information is gathered in the minimum number of experiments.

(From Wikipedia)

Click here to read in detail.

Execution Approach
The terms “Manual testing” and “Automated testing” really indicate the method of execution of test cases, the former implying using a human being whilst the latter is about using a machine to execute the test cases.

Black-box testing
 … is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance. It is sometimes referred to as specification-based testing. (From Wikipedia)
Click here to read in detail.

White-box testing 
… is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality. White-box testing can be applied at the unit, integration and system levels of the software testing process. Although traditional testers tended to think of white-box testing as being done at the unit level, it is used for integration and system testing more frequently today. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it has the potential to miss unimplemented parts of the specification or missing requirements. (From Wikipedia)
Click here to read in detail

Model-based testing
… is an application of model-based design for designing and optionally also executing artifacts to perform software testing or system testing. Models can be used to represent the desired behavior of a system under test (SUT), or to represent testing strategies and a test environment. (From Wikipedia)
Click here to read in detail.

Adhoc testing 
… an approach to testing a software in a unstructured manner with consciously applying any techniques to design test cases, to break the system using unconventional ways.
Click here to read in detail.

Exploratory testing
… is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.  It is defined as”a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” (From Wikipedia)
Click here to read in detail.  Another great read on this is here.

Risk-based testing (RBT) 
… is a testing approach which considers risks of the software product as the  guiding factor to support decisions in all phases of the  test process.
Click here to read the full article.

Shift left testing
While early testing has been highly recommended by software testing and QA experts, there has been a special emphasis on this agile approach of Shift Left testing that recommends reversing the testing approach and involving system/software testing earlier in the lifecycle. Practically, move the testing approach to the left end on the project timeline.
(From Cigniti blog, Click here to read the blog).

Continuous integration (CI)
… the practice of merging all developer working copies to a shared mainline several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day. (From Wikipedia)
Click here to read in detail.

Continuous delivery (CD)
... a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.  It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. CD contrasts with continuous deployment, a similar approach in which software is also produced in short cycles but through automated deployments rather than manual ones. (From Wikipedia)
Click here to read in detail.

Test-driven development (TDD) 
… is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements. (From Wikipedia)
Click here to read in detail.

Acceptance test–driven development (ATDD) 
… is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD),example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language.

ATDD is closely related to test-driven development (TDD). It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding. (From Wikipedia)
Click here to read in detail.

Behavior-driven development (BDD) 
… is a software development process that emerged from test-driven development (TDD).Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. (From Wikipedia)
Click here to read in detail.

Health checks
Sanity testing is primarily a basic evaluation for the system to ascertain if it basically good enough to go ahead so that we may proceed to do thorough testing. Regression testing on the other hand is primarily about if checking prior health of the system has not not compromised due to changes done now. It simply means that was was available and working in the system continues to do so.


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

50 Tips to Smart QA

by T Ashok

SUMMARY
Here is an interesting collection of FIFTY tips that spans across many dimensions to enable one to become “Smart Tester”.


1. “Don’t do work. Prevent.”
Smartness is about thinking well, so as to not do. It is not avoiding it, but about quashing the need of it. For example, do I need to regress this? With smarter analysis of change, should I really regress this? Can I inject code to self test, so that I don’t have to test it?

2. “Do less.”
Smartness is about doing minimally. It is not because of lack of time/effort, it is about being sharply focused to not spread thin. For example what may be the minimal data sets to ascertain correctness, what may the optimised combination of environments to test on.

3. “Do just as much.”
It is kind of mix of (1) & (2). How much to do and what can be avoided. The continuous sharp sensitivity to be just right enough. Selecting just the right set for scenarios from a larger set for (say) a given specific customer.

4. “Do anything beautifully.”
Be it writing a document, or presenting a report, or test data sets, let it be beautiful. Great aesthetics nourishes the should making us do great work.

5. “Do quickly.”
Chunk tasks, get it done quickly. Don’t stretch an activity, strive to complete quickly so that you can get feedback, learn and refine and of course, get the work done faster!

6.“Detect at the earliest. Prevent if possible.”
Guess this is self explanatory!

7. “Exploit technology.”
Automate maximally, use tools for setup, compare, manage, check, monitor etc, to help you do, to help you gain better insight.

8. “Adapt, adjust, adapt, adjust..”
Be like the water that flows, not fixated, open, to constantly adjust and refine the strategy, plan, scenarios, scripts, tools, priorities, understanding..

9. “See the mirror constantly.”
Setup measures for feedback, to constantly analyse and stay on course continually.

10. “See consciously, see unconsciously too.”
Observation is a key skill for test folks, to judge, to see patterns, to connect the dots and enhance test strategy and action. 

11. “Add, delete, refine. Evolve.”
Utility of anything is never fixed, everything looses shine with time. Constantly egg yourself to evolve. For example test cases over time will stop finding issues, in certain customer environments, some flows may be never be done requiring continuous evolution.

12. “Empty yourself periodically.”
Make way for new thoughts/ideas, by discarding the ones we have periodically. Consciously discharge to recharge.

13.“Focus on outcome, enjoy the journey.”
Repetitive testing can become boring, the trick is to enjoy the journey by noticing the finer nuances that are different each time.

14.“Doing is great, but value matters.”
It is not just doing activities, but about producing great outcomes. Doing excessive testing without demonstrating high utility to end customers is sadly an exercise in futility.

15. “Be mindful, immerse yourself.”
Being in a flow allows to be very sharply observant unconsciously enabling us to deliver great work and making it enjoyable!

16. “Leverage other people work.”
Don’t do what has been done before. Leverage assets aggressively be it tools, frameworks, scripts, scenarios/cases/data, strategy/plan. Before embarking on activity check if this has been done before.

17. “Blend your left and right.”
It is not just about using the logical left brain or the creative right , it is about a harmonious combination of logical/scientific left brained thinking with the creative right that makes testing super effective and super efficient.

18. “Be rational, but trust your gut too.”
Staying engaged, being immersive results in deep unconscious learning resulting in the gut feel. Something we look for certain issues in certain situations kinds based on gut feel. Staying logical and rational is important, but don’t understand the power of gut feel.

19. “Analyse situations logically, but act on the choices.”
We analyse situations (say) ‘why did this occur’ and come up with a list of choices. It is necessary to use and on these choices, to realize the full benefit of logical thinking.

20. “Stay focused and purposeful.”
A purpose gives the power to focus,  for example looking for specific issues allows to sharpen the approach and test cases. 

21. “Focus is great, but meander too.”
Focus enables to being purposeful, but it is like a horse blinder. Some bit of meandering, observing the system at large while performing a focused test improves our overall understanding enabling us to refine to do better.

22. “Look outside, learn from other disciplines.”
The stick robot was inspired by the insect, velcro was inspired by lizard feet. Read, watch, experience things outside of our discipline to innovate.

23. “Stay curious, question, explore.”
Testing is scientific exploration, driven by curiosity and fueled by intense questioning.

24. “Decompose well, and problem solve itself!”
Well the problem may not solve itself completely, but good decomposition of a problem is very to solving it. For example clearly decomposing ‘what-to-test’ into various granular entities like screens, features, flows and ‘what-to-test-for’ into different types of issues and therefore clear set of tests ensure clarity of problem and also of the solution.

25.  “Relentlessly simplify.”
Albert Einstein said “If you can’t explain it to a six year old, you don’t understand it yourself”. So relentlessly simplify to sharpen clarity and understanding, the key ingredient to great testing.

26. “Write less, accomplish more.”
Documentation is useful history and that happens only when the present is meaningful and valuable! So think better, write just enough, focus on doing great.

27. “Sift continuously to sharpen clarity.”
It takes tremendous sifting to separate gold from rocks! To understand a system, play with it, read, explore, discuss, repeat by varying, discard what is not need, repeat until time runs out. A deep understanding of context, usage, system is central to great testing.

28. “Think like a scientist, do like an engineer, feel like an artist.”
Deep scientific thinking, pragmatic implementation and enjoying the aesthetics of doing and outcomes in a brilliant combination makes the activity enjoyable and outcomes very valuable.

29. “ Visualize in the mind’s eye.”
Seeing the system flows, the perturbation of a modification, the structure of systems in one’s mind eye clearly, the ultimate result of great understanding, makes probable issues stand out.

30. “Fly high to abstract, stoop low to see details continually.”
See the forest for the trees to gain a great systemic understanding, and also dev down to look at the individual leaves to understand the details, repeating this in an endless cycle to understand a system and context better.

31. “Keep your cup half empty.”
“Exactly,” said Master Ryutan. “You are like this cup; you are full of ideas. You come and ask for teaching, but your cup is full; I can’t put anything in. Before I can teach you, you’ll have to empty your cup.” Create space in your mind to space to absorb, to learn and understand , and therefore defer what is not needed now.

32. “ Problem solving is a mix of techniques, principles, heuristics.”
Apply techniques to solve clear problems, employ principles to chart the direction and use heuristics to guide you. There is no formula, not is everything from experience. It is a judicious combination of techniques, principle and heuristics(guidelines)

33. “Trust what you do, prove what you have done.”
It is not just about “trust me”, it is about demonstrating proof in what you have done. Justifying  test adequacy is one key application of this in our discipline.

34. “Understand the behavior outside, know how it composed inside.”
It is not ‘black’ or ‘white’. it is about knowing the external behaviour and also the internal structure in terms of architecture, data/control flows, interfaces and so on.

35. “Never forget that human uses the system.”
Testing is not a clinical examination of the system, it is being empathetic and ensure the human end user benefits from the system.

36. “See the many dots, connect them continually.”
Testing is not deterministic following a simple set pattern, it is about observing, experimenting creating and seeing dots and constantly connecting them to do better and better.

37. “Be open to different points of view without bias.”
Testing requires a very open mind, to see various points of video, engage in arguments and disagreement without bias so that we may get new ideas to ‘poke’ the system and find issues.

38. “Form opinions based on facts.”
As much as it is important to be open, formulate opinions based on pure facts so that you can anchor and explore better.

39. “Relentlessly pursue, but know when to timeout.”
Sometimes bugs vanish down the rabbit hole, sometimes systems behaves weirdly, these are not to ignored, these are opportunities to pursue relentlessly, be watchful of the large picture of business and timelines, know when to timeout.

40. “Constantly assess what you don’t know, not gloat about what you know.”
It is the gaps in knowledge that help us to become better forcing us to learn and refine and not just the knowledge that we possess.

41. “Do with pride, stay humble about outcomes.”
Pride in work comes from confidence we possess, very necessary for great testing. When test artefacts are reviewed, demonstrating confidence is key. To be able to stay that way, it is important to be humble enough so that we don’t become over confident!

42. “Prioritize continuously.”
Testing is risk reduction, and given the challenges of time, cost and quality, staying focused and continuing to do with the issues and challenges demand we constantly re-prioritize focusing on what is most relevant as of now.

43. “Stay balanced.”
Extremes of too much testing or less testing, too much reliance on tools on only on facts etc may not be very productive. It is the fine art of attempting to staying in balance that is key to great outcomes.

44. “Try to connect cause to effect constantly.”
Attempting to figure out the potential cause from observed effects enables us to refine our strategy and explore better.

45. “Pay attention to special cases, not be satisfied with common causes.”
It is the interesting one-off situations that help us to understand somethings far more deeply rather that the common occurrences that cause issues.

46. “Time is not a constraint – It is what can I do, not how much do I need.”
We all know that the clock does not stop, we can only freeze what we can deliver. Given a time target, it is about how much I can accomplish that matters in today’s world.

47.  “Listen silently, talk excitedly!”
When we listen to some one’s views silently without bias, new ideas emerge. On the same view, when we talk excitedly about our view with the other person silently listening to us, ideas refine and sharpen!

48. “Take notes copiously.”
While observing, listening, experimenting, exploring, take notes liberally to help you remember, and more importantly come with interesting ideas when you re-read it.

49. “Stimulate all senses – write, draw, colours, direction, voice.”
When you note down observations, put together a plan, jot down scenarios etc., mix it up – write words/sentences, using colours and directions (up, down, angle..), voice record too, so that you keep the right brain vibrant and stimulate the unconscious to see the unknown.

50. “Code, design, build, troubleshoot, write, read.”
It is not just testing that matters, it takes well rounded skills from the entire life cycle that ensures we deliver clean code. Design and code to build systems, troubleshoot and support, write documentation and read other people’s outfits to become a great software professional!


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

7 Thinking Tools to Test Rapidly

by T Ashok

Summary
The act of testing is a scientific exploration of a system done in three phases – RECONNAISSANCE to understand and plan, SEARCH to look for issues, REST&RECOVER to analyse and course correct. To enable the various activities in each phase to be done quickly and effectively, is where the SEVEN Thinking Tools outlined in this article help. How to apply these tools in a session-based approach is also briefly outlined.


When I hear people talking about testing as Manual or Automated  with the latter being the need of the hour, I am flabbergasted. All the word ‘manual’ conjures in my brain is that of me doing a menial job of painful scrubbing!

Definition of manual from Cambridge Dictionary

It is time we used Intellectual & Tool-supported. “Think well. Exploit tools to do.”Enough of rant!

In current times, speed is everything, right?  What can we do to test quickly ? Use tools. Automate. Right? Wait a minute – This is about execution, right? What about prior activities?

To answer, let us ask the basic question what is testing after all? Testing is exploration. Let me correct it. Testing is scientific exploration.  And exploration is a human activity that is aided by tools & technology. How can we do scientific exploration rapidly? By using tools that help us think better and do faster.

Let us say you want to explore the nearby mountain range by foot. Would you just pick up your backpack and go on? I bet not, unless it is a really short trip. Otherwise I think you will study the geography/terrain, read others’ experiences, do a reconnaissance, create various maps of terrain, of pit stops, of food joints etc before you chalk out the full route. Once the route is setup, you will pack your bags and go. As you explore, you will discover that “the map is not the terrain” and be taunted, surprised, challenged and you will learn, adjust, improvise, revise the maps, routes as needed. Tired, you will rest, analyse, replan & recover to continue on your journey. This is not ad-hoc nor driven by sheer bravado. This requires logical thinking(scientific), planning and ability to observe, adjust continuously and also some bravado and good luck!

This is what we can apply too in testing our software/systems. This article distils this and provides you with SEVEN THINKING TOOLS to enable you do these easily and scientifically.

Applying the above analogy, we look act of testing as being done in THREE phases: RECONNAISANCE, EXPLORATION, REST&RECOVER.

RECONNAISANCE : Do survey and create maps
Survey : Get to understand the system under test by reading documents, playing with the software/system, discussing with people, to clearly understand who the end users are, what the entities (e.g. features, requirements..) to test are, what the various attributes the end users expect are, and the environment in which it will be deployed. In a nutshell we want to know the Who, What-to-test, What-to-test-for and Where. This is done by the Tool #1 “Landscaper”.

Picture of Landscaper tool

Create Maps: Now that you know the key information, connect them to four useful maps: Persona map, Scope map, Interaction map and Environment map.

(Tool #2) Persona map : A list that clearly connects  the “Who” to What”. This helps us understand who uses what and therefore helps us prioritise testing and certainly enables us to get user centric view to validation.

Picture of Persona Map tool

(Tool #3 )Scope map: A list that connects the ‘What’ to ‘What-for’. This helps us to understand what the expectations of the various entities are i.e. That for even feature F1, we have an expectation of performance. What does this help us do? This helps us identify the various types of tests to be done.

Picture of Scope Map tool

(Tool #4) Interaction map: No entity is an island i.e. each entity may affect one or more entities. i.e a feature F1 may affect another feature F2 and therefore a modification of F1 may require retesting of F2. How does his map help us? Well, this helps plan our regression strategy intelligently.  

Picture of Interaction map tool

(Tool #5) Environment map : This lists out the various environments on which the final system may be run so that the functionality and attributes may be evaluated on various deployment environments.

Picture of Environment Map tool

Now that we have done done the reconnaissance, we should have good idea of the system under test and therefore be ready to explore.

SEARCH : Now that we have the maps, the next step would be chalk out the routes and then we are ready to commence our search for issues. This is done using the “Scenario creator” tool. Once this is done we commence our search for issues. When doing this we will encounter things we don’t know, things that we did not anticipate, issues and therefore will need to revise and course correct revise the landscape, maps and routes. This is accomplished via the Dashboard tool in the Rest&Recover phase.

(Tool #6) Scenario creator: This tool helps to design the various test scenarios that would serve as the starting point. Note that these will be continuously revised as we explore and gain a deeper understand of the system and its context and usage. What is important would be segregate the scenarios into Levels so that the test scenarios are focused and clear in their objective. Robust Test Design approach of HBT helps you design scenarios that may be done using a mix of formal techniques, past experience, domain knowledge, context but clearly segregated into various HBT Quality Levels.

REST& RECOVER: In this phase, the objective is to analyse the exploration phase results and improve what we can do, track progress of doing and judge of the quality of the system-under-test. This is done by the tool ‘Dashboard’

(Tool #7) Dashboard: This tool helps you to do there things : (a) judge adequacy by look at the map and route information and improve the same (b) track progress of work done by checking the what has been done vs.planned as far as routes are concerned (c) judge quality by looking at the execution outputs of the scenarios level wise.

So how do we apply this tools?
We saw that these 7 tools could be used in the THREE phases of RECONNAISSANCE, SEARCH, REST&RECOVER by a session based approach “Immersive Session Testing”. Each session is suggested to be short and focused say 60-90 minutes with a session objective to one or a mix of the phases.

Note that a session could be an exclusive RECONNAISSANCE or SEARCH or REST&RECOVER on a combination of these. Why is the session time suggested to be 60-90 minutes? Well this is to ensure razor sharp focus on each on the activity done. Also a short focussed sessions allow one to get into a state of flow enabling higher productivity and enjoy the activity!

Click here to play the webinar video.

Click here to see the slides in SlideShare


About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

Surviving the QA disruption- Smart testing is the way

by T Ashok

Summary
The confluence of extreme speed of business, rapid new technology adoption, cloudification & platform-ising of apps, finicky end users has created serious inflexion points, threatening the  QA practice. How do we test smartly to survive & continue to grow? 


Smart testing is about doing less and accomplishing more, and  rapidly with razor sharp focus on business outcomes and end user experience.  It is about doing what it takes to ensure great end user experience all the way, ‘extreme ownership’ as my friend called it!  It is not just in the act of assessment/evaluation, it is across the entire of lifecycle of dev/test of smartly using the process, technology and tools.Technology, business, process models are evolving rapidly and disrupting the way we do things and testing too is disrupted.To survive and accomplish more in these interesting times, ‘Test smartly. Accomplish more’.

In a discussion with Sudhir Patnaik,  I asked him as what the key disruptors  to our discipline of testing are. His single phrase answer was “Extreme Ownership”. That it is, not just owning the act of validation, but the ownership of entire customer experience.And this he said, changes the team structure , the way we perform test, and the  skills required.

Watch the full video of my discussion with Sudhir Patnaik on the theme “The changing facet of our discipline/industry”.

https://youtu.be/nDcx_1PvUF0

The ownership mindset requires a two faced tester, one adept with technology and development on one side and the other to test well. Code when required, dig deeper to understand better, shift left tests, automate as much as possible and test intelligently. 

The confluence of extreme speed that business demands today, the rapid adoption of new technologies, the cloud-ification and platform-ising of applications and the  finicky end users have created serious inflexion points. It is threatening the test/QA practice, what do we do now?  The demands that we have on how we need to complement dev, expand our base of skills, deal with far more imprecise information and embrace technology to get work done implies a far greater reliance on our intellect. To survive this QA disruption, ‘Smart testing’ is very necessary. So, what we do ‘smartly’ across the lifecycle of dev/test?

Smart understanding
Being able to appreciate the intended customer experience implies a smarter approach to understanding the larger context, figuring out what is expected rather that ‘what is there’ to be validated. It is about figuring out how the sum total of various entities of a system contribute  to the wholesome  end user experience, beyond the typical piece meal validation of an entity. ‘Smart Understanding’ is an essential ingredient here. Understanding that is multidimensional, of business, end users, environment, context of usage, architecture and deployment, the technology stack and its nuances. 

Smart strategy/plan
How much do we test? How much do we test earlier (Shift Left)? How much can be done  statically using software tools on SmartChecklists? How much testing can be avoided? How and what do we need to do to maximally automate? How to set up a continuous health check? How much can we test under the hood? What are the ‘-ilities’ that we need to test? What is the impact of changes done? Coming up with answers to these at start and continuously refining them enables us to setup a continuous test flow that is rapid, optimal and effective.It is the sensitivity and refinement of what, how much, how early, how to test minimally, employing maximal automation. It is making appropriate choices to deliver a great customer experience continually, that demands ’Smart strategy and planning’, so that we may be continuous, responsive and effective. 

Smart Design and Execution
How do you ensure that you have “potent” test scenarios/cases? That is, test scenarios/cases that are powerful enough to explore all nooks and crannies of the software to uncover issues. It is not just optimising execution via automation but using intellect and technology to ensure the net is cast wide enough and this can be done quick enough. Never underestimate that all scenarios can be designed a-priori;  it is about being sensitive to the context and execution, and refine continuously. ‘Smart design’ is about being logical and use design techniques to model better, whilst at the same time be highly observant , curious and creative to come with really interesting and meaningful scenarios.

As much as good design matters, it only translates into great reality when its executed, statically or dynamically. Well as much as it sounds great to use this earlier via shift-left, it would be smarter to be sensitive and prevent. Static execution does make great sense and these  can be done using software tools or thinking tools expressed as a ‘Smart Checklist’.In the case of dynamic execution to evaluate software, we have various choices : (a) under the hood automation via API (b) Front based automation of short feature thread or long business flows (c) execution by an intelligent human. Making appropriate choices using available information at the earliest and refining would be ‘Smart execution’.

Smart Documentation
Why do we document? For posterity, for future support, right? Nah, that would be old school thinking! In today’s world, documentation is to enhance one’s understanding, with the side effect of making these understanding,  choices and actions available to others. Note that first reason is ‘improving one’s understanding’, to think better. So ‘Smart documentation’ is about being to-the-point (terse), staying uncluttered i.e crisp, visual as applicable with meaningful notes, and appropriate elaboration that is strictly on need basis. Given that testing today is done in short sessions, the act of documentation should never disrupt the flow of thinking, in fact it should catalyse smart thinking.

Smart Automation
Smartness is not only in doing the work oneself, it is smartly exploiting tools and technology to get this done. Automation is not limited to execution of tests to assess correctness, it is also about doing all other work in the larger context of assessment.

This could encompass test design, environment setup, data generation, problem analysis, runtime measurement, health checks, project management and deployment. In the context of assessment, ‘Smart automation’ can be (a) enabling self-test integrated into the code (b) health check suites that monitor health when change is done (c)under the hood automation using API  that is more resilient (d) front end based user oriented suites (e) building frameworks that can assist the dev folks earlier to test easier (f) scripts that be easily generated and modified rapidly i.e. ‘code-less automation’ especially for UI.

Smart Analysis
When we test, we may find issues or we may not. The key is, what we do with this information.How does this help in getting a clear picture where we are and how good the system is ?  How does this help make meaningful business decisions rapidly? How does this allow us to rapidly refine what we are doing?  It is about sifting thorough the rich testing dataset and just showing the minimal crisp information to enable rapid decision making. This is what ‘Smart analysis’ is about. Quickly dig in deep and extract nuggets.

Smart testing is the way 
Smart testing is about doing less and accomplishing more, and rapidly with razor sharp focus on business outcomes and end user experience.  It is about doing what it takes to ensure great end user experience all the way, ‘extreme ownership’ as my friend called it!  It is not just in the act of assessment/evaluation, it is across the entire of lifecycle of dev/test of smartly using the process, technology and tools.Technology, business, process models are evolving rapidly and disrupting the way we do things and testing too is disrupted.To survive and accomplish more in these interesting times, ‘Test smartly. Accomplish more’.

———————–

The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology.  Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

How to test rich UI – Smart Modelling

by T Ashok

In a consulting engagement with a product company, I noticed that the tester came up with a complicated decision table to represent the behaviour model. On closer examination I noticed that he had arrived at behavioural conditions by examining the complex UI visually, rather than digging deeper to understand the behaviour. This is not the first time I have seen this, I have observed the challenge with behaviour modelling many times in numerous companies.

So “why does a complex UI faze a tester?” It is possibly the inability to see beyond the UI, the inability to question beyond the obvious. The result –  too many test cases, and the overwhelming feeling that scientific modelling & design cannot be practiced due to time constraints. Well this is the fun part of testing ‘the intellectual one’, where one decomposes an entity through a process of rational analysis and utter curiosity by thinking better to test smarter.

So how does one smartly model the system with a rich UI? How does one go beyond the veneer of the what is visible and see the various behaviours offered by this rich UI and smartly design scenarios that comprehensively evaluate the system?

What is the problem that a rich UI poses to a tester? 
What I have observed is that a rich UI results in ‘spaghetti test cases” . This is illustrated in this video below (1m:48s).

Rich UI problem analysis
Let us now analyse a rich UI of a real software to understand the challenge posed. (2m:48s minute video)

Decompose clearly to enable good design
Now let us dig deeper into the problem by analysing the various elements to test in this rich UI so that we can decompose clearly to enable good design. (3m:30s)

So what is good design?
It is about high cohesion and low coupling, as we say in software design. Let us see how we can apply this in the context of testing for good test design. (4m:19s)

Application of design principles
So what we do we now? How do we apply the good design principles here? 

  1. Decompose ‘what-to-test’ into various of entries of different granularity : Fields, Features, Flow and Screen. 
  2. Use a simple checklist (which is a really standard set of scenarios) to test the smaller granularity entries – Fields and Screen 
  3. Model the behaviour of the higher granularity entity – Feature and Requirement maybe, using say a ‘Decision table’ and generate various test scenarios

This is outlined in the video below (2m:21s)

Summarising

  1. We have ‘decoupled’ the complex UI into  ‘cohesive’ entities – Field, Feature, Flow and Screen.
  2. We then applied a simple checklist to test Fields and Screen  and then applied behavior driven approach(say decision table) to design scenarios for each feature.
  3. To test a flow, we combined the various unique outputs of each feature to generate the flow test scenarios.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.

Exploit visual thinking – Smart exploration of software 

In today’s world of Agile development, where minimal documentation and rapid evolution of features rule, understanding what may be appropriate for end users, what may be intended behaviour and what is actually present, requires not only a logical mind but a very creative mind. A smart approach to understanding the various parts, connecting to the bigger picture, and identifying missing parts in a rapid manner is the order of the day.

It is interesting that in the current technology/tool rich world, we have realised that human mind is the most powerful after all, and engaging it fully can solve the most complicated problems rapidly.  One of the key ingredients of an engaged thinker is “Thinking visually”, to clearly see the problem, solution or gaps. 

Design Thinking relies on sketching/drawing skills to imagine better ideas, figure out things, explain and give instructions. Daniel Ling(1) in his book “Completing design thinking guide for successful professionals” outlines this as one of the five mindsets – “Believe you can draw”. 

Sunni Brown(2) in her book “The Doodle revolution” states “doodling is deep thinking in disguise – a simple, accessible and dynamite tool for innovating and solving the stickiest of problems“ by enabling a shift from habitual thinking pattern to cognitive breakthroughs. 

David Sibbet(3) a world leader in graphic facilitation and visual thinking for groups in his brilliant book “Visual Meetings” outlines three tools for effective meetings to transform group productivity : (a) ‘Draw’ to communicate visually (b) ‘Sticky notes’ to record little chunks of information and create storyboard (c) ‘Idea mapping’ which are visual metaphors embedded in graphic templates and worksheets to think visually. 

Dan Roam(4) in “Show and Tell” states that the three steps to create an extraordinary presentation are (a) Tell the truth (b) Tell it with a story and (c) Tell the story with pictures. The book ‘written’ beautifully in pictures entirely is about ‘how to understand audience, build a clear storyline, create effective visuals and channel your fear into fun’. 

Jake Knapp(5) in “Sprint – How to solve big problems and test new ideas in just five days” outlines a five-day process to problem solving relies on SKETCHING on Day 2. He says that “we are asking you to sketch because we are convinced it’s the faster and easiest way to transform abstract ideas into concrete solutions. Sketching allows every person to develop those concrete ideas while working alone”. 

Not to forget my very good old friend “mind mapping”, from Tony Buzan which I have extensively used to understand, document, come with up with ideas and the plan.

It is interesting to note that visual thinking has taken centre stage now with mind mapping, sketch noting and doodling as a means to unleashing the power of the mind. 

As software QA folks, going beyond the given documentation (detailed or otherwise) is very necessary. In the current times with documentation being terse, a logical approach to exploring and covering a lot of ground rapidly and taking notes that forms the basis for a great visual summary is very necessary.  Mind maps have been very useful here and we now have other tools like SketchNote and Doodling.

These visual tools are useful not just for capturing information to aid understanding but can applied to create plans, and design scenarios to validate better. These allow us to move from the structured templated documentation to a breezy and creative way that not only allows to expand our thinking but ensures that we are terse and focused and in a flow. 

As I explore the product and ideas start to flow, visual tools are what I resort to using both software tools and good old paper to ensure that I can capture this rapidly and ensure I stay in the flow.

I use mind mapping extensively to take notes as I explore a product to understand using the tool iThoughts on my iPad along with sketches and doodles in my notebook accentuated with colour pens and PostIt.

Templates that have typically served as the backbone for test documentation are like “horse blinders”, for they provide a sharp focus in a narrow field restricting purposefully the peripheral vision enabling strict compliance. On the contrary “Fish Eye Vision” allows for a 360 degree vision to be able to see all around. Visual thinking enables this “fish eye vision”.

“Software testing is a funny business where one has to be clairvoyant to see the unknown, to perceive what is missing and also assess comprehensively what is present ‘guaranteeing’ that nothing is amiss.”

As much as tools and technology helps us to perform tests far better,  “Smart understanding and documentation” based on visual thinking tools can be very useful in today’s rapid product development cycle.

Testing is scientific exploration and the first step to do this smartly this is
“Exploit visual thinking – Smart exploration of software”.


References
(1) Daniel Ling “Completing design thinking guide for successful professionals”, CreateSpace Independent Publishing Platform, 2015.
(2) Sunni Brown, “The Doodle Revolution: Unlock the Power to Think Differently“, Portfolio, 2014.
(3) David Sibbet, “Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity”, Wiley India Private Limited, 2012.
(4) Dan Roam, “Show and Tell – How everybody can make extraordinary presentations” Penguin, 2014.

(5) Jake Knapp, “Sprint – How to solve big problems and test new ideas in just five days”, Bantam Press, 2016.

Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.