In our User Forum, Kobep wrote:
Do you ever take on "test suite development" work?
Our primary goal is to support the eValid product suite, but yes, on occasion we
do take on the job of building a test suite for a customer. But it's important
to note that we are not primarily a service organization and as a result of that
we do NOT send any script development work offshore.
A typical test suite that we would develop would the for a relatively stable product, for which there is reasonably stable documentation. Our goal would be to build up a suite of test -- a nominal count of 100 tests, arranged ideally in ten groups of ten tests. While we welcome the chance to make tests test powerful and effective -- and we generally succeed in this goal -- the main purpose of such a project is to help do a "technology transfer" to the customer.
We've found over and over that when a customer has a set of tests that are in the customer's context -- they run on the customer's machine and exercise a web application that is familiar to all of the staff involved on the customer side -- that the suite works very well as a mechanism for the customer to take over the suite for long-term maintenance. It seems that having both the context, a working sample, and ownership of the actual tests all serve to make it very easy for customer staff members to understand and maintain/modify/upgrade the tests.
In some cases, when there is some structural testing script modification that has to be done, then the examples in the nominal 100-case suite also serve as the basis for future modification.
The good news is that we like to do these projects on a very short term basis -- in some cases it's taken less than a week or two to flesh out tests for an application. And, yes, some of those tests take a LOT longer than most of them; there always seems to be a rough one in the bunch.
If you're interested in the details, give us a call.
eValid Support
A typical test suite that we would develop would the for a relatively stable product, for which there is reasonably stable documentation. Our goal would be to build up a suite of test -- a nominal count of 100 tests, arranged ideally in ten groups of ten tests. While we welcome the chance to make tests test powerful and effective -- and we generally succeed in this goal -- the main purpose of such a project is to help do a "technology transfer" to the customer.
We've found over and over that when a customer has a set of tests that are in the customer's context -- they run on the customer's machine and exercise a web application that is familiar to all of the staff involved on the customer side -- that the suite works very well as a mechanism for the customer to take over the suite for long-term maintenance. It seems that having both the context, a working sample, and ownership of the actual tests all serve to make it very easy for customer staff members to understand and maintain/modify/upgrade the tests.
In some cases, when there is some structural testing script modification that has to be done, then the examples in the nominal 100-case suite also serve as the basis for future modification.
The good news is that we like to do these projects on a very short term basis -- in some cases it's taken less than a week or two to flesh out tests for an application. And, yes, some of those tests take a LOT longer than most of them; there always seems to be a rough one in the bunch.
If you're interested in the details, give us a call.
eValid Support
1 comment:
Making Difference...|All kind of IT Solution
ideabdl.com,You can bayer, provider or contractor of outsource for software, we offering you come,see & make.
http://www.ideabdl.com/
Post a Comment