I remember the good old days, when development teams used to have the luxury of planning 9-16 month releases. We would take our time to plan the release from soup to nuts. Generally developers would take a good amount of time to build the software while testing was considered to be throwing over the wall event. In majority of the cases, testing phase (stabilization) used to take much longer than anticipated. Fast forward 10 years, and now we can no longer afford that luxury. With the changing realities in this application economy, we need to not only be faster but also be much higher in quality-- slipping dates is not as much of an option, and our customers are not forgiving on quality.
Agile methodology has promise, but being able to deliver working software at the end of each iteration is easier said then done. QA efforts still can be a bottleneck: how can you test something which does not exist yet? Traditionally, QA had been focused on UI testing to verify software functionality. However, in the beginning of the project, UI either is non-existent or very fluid making it almost impossible to do any sort of test automation a reality and it goes on the back burner. For agile teams, the “Aha!” moment came when in his book, “Succeeding with Agile”, Mike Cohn introduced the testing pyramid concept.
Cohn argued that for test automation, we have been targeting wrong place. We will have a better luck in automating if we focus on Unit Testing and services layers to validate the application functionality.
Let’s see if this testing services layer approach for automation can also help us achieve our First Day Test Automation goal. I will illustrate it through an over simplified project example below.
Requirement: We need to build this awesome “Calculator” which can Add, Subtract, Multiply and Divide 2 numbers. I would want my end users to interact with the calculator via a web app (which supports IE, FF and Safari), as well as through native Android and iOS Apps. Also partners are interested in consuming our “Calculator as a Service” using an API. I also want my end users to be able to see which functions of the calculator are more popular.
Design: My fellow architect takes this requirement and comes up with the architecture below.
At the release planning meeting, we started drilling down on the stories and high-level architecture. The architect explains he is using the DB to store the API usage statistics. We ask the team to estimate the work. The API developer says it’s going to take him approximately 20 points to get to the state where he has the basic service up, and he may potentially finish Add and Subtract in sprint 1. The UI and Mobile developers are sitting there thinking, “I can start basic application stuff…but finalized interfaces can only be achieved after the services layer is in place.”
My QA reviews the architecture and acknowledges that with CA Application Test he can invoke and verify each layer individually as well as combinations of multiple layers (WebUI, Mobile, APIs or JDBC). “But wait a minute. I also need these components available before I can start building my automated test cases!” At that point, a light bulb goes off in QA engineer’s head and he suggests that let’s quickly agree upon the API interfaces and create a virtualized calculator service using CA Service Virtualization which can be used by me but also by UI/Mobile developers.
That did it! The architect creates the virtualized service and hands it over to the engineering teams. By using this virtualized service, we not only achieved parallel development of both the services and presentation layers, but also enabled QA to start creating automated test cases right from sprint 1.
Do you strive for First Day Test Automation in your organization? What are the tips and tricks you use to achieve this goal?