Today, I like to define what exactly agile testing is. And also I like to mention drawbacks of agile testing and how to accommodate that. If you find something missing please reply on the comment section.
Following seems to be the unique parts of Agile testing. It's an interesting mind shift if you've been working as a tester in Waterfall environment.
Testing effort on defect prevention.
This is one of the fundamental differences between Agile testing and testing in Waterfall. In Agile testing, test team puts their effort on creating good quality builds before it gets to QA team (before deployment) whereas Waterfall testing puts efforts on after it gets to QA team (after deployment). This seems just a small difference but it has quite valuable implications. First, for test team to find issue before dev code gets deployed to QA environment, there should be a good communication channel between dev/pm/test and even business. Test team can help dev team not to make any assumptions about unclear spec. Test team can provide potential impact to the application due to current development(risk assessment/analysis). Test team can also provide some scripts or test data that dev team can run and use on their local environment. Dev team can do a simple demo to the test/pm/business to verify his/her progress. All these to be happened, barrier among all disciplines has to be removed and all has to simply work as a team. I've seen a lot of issues are found during those informal discussions and demos. And those issues are quickly resolved and not logged as bugs, which can reduce the time and effort on filing a bug (repro steps, screenshots and all that stuff), triaging the bug, and dev team reproing the bug and etc. Also, enforcing writing and reviewing unit tests and checking on coverage metrics are also contributing to the defect prevention. There are a lot of things you can do to prevent defects in your software. It's a good discussion to have with your dev/pm/tests and business. You'll normally have multiple checks before code gets deployed. And you'll actually find less bugs after deployment happens. But now when you find a bug on QA environment, you can think about how you could prevent that and add more checks. It's kind of addicting. I would say..
Speed
Speed is another the key part of Agile testing. Fast feedback on developer's new check-in. Think about the time it takes where a new mistakes goes into the check-in and those mistakes are found in testing. duration between dev puting mistakes in his/her code and finding that mistake from test. Lots of articles and papers mention about pyramid and what kind of tests take place in that pyramid. It actually has to do with speed of test execution and creating targeted and controlled tests. Each level of pyramid defines purpose of its own. Another way of looking at this is to check the Think of find the same bug in selenium UI tests vs. fast and furious unit tests. So if your test team’s primary automation strategy is something like selenium, think again. Seriously
Consistent feedback mechanism
No doubt about this. Continuous Integration! Every check-in of the code gets tested thoroughly from unit tests to UI tests. Gated check-in using unit test coverage percentage and promotion model of build increase the quality of the build. Test team can contribute to reviewing unit tests, writing fast component-wise testing, UI testing using mocking or spoofing.
Skilled testers.
Agile testers do not only think like users. They do think like users and engineers. They are beef-up with tools. They can pick and choose whatever tool is necessary for the execution of test of any kind. Skilled testers not only tess the code but also make good recommendations to the dev team. Testability is one of the key components of good design of the application.
Now, let’s take a look at how to accommodate drawbacks of agile testing.
Context-Driven testing
One of the tendencies of agile testers is to think a lot on mechanics of the code. Functions and components of the application. But there are places where testing strategy matters. Because each and every testing problem has to do with its context. What are the best testing strategy for calculation heavy feature? (like data driven testing) What are the best testing strategy around state based application? (like model based testing). What are the best testing strategies around infinite inputs and outputs permutation applications? (random sampling, equivalent classing, pair-wise testing) Coming up with best testing strategy around given context actually matters a lot.
Systems thinking
Since agile testing is working on small features and make iterative progress. Testers sometimes lose the big picture of the application. Systems thinking is a great way to look at your testing. Check this video out. https://www.youtube.com/watch?v=OqEeIG8aPPk If you trying to improve the application by taking parts separately from the system, you’ll not be successful. Watch this video, you’ll get it.
