SmartQA Community

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.


digest #12 – “Delivering Clean Code #1”

SmartQA Digest

Welcome to SmartQA Digest on the theme of “Delivering Clean Code”. Raja Nagendra Kumar discusses what it takes to deliver clean code. The featured article “10 Simple Tips to Clean Code” is about simple practices to ensure that code developed is constantly cleansed. This is a two part series with the first one featured this week.

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#11 : “The changing face of testing”

SmartQA Digest

Welcome to the SmartQA Digest  on the theme of “The changing face of testing”.  Vivek Mathur outlines his thoughts on changes in testing due to the changing landscape of dev.The featured article “12 tips to reinvent yourself in testing” outlines tips for test practitioner to reinvent.

Yay, we crossed our first two-digit mark. Yes, this is the 11th!
I would be delighted to receive your comments. Thank you /Ashok.

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#10 : “Reinventing yourself ”

SmartQA Digest

Reinventing yourself“. In these rapidly changing times, reinvention is key to staying relevant. Anuj Magazine says reinvention has to be treated as a skill, with the ability to unlearn.The featured article “How do I grow in my QA career?” complements this.

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#9 – The changing face of development

SmartQA Digest

Welcome to a special edition of SmartQA Digest on the theme of “The changing face of development”. 

 
The way we develop software today has changed significantly. Vivek Mathur outlines his thoughts on this theme in this edition of SmartBites. The featured article “The changing face of development” outlines the key changes in terms of approach, technology, build-vs-integrate succinctly. Enjoy this edition of SmartBites!
software testing changes

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#8 – “Testing in the age of speed”

SmartQA Digest

Welcome to a special edition of SmartQA Digest on the theme of “Testing in the age of speed”. 

 
The pace of dev and release and therefore of test is very rapid. Agile/DevOps and Automation are the key enablers. Srinivasan Desikan in the SmartBites outlines his thoughts on this. The featured article takes a different look at how good QA habits can speed up an individual to do faster.

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#7 -“Creativity & Visual Thinking”

SmartQA Digest

Welcome to a special edition of SmartQA Digest on the theme “Creativity and Visual Thinking”.  

 
Want to be curious? 
Drop the linear thinking. Think visually.
 
Keen to innovate?
Then look outside your discipline!

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

#6 – An insight into big data/analytics applications and testing

SmartQA Digest

Welcome to the next edition of SmartQA Digest that features an interesting discussion with Dr. Arun Krishnan on “An insight into big data/analytics applications, and testing” as SmartBites video. 
 
Smart QA is about having great clarity, that occurs when you are actively questioning with an agile mind, not passively absorbing and getting weighed down. Lessen your burden and your mind is like a nimble goat climbing the mountain of complexity.

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

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.


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.