The following article is a guest post to Zephyr from Larry Cummings, Atlassian Consultant and Atlassian Certified Trainer at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.
I always have software development teams use a mix of Test Driven Development (TDD) and Development Driven Testing (DDT) in the same project and in the same release. I’m going to talk about why I do this and how Zephyr for JIRA helps.
I’m assuming you’re using Agile software methods and are very intentional about testing
Using JIRA for software projects tends to steer teams towards a disciplined and agile approach. Integrating Quality Assurance activities with normal software development processes is a no-brainer for anyone who wants to improve software quality. This doesn’t mean it’s easy, though.
My work with Software Development teams is as a Product Owner or Product Developer. These roles are heavily invested in maximizing quality. One of my favorite add-ons is Zephyr for JIRA because it allows distribution of the ability to test for quality to the whole team. Furthermore, this distribution is organized, fits how teams want to work, and intuitively meshes with how JIRA tracks software development process activities.
Every software development team has to find the balance between under- and over-testing different parts of releases
Teams I work with often combine testing methodologies to find an approach that fits what they are trying to achieve. Let’s compare two of the most popular software development testing methodologies: Test Driven Development (TDD) and Development Driven Testing (DDT).
Test Driven Development
Test Driven Development emphasizes the creation of tests before starting to code. You value code (test) coverage and automated testing as a primary activity of your software development team. Your entire team does QA. It’s not just delegated to QA staff. QA staff concentrates on User Acceptance Testing (UAT) testing and spends their time finding defects the software development team didn’t find.
This approach to testing is hard to implement but is an extremely thorough way to ensure a high quality product.
Some of the things to consider when choosing Test Driven Development are:
Development Driven Testing
On the other end of the spectrum is Development Driven Testing. Development Driven Testing means you test for what is meaningful and reasonable. You achieve 100% code coverage in a more manageable model because you write your tests after you get the software design figured out and mostly working. You are not testing for design flaws that can’t ever occur because the tests are created after, or at least near the end, of the design of the software. This approach is actually preferred by many teams when they are looking to save time or the problem they are solving isn’t interesting enough to create runnable tests prior to creating working code.
This approach is preferred when your team doesn’t consider automated testing as the primary or sole means of ensuring high quality software.
DDT testing can test very efficiently because it leverages the design of the software to improve efficiency of automated testing.
Some things to consider when choosing Development Driven Testing are:
Actually, software teams don’t do only TDD or only DDT. They end up doing both at the same time
For any given user story and any given software design, the developers, the QA staff and the stakeholders tend to find a balance somewhere between these two extremes on a case-by-case basis. When you are creating new software that expresses a high risk to quality, you tend to favor a more TDD based approach. When you are creating a new solution that relies on problems you’ve solved many times before, you tend to favor a DDT based approach. These two approaches live comfortably side-by-side because it’s extremely hard for a team to achieve 100% code coverage for parts of the software that are well understood and make use of reliable and robust existing architectures.
Moving back and forth between TDD and DDT in the same project is easier with a tool like Zephyr for JIRA
Being able to represent your tests right in JIRA means everyone has access to facts about tests. Getting testing visible in your project issue tracking tool is, in my opinion, the best way to ensure that testing is integrated into your delivery process.
Because Zephyr for JIRA’s test adds a Test issue type to your projects, using both a TDD and DDT based approach is no problem.
The only real difference from a JIRA and Zephyr from a JIRA perspective between TDD and DDT is when you create the tests. Since these tests are represented in your JIRA project, there’s no limitation on when individual test creation occurs. It’s up to you and your team!
Reporting on your test results
Getting all of these facts about tests into your project is great, but how do you leverage them?
Zephyr brings testing into your production context in two important reportable ways.
How does your team do it?
I’ve spent quite a bit of time in this article talking about TDD and DDT, but there are many different approaches to testing that I haven’t touched on. I love the way Zephyr for JIRA adds the ability to create tests, manage their execution and track those results. I love it because it does so without requiring my team to adopt a specific testing methodological approach. We get to decide which approach to use where to use it. Mixing TDD and DDT is just the beginning. When you want to add Behavior Driven Design based testing you’ll find Zephyr for JIRA is an excellent tool for that too!
The important thing is that you test your software using the methodologies (note the plural there!) that works best for your team. This leaves you in control of how you will work together to maximize the quality of your software while still maintaining a timely release schedule.
Larry Cummings is an Atlassian Consultant and Atlassian Certified Trainer at Isos Technology. He helps organizations share, cooperate and collaborate in alignment with the organization's mission. This is a fancy way of saying he make the mission real by concentrating on the community dynamic required to make it happen. Larry especially enjoys working with product development teams, helping find the right balance between the people that use new systems, and the machines used to build the new system.