When we develop with an Agile approach, we will find ourselves needing to test our software as well. Unfortunately, too often Agile developers find themselves developing with Agile but testing with Waterfall. This hybrid mixture creates technical debt, an untrue picture of the project, and a disconnect between the testers and the rest of the development team. To help, this blog details approaches and methods of Agile testing within an Agile methodology.
Agile testing differs from traditional approaches by:
- Involving testers in the entire release
- Continual testing throughout a sprint
- Collaboration and pair working
- Flexibility to change
Minimise technical debt
You need to focus on reducing technical debt. You must aim to Analyse, Design, Develop, and Test a feature within one sprint. Try to not let a feature leak over to other sprints. For example; instead of working on 5 features a sprint and not finishing them or fully testing them, work on 2 features and sign those off.
Involve the testers early as part of the team
Testers are developers, they are not a separate entity. And as such, they should feel part of the development team. They should have access to the board, the source control, and be involved in any planning or scrum meetings. This is important because you need to reduce the feedback loops. Lengthy feedback loops create confusion, delays problems, and are inefficient. However, short feedback loops help with clarity, you find problems sooner, and will help boost morale.
Acceptance test-driven development
Acceptance tests must be written before the development of a feature. The testers in the team should write acceptance tests for the developers to test the product as they’re developing it. This will reduce the number of issues, and the test-driven approach will help create a quality and test-driven mindset. These acceptance tests should be written during a refinement session and placed within the user stories.
Have a critical mind-set
You could be the greatest developer in the world, but unfortunately, we all make mistakes with our development. It’s important therein to have a critical mindset. The developers and testers should try to find issues with the product. The discovery of issues during the development will help increase quality and reduce technical debt.
Team code ownership
As an agile team, the whole development (including testers) need to take responsibility for the entire code base. Segmenting responsibility will lead to a disparate solution, with potential problems. To do this, team members need to peer-review work, test the solution, and when it goes wrong; take responsibility, then rectify it. A blame culture will hurt the development and testing of the product. Try to make time each sprint so other developers and testers understand pieces of code that they’re not specifically working on.
Evaluate and report test results and test progress
First, make sure you are logging the test results and the test progress. And make sure that this is available to the entire development team. By doing this, the whole team should take responsibility for the progress of testing and understand issues.
Communication
Communication is vitally important, as I mentioned earlier, reducing the feedback loops is critical to the development and testing of the solution. When you can, co-locate, work in the same room, and work together. Key to this is using practices from extreme programming development such as Pair-Programming and Test-Driven development.
Define the definition of done and ready
It is important, as a team to define when a feature is ready (ready for testing) and done (e.g. Signed off). Testers and developers can have different definitions of what is done and ready. Agreeing is important so that issues found in work marked as ‘done’ is agreed as done, and work marked as ‘ready’ is understood as ready. Unfortunately, in agile projects, this miscommunication and confusion can lead to a different perspective of the project performance.
Further References
A lot of this blog was derived from my own experience, but the book Agile Testing Foundations by Rex Black helped formalise and improve this blog.
Introduction to Data Wrangler in Microsoft Fabric
What is Data Wrangler? A key selling point of Microsoft Fabric is the Data Science
Jul
Autogen Power BI Model in Tabular Editor
In the realm of business intelligence, Power BI has emerged as a powerful tool for
Jul
Microsoft Healthcare Accelerator for Fabric
Microsoft released the Healthcare Data Solutions in Microsoft Fabric in Q1 2024. It was introduced
Jul
Unlock the Power of Colour: Make Your Power BI Reports Pop
Colour is a powerful visual tool that can enhance the appeal and readability of your
Jul
Python vs. PySpark: Navigating Data Analytics in Databricks – Part 2
Part 2: Exploring Advanced Functionalities in Databricks Welcome back to our Databricks journey! In this
May
GPT-4 with Vision vs Custom Vision in Anomaly Detection
Businesses today are generating data at an unprecedented rate. Automated processing of data is essential
May
Exploring DALL·E Capabilities
What is DALL·E? DALL·E is text-to-image generation system developed by OpenAI using deep learning methodologies.
May
Using Copilot Studio to Develop a HR Policy Bot
The next addition to Microsoft’s generative AI and large language model tools is Microsoft Copilot
Apr