- 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?
2 comments:
Do all your test cases require equal effort? Automating 40% of test cases by a count of test cases does not necessarily result in 40% of the effort being automated. Often parts of a test case still need to be performed manually.
... oh, we are dreaming. I should then take off my dream-killing tester hat and put on my dreamer hat.
I want to push a big red button to start unattended tests that will find all the bugs in the software under test. And while I'm dreaming, I want all possible tests to run in under a minute.
Maybe I should just dream for bug-free software and happy customers with deep pockets.
Then, there'd be no need to test.
... except ...
I can't resist testing this dream. If software was bug free and did not need to be tested, I might be out of a job. Maybe that's not such a good dream for us testers.
The truth is that no matter how "smart" we make the machines, there will still be a need for us testers. People are not perfect and I don't think we will ever be able to fully understand the complex systems that software allow us to create.
:P
Ben Simo
QuestioningSoftware.com
Well.. . Can I have a single realistic dream :).. Use automation to add value in the project, Do not use automation to do some complex things for the sake of it, do not do automation to impress client, do not do automation to make your resume look good and many more do not use...
In My Opinion, there should be only one simple goal for automation i.e Use automation wherever it adds value to the project, be it to assist you in data generation, at sanity level, performance level, system level.. etc. This value addition is subjective and will invite some discussions instead of goals based on some numbers or other criteria.
Post a Comment