Q: In this digital age, what do you believe is the role of human intellect in QA? Raja’s view: The products meaning is not that selling it to one or two clients. It will have millions of clients coming in the QA role has become 10x, the way I want to classify is now QA has to start behaving as a first client themselves So they have just to not get into the requirement, but they have to always be wearing the hat of a customer in the digital age which could be hundreds of verities of customers. That is one thing they have to really start acting on. So no more just say I’ve compiled to SRS. Second is cloud has given them too many configuration approaches. How do you deploy? How do you scale? How do you perform? so one in the software scale and other is coming from Hardware. Now all these configurations are not easy to be done even by QA if they want to do it manually, they have to become coders. So basically the DevOps and QA. Previously they were actually no human. Yes. I think that’s where you said no brain required, but now they have to start their intellect so well that they are able to handle so many verities of deployment, so many customers intent they’re able to bring it to the developers that’s one and then if they have any problem in testing it they have to communicate to development saying that, this is a requirement. I am not able to test. Make sure that the developer addresses it because that is a good input for a great developer. If it is not testable if it is not maintainable which means it is not verifiable, which is not a good way to say I have done as a developer. Lot of information in Enterprise is coming from various sources, one is the QA one is the support other is production. All they are supposed to do is the first level of filtering why they were not able to capture that and then give it in a way where developers are able to consume it faster if they can really do that well, they are fulfilling not just a QA job, they are representing thousands of varieties of customers thousands of configurations in the cloud. All that complexity they are able to bring in lot of intellect and then making. They’re not totally depending on the developer or they have to become developers at a next level. So they have to know to code to some extent or if they know in a larger extent it is good, but they are not small things which can be just said, if you train somebody and then they will be accurate.

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.

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.

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.

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!

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”.

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.

(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.

(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.  

(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.

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.

[grwebform url=”https://app.getresponse.com/view_webform_v2.js?u=hzsfs&webforms_id=BxdSM” css=”on/off” center=”on/off” center_margin=”200″/]

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”.

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.