The Inovis Blog

We are pleased to introduce our readers to the newest writer for the Inovis blog. Linda Eason is the QA Manager for Inovis Actionable Intelligence here at Inovis, and has 6 years experience with testing in an agile development environment. She has been a QA analyst, a QA team lead and will be providing a wealth of knowledge about Scrum. Linda currently resides in Austin with her husband Lance, who also works at Inovis. They have 3 cats and one dog that she says “pretty much rule the house.” In her spare time, linda loves broadway musicals and live stage productions.  Here is Linda’s first post. Enjoy!

Disclaimer: The opinions expressed in my blogs are based on my personal experience with testing in an agile development environment – warts and all.  What works for one person, product, or company may not work as well for another.  My hope is these blogs will give the reader some insight into agile testing that they can then use to help them inspect and adapt their own QA process.

Agile

I am going to assume that anyone reading my blogs understands the basic concepts of agile.  So in these blogs I will be talking more about how the Actionable Intelligence development environment has implemented agile and the challenges that we face. Then I will talk about agile principals in general.  This first blog is a general overview.  I will go into more detailed discussions of testing in an agile environment in my subsequent blogs.

image source: http://www.infoq.com

Agile Testing Overview

Agile development environments are dynamic and fast paced.  This means that the testing methods and procedures in an agile environment must also be dynamic and fast paced.  More traditional testing procedures (like you find in waterfall) do not work effectively in an agile environment.  In my experience, they don’t work at all because they are based on waiting – wait until all the requirements are written up in a big document, wait until development finishes the code, wait until Dev turns the code over to QA for testing, wait until you are given a window of time to actually test the code, wait until an “acceptable time” to release.  All this waiting makes traditional testing procedures very slow paced and somewhat rigid.  It has also been my experience that QA testers trained in these more traditional procedures have a difficult time adjusting to the pace and flexibility of an agile environment.  They have been taught that testing is a long and drawn out compartmentalized process that requires pages and pages of documentation before testing can begin.  The idea of testing code without all the supporting documentation, planning time and compartmentalization makes them extremely uncomfortable.

This is not to say that an agile QA environment does not follow recognized and proven QA methods.  We do, we just have a different focus and execution strategy then a more traditional development environment.

The primary goal of agile is to get releasable code completed in each sprint.  This means that testing has to be done as part of the sprint.  QA cannot wait until the feature is 100% completed.  They must be planning for testing at the same time that dev is planning the code.  Test case design must be started at the same time that dev is beginning to write code and testing must occur as soon as QA has a build that contains the code.  This coordination of effort can only be accomplished by QA and Dev working very closely together.  It also requires a very skilled and independent QA staff.

In an agile development environment you cannot wait for things to happen.  You must be proactive.  This is true for all team members, but it is especially true for QA.  QA team members cannot let anything get in their way of testing. If they don’t understand the requirements (user story) they need to ask the Product Owner for clarification.  If they are not sure how dev is going to implement the new code, they need to discuss how the code will be implemented with the developer ASAP.  They must become self directed experts at removing any obstacles that prevent them from testing.  I will expand more on agile testing methods, challenges and personnel in later blogs.

Quality in Agile

There are some that believe that testing in a very non-traditional manner means that the code is not well tested.  This is simply not true.  If it was, I would be writing my resume instead of this blog.

Our agile testing focuses on how the application is actually being used by our customers.  How we test is just as important as what we test.  Running 100s of tests may make everyone feel better about the code, but it does not make the code well tested.  It is the tests themselves that determine how well the code is tested.

There are a ton of books on testing strategies and methods.  These books are full of theories and studies designed to help people test better and to improve the quality of their testing.  These books are great reference tools, but like all reference tools the reader has to take what they can use and leave the rest.  As a software professional, I have to deal in reality and the reality is that software is a business.  Businesses cannot make money if they can’t get working product to their customers.  All of my testing strategies are based on getting the best code I can out the door in the minimum amount of time.  I will go into detail about these strategies in future blogs.