BRIDGING THE COMMUNICATION GAPGetting into agile aceptance testing.
WHY THIS TOPIC?
• I am not native English speaker.• New project with new business vocabulary.• Problems implementing business
requirements. Missing conditions to test, half implemented features.
• 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.
WHY THIS TOPIC?
AGILE ACCEPTANCE TESTS (AAT) Move Business rules (requirements) => Tests. They are a bunch of automated tests built
collaboratively from the requirements during specification workshops that lead the development, ensuring that we are fulfilling our customer expectations completely.
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 to work out how to stop them from appearing in the first place.
Building the product right and building the right product are 2 different things.
ADVANTAGES The biggest benefit of agile acceptance testing is improve communication
and mutual 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.
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.
SPECIFICATION WORKSHOP The primary output of the workshop is a tangible
set of realistic examples that explain how the system should behave once the next phase is complete.
The key feature of these examples is that they should provide enough information for developers to implement and for testers to verify the stories planned for the iteration.
We want to discuss what the software does, not how it does it.
Enables developers and testers to learn about the domain.
Building a domain language.
SELECT EXAMPLES AND AUTOMATING. We need to distil what should be done and not really focus on how
it is going 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 should iron out any ambiguities and inconsistencies.
Mix different tools to test different types of requirements. (Selenium, Fit and Fitnesse, Gatling ...)
A GOOD ACCEPTANCE TEST
FOCUSING DEVELOPMENT In practice, Acceptance tests provide a very good specification for
required functionality. Acceptance tests provide design hints.
A piece of code is complete when all the related acceptance tests run 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
names used in the acceptance tests.
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-specific
keywords to describe actions in a business language. TextTest can be an interesting choice for inspecting workflows and
building up regression test suites for existing systems.
Tomorrow Domain Specific Language.
SUMMARY
Programming tools, practices and methods are definitely important, but if the communication fails the rest is just painting the corpse.
Both unit tests and AAT are important. AAT and Specification by example help
business people, software developers and testers to communicate better and understand each other.
They will be our live documentation. They will help to ensure that all of us
understand the same from the requirements.
.