Agile2012

Good Agile Testing is hard. Transitioning to Agile is doomed if the testers, team or org. aren’t prepared to handle the changes in how testing is performed, managed and communicated. The path to great testing contains many traps and pitfalls along the way - including: only performing manual testing, automated tests that aren’t maintained, and user stories that aren’t “done” on time. In this interactive workshop, you will explore some of the major challenges and discover ways to avoid them. Everyone tests. Are you ready?
http://submit2012.agilealliance.org/files/session_pdfs/Agile 2012 - Pitfalls in Agile Testing - Paul Carvalho.pdf

Get rid of heavyweight Test Plan documents that no one reads, focus on process, make it difficult to respond to change and don’t help with customer collaboration. In this hands-on session, you will create a multi-dimensional Test Strategy that _radiates_ information (i.e. helps everyone know what’s important to test _right now_), highlights non-functional requirements, and easily adapts to changing requirements. Everyone on an agile team can use this method to get on the same page - this is **not** just for testers.
http://submit2012.agilealliance.org/files/session_pdfs/Agile 2012 - The 0-Page Agile Test Plan - Paul Carvalho.pdf

Agile teams incrementally deliver functionality based on user stories. In the sprint to deliver features, frequently software qualities such as security, scalability, performance, and reliability are overlooked. Often these characteristics cut across many user stories. Trying to deal with certain system qualities late in the game can be difficult, causing major refactoring and upheaval of the system’s architecture. This churn isn’t inevitable. Especially if you adopt a practice of identifying those characteristics key to your system’s success, writing quality scenarios and tests, and delivering on these capabilities at the opportune time. We will show how to write Quality Scenarios that emphasize architecture capabilities such as usability, security, performance, scalability, internationalization, availability, accessibility and the like. This will be hands-on; we present some examples and follow with an exercise that illustrates how you can look at a system, identify, and then write and test quality scenarios.
http://submit2012.agilealliance.org/files/session_pdfs/TestingSystemQualities - Agile2012.pdf

Fluid delivery stream is a strong requirement for business performance. Managing Technical Debt is a key factor for sustaining this delivery stream. The **SQALE open sourced method** is used in numerous places; from small to ultra large companies for monitoring their Technical Debt (one of the largest banks in the world is using SQALE on a daily basis across 3,500 builds and 30,000 + developers). Jean-Louis Letouzey, the author of the SQALE method will introduce it, explain and demonstrate how its indices and indicators provide valuable information for managing and optimizing Technical Debt.
http://submit2012.agilealliance.org/files/session_pdfs/SQALE-Meaningful Insights into your Technical Debt.pdf

Creating automated end-to-end functional acceptance tests is hard. Maintaining them over time is harder. Some agilistas even claim that the cost outweighs the benefit. In this tutorial, Jez will explain how to create valuable, maintainable acceptance test suites and keep costs under control. First, he describes how to layer acceptance tests to reduce coupling between the test harness and the system under test. Then he discusses how teams should be organized in order to efficiently manage acceptance test driven development. Next Jez shows how to manage the evolution of acceptance tests by organizing them as scenarios rather than as suites of story tests. Finally he discusses how to manage data for acceptance tests.
http://submit2012.agilealliance.org/files/session_pdfs/automated_tests_workshop.pdf

There is a common practice in our company to perform Developers Exploratory Testing (DET) sessions, explained by my colleague Davor [here](http://www.stickyminds.com/sitewide.asp?function=DETAILSIDX&tvniu=1&sqry=*Z(SM\)*J(ART\)*R(createdate\)*&ObjectId=17003&ObjectType=ART&sidx=1) . The cool thing is that this way of performing higher level testing has actually become accepted by our developers, and [they really enjoy it.](http://blog.jayway.com/2010/10/11/three-reasons-for-me-as-a-developer-to-love-developer-exploratory-testing/) In my current work of [developing our organization wide practices for quality](http://blog.jayway.com/2011/12/01/organization-wide-test-strategy-step1-deriving-our-quality-values/), I have made a deep dive into how DET is carried out on a regular basis. What I have seen is that DET is accepted and acknowledged as a valuable practice, however it is not really carried out in its full potential. There are many details and aspects of it to work on, especially regarding reporting and follow-up. This talk will gather my learnings from coaching many of our different development teams in their DET sessions. Some improvements are achieved just by carrying out ET in a better way, but there are also specifics about the involvement of the whole team testing together that give alot of value back to the project. One example is about what information that is gathered which are not plain bugs.
http://submit2012.agilealliance.org/files/session_pdfs/20120815_Siggeb_DET_Agile2012.pdf

Whether you are a developer, tester or manager, you'll gain insight and actionable information on how to more effectively test both new and legacy code using the open source ApprovalTest library. Through both demos and explanation of theory, the presenters will show you how using ApprovalTests make testing many types of objects (from simple types to complex objects such as GUIs, arrays, database query results and more) more manageable. The library is available in many programming languages, including C#, Java, Ruby, PHP and more. Most demos will be presented in C#.
http://submit2012.agilealliance.org/files/session_pdfs/ApprovalTests_Agile_Aug_2012.pdf

The benefits of making quality the responsibility of both developers and testers are increasingly recognized by Agile teams. Such an approach improves accountability, eliminates bottlenecks and allows testers to focus on the most complex and difficult testing issues. However, getting developers engaged in non-code facing testing is often a challenge. This presentation will detail two techniques - blitz testing and mentored testing, that we've developed at Atlassian that have been highly effective at not only engaging developers to undertake such testing, but also to gain the knowledge and skills they need to improve the quality of the software that they write. Blitz testing, widens test coverage, and involves regularly assembling an internal “SWAT” team to perform focused testing as a group for short periods. The roles within the group and the structure of the sessions are adapted to suit the various goals of the testing. Mentored testing, deepens test coverage, and involves a tester working directly with a developer to help guide the testing that developers perform, as well as a combination of paired and simultaneous test execution to help developers identify where and how to improve their testing. Together, these practices result in developers who spend less time fixing their code and testers who are able to focus on complex testing challenges, enabling the team to improve quality without sacrifice.
http://submit2012.agilealliance.org/files/session_pdfs/TestersRole_Agile2012.pdf

Acceptance Test Driven Development is a very popular topic these days. Everybody’s excited about the idea of writing tests prior to development. And yet many teams run into difficulties as they attempt to implement this practice. It is all too easy to fall into the trap of writing acceptance tests that specify every keystroke and button click. Acceptance tests that are tightly coupled to the system under tests are the norm. Most software changes over time and our tests need to be able to adapt to that change. Join Cheezy as he shares the experience and insight he has gained while working with numerous teams implementing ATDD. Cheezy will take us on a journey of discovery where he demonstrates techniques to write Acceptance Tests that describe the essence of what they are specifying while hiding unnecessary details that obfuscate their meaning. Cheezy will also demonstrate how to structure and layer your test code to reduce brittleness and fragility so they will retain their usefulness well into the future.

Hi, my name is Dave, and I'm a recovering Selenium user. I was like you once -- new to Selenium, using the IDE for a quick fix. Oh sure, "Just this once. I'll have plenty of time to change it later." is what you'd say. But before you knew it -- BAM! -- you're in so deep you don't know how to get out. Trying to debug a large suite of brittle tests that constantly break only to find false positives after slow run times along with a nice helping of poor cross-browser coverage. I've seen it a thousand times, and I'm here to tell you, it doesn't have to be this way. Here at Selenium Users Anonymous, we offer practical advice from those that have gone before you -- showing you how to evolve your current Selenium nightmare into a bright automated testing future with our universal 12 step program.

This session is an easy introduction to writing small automated tests for very Big Data systems. If you're considering Hadoop, Cassandra, or Riak but don't know how you would begin with good developer testing practices, then this talk is for you. I'll be showing live test execution and debugging for some very Big systems: 1. The ant/maven config to enable testing 1. How to connect to a local or in-memory testing harness 1. Demonstrate execution and debugging in an IDE The code and configuration will be published on GitHub for all to repeat what's shown. The session agenda is: 1. Brief presentation introducing Big Data technologies. 1. An hour of code/test live demonstrations. 1. Discuss the hard questions: large test datasets and test execution performance. 1. Wrap up with Q&A.
http://submit2012.agilealliance.org/files/session_pdfs/BigDataLittleTests-Heintz.pdf

This presentation challenges the "norm" for TDD. Testing should be an integral part of your daily programming practice. But you don’t always need to derive your code via many test-code-revise-retest cycles to be test-driven. Some find it more natural to outline a related set of tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, there isn’t a single best way to be Test Driven. There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s be practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing.
http://submit2012.agilealliance.org/files/session_pdfs/PragmaticNotDogmaticTDD - Agile2012.pdf