For Programmers: Free Programming Magazines  


Home > Archive > Software Testing > May 2007 > How to Increase Productivity in Automation testing









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author How to Increase Productivity in Automation testing
abu bakar siddiq

2007-05-22, 8:13 am

Hi All,
I am working on QTP scripting, we are using Descriptive programming to
automate our application.
Each time we interact with client, he makes a point to increase
productivity. i.e. asks us to write scripts more in number everyday,
which we are not able to achieve.

I want suggestions, guide lines from you all in this regard.

Any resources online, documents regarding Automation Architecture,
Strategy,Methodologies,process model,optimization techniques and Plan
i will be very thank full to you.

Thanking you,

Siddiq

Vladimir Trushkin

2007-05-22, 8:13 am

On May 22, 6:51 am, abu bakar siddiq <sab...@gmail.com> wrote:
> Hi All,
> I am working on QTP scripting, we are using Descriptive programming to
> automate our application.
> Each time we interact with client, he makes a point to increase
> productivity. i.e. asks us to write scripts more in number everyday,
> which we are not able to achieve.
>
> I want suggestions, guide lines from you all in this regard.
>
> Any resources online, documents regarding Automation Architecture,
> Strategy,Methodologies,process model,optimization techniques and Plan
> i will be very thank full to you.
>


Good question. Thanks for asking. I've been there; done that.

First of all clarify let's your intention. You need either to satisfy
a customer not caring about the ROI of your automated test suit or you
care about ROI, and, having a good test suit would like to make a
customer happy. Depending on where you put your focus one of two
suggestions that I have will work.

Suggestion A: If you want to keep a customer happy first of all then
focus on designing simpler tests and automating the easiest ones.

Suggestion B: If you want to have a good and useful test suit with
high ROI then focus on prioritizing tests in the backlog and selecting
most important ones for automation.

There is a well known pitfall in the measurements -- what you measure
is what you get. If the only thing you measure is the number of
automated tests you get the number, most probably for the expense of
the quality of your suit.

So decide on what you need and chose your way.

Here are some best practices that I learned directly affect automation
productivity:

- having clear, challenging but realistic goals (keep informing the
team about the progress)
- no capture-playback (maintenance nightmare)
- organized, maintained, and reused code libraries
- early involvement of automation team in the development (to get
required helper function from developers)
- area specialization (one engineer keeps working on same area in
different releases)
- tools to help running tests and gathering test results
- clearly defined test states and the process of test result analysis
and automated reporting
- coding standards and code review
- cross-training (if one of team members learns something useful he or
she shares it to all)

All this helps people to be productive and focus on what they need to
do.

----
Best Wishes,
Vladimir

info@e-valid.com

2007-05-23, 7:17 pm

In many cases, the design of the test tool itself may create
intrinsic productivity barriers. Which is a strange statement
to make, considering that such tools are themselves supposed
to be amplify productivity, not diminish it.

Meaning in no way to derogate the product class you mentioned,
it may be useful to point out that one of the main design
goals of eValid was to make creating tests for web
applications as simple as possible -- to increase the
productivity of the tester.

At the same time, we recognized in designing eValid that test
playbacks must tolerate pages' "inconsequential changes"
without breaking. So we had to have a way to protect even
that low-cost investment.

In keeping with these goals, eValid was made with as simple a
GUI, as simple a scripting language, and as simple a recording
protocol as we could engineer. And, the built-in Adaptive
Playback feature lets tests PASS (with appropriate warnings)
even when there are inconsequential page changes.

eValid tests are quick and easy to create, are easy to
understand, and are quite durable. Testers spend less time
puzzling out how to create tests, and more time analyzing test
failures.

Why don't you give the eValid solution/architecture a chance?

You can download your evaluation copy of eValid V7 from:

http://www.e-Valid.com/Products/Dow...tml?status=FORM

Full details about the eValid web analysis and testing suite
can be found at:

http://www.e-Valid.com

On May 21, 8:51 pm, abu bakar siddiq <sab...@gmail.com> wrote:
> Hi All,
> I am working on QTP scripting, we are using Descriptive programming to
> automate our application.
> Each time we interact with client, he makes a point to increase
> productivity. i.e. asks us to write scripts more in number everyday,
> which we are not able to achieve.
>
> I want suggestions, guide lines from you all in this regard.
>
> Any resources online, documents regarding Automation Architecture,
> Strategy,Methodologies,process model,optimization techniques and Plan
> i will be very thank full to you.
>
> Thanking you,
>
> Siddiq



Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com