The world is becoming more and more Agile and many companies are discovering the undeniable truth that Agile software development provides a cost effective solution for delivering working software. Adopting Agile processes within your company and changing the general ethos of your working environment can be harder than it might first appear. Sure, the introduction of daily stand ups, user stories, story points, planning sessions and retrospectives all help to improve the efficiency and communication within your company but there is one important part to the process that gets left out because it is deemed "too hard" to start doing immediately - and that is Automation.
Automation is a fundamental piece to the Agile development puzzle that often gets overlooked and it is only when a development team is struggling to cover all of it's regression tests and bugs are starting to be found by customers that companies generally look to do anything about it. Without automation, every piece of software that gets written, tested and shipped to the customer becomes another piece of technical debt that must be manually tested in order to ensure that any future work does not impact the original expected behaviour of that software. Most software development teams try to negate this by hand picking "just enough" regression tests to cover what they believe should have been impacted by any changes within the current release and generally this works well enough until something "just gets missed".
Numerous studies have been made into the cost effectiveness of finding a bug as early as possible and it should be no different for finding regression bugs, but without increasing your test team exponentially as your technical debt grows it is inevitable that you will have to face the fact that you will need to automate your software testing, the question then becomes how?
Getting started with test automation?
I believe a good place to start is to look at what your current testing practices look like in the Automation triangle. There have been a number of authors (including but not limited to Cohn, Mezaro and Crispin) that have written about the concept of an automation triangle and this something that I wholly believe in. The image below shows some of the subtle variations of the automation triangle amongst authors and I recommend that you do some further reading around.
The base of the triangle represents your unit testing level and this should contain the vast majority of your tests. The second level are tests that check the service or api layer, this is where I believe you can obtain the most "bang for your buck" in testing and yet it seems to be the area where most test teams are lacking. The third level of the automation triangle is UI automation tests and finally at the fourth level there is still some need for exploratory manual testing but the critical point here is that if an issue is found whilst manually testing the system then this should be captured as an automation test as soon as possible in order to minimise the technical debt.
In my experience, most software development teams already do a lot of unit testing which is ideal for working in small units and testing elements in isolation but when it comes to automation of acceptance tests they are somewhat lacking. When the discussion of automation of acceptance tests begins it almost certainly starts by looking at automating the user interface (UI) of the product, after all this is what the customer sees, right? Unfortunately there is an implied cost to implementing UI automation tests that means they are generally the most brittle, the most costly to write and they take the longest time to run. That is not to say that there is no place for automation of the UI, quite the contrary in fact there is immense value in performing UI tests but these must be carefully chosen to ensure you are getting the most value in the least brittle way and the least time possible.
As companies start to implement automation tests the trend to gravitate towards implementing UI automation tests ends up making the automation triangle look a bit more like an hour glass shaped automation rhomboid with few if any service/api level tests. I believe the reason for this is that UI testing does not generally require a technical understanding of how the application works underneath. Tests can be written (using a huge variety of different types of tool) from the view of a system user and as such only tests things that the user can see through the UI of the system. This generally results in all test setup, execution and assertions to be performed via the UI which all takes time (too much time in most cases).
Typically the UI tests will be created using a point and click style of UI testing tool that allows the test team to learn and embrace a tool that they can own and take control of that will free themselves from some of the manual day to day grind of regression testing without the need for the developer team's involvement. Unfortunately choosing UI automation test tool is not enough to ensure the successful implementation of an automation test strategy.
How can I implement a successful automation strategy?
In my opinion, communication and collaboration is one of the most important aspects of Agile software development. Any tools that a development team chooses should first and foremost help to radiate knowledge and increase the overall ability of the team to interact and adapt to their ever changing environment in the quickest way possible. What I mean by this is that the process of determining what automation is necessary should be an integral part of the development teams process from the very start of the project and each subsequent iteration instead of something that the test team goes off and just gets done.
Summary
I thoroughly believe that in order to get the most bang for your buck from your test automation strategy you need to implement of a process that helps improve the communication and collaboration within your team so that testers are working closely with developers at all levels of the automation triangle, the goal of this process is to make your developers better testers and your testers better developers. After all each member of an Agile team should be cross functional – it may well be that your testers are your worst developers and your developers are your worst testers but the key thing to strive for is that they work together in order to deliver a better quality product.
Next Steps
Why not have a think about different ways that you could try and improve the way in which your development team members (Product Owner, Developers and Testers) collaborate and in my next post I’ll look at what I believe is the key to implementing a successful automation test strategy.
No comments:
Post a Comment