A quick note to make sure I do not loose a little idea I got while browsing recent presentation a STARWEST. The specific presentation I have in mind is here:
http://www.stickyminds.com/interview/five-patterns-test-automation-starwest-2015-interview-matt-griscom?page=0%2C0
Matt Griscom links you to his website and a download for the .NET Framework based tool he created. I believe it warrants a try, because although it glosses over some problem-domain specific areas for me, it seems to take account of a lot of the automation framework gotchas I currently face.
His blog is http://metaautomation.blogspot.co.uk/ and the download is hosted here http://metaautomation.net/ .
Basically I face a problem where my current automation system is not flexible and powerful enough, so requires fragile customization. Stable over the short term, your test code breaks every time the framework revision changes. Which has to happen as you integrate common or shared test-code down into a pattern in the toolstack or into a shared library. All this work needs to be designed and to be planned to reduce maintenance load. Matt seems to recognize many of the related problems I face there, although maybe not solving them, the act of identifying them helps us a lot. Basically he takes the approach "measure everything". Make it easy to mine all data and suddenly you can do comparative and performance testing as well as predictive triage.
So, just a quick note before I forget all about this angle.
http://www.stickyminds.com/interview/five-patterns-test-automation-starwest-2015-interview-matt-griscom?page=0%2C0
Matt Griscom links you to his website and a download for the .NET Framework based tool he created. I believe it warrants a try, because although it glosses over some problem-domain specific areas for me, it seems to take account of a lot of the automation framework gotchas I currently face.
His blog is http://metaautomation.blogspot.co.uk/ and the download is hosted here http://metaautomation.net/ .
Basically I face a problem where my current automation system is not flexible and powerful enough, so requires fragile customization. Stable over the short term, your test code breaks every time the framework revision changes. Which has to happen as you integrate common or shared test-code down into a pattern in the toolstack or into a shared library. All this work needs to be designed and to be planned to reduce maintenance load. Matt seems to recognize many of the related problems I face there, although maybe not solving them, the act of identifying them helps us a lot. Basically he takes the approach "measure everything". Make it easy to mine all data and suddenly you can do comparative and performance testing as well as predictive triage.
So, just a quick note before I forget all about this angle.
Comments
Post a Comment