Throughout the software development life cycle (SDLC), the purpose of testing is not only to guarantee the quality of the software being developed but also to guide development and keep the focus on the user’s needs.
History of Agile
Agile development was born to answer the software development crisis back in the early ’90s. At that time, it took roughly three years for an application to be delivered. By the time the app was ready to be released, the business requirements had changed along with the user needs. With this approach, many apps didn’t see the light of day.
Agile development came to the stage to address these weaknesses. This lightweight technique should have ensured that working software gets to the end-user in less time, getting the earliest possible feedback to define the future development direction.
Along with agile development, agile testing evolved. It went through various stages — from a marginalized process covered by practitioners in several disciplines to just a phase in the development process with a dedicated team member. Now, it is an activity practiced throughout the development life cycle and by every team member.
Traditional Testing Method vs. Agile
Unlike the traditional testing that adheres to a linear or sequential development model, Agile advocates a more iterative and incremental approach to testing. The Waterfall model is an example of a traditional SDLC method. Here, every phase in the development process begins after the previous one has been completed, implying that the testing team receives the product late in the development cycle. This kind of approach directly opposes one of the leading testing principles — early testing.
On the other hand, Agile is often driven by tests, and thus the notion of testing promotes continuous integration with development. Testing and quality have become imperative for all team members.
By being actively involved in every segment of the development cycle, testing provides valuable and frequent feedback to the software being built and, by doing so, contributes to the global quality of the product.
Testing in Example-Driven Development
Example-driven development is similar to test-driven development but differs in how examples are expressed and composed. While TDD operates on low-level (unit tests), EDD operates on higher-level (acceptance tests). Primarily it highlights the business level and end-user perspective.
EDD provides several techniques that can be used to guide development with examples. Whichever you find the best, they all have the same goals.
- the business goal is better communicated
- by identifying potential problems with US at the early stage
- Finding and bridging the gaps between tech and business
Acceptance-Test-Driven Development (ATDD)
Although it sounds like a testing technique, ADD is a software development technique where tests play a vital role, and automated acceptance tests lead to the development of the application.
The process mainly refers to the functionality of the application. It puts the system’s functional behavior in the spotlight, which leans on users’ needs and tries to answer the question – Is the code working as expected?
The collaboration among developers, QAs, and stakeholders/PO or clients is crucial. The mutual understanding is over clean code, coverage percentage, and passed tests.
The acceptance criteria sets are turned into executable tests that ensure the developers implement functionality based on requirements.
The role of the QAs here is to find all blind spots that can jeopardize the application in the later stage of development.
Behavior-Driven Development (BDD)
BDD is another software development technique mainly used along TDD or within ATDD. Additionally, some find it to be a synthesis between TDD and ATDD.
BDD places a heavy emphasis on team collaboration and cross-functional workflows.
BDD has evolved into both analysis and automated testing at the acceptance level. The target is a mutual understanding of requirements from the business perspective where shared language and the Given-When-Then approach enhance it.
Rather than just verifying whether a particular function works, the crucial role of QA in SDLC is to think of a context in which one function is being used.
Specification by Example (SBE)
Specification by example is a collaborative approach for defining requirements and tests relying purely on realistic and illustrative examples. This technique is compatible with flow-based delivery models such as Scrum or Kanban. It helps align various roles involved in the development process with the idea of what needs to be built and how to achieve it. Particularly useful in complex business domains, SBE bridges the communication gap between the stakeholders and the development team through knowledge-sharing sessions where business goals and objectives are converted into real-world usage examples that will later become specifications.
Based on those examples, the test team forms story tests allowing them to automate specifications by using an adequate tool, the most famous being Cucumber. Via this approach, the development team decreases the chance of bugs and avoids costly rework that can impact the quality of the product.
Example-Driven Development Limitation
A stumbling block of example-driven development can be the level of complexity and details of the examples based on which the specifications are created. A higher level of complexity could lead to misunderstanding and could increase the time needed for development due to uncertainty. A remedy to this potential threat is establishing how much detail is appropriate for the team through experiments. The difficulty of immediately recognizing the advantages of example-driven development is an additional problem. Due to a lack of time, the business stakeholders or developers may feel too busy to engage in this practice. A solution would be to point out the benefits of examples by gradually including stakeholders in the development process.
However, we should remember that not every feature is suited for an example-driven approach, especially when there is an insufficient experience in treating the topic. If this occurs, an alternative solution would be an exploratory investigation performed by a programmer-tester pairing.
In Conclusion
Software development has gone through constant changes throughout its history. With Agile, a foundation has been laid for a modern development process in which testing became an activity of crucial importance. Through its active integration with development, testing activities can easily be incorporated into all techniques that ensure a higher quality of the software, as shown in the aforementioned example-driven techniques. Although implementation requires time and commitment, example-driven development offers an innovative and inclusive approach to building software that relies on a mutual understanding of requirements and tight collaboration between all roles.
——————————————————————————————————————
About authors:
Dunja Ibročić, BrightMarbles’ Quality Assurance Consultant with over 5 years of experience working on complex projects.
Darko Bučevac is a French-speaking QA Engineer with over 5 years of experience, specializing in test automation and web development in BrightMarbles.