1. BRIDGING THECOMMUNICATION GAPGetting into agile aceptance testing.
2. WHY THIS TOPIC? I am not native English speaker. New project with new business vocabulary. Problems implementing business requirements.Missing conditions to test, half implementedfeatures. Project documentation (no linked to the code). Too much time wasted fixing bugs. Problems to get an understanding of the project,and what the feature was developed for. 3. WHY THIS TOPIC? 4. AGILE ACCEPTANCE TESTS (AAT) Move Business rules (requirements) => Tests. Theyare a bunch of automated tests builtcollaboratively from the requirements duringspecification workshops that lead the development,ensuring that we are fulfilling our customerexpectations completely. 5. AGILE ACCEPTANCE TESTS (AAT) They will focus the development. They will be a live documentation of our project. They will make changes easier. Instead of discovering problems, we need towork out how to stop them from appearingin the first place.Building the product right andbuilding the right product are 2different things. 6. ADVANTAGESThe biggest benefit of agile acceptance testing is improve communication andmutual understanding, not test automation. Developer Most functional gaps and inconsistencies in the requirements and specifications will be flushed out before development starts. Be sure business analyst understand special cases that you want to discuss with them. You will have automated tests as targets to help you focus the development. It will be easier to share, hand over and take over code. Tester You can influence the development and stop developers from making the same mistakes. Better understanding of the domain. Will delegate a lot of dull work to developers, who will collaborate with you on automating the verifications. You can build in quality from the start by raising concerns about possible problems before development starts. You will be able to verify business rules with a touch of a button. More time for exploratory testing. 7. AAT IN A NUTSHELL1. Use real-world examples to build a shared understanding of the domain.2. Select a set of these examples to be a specification and an acceptance test suite.3. Automate verification of the acceptance tests.4. Focus the software development effort on the acceptance tests.5. Use the set of acceptance tests to facilitate discussion about future change requests, effectively going back to step 1 for a new cycle of development. 8. SPECIFICATION WORKSHOP The primary output of the workshop is a tangible set ofrealistic examples that explain how the system shouldbehave once the next phase is complete. The key feature of these examples is that they shouldprovide enough information for developers toimplement and for testers to verify the stories plannedfor the iteration. We want to discuss what the software does, nothow it does it. Enables developers and testers to learn about thedomain. Building a domain language. 9. SELECT EXAMPLES ANDAUTOMATING. We need to distil what should be done and not really focus on how it isgoing to work. Examples should be SMART (Naresh Jain) Specific: They are explicitly defined and definite Measurable the result is observable and quantifiable Achievable they describe a realistic scenario Relevant they are related to the particular story Time bound the result can be observed almost instantly Formalising examples into tests is the final phase in which we shouldiron out any ambiguities and inconsistencies. Mix different tools to test different types of requirements. (Selenium, Fitand Fitnesse, Gatling ...) 10. A GOOD ACCEPTANCE TEST 11. FOCUSING DEVELOPMENT In practice, Acceptance tests provide a very good specification forrequired functionality. Acceptance tests provide design hints. A piece of code is complete when all the related acceptance testsrun correctly. Unit Tests vs. Acceptance Tests. To mock or not to mock. We should use the same names for concepts in the code as the namesused in the acceptance tests. 12. TOOLS Today Fit and Fitnese, Concordion and Jbehave for business domain testing. Selenium, CubicTest and StoryTestIQ might help with UI tests. To maintain UI tests more easily, use page objects or domain-specifickeywords to describe actions in a business language. TextTest can be an interesting choice for inspecting workflows and building upregression test suites for existing systems. Tomorrow Domain Specific Language. 13. SUMMARY Programming tools, practices and methods aredefinitely important, but if the communicationfails the rest is just painting the corpse. Both unit tests and AAT are important. AAT and Specification by example help businesspeople, software developers and testers tocommunicate better and understand each other. They will be our live documentation. They will help to ensure that all of us understandthe same from the requirements. 14. .