Testing is not just for testers any more. One of the most important parts of an agile transition is getting us developers to change our attitude and start writing tests alongside our code. Many teams are adopting a policy of writing unit tests for all new features, and some even plot the rising code coverage at every build. All this testing activity has reverberations around the whole project team, not least for the dedicated testers. What will they do with their day when the software they are given has already passed several thousand automated unit tests? Project managers may start wondering if all these green tests are in fact a green light to ship the product. What if some tests are missing, how would they know? In this talk I'd like to take a look at the big picture of testing on an agile project, and talk about how developers and everyone else on the team should reason about their agile testing strategy.

Testing a program by monitoring changes in it's plain text log files is an old idea, but one which has fallen out of fashion lately. This talk aims to show you that with a tool like TextTest, it can not only work, but work well. Well enough to enable agile development, especially in situations where for example xUnit breaks down. This is a technique and a tool that I have developed over the past decade at Jeppesen, for automating maintainable black-box tests that work entirely outside of the code. In this talk I will demonstrate how the tool works in practice, and examine the advantages and disadvantages of this approach in general.

Spelar det någon roll? Borde vi inte istället fråga oss om det är ett beteende i produkten som vi vill förändra eller ej? Det jag ifrågasätter är behovet av de tungrodda ändringsprocesser man ofta implementerar. Man gör något väldigt komplicerat av något som i grunden inte är så svårt. Lösningen på detta problem är att behandla information direkt och inte spara undan den till senare. Ska något rättas gör det då direkt annars lev med beteendet. Skippa alla olika benämningar som buggar, förändringar, förbättringar o.s.v. Anpassa er process utefter era behov och ändra den när behoven ändras.

This is how I introduced Exploratory testing at a Swedish based telecom company. Astonishing that we did it in only 8 days to an organization with 80 testers! This was possible by intruducing the role Exploratory Testing Champion. The objective is to give a road map and a tool kit to enable you to set up a similar project. I present a background to Exploratory testing, scope, contents and results of the workshops , responsibillites and expectations of the Exploratory testing Champions. I will present real facts from this live case, schedule, statistics, comments from praticapants and where we are today.

Unit testing is a fundamental complementary activity in robust software development. It promotes reliable code and drives testability into design, as well as helping discover defects at an early stage where they can be eliminated with relatively low cost compared to later stages. “Data-Driven Transaction-Based Unit Test”s (DTUT) helps fast unit test development with increased test-case maintainability in applications based on similar architectures to that of application-under-test, namely ROTA framework based on Microsoft’s Enterprise Development Reference Architecture (EDRA). With this approach, writing trivial unit-tests is reduced to inserting a row in the test database. Transaction-level scope of tests allows achieving high coverage quickly with the option of intensifying unit tests in critical areas of the system.

Agile teams measure their progress by looking at delivered stories—features that users value. Many agile teams produce solid unit tests (e.g., using Test-Driven Development). Such tests are great, but they only establish that the parts are working; to ensure that we’re doing the right thing at the story level, we have to test at that level as well. Storytesting is the process of creating acceptance tests (preferably automated) that customers can understand and value. You’ll take away ideas for how to write effective storytests, how to divide the work, and tools and trends. (This session will mostly be tool-agnostic, focused on techniques over tools.)

To my lasting embarrassment, I reviewed the very first paper on mock objects, "Endo-Testing: Unit Testing with Mock Objects" (Mackinnon, Freeman, Craig), and completely missed the point. Like many people since, I mistook mocks for stubs. That confusion was quickly cleared up–and yet, as I came to hear more about what’s sometimes called the “London School” of test-driven design, particularly as represented by Nat Pryce and Steve Freeman2, I remained puzzled by the consequences of mocking. Representatives of the school described it as placing the emphasis on defining the interactions between objects, rather than on defining classes. It was easy to accept that intellectually, but I didn’t understand what it meant for program design or the act of programming. Now I do, I think, and I think I’ve hit upon an interestingly odd way to explain it: 1. In the early days, what we now call test-driven design (TDD) was known as test-first programming. The name changed after practitioners realized how to create tests that (a) ran fast and (b) didn’t break wholesale when the underlying code changed. They did it by building programs that had properties we knew all along were important: high cohesion and low coupling. But until TDD, the short-term cost of those properties kept us from enjoying their long-term benefits. TDD made them–and good design in general–matter to us right now because we care about ease of work. So we did what we should have done all along. 2. Mocks make programming even easier, especially when programming is done in “sashimi”3 or “tracer bullet”4 style, where classes are changed or modified in the order that user input would encounter them. 3. More importantly, programmers using mocks have more control over the pacing or cadence of their work. Working with mocks leads to a steadier pace than ordinary TDD. 4. The desire to control pace produces designs even more uncoupled and cohesive. In the talk, I’ll explain my claims in more detail, using examples from a web application I’m writing in Ruby and Objective-J5. I’ll also discuss the weaknesses of mocks (mainly expectation mismatches) and how they can be handled.

Another take on Inside-Out/Outside-In thinking in test-driven development. Two simple, connected thought patterns, with examples, that helps you avoid serious but all too common mental pitfalls of different takes on test-driven development like TDD, BDD, ADD. Too often both beginners and seasoned TDD-ers skip all the tests for the hard part of a piece of code. We find that the hard The Russian Doll pattern helps us think in clean onion layers of tests. We learn to recognize a Clockwork and switch design space to TDD its gears, not just the interface, thus saving a lot of debugging.

Automated testing via the GUI has got itself a bad reputation - and with good reason. It is associated with bloated, expensive tools, horrible proprietary languages and maintenance nightmares. The prevailing wisdom has become that the best thing to do is to minimize testing through the GUI and instead go directly into the code via an API. But does it have to be like that? The heart of the problem is one of coupling. Tests that go through the GUI end up too tightly coupled to it, and hence break when it changes. What if we had an abstraction layer in between, a "GUI interpreter" that mapped the possible actions in the current GUI to carefully chosen domain-language statements? We could have high-level, readable tests that describe user intentions rather than GUI mechanics. PyUseCase is a tool that enables you to work in exactly this way. I've been using it for several years to testing rich client applications written with Python and GTK (similar tools exist for Java and .Net). In this talk I hope to demonstrate how productive this approach to GUI testing can be.

Traditional testing methods teach us that explicit and testable requirements need to be developed and formalized in order for testers to design relevant test scripts or test cases. These scripts must be written in such a way that even a tester with limited or no experience from working with the system under test will be able to execute the scripts in an exact and repeatable manner to ensure that we test the same every time. Exploratory Testing, as coined by Cem Kaner in the early 1990s, is an approach that complements traditional scripted testing. It encourages and emphasizes simultaneous learning, test design and test execution. Its strength lies in empowering testers to ask themselves, what is the best test I can perform next, without being limited to a prewritten script or set of rules for their testing. This talk gives an overview of Exploratory Testing and how it can be structured for traceability and credibility without losing out on the creativity and freedom of the approach. It will also present experiences from a real world introduction of the concept and discuss the positive impact that adding Exploratory Testing can have on the overall quality of testing in a heavily scripted test organization.

Nbehave är ett av många BDD ramverk inom .net. Nbehave försöker främja kommunikation mellan kravställare, utvecklare och testare. Denna session kommer att ge dig en introduktion till BDD och demonstrera funktioner i Nbehave.