I wrote a blog post giving an introduction to the 30 days of testing challenge that I am doing. Task 2 of the challenge is to write down what I think Agile Testing is. As I was thinking about this one night, I decided to jot down my thoughts.
Introspective
The term Agile Testing confuses me a bit. What does it actually mean? Is it to be able to move fast or be agile when testing? Or is Agile Testing, “testing to make a team fast or agile”.
I once heard Uncle Bob Martin say “tests enable change”. So, can we say that testing enables us to move quickly? Maybe. Not all testing. What about if we manual tested? I have done this a lot in my career and it is not fast. Especially when you have no idea how the feature is supposed to work.
Is Agile Testing “writing automated tests that enable us to safely make changes”?
What kinds of tests would be best for this? What makes code easy to change? I like to change code that I can easily understand. Code that almost reads like English. Unit tests are good for this. Well, unit tests won’t do this alone but used as a tool to test the design of your interfaces. When writing a unit test I will ask myself “how do I want to call this function?”. If I am using unit tests for design I use Test Driven Development (TDD). Unit tests are great. They are usually easy to write, fast to run and fairly easy to maintain if written correctly. But if I am in a code base that only has unit tests, I don’t feel completely safe when I make a change. Even if all unit tests pass, there is still a chance that a change I make breaks something.
The next set of tests that help me feel safe as a developer are integration tests. Integration tests are tests that exercise one or more units of code. I don’t get hung up on the semantics.
If the application has a database (most do) I use these tests to test any queries I write. These tests give me confidence in my dB changes but what about the needs of the user? How do I know if we are meeting the needs o the needs of the user?
Acceptance tests. Acceptance test tells us whether the application is meeting the needs of the user. The user can be another system or a human. these tests are the most valuable tests. Yes. This is a strong statement but I have seen the benefits in large complex applications. The last product I worked on was an FDA regulated application. This means that every release had to go through a full regression test for every requirement. The application had automated tests for 90 percent of the requirements. Running the test took a couple of days. This would be several months of manual testing.
So Agile Testing is “writing automated tests that enable us to safely make changes”. But wait! If I make a change and have to run all the tests, how is that moving quickly? Huh. So is Agile testing “writing automated tests that enable us to safely make changes and get fast feedback about the quality of the system”?
What about performance? What about security? What about usability!?!? Good Grief.
What else makes changes safe? Documentation, right? The agile manifesto values “Working software over comprehensive documentation.” So is one of the jobs of tests to document how the software works?
Conclusion
I kind of like this summary of Agile Testing:”Writing automated tests that enable safe changes“. How much testing and how often you run all the tests depends on your context. In my FDA example, it was necessary to document how the software works by having 90% test coverage of the requirements. But it may not make sense for a startup that is trying to get their head above water.
Go to 30 days of testing
Task 3: Find a Video about Agile Testing and Watch it
