mgroen2 wrote:
One extra thing I'd like to mention: enhance your automated regression test suite to a data driven test suite. Keep the test data in external sources (Excel, SQL). Why? In this way you can execute regression testing with unique and manageable testdata, and easily extend your framework with new testdata. The big win here is that when focusing on your test data on a frequent basis, keeps you focused and feeds your creativity to come up with "odd test data".
This.
Exactly this.
It's how mine is built. The code is pretty much entirely test agnostic. It is just a series of functions. There would be no tests without the input data. Which is on Excel sheets. Which anyone can populate. Flexibility is key in my opinion. (Along with un-crash-ability...)
We use "agile", although where I work, up to now that's been an excuse not to document anything. We're getting better at it now. But test automation is almost exclusively for regression testing. As most will know, it takes longer to do the initial prep and build of an automated test than it does a manual one (although not so much once you have a good keyword and data driven framework in place). So we tend to manual test new functionality, and then translate the suitable parts into automated tests which get added to the ever growing automated regression pack.
Colin_McCrae wrote:
mgroen2 wrote:
One extra thing I'd like to mention: enhance your automated regression test suite to a data driven test suite. Keep the test data in external sources (Excel, SQL). Why? In this way you can execute regression testing with unique and manageable testdata, and easily extend your framework with new testdata. The big win here is that when focusing on your test data on a frequent basis, keeps you focused and feeds your creativity to come up with "odd test data".
This.
Exactly this.
It's how mine is built. The code is pretty much entirely test agnostic. It is just a series of functions. There would be no tests without the input data. Which is on Excel sheets. Which anyone can populate. Flexibility is key in my opinion. (Along with un-crash-ability...)
We use "agile", although where I work, up to now that's been an excuse not to document anything. We're getting better at it now. But test automation is almost exclusively for regression testing. As most will know, it takes longer to do the initial prep and build of an automated test than it does a manual one (although not so much once you have a good keyword and data driven framework in place). So we tend to manual test new functionality, and then translate the suitable parts into automated tests which get added to the ever growing automated regression pack.
With regards to implementing test automation, that's a very good approach to take.
