For the past years, Agile methodology is recognized as an innovative approach to developing and testing software. Based on the 2018 VersionOne’s State of Agile Report, nearly many of the large corporations worldwide are using agile in some sort.
However, some respondents noted that adopting agile is not commonly used within their corporations. This simply shows that it is still a long way to go in agile’s full adoption and functionality.
What is agile’s definition? Why is this software has been so popular these days? This article explores what agile methodology is all about and what is the best approach in introducing it within your organization in detail.
Four Agile methodologies in testing
1. Behavior-driven development (BDD)
Many people are aware of or have tried test-driven development (TDD). For instance, many developers take TDD when writing unit tests to fail prior to writing the code. BDD works on the same principles as TDD. However, instead of unit tests, it takes higher kinds of tests at the business level. Instead of beginning with a technical-facing unit test like TDD, BDD starts with the early requirement according to the end user behavior and seeks tests that are ‘human readable’ and can substitute some requirements of the documentation. This is based on the behaviors that the product should highlight, developing an airtight guide for the engineers to use when conducting tests.
Basically, BDD has a functional specification that uses the Gherkin Given, When or Then syntax. This specification is used as guides for developers, testers, and product owners to examine the features. By doing so, they take automated test functions to identify the completeness, revising the code until it passes the test, similar in the TDD method, except at the team level. To do several test passes, which generally need multiple attempts, the developer is only requested to refactor code and not put any additional functionality.
In summary, BDD needs a ‘smart’ automation system that promotes a high level of efficiency. This strategy makes BDD different from other Agile methodologies.
BDD vs. Waterfall
BDD is very much different from traditional Waterfall testing. BDD takes test cases so it can be written initially based on the requirements and needs to execute those tests toward the end of the development cycle. Using BDD in an Agile environment, tests are not dependent on the requirements and testing occurs along with feature development.
At the same time, in a Waterfall methodology, testers are those assigned in writing the test cases. In a BDD process, it presents itself to the business owners during test writing. This shift minimizes potential miscommunication within the team members.
Shifting to a BDD methodology can oftentimes be challenging, especially when the team is more familiar to traditional testing. In BDD, an analyst or tester should write tests upfront while the developers need to write the right test specification in the code. This is an innovative means of coordination in the team. It is extremely positive where the team works together as one unit, including the end users.
The BDD methodology is most suitable for teams that take feature-focused software and/or groups that focus on the user experience initially. The key members in a BDD environment are product owner, business analyst, developers, project manager, and automation engineers and testers.
BDD best practices
- Streamline documentation to ensure the complete process is lean.
- Create a three-amigo model to build a cohesive team such as product owner, developer, and tester.
- Use a test framework like Cucumber for developing criteria.
- Establish automated tests to reuse them easily as much as possible.
- Enable business analysts to know the Gherkin syntax and directly write test cases.
2. Acceptance test-driven development (ATDD)
ATDD is quite the same as BDD. Tests need to be created initially with the code to be written as a requirement to pass those tests. However, compared to TDD where the tests are generally technical-facing unit tests, ATDD tests are considered customer-facing acceptance tests.
The concept behind ATDD is that user product perception is as vital as functionality. With this perception, this promotes product performance to encourage ATDD adoption. In application, ATDD gathers input from the customers, collected input is used to develop acceptance criteria, transforms criteria into manual or online acceptance tests and creates the code from the tests. Like TDD and BDD, ATDD is the test-first approach and not a requirement-driven method.
At the same time, ATDD helps get rid of potential areas for miscommunication by eliminating the necessity for the developers in interpreting the use of the developed product. ATDD is one step ahead compared to TDD and BDD. However, it passes directly to the source (customer) to help explain the product use. This direct link help in reducing the re-designing of product features in the new releases.
ATDD vs. Waterfall
ATDD is not the same from the standard Waterfall testing as the former uses a test-first process. The conventional Waterfall testing seeks upfront test cases to be written based on the requirements while ATDD is not a requirement-driven testing method.
ATDD is not patterned to the traditional methods. Shifting from one method to another requires some adjustments for the teams. In the adoption of an ATDD methodology, several teams require to get buy-in from stakeholders, which can be challenging at times.
ATDD is ideal for teams that focus on the users’ experience, seeks goals to have high rates of adoption, and willing to reduce the number of feature changes in the next releases. Key members involved in an ATDD environment are the developers, customer advocate, product owner or business analyst, project manager, and automation engineers or testers.
ATDD best practices
- Interact directly with customers, such as focus groups, to meet expectations.
- Rely on customer-facing team members (e.g. sales representative, customer service agents, and account managers) to identify the customer expectations.
- Create acceptance criteria according to client expectations.
3. Exploratory testing
Exploratory testing provides testers with code ownership to evaluate it in an organized approach. In this instance, testers do not follow the required steps. Instead, it employs the software in common or intelligent means to try to break it. Testers are documenting the defects as usual. However, the comprehensive documentation regarding evaluating the application is not always cited. This testing methodology is not scripted. Generally, it is focused on creating the best tests according to every distinct piece of software. With its unscripted method, this type of testing often imitates how the users will work with the software in real life.
Four key principles of exploratory testing
- Parallel test planning, design, and execution
- Flexible and specific
- Aligned with the evaluation of potential opportunities
- Open for knowledge sharing
Exploratory testing vs. Waterfall
Exploratory testing can be applied both in Waterfall and Agile environments. However, the close interaction between the testers and developers in an Agile environment assists in easing any issues that may surface while operating exploratory testing in a Waterfall environment.
Also, to operate exploratory testing in a Waterfall environment, documentation on the test results is necessary. This documentation should be handy in tracing back to the requirements and is always helpful in any environment.
Exploratory testing adoption
Employing exploratory testing is quite easy. It is both easy to launch, scale, and learn. Also, this provides benefits for the whole team. It is essential to note that it is not the only form of testing. Instead, it shows what type of testing occurs next. Also, although it’s unscripted, this type of testing should not be unstructured. The testers are required to set a goal, log in their tasks, and consider the mindset of a specific user.
Exploratory testing is designed to minimize time spent on testing, detect more defects, and enhance the coverage of the code coverage. This is ideal for teams experiencing time constraints or those that need assistance in identifying the best tests to run, particularly where there are no specs provided by developers and teams who seek to ensure they are not missing out anything in the initial tests. Key members involved in exploratory testing are testers and everyone in the team.
Exploratory testing best practices
- Organize the app functionality using a Mindmap or spreadsheet.
- Focus on specific areas or situations.
- Track what needs to be tested to reduce any errors.
- Document results employing the tool like qTest Explorer to ensure some accountability for conducting testing.
4. Session-based testing
Session-based testing is derived from exploratory testing, which promotes more structure. Considering the exploratory testing is entirely unscripted, accountability is quite difficult to address, and this methodology is heavily dependent on tester’s skills and experience. Session-based testing is designed to ease such shortcomings by providing more structure to exploratory testing without eliminating its benefits like the capacity to satisfy the user experience and exemplify creativity with testing.
Session-based testing brings structure by evaluating during time-boxed, uninterrupted sessions, examining against a charter, and seeking the testers to communicate what type of evaluation occurred in every session. Also, the session-based testing provides a debriefing between the testers and the manager that outlines the five proof points.
1) What occurred (previous events)
2) What was attained (results)
3) What issues were encountered (challenges)
4) What needs to be completed (forecast)
5) How does the tester feel about the situation (feelings)
Session-based testing vs. Waterfall
Like exploratory testing, session-based testing operates in both Agile and Waterfall environments. However, it is more conducive to the close collaboration between testers and developers that is commonly found in Agile environments.
Session-based testing adoption
Compared to exploratory testing, employing session-based testing is also relatively handy to as it is easy to learn and launch instantly. For testers who are used to exploratory testing, the main challenge is adopting the new structure that session-based testing provides. At the same time, teams shifting to session-based testing should note that it is not a final step. Instead, it is an optional method to help identify the best type to use next.
Session-based testing can help minimize testing period while enhancing how defects are found, including code coverage. This type of testing is ideal for teams that encounter time constraints and require proper guidance to identify what types of tests to work on. AIso, it is suitable for teams that enjoy the benefits of exploratory testing but has yet to upgrade accountability within the process. Key members to be involved in the session-based testing are the testers and managers.
Session-based testing best practices
- Cite a goal so the testers are fully aware of the software they should be testing.
- Build a clear charter with a mission, software areas to test, which tester will work best on the session, when the session will occur and how long, how the tests are designed and executed, the bugs seen and the overall notes.
- Implement the testing session without being interrupted.
- Document the activities and notes in the session report.
- Conduct a debriefing between the testers and the manager to review the session findings and discuss the next testing processes.