Keynotes

In the decade since agile has gone mainstream, testing has received more emphasis—and in many organizations an automated test suite is now a prerequisite for delivery. For the first time, testing is a core activity within an integrated dev team rather than a downstream activity to be commoditized or outsourced. However, when you scratch the surface of agile testing, it seems we have lulled ourselves into a false sense of security. In an era of “automate all tests,” testing on agile projects broadly falls into two categories: automated deterministic testing provided by TDD, BDD, ATDD, and friends; and manual exploratory testing, carried out by expert testers. However rigorously we apply these methods, entire classes of tests aren't being considered, and entire groups of stakeholders are falling through the testing net. Not all automated testing should be deterministic; not all testing should be automated. Dan North helps identify the gaps in your testing approach. By considering testing as a risk management exercise viewed through the eyes of multiple stakeholders, Dan hopes you will share his mild panic about how much testing we aren't doing.

In chess, the word blunder means a very bad move by someone who should know better. Even though functional test automation has been around for a long time, people still make some very bad moves and serious blunders. The most common misconception in automation is thinking that manual testing is the same as automated testing. And this thinking accounts for most of the blunders in system level test automation. Dorothy Graham takes us on a tour of these blunders, including: the Stable-Application Myth (you can’t start automating until the application is stable), Inside-the-Box Thinking (automating only the obvious test execution), the Project/Non-Project Dilemma (failing to treat automation like a project by not funding or resourcing it, and treating automation as only a project). Other blunders include Testing-Tools-Test, Silver Bullet, Automating the Wrong Thing, Who Needs GPS, How Hard Can It Be, and Isolationism. Different skills, approaches, and objectives are needed or you’ll end up with inefficient automation, high maintenance costs, and wasted effort. Join Dot to discover how you can avoid these common blunders and achieve valuable test automation.