The Importance Of Dev Testing

Introduction

What is the cost of a bug found by your stakeholder?

The immediate answer is the time taken to fix it. But it is so much more than that. It's a crack in the foundation of trust, it's the user who is now silently thinking: "Can I rely on this?", it's the embarrassment for the developer and a new item that derails the plan for the next sprint.

During the course of my career I've worked in some teams who treat Dev Testing as a luxury which is usually the first thing sacrificed to the God of Speed. They almost see it as a nice-to-have, a task to do "if we have time". Many developers seem to rush to "done" without stress testing their own work thoroughly.

In my view, this isn't a curious choice. It's a strategic failure that trades short-term success for long-term chaos.

I believe that Dev Testing is as crucial for the team and therefore the data product as the actual development work.

Why Dev Testing Matters

Dev Testing should be seen as an integral part of a data developer's role. Builders of the product and users of the product view it through different lenses.

As developers we spend our time building. But once the building has stopped, we must pause and change our role to then view through the lens of the user.

Dev Testing is important in my view for three main reasons:

• It builds trust with the stakeholders - fewer embarrassing bugs get spotted in demos or other public forums.
• It reduces the number of rework items thereby saving time for developers, testers and the team as a whole.
• It encourages the developers to own their work end-to-end, not just hand off to the tester to spot issues.

What Good Dev Testing Looks Like

To be good and effective at dev testing, the developer has to change their view of the product. Now they are a 'User'. Their one job is to press buttons, change slicers, click on visuals and so on with the sole aim of breaking the report or returning an abnormal value or visual.

In practice and to give this a bit more structure I would encourage a developer when dev testing to:

• Check the values / visuals when applying multiple filter contexts at once.
• Click any buttons and ensure what happens is correct - check that 'Reset' and 'Back' do what they say.
• Click any buttons / navigation more than once. Do they give odd results?
• Consider edge cases: what would you expect to happen if there was no data for a selection or for a (data point on a) visual? Test with nulls, negatives and duplicates.
• Validate the numbers against either the source system or the semantic model. Do they make sense? Do they match?
• If possible, validate the numbers with a different dataset.
• Consider performance, not just accuracy.
• Consider UI: are any new objects aligned with the existing ones? Do the fonts / styling / colours match other existing objects in the report?

The Objections and Why They're Wrong

I wanted to cover off the three main objections I hear and why I believe they're wrong and actually a form of self-sabotage.

We don't have time to Test

I would argue strongly that you don't have time not to test. If you spend 30 minutes testing now while you're still in the context of the development, this will save a call with a confused user down the line (be it the tester, the PO, another stakeholder or an external user) or a couple of hours in a later sprint having to context-switch back to this exact scenario to fix the bug. It's like ripples in a pond, fix it at source and they stay small with little knock on effect. Leave them and their effects get more widespread.

That's the tester's job

This is a dangerous viewpoint. This encourages a "throw it over the wall" culture. A culture where the tester is the enemy and the developer has no accountability for their code.

It absolves the developer of any pride in their work which can easily result in a dropping of standards to mediocre. The attitude changes from "This has to be perfect when it leaves my desk" to "That'll do, the tester will catch anything I messed up".

It's also inefficient for both parties. The tester, when they find fault, has to pause their testing and pick up some other testing while they wait the fix. The developer also has to change context to pick up and re-work the issue found. As mentioned above, the whole process takes longer and involves more resource than the initial 30 minutes dev testing would have.

The developers need to see the tester's role differently. See it as a game: one in which they produce high-quality, well executed work and silently challenge the tester to find any fault.

It works on my machine

This is a concerning statement to hear any developer say. Translated it says "My job is to write code, not to ensure it actually delivers any value to the outside world."

This highlights the difference in role between a coder and a developer. Any coder can write semantically correct code that functions in the sterile environment of their own machine. But a developer must be able to produce reliable code that functions on any machine, for any user.

I would also argue that this does not meet the definition of dev testing. The whole point is that you assume the role of a user and test it in as many different scenarios and as many different setups as possible.

Working on your machine is a great start. But it's not a great finish.

How To Build A Culture Of Dev Testing

Fostering this mindset requires more than just an email to the team. It requires a deliberate, structured approach. Here is a practical framework for how to embed Dev testing into a data team:

1. Make it an explicit item in the Definition of Done.

   This way it is baked into the team's standards and becomes non-negotiable. An item is only considered done it is has passed the developer's own rigorous testing.

2. Maintain and share testing checklists across the teams

   Create a document detailing common pitfalls e.g. "slicer synchronisation across pages" or "check source connection". This provides a valuable resource for new or junior developers and a quick reference for others ensuring consistency and catching repetitive failures early.

3. Gamify the QA Cycle

   Cultivate a healthy, competitive dynamic where developers take pride in shipping "unbreakable" work. This shifts the question from "will the QA find any bugs?" to "can I build something so robust that the QA can't find anything wrong?"

4. Publicly celebrate developers who ship clean, low re-work items.

   Shout out developers who successfully live these values. This indicates that the organisation values sustainable quality as much if not more so than raw output. This is immensely valuable for the team to see and hear.

Conclusion

In woodwork, we're always taught to measure twice and cut once to ensure accuracy and for best results. Testing should be seen in the same light: It's a QA function but it's also part of the developer's work.

Dev testing is the quality control that ensures you're building the right thing, correctly. It's what separates a hastily assembled prototype from a professional, trustworthy data product.

The mark of a professional isn't how fast they code, it's how reliably they deliver.