More on definition of Test Automation ...

While discussing about "definition" of "test automation", with Ben Simo I left a comment at Ben's blog post. I am sharing that here for the benefit of my blog readers ...

(You would also find some debate about "model based testing" in comments)

Test automation involves - Automation Design and Execution of automated tests ...

Design: An act of translation of some question that one asks regarding a feature of an software application into some programmable instructions so that the question being asked is modeled with reasonable accuracy (courtesy: Michael Bolton) In simple words translating a testing question into a program

Execution: Use of a machine (hence a set of computer programs) to support any aspect of Testing with Testing at the center of whole scheme of things.
(derived from the definitions by James Bach and Michael B)

As I continue to write about definitions and terminologies around test automation, let me reiterate - Nothing called "Automated Testing" exists in this world....

Shrini

Shrini

Simple things and me ...

World likes simplicity – Pictures, Colors, Sound, Odor are used to abstract some complex behaviors.

Consider following –
Software Project Status – Red, Green and Yellow
Project Size – Small, Big, Medium
Test cases – Simple, Medium, complex
Testing – Gather requirements, write test cases (some times even prepare them), execute them, check if the pass, if pass report and go home and if fail log a bug and go home

Automation – Create an automated script using the state of the art Automation tool. Store the script in test management tool and execute it from it. See the result logged automatically. If script fails (I mean reports failure), automatically make another script to log the bug

Knowledge Transfer – As simple as Fund transfer in bank. Transfer the relevant documents to the subject – transfer. If there are clarifications there always our best friend “issue list”, “action item tracker”, “clarification list” – many names but all is one.

Knowledge acquisition – As simple as one country invades and acquires another country. Just acquire – by force

What is common between each one of these – simplicity.

I become restless when

- People tell me about testing project status in terms of Red, green or yellow.
- People start approaching testing as sequence of actions – test design, execution, bug logging and regression
- People start describing a bunch of test cases or software features as Simple, medium and complex – SMC model.
- Testers getting classified as great, lousy based on the number of test cases executed or number (not the type) of bugs logged.

To me, all of these are simplifications of some complex things that we are trying to understand. My frustration is “Why things can be so simple”? “There must be something that is hidden behind this simple thing”

Imagine, if Newton were to think – when apple fell on his head – “No big deal – it had to fall so it fell down – Gosh – my head is aching. Why did sit bellow this tree?” Same thing applies to Archimedes. Jump out bath tub and run …?

While thinking about simplicity about some things that we deal with helps us to get started off – important to understand that it was just a beginning.

While testers and most of the managers are happy about such simplifications - a skilled tester is always worried about such simplifications and often attempts to find the loop wholes in simplified models, notions, beliefs, description etc…

Nature’s simplest things have hidden inside then greatest and deepest mysteries. That would a fascination journey – we just need vehicle capable moving into it – Our imagination and curiosity. Today’s skilled testers are blessed with this imagination and curiosity. The journey has just begun …

Do you think post has horribly and outrageously simplified the seriousness and intent behind the post? Well, I can not be too serious …

Automation Dreams - Thinking about END in the begining ...

"Cherish your visions and your dreams as they are the children of your soul; the blue prints of your ultimate accomplishments."

- Napolean Hill

Thinking about “end” in the mind helps me most of the cases such as planning, checking and carrying out various day –today tasks like performing 4-5 interconnected tasks, leaving home for a week/month long journey, arranging my daughter’s birthday etc. Thinking about “END” while you are about to begin or at the time of beginning a task - can help you to visualize the entire stretch of journey from start to end, anticipate various milestones, problems and as many as details as possible. This can prove to be a powerful mind modeling concept if you train yourself in visualizing from the END and work backward from there to the beginning.

Let us apply this to Test Automation …..
- How do you describe a successful automation?
- How can one describe steady state automation in deployment?
- Can you trace a journey from the beginning of an automation initiative and the end where your automation has become “obsolete” or has reached a steady state?
- Is there any END for Test Automation as a software project?

Automation initiatives have end goal(s) to achieve – cut testing cost by certain percentage, increase test coverage by certain percentage etc. In a way every automation project has some dreams to realize. Can we describe those dreams related to automation?

Let me give it a try ….

I will have an automation suite that runs “unattended” for up to 8 hours. (Length of Execution)
My automation suites covers 40% of my regression tests for product X. (Automation coverage)
I will have an automation suite whose results I can trust the most or When my Automated Test fails – I am sure that is bug (Reliability and Trust)
I have 40% of my test cases automated. Hence my testing effort now on will be 40% less (You can dream and these are DREAMS …. )
My smoke test suite is automated – I can now make changes to the code more frequently even when there is time crunch.
And so on ..

What are you Automation Dreams? Can you describe them?

Physicians, Surgeons, X Ray Lab Technicians ....

Heard of this rant?
“We would like our business users, domain experts and subject matter experts write automated scripts (tests?)”
“Our next generation automation tool – allows persons with ZERO programming and testing knowledge generate automation scripts in MINUTES”

Think about it …. Will you ask a Physician (Medical Doctors) or Surgeon to work as XRay or Ultra Sound Lab Technician and vice versa? Or An Aneathesian to perform a surgical operation?
Each one in professional life are known to have some core competencies. Best bet will be to utilize each one to their strengths….

Business users know business domain while Automation engineers and Tester know programming and software testing.

IMHO, asking business users to do “main stream” testing and automation is sure recipe for “failure”.

Any views? Do you think the analogy presented here is logical?

More as I hear from you ….

Shrini

Inattentional Blindness ...

Sajjad has an interesting article on "inattentional blindness" and Exploratory Testing here


Sajjd mentions that - "Exploratory testing is supposed to be better at minimizing inattentional blindness". This kicks off a thread of thinking in my mind - Why it might be so? what elements in ET helps one to minimize inattentional blindness?"

Let me take a guess and answer --
May be it is "thinking between alternating polarities" while doing ET - doing vs explaining, fast vs slow, reading vs doing, focussing vs defocussing. In my opinion inattentional blindness happens due to "heavy" focus on one or more "atomic" aspects of bigger object under observation. one possible solution is to defocus as often as you can.

A related phrase (a kind of antonym) I use is "your eyes will see what you would like to see". This is more dominant theme in scripted testing where a tester is "pre-programmed" observe only expected results.

Here is a wikipedia page http://en.wikipedia.org/wiki/Inattentional_blindness

Do not forget to read James Bach's comments for this post -

"Testing is a lot like fishing. You try to create conditions that maximize your chances for catching something tasty. Exploratory testing is a little more like fishing, because just as with real life fishermen ......"

Shrini

Presenting a tutorial @ QAI STC 2007

I am pleased to announce that I will be presenting two half tutorials as a part of QAI's Software Testing conference at Delhi and Bangalore. The dates are 29th Aug 2007 at Delhi and 31st Aug 2007 (Bangalore).

The details of the conference tutorials are as follows:

http://www.qaiasia.com/Conferences/STC_conference_2007/tutorials_kulkarni.htm
http://www.qaiasia.com/Conferences/STC_conference_2007/Tutorials.htm


This half day tutorial has been created out of my last few years of "on the floor" experience of managing automation projects - right from conception till UAT and deployment. I hope to improve the material and other stuff to a day long program ..

See if you can make it to this and share your thoughts ...

Sorry for last minute announcement .. :(

Shrini

A mystery called Automated Testing ...

"No device has been invented which can match the human eye for accuracy and precision in many tasks; nor the human ear. Even the admittedly handicapped human is able to identify and distinguish among far more scents than any automated device. Human pattern recognition, language recognition, and language production ability is well beyond anything currently envisioned by automation engineers."
- Answers.com

Hope you have heard many times the word “Automated Testing” (Some places I even have heard “automatic Testing”)

Have you ever thought – what does that mean? Let us dig little and try to figure out what each term in above phrase *might* mean?

We have two words in above phrase – “Automated” or “Automatic” and “Testing”. Let us explore possible meanings of these terms ….

(A) Automated – something that happens without any human intervention – something that is done by a machine-software program or by self.

Answers.com says -
"automated" (adj )
Definition: made or done by a machine
Antonyms: by hand, manual

Automation (ancient Greek: = self dictated),

The word testing has many meanings – I present two contrasting definitions

(B) Testing is an act of technical investigation performed on behalf of stakeholders in order to reveal quality related information – it is an act of questioning – An infinite search for problems – problems that can annoy/irritate/destroy/damage a stakeholder.

(C) Testing an act of executing a test case derived from a specification and verifies whether the test case passes or fails.

(D) It is an act of confirmation that software behaves in a way as prescribed by the underlying specification/design.

(E) Testing proves that the software works as desired.

Now think about constructing the meaning of the word “Automated Testing” and we have these definitions (A), (B), (C), (D), (E) …

Automated Testing = (A) + (B) - Possible? I believe No!!!
Computer/Program can not question, improvise, learn, adapt, think, emphasize

Automated Testing = (A) + (C) – Seems possible – but in a narrow way. Using another program (automation tool) one can execute an automated test … but that is only a part of whole story – what about Test design? Defect investigation? And host of other activities that fall under testing umbrella …

Automated Testing = (A) + (D)
Automated Testing = (A) + (E)

Both of above seem to be “Not possible” as checking or proving that software works the way intended or as per spec (writing in English – hence can be interpreted in infinite number of ways) using “automation” – solely – is not practically possible.

So … think twice before using the term “Automated Testing” – as nothing really EXISTS in this world of testing called as such …

Challenge me … think of ways where you can justify the use of “automated testing” – come up with definitions of “automation” and “testing” and link them !!!

BTW what do you think about "automated tests" ??

Shrini

A Blogger Bug

A bug in blogger Create Post --

The title field is "non editable" - hence this post and my previous posts are going without any title for the post ...

I am investigating this -- any clues?

Update 13th July : The title field becomes editable when (this is one the ways I figured out) I edit (quick edit from the blog ) the post with the blank title.

Shrini

Regression Testing and Insanity ....

"Insanity is doing the same thing, over and over again, but expecting different results"
Albert Einstein (attributed to Ben Franklin too)

Does this sound similar to what we do in the name of "regression testing”? In regression testing (more so in that regression testing whose test execution is automated - note I am not using the term "automated regression testing") , we believe that by doing repetitions of some things that we did previously - we can find new results.

Thanks to inherent complexity in software and involvement of humans in development, testing and usage of the same - this regression insanity appears to be *working*

This one of those Francis Bacon's idols - Idols of the Theater: Errors formed from dogma (institutionalized doctrine) and flawed demonstrations.

Read following to know more about Francis Bacon and how his idols are relevant in testing

Francis Bacon’s New Organon (James Bach)
Bacon and boundary testing (Mike Kelly)
The four Idols of Francis Bacon
The Four Idols of Sir Francis Bacon by Ben Chambers and Zeb Dahl.


More on this later...

Shrini

My acrobatics on the Boundaries ..

The boundary condition of the universe is that it has no boundary." The universe would be completely self-contained and not affected by anything outside itself. It would neither be created nor destroyed. It would just BE

Stephen W. Hawking - A BRIEF HISTORY OF TIME

Science is a differential equation. Religion is a boundary condition- Alan Turing

Boundaries are actually the main factor in space, just as the present, another boundary, is the main factor in time- Eduardo Chillida

Earth has its boundaries, but human stupidity is limitless – Gustave Flaubert

I would read above quote from French novelist of 18th century (Flaubert was regarded as the prime mover of the realist school of French literature and best known for his masterpiece) by replacing the word “Stupidity” with “intelligence” or “imaginative power”.

Mike Kelly has an interesting post related to boundary testing here

I blogged about this topic few months ago under the name BVE and I think it makes perfect sense to link these two posts and get a new perspective of boundary test design (part of domain testing)

Note following important points in Mike’s post (with my views/comments) ---

1. Understanding, Identifying and working with boundaries in software - is a Modeling problem. There can be multiple ways in which boundaries in a software system can be modeled.
2. Depending upon how *close* your model models the system behavior, your (boundary) testing can be incomplete or wrong to *that* extent. Since there can be boundaries out side your model – you will not notice them.
3. There can be (are) multiple boundaries - what you notice is limited by your model (ref. #1)
4. No boundary exists in isolation
5. All boundaries, those that are explicitly identified in model – hence are known to you and those laying outside your model, INTEREACT and ALTER/AFFECT system behavior in some *significant*. This introduces complexity in the model. In other words there exists some RELATIONSHIP between these boundaries.
6. Inputs in identifying (in fact for modeling) the boundaries come from various sources such as technical specifications, user expectations, requirement specifications, device/OS specifications. If you narrowly focus on any one source of information – you will miss modeling of others boundaries (outside the mode) hence you would miss bugs/system behaviors associated with them.
7. A weak boundary Analysis would start with boundary first without first having a thought /explicitly/ about my model.
8. A strong or useful boundary analysis would start with model and identifying boundaries resulting from all possible sources of information.

Don’t forget to check following ---

All models (those especially having predominant influence of domain testing) are APPEAR to be deterministic (algorithmic/mathematical representations - set, graph, state machines etc) but indeed are HEURISTIC models as act of modeling seem to follow (in most of the cases) a heuristic approach…


Shrini

Tester's Quiz: What is Equivalence Partitioning Technique?

Most of you have heard this term "Equivalence Partitioning Technique". It is one of the common techniques associated with black box test design techniques (under Domain Testing techniques). Today's Quiz on my blog is related to this...

Explain in 4-5 sentences or less about "Equivalence Partitioning Test design Technique" and provide an example that illustrates the technique (avoid examples like "login" screen)

Notes:
I would also appreciate lots of "context" specific questions like "Who is asking?", “Why 4-5 sentences” etc …

I will consolidate all comments and questions and make another post later....
I am also looking for "real life" experiences of applications of this technique....

Some background:
One motivation for me to present this to my blog readers is my own experiences of discussing in various job interviews (where I was the interviewer) and lots of informal discussions with people. In my experience, lots of testers (especially in India) seem to have a very narrow view of this technique. Most of them have admitted that "it is a theoretical technique - useful only in interviews... etc"

What would happen next?

I would like to de-mystify this stuff (with your views, questions and opinions) and present to you my version of EQ partitioning technique in a blog post....

Shrini

Skill Vs Technique ...

Mathew Heusser, wrote following lines for an article for Better software..

“…..instead of listing specific techniques, we might be better off listing skills …Once we have the skills, the techniques and terminology can help. After all, our community created test terminology as a servant …”

That is excellent point. In the industry like our where “terminologies and jargons” rule, focusing on skills would be greatly useful.

Skill - A skill is an ability, usually learned and acquired through training, to perform actions which achieve a desired outcome. It is more of a subjective attribute.

Example:

Writing
Speaking
Problem solving
Critical thinking and General system thinking
Modeling
Questioning
Creativity

Technique - A well-defined procedure used to accomplish a specific activity or task. More than one technique may be available for accomplishing a specific activity or task. Selection of the technique should be based on project approach, available tools, cost and time constraints etc.

Note that a skill denotes an “ability” where as Technique is a “procedure”. It becomes very easy for a technique to be lost in the jungle of jargons and terminologies – for skill it is less likely so …

Invest time in identifying and developing skills are important to your job …

Shrini

Tester's Tool kit ....

James Bach mentions about a tool kit - a small set of utility programs that every tester needs to have to help in his/her testing, here ...

Programs like perfmon, burp poxy, filemon, regmon etc can be really useful and check here for other windows platform utilities

So far I have been using ethereal as network monitoring tool ...

Here is an improved version from microsoft Netmon 3.0

Shrini

Michael Hunter Interviews me for DDJ ...

Michael Hunter aka Braidy Tester, interviewed me for DDJ. See the interview here

With this I have joined illustrious list of Whos who in software Testing arena...

Michael has interviewed following people earlier (few notable ones) ... When you have time, go through each of these interviews and figure out how each one of following thinkers and great visionaries in testing present their views and their world of Testing ...

Gerald M Weinberg
James Bach
Michael Bolton
Jon Bach
Brian Marick
James Whittaker

I interacted with Michael from my Microsoft days. My first ever blog (on msdn) mentions Michael as sole inspiration for me getting into blogging. I enjoy reading Michael's blog and I keeping checking it once in every 2-3 days to see if anything has come up new there...

Michael hunter represents a unique testing culture within Microsoft and it is good see him working with people in context driven testing community. That makes him more special as a context driven microsoftee ....

Thanks Michael for featuring me in your 5 questions interview series ... I hope that will inspire many more testers in India, especially, to embrace testing and grow this community

Shrini

Reliving TASO ...

Ben Simo and Sam Burgiss reminded me about "mother of all" paper on Test automation.

Yes, I am talking about James Bach's Test Automation Snake oil ... It is kind of bible for all Test automation professionals.

This is nearly a 10 years old article (original in Nov 1996 and a rewrite in June 1999) - I am surprised to see, like Nostradamus (a Famous a French apothecary), James, 1o years ago predicted and neatly articulated "wrong" ways of applying automation. The statements and observations made in the paper are mostly valid and applicable in Automation world even today.

I have started learning about Automation from this paper in a “real” way. Before I got into what I call it as "Holistic Approach to Automation" (for the lack of any better word) I did some automation here and there using some tools and later I realized how bad that was.

Today, I see so many young and upcoming testers falling into the trap and start learning Automation tools straight without knowing about Testing and how automation affects human testing. And there are tool vendors, training institutes and recruiters/head hunters – all just look for few words “automation" and names of some leading GUI automation tools - you got a job.

My advice to all who would like to pursue the career in Test automation...

1. Knowing tool is a very small part of you as automation Engineer.
2. Invest time in learning "Testing" especially human side of it and practice
3. Pick up a programming course - learn programming - C, C#, Java, VB, PERL can be good candidates.
4. Read anything by TASO by James and his other articles ... When I say read - don’t just go over them once and discard them ... Understand them deeply, discuss them, if you have question - share it with others in the community -- write to me I can help you with my views ...
Every time I read James' articles - I get new ideas, new thinking, new interpretations...

After doing all above - if you get time - use (I say use) an automation tool ...That is last thing that you require in the path to success in Test Automation...

You might also want to have a look at following noteworthy references related to Test automation...

Seven Steps to Automation success by Bret Pettichord
High Volume Test Automation Cem Kaner

James - you should seriously consider writing a sequel - TASO part II ...

Though you say Agile Automation is your TASO II, the plot appears to be not the same -- we are carving some more on the lines of TASO ....

Shrini

I will be presenting at STAR EAST ...

I am pleased to announce that I will be a track speaker for this year’s STAR EAST conference at Orlando, Florida May14-18. I am very excited to speak this biggest and most popular conference dedicated to software testing. I will be speaking on “10 classic Reasons why Test Automation projects fail” (Track T17- on May 17th) - one of my popular paper till date.

I also excited to get on stage for 2 other occasions other than my presentation –
Lightening talk for 5 minutes on “Traps in test estimations” - see the announcement regarding this by the moderator “Mathew Heusser”, here. It is really privilege to be in the line up for lightening talks that includes “who’s who” in “Software Testing” world – James Bach, Scott Barber, Michael Bolton, Mathew Heusser …

I will be chairing the session for “Test outsourcing track– Track F8” helping the speakers with introduction and time keeping.

This conference being my first STAR EAST conference (first ever) will also is a special one as I will be meeting some special people whose work has greatly inspired me …
I hope to see and chat with people like Cem Kaner, Jon Bach, and Ben Simo and off course James Bach , Michael Bolton and Scott Barber…

Drop a line to me if you are interested to meet me and discuss the common passion - software testing…

See you there …

Shrini

Story around a bug ....

I found this interesting, lucid and narrative story related to a software bug (or bugs) here. Something on the lines of Story of testcase that I wrote sometime back.

Happy bugging ...

On a different note, do check out Jonathan Kohl's post on "Getting started with Exploratory Testing Part 1" here

Shrini

Ten Software Testing Myths ...

I was reading Lidor Wyssocky’s blog and his post on 10 software development myths. I thought, let me re-do this list for software testing – replace words “development” by “testing” and other relevant words. Here is the list … Bingo … we, the software testers *nearly* share the list of myths (frustrations?) …

It is interesting to note that last 5 myths go unchanged … development and testing share the honor. I even doubt that Lidor might be a software tester or a developer having a strong tester like mind.

10. The tester’s task is easy: he should merely write and execute the test cases by translating requirements to test cases. Additionally log some bugs.

9. Every test case is documented. Otherwise, how on earth can we expect to do regression testing and in general repeat testing?

8. Test case Reviews are a one-time effort. All you have to do is take an artifact after it is completed, and verify that it is correct. Test case reviews, for example, should merely verify that *all* requirements are covered by test cases and EVERY REQUIREMENT is COVERED by AT LEAST ONE TEST CASE.

7. Software Testing should be like manufacturing. Each of us is a robot in an assembly line. Given a certain input, we should be able to come up automatically with the right output. Execute a set of test cases (should execute 100 test cases a day) and report pass/fail status.

6. Software Testing has nothing to do with creativity. Creativity – what? The only part which requires creativity is designing your assembly line of test case design. From that point on, everyone should just be obedient.

5. Creativity and discipline cannot live together. Creativity equals chaos. [This one remains unchanged from original list of software development myths]

4. The answer to every challenge we face in the software industry lies in defining a process. That process defines the assembly line without which we are doomed to work in a constant state of chaos. [BIG ONE …This one remains unchanged from original list of software development myths]

3. Processes have nothing to do with people. You are merely defining inputs and outputs for different parts of your machine.

2. If a process is not 100% repeatable, it is not a process. Letting people adapt the process and do “whatever they want” is just going back to chaos again.

1. Quality is all about serving the customer. Whatever the customer wants, he should get. Things that don’t concern your customer should not be of interest to you.

Like Lidor, can say "As I said, I guess we still have a long way to go…" ?

Shrini

this app can break ... Notepad Bug challenge ...

Jon Bach is another brilliant thinker, speaker and coach in the area of software testing. Along with his "illustrious" and "one and only" James Bach - Jon has been doing some pioneering work in the area of exploratory testing and human aspect of testing.

While I was reading Jon's interview by another famous "Michael", the braidy tester - Micheal Hunter , I bumped into this interesting bugs that Jon mentions. This happens to be Jon's one of the most interesting bugs.

In words of Jon "Run notepad.exe and type "this app can break". Save it as test.txt, close it, then open it again. You might see that it now shows all rectangles, as if the font couldn’t be loaded."

There are other mentions of this bug here ( "Bush hid the facts")

I bet as you read this, you will be trying see if bug appears --- Bingo ... what an interesting bug ...

I did some very initial investigations around "nailing down" the bug - I posting them as they are -- I can not wait until I completely nail down the bug. It is too tempting for me to blog about it....

Successful cases
===================

this pap can break
this app can creak
this app nan break
thin app can break
shin app can break
shis app can break

this app can breal

aaaa aaa aaa aaaaa
bbbb bbb bbb bbbbb
aaaa bbb ccc ddddd

1111 111 111 11111 (interesting)


Unsuccessful ones
=====================

1a11 2b2 3c3 4ddd4
1aaa 2bb 3cc 4dddd
this cap can break (interesting)
THIS APP CAN BREAK (interesting too)

Few other observations
======================

Does not happen second time in a same file
Does not happen if a file with garbage appears once and create a copy of the same and open and check.

Investigation continues …..

What are your takes?

Finally, when you give up and do not find any more ideas as what is happening -- See here , here (good ones) and here... there are some interesting discussions and paths of investigation …. But don’t read (cheat) until you give your best try … I would say using Google would also amount to cheating …

BTW -- have seen following testing challenges put up in blog world in recent days?

1. Elisabeth Hendrickson’s Triangle challenge
2. Mathew Heusser’s challenge


Shrini

Ways to make Test Automation difficult ...

One of the interesting combos in Test automation is “Test design and Extent of achievable Automation”. I have seen in several automation projects that I worked, involving commercial automation tools that test design is the single most important aspect that decides the extent of automation one can achieve in a automation initiative. Techincal feasibility which is decided by the tool or tool set is another important parameter that affects the reach of automation

The context here is that test cases are developed first with the intent of manual execution and later picked up for automation. This is a very common scenario that is prevalent today.

Let us consider two following situations or examples that indicate two distinct and extreme styles of test design

Design 1: “Understanding tests require domain knowledge” - Tests are designed and documented in a style that suitable for someone who is expert and has a familiarity with the application. Abbreviations and shortcuts etc are used very commonly. For a tester who does not have previous experience (they call it as domain knowledge), the tests does not make any sense and look like incomplete. Objective here is to write tests in quick time so that only a select few can understand. An analogy would be a prescription written by a doctor that only a pharmacist can read and understand (this is a regular practice for the Doctors in India). Test design of packaged software apps, ERP applications is seen to follow this approach


Design 2: “Even college students should be able to execute the tests” – This is other extreme of test design where, the tests are detailed to a greatest detail possible so that each documented test is complete unit. Some of these tests even start from “Start windows ….” The intent of test design is to reduce the time required for a new person to understand and execute the tests. The drivers for such a test design/documentation style are high resource turn over and high cost of testing resources. IT organizations with very small or no testing teams on their own seem to follow this approach of test design.

Now, which test design style would be suitable for “Automation”? Which test design style lends itself for automation?

I would say none. In my opinion, both of these test design styles are excellent examples or ways of making the automation “difficult”

Important questions in this case would be “What is testing mission” and “what are objectives of Automation”. Unfortunately, the proponents of both of these styles of test design tend to down play the importance of these questions.

An excellent example of “context free thinking” …

Quoting James Bach --- “What makes something not context-driven is partly that the methods applied don't solve the problems at hand. This is the most common situation I encounter with large projects: somebody thinks that documentation is important, but they don't think much about whether the documentation they produce is really helping the situation, or rather hurting it.”

-- Shrini