The test team here at PleaseTech are at full speed ahead. This is currently one of my more exciting times as a tester as the next release of PleaseReview, our collaborative review solution, looms on the horizon and a host of new functionality and enhancements start to roll in. Getting to strip down a specification for new functionality where new ideas and possibly new technology are being implemented, analysing and identifying areas of risk, prioritising risk and ultimately identifying test case criteria are what gets the blood of a tester flowing - what other job pays you to break things!?
At the beginning of every release cycle for PleaseReview I sit down and look at what is coming, and establish a plan of attack – and then the murmur of automation creeps into my mind. Automation is on the mind of every test team I have been a part of, whether it was only a consideration or was being actively worked on. As a relatively juvenile profession, the core of a test team’s work is on a predominately manual basis. Automation is the evolution of testing.
When you sit down and think about it, automation initially appears a no brainer. The brilliant thing about automation is the flexibility it provides, for example:
- It can be added to the overnight build script which then provides you with a log of results, which are waiting for you on your arrival in the morning and highlight any potential issues
It can be used to lighten the load of regression testing allowing manual focus to be intensified on high risk areas;
It can even (subject to software and configuration) identify areas of code change and call on previous automation test cases that ran over that specific area of code, giving you a heads up on potential issues before you have even had the chance to look at the work item.
However, automation is not answer to everything… Certain software and testing activities lend themselves to automation but many don’t, especially in the area of document review.
For example, it’s one thing to automatically test the completion and submissions of an HTML form, it’s another to select some text in a document and edit it to create a proposed change. If you think about it, the test is going to work for that precise document and that precise edit. However, we can’t control what documents clients put into PleaseReview, which bits they edit and what they put in that edit. In reality, edits are frequently copied and pasted from other documents. In fact, the Word documents are frequently large, complex documents which make full use of Word’s cross referencing, field codes, styles, and so on.
So, whilst there are areas of the testing we can automate some areas will have to continue to be manual.
There is also the fact that the initial implementation of an automated suite of tests is incredibly labour intensive, as is the maintenance. Before you even get to the stage of writing test cases you must establish which software fits best and what technology you are going to use. Once that has been decided on you can get to grips with creating an automation suite.
Creating an automation suite is, in itself, a software project. It needs to be designed, developed and tested, and that’s a challenge I’m up for.
Ultimately the quality of a released product lies with me. So automation is a must have in my point of view. We pride ourselves in the quality of our product, and to maintain the high standards that we have set ourselves, I plan to have automation up and running in the near future. The initial analysis of automation implementation suggests that it’s not going to be easy, but who likes easy?
Watch this space and I’ll let you know how I get on.