Role of an Agile QA Engineer

Agile Software Testing has literally transformed the role of an Agile QA Engineer.  There are several key differences which software testing organizations will need to adjust in order to effectively operate with Agile.

Documentation:  It isn’t practical within Agile for the Agile QA Engineer to have lots of documentation.  Don’t get me wrong, there does need to be sufficient documentation for the QA Engineers to do their job well. If a developer tries to convince you that the Agile Manifesto doesn’t require documentation, Houston we have a problem!

• In terms of requirements, there needs to be enough documentation that the Agile QA Engineer knows how the system is supposed to operate.  In my team, we currently use a 1 page document that will provide that information for each story.  It really does help the agile testers know what is expected so they can adequately plan.
• For the Software Test Plan, it isn’t necessary to go through all the hoopla of creating a massive plan that nobody will read or follow.  A one page document will be sufficient.  I encourage the creation of the one page plan because it forces the agile tester to think about what testing is needed.
• For the testing sign off a simple email will suffice.

Test Automation: One of the hottest topics naturally is test automation, especially within Agile software testing.  Test automation without a doubt is critical.  However, there needs to be a strategy that is going to work.  In previous organizations, I have built world class automation teams.  We had thousands of automated test cases within our regression suites.  Were all those tests necessary, probably not.  Was it expensive to maintain, absolutely!  I believe having a centralized automation team that can build and execute the automation tests is most effective.  The team prioritizes the work based upon the needs of the various agile teams.  I have found this to work most effectively.  I usually recommend that the agile testers execute the tests within the current sprint and once those have passed, they can hand that off to the agile team to automate and put in the regression suite.  Having an Agile QA Engineer do both the functional and automated tests within a given sprint is extremely challenging and often the functional testing gets done and the automation gets put on the back burner.

Performance Testing: Another challenge is system performance.  If automation takes a back seat, then performance testing is usually behind that.  In order to deal with that challenge, having a centralized performance team will help.  Usually 2-3 performance engineers will be sufficient.  I encourage a very close look at performance testing within the Agile context.  If you don’t need it, don’t do it, if you need it, you better do it.

UI versus Web Service:  Agile software testing requires some fundamental changes in terms of how things get tested.  More and more agile software testing is taking a closer look at web service testing.  It is a critical component that can find a lot of defects.  The need for agile teams to focus on spending more time in this area is due to the amount of applications that are using API’s to transfer information.  It is a lot quicker to run hundreds of transactions through an API versus through the UI.  Agile software testing teams who are able to make this transition are simply more effective.

Let’s face it, transforming your software testing organization is going to be very challenging.  Agile software testing is extremely challenging.  The key is to have a strong team who is flexible and is adaptable to constant change.  The teams that can do that most effectively will be successful.