A Test Design being guided by the Test Strategy

In this post, this image looks to have too much structures around it.  But, it is not. It is very simple one as I see it.  It is simple when I happen to understand the Test Strategy and what is the help out of it.  Having said this, why is that simple, because, it is from the fundamentals and nothing else.

If I understand, Test Strategy is set of ideas which directs my test ideas and test execution, then the test strategy has influence on Test Design.  Where the test design consists of these elements necessarily within it and it is as below.

1. Test Model
2. Knowing the Oracle
3. Knowing what is my Test Coverage
4. How do I operate my tests and execution of it.

The below picture says the same in the equating form.

The same applies when I have to figure out how to approach the automation for assisting my testing. I use this and when it requires a change in the context, I will do it accordingly and try to get most out of it.

Update (on 23rd Aug 2016):  I unlearn and learn the equation represented as this is more meaningful:

Test Strategy = { Ideas <--> Test Design + Test Execution}

As the test design and test execution in turn helps the ideas to evolve better as the testing progresses.

Inside Out of Test Design: Test Technique Identification with help of Test Model and Strategy -- Part 2

From the overlapping, I move ahead to learn how the test, technique and design is part of each other, I see, the three more now by adding to conversation.  It is -- Coverage, Action, Information (Potential Problem), and Assessment. This looks to be me as in the below image. 

Figure: Test Design and Identification of Test Technique

I understand this for Test Model -- a representation by which I'm learning the product either associatively or relatively or by both means. Further, I can still refine the model to specific learning i.e. to assist in obtaining the specific type of information from my testing.

Moving ahead, I will learn what information is expected from my testing. Knowing this, I will have to build a Test Model or use a existing one, to understand the product and my tests which I will be executing. The Test Model will help me to learn critical factors associated to product, environment, project and related components.

Now, I will have to choose the test techniques or build one. This has to assist me in building and strengthening tests by involving the heuristic within it also by identifying the heuristic from Test Model and tests.  This heuristic will help me to understand the outcome of test.

When I have figured out (or as I figuring out) the Test Model, Test Technique, and Heuristic for the test, I will have know what is the Test Coverage to be accomplished in context of testing.  This gives the dimensions and influencing description to say why is this my Test Strategy, and why I have made use of this model, technique, and heuristic to arrive at this coverage. As I execute my test and the way in which I record it, this overall constitutes the part of my Test Design.

Looking at the techniques, I have known there classification from the Software Testing books as Black Box, White Box and Grey Box. I'm learning there is much more within each of these types than the books say.

To summarize my so far learning, I see, the Test Techniques is one of the outcome of Test Strategy. The test strategy directs me to pick or build a Test Model. With the help of Test Model(s), I will execute the test by learning how I have to execute it and to what extent using the technique(s) (which is also a heuristic).

Inside Out of Test Design: When each disguises each other - Test, Design, and Techniques -- Part 1

I have been and continuing to be mesmerized about the Design Patterns in programming space. While I'm continuing to look at the Design Pattern, I ask myself is there anything similar in the 'software testing' space? If software programming and software testing are subset of a super set, the engineering, then design pattern and test design are to each other. That is, the both exist to support each other well enough in the context. Isn't it?  This is the question among lot other which runs in me when I think about Test Design.

Further, I go into my thoughts (of today) for letting know myself what I understand for 'test', 'design' and 'techniques', I hear below from me.

• test -- An experiment which is an open ended and whose outcome is unknown.
• design --  The set of ideas which says how to (I) use it or how to go about; and how I see it further to use it by learning. How simple it is to use for me, those are the attributes of design with the learnability in context being prominent.  In other ways, it comprises of pattern as soon as I say, 'design'.  Each design has a pattern isn't it?
• technique --  applying; i.e. a skill being applied to study, observe and evaluate a subject of interest further.

While I'm learning this, do I see a familiarity or the familiarities in these three above said?  May be this familiarity or these familiarities, it disguises each other while they are distinct and co-exist mutually in practicality of Software Testing practice.

Why one cannot see the differences or draw the differences between these other is, a simple fact. Yes, the fact, which is not studied quite often; hence it is a fact.  The unquestioned fact is, all three of these are heuristics - which helps in discovering, learning and solving, while it can fail as well.

A test does not help one to learn, discover and solve? But how a test can fail? Test never fails, it provides the information and I tag the label of true positive or false positive to the outcome of it. Likewise, is the design and technique, it helps in discovering, learning and solving; and as well it can fail too. But how do I see the 'fail' in case of design and technique is -- it did not meet the purpose or serve the purpose. Because out of the design and technique, I expect the discrete value which is of usabale, reusable and valuable. Whereas for a test, I see the information is an outcome from the execution of it (or out of not execution as well; not testing is as well a useful test in a context).  This is where the disguising appears by each others to each other.

Do I want "the bug" or "the testing" ?

When a fellow tester or colleague or stakeholder ask, "Let us find the bugs by testing" and "Let us learn the problems and risks by testing", I think the below.

Why testing is often seen or taken granted just to see the bugs out there or the risks residing within, if at all? Do programming is to introduce the bugs and fix them, all in all?  Then why testing and testers are seen as behind the bug always or put around the bugs?

I see this attitude (mindset) and expression of looking and practicing the Software Testing, yielding to experience just the one small part of a petal of the craft. While there are other petals and benefits of the craft, it goes unused and unexplored.  Unlocking from this expression and attitude becomes so complicated, it looks inseparable from the above said thought. The reality is, it is distinct and separate; but, taken as one.

While programming is to solve the problem, isn't the testing is to learn the problem if any in hand. Before this, I ask myself, why there should be a problem always to solve? I see this notion i.e. seeing a problem in first hand, makes the mindset just to focus on the problems rather than placing the problem as one part of the study. That means, problems get associated with everything, then! Why so? We look for it placing the importance for it? Does that importance is studied well to make it important to emerge as a whole than being a part?

To recollect the definition what I remember from Dr. Cem Kaner is, Software Testing is an empirical technical investigation activity conducted to provide (learn) quality related information of product to the stakeholder so that they make informed decision.

Here he does not say about the 'bug' or 'problem' or 'risk' or 'defect'. I see this is so close to daily work I do in my practice.  After this I get the question for myself, "He says, 'information' about quality criteria. Is there anything that is 'not a quality criteria' and still the tester provide the information from her or his testing about that too?"

Leading from here, my thought spans to a branch. This branch gives the thought of the word 'value'. In programming, declaring a variable and assigning it a value is simple? And this assignment takes it's types and namespace in the defined environment.  If this is simple to declare and assign a value, why this value of a product tend to become so complicated when it is tried to in terms of a software product to use?

Now should I learn the value of each and every aspect that is getting collected, then written as part programming and coming out as a usable commodity and the outcome of using it?  Is that value here is -- a bug or problem or risk, I learn from my testing?

Later this points me to line -- "A bug is that which threatens the value of a product". If this is so evident, then, why I hear or asked to look for bugs alone around the product? And, not to learn the value and what is that trying to diminish it in the context?

This further makes me to ask myself, fundamentally, are there anything else in the existence, which is non-bug that can threaten the value of a product and annoy the user? Something as this, programming is just to write buggy code? If so, testing is to look and anticipate just the bugs?

Unfortunately this has crawled so deep in the industry, we want bugs but not the testing. We ask the bugs and not the testing. The impact of this is recursive and passes on to the generation of testers as it is come to my time as well. It makes me to look for bugs (information) i.e. one of the outcome from testing while ignoring and tending to being away from the testing. 

I'm not saying to unroot this or to do anything that helps. But, is it possible to give a thought from the practicing tester before asking anyone to give the thought about this. I want to give my thought about this each time I test to learn what I'm doing and practicing.

That's the common thing to happen! What is next?

The words "hang' and "crash" looks so attention grabbing!  I see these words grabs attention today as well but it does not retain the attention for longer time unless the someone is behind the programmer and tester for it seriously.

Gradually, I'm learning, the crash and hang are something very usual in software applications or hardware products.  Crash and hang are not cruel but it is an indicator of what is being missed to see. Like fever in human body is not a threat; but, it is an outcome of something that is not good in body and an indication.

I have to admit this honestly. I was so thrilled some years back when I happen to see the hang and crash. I use to say it hanged and people use to run for lab.  Unfortunately I was not in a state of mind to tell "that is okay, but what we have to looks is what made it hang or crash".   The hang or crash behavior is an outcome of an actual problem which was never learned by me, then. 

While I happened to practice the test investigation, I learn, hang is a symptom. I fetching as much as information from symptom to unlock the problem node, is the essential part of what I'm practicing now.

Today when fellow practicing testers come saying, "it got crashed", "it is hanged and unable to proceed" and as this, I say "It is a common thing to happen in software products.  Than writing this as a bug, go figure out what is making the product to fall into this state.  If you are not aware to learn that from test investigation, let us pair up and learn it."

Most times or all most every time, the symptom is reported as bug while the problem source is unattended by the engineering teams. Fixing symptom is easier so that symptom is not visible again. But the problem resides and it shows up something else as symptom and one more bug if identified this symptom.

Symptoms are trace backs to the problem source. Not stopping here is a good little small step for being better in test investigation skills.