How we approach engineering quality at GDS

[heathd]

There have been several attempts to document GDS's quality engineering approaches/practices, which are rooted in TDD, pair programming and continuous delivery. None of them have made it into the GDS way.

This document is the most complete attempt:

https://docs.google.com/document/d/1aPbXwDkNG3eJgrkIMm2TkMQJq4DyLlWorOA089DsjIk/edit

We should review this and try to add something to the GDS way that summarises current practices

Tasks

Preview Give feedback

No tasks being tracked yet.

[louzoid-gds]

We now have a few pages in this space including

• Breaking down work
• Test-driven development
• Pair Programming
• How to review code

I think worth reviewing this issue to consider where we think we still have gaps and then refining next steps

[mboban2024]

These are great topics, thanks. To build on this, I was wondering if we could consider:

• Static testing of work products is important to build quality at source - architecture, UI designs, Requirements, ACs. Efficiency of code and later validation depends on quality of inputs into development cycle.
• Non functional attributes of quality : performance testing, security testing, accessibility testing, compatibility testing etc.
• There are a few operational attributes of quality: Observability, RUM, Feature flagging, Canary releases, user research
• How do we verify efficiency of our quality engineering activities - indicators, KPIs, reporting mechanisms
• How do we cover all test pyramid layers. Unit test level is important part, but that's not the end of testing. We need specialised tasks like exploratory testing, functional integration testing, contract testing etc to prevent unknown - knowns (unaware of behaviour, but can exist in real usage) or unknown-unknowns (latent issues within our systems—problems we didn't even know could be problems or manifest when conditions line up just the right way) in the system.