Cogo was a carbon-footprint app being redeveloped, with a lot of moving parts and a lot of ways for things to go quietly wrong. I provided quality assurance throughout the redevelopment, combining methodical testing with the kind of curiosity that finds bugs nobody planned for.
Curiosity first, then method
I’ve always been good at breaking software. I get curious about “what happens if…” or sense that something’s off, and a few minutes later there’s a bug that needs fixing!
I paired that instinct with structured testing of how the app behaved across different scenarios, so we got both the surprising bugs and the systematic coverage.
I also kept an eye on live user data for signs of problems, especially after each update, since real users find things no test plan does. How I reported depended on where the bug was: for features still in development, I discussed each bug with developer responsible in the format they preferred. For the live app I wrote formal bug reports.
Does it do what it’s supposed to do?
Not every problem is a bug. A feature can work perfectly and still not be right. When testing a new feature, I started from the original wireframe and specifications from the product and behavioural science teams. I then checked the developers’ work against this. The question was never just “does it work?” but “does it do what it was designed to do?”
That caught a different kind of problem: places where the build had quietly drifted from the intent or where the specification itself left room for interpretation. I took these back to the right people, so each one got resolved before the users ever saw the fearure.
Testing journeys, not just screens
Some of the trickiest problems only appear across a sequence of actions. One example was a feature letting users commit to changing their diet. They could swap out beef, go vegetarian or go plant-based for a period, and the app would show a reduced carbon footprint on their food transactions plus a total saving. Users could also change their minds, perhaps avoiding beef usually, joining in with Veganuary, then swapping back.
That meant every transaction had to show the right footprint, saving and graphic for whichever diet period it fell into, and link to the right prompt for an even better option. I built and tested user journeys for each of these scenarios, then did the same for swapping fuel for public transport, planes for trains, and new clothes for second-hand. With hundreds of possible combinations, I found several bugs that a quick check would never have caught.
Checking the data worked before launch
The app also had to collect data on user behaviour so that the behavioural science team could test their research hypotheses. Before each feature launched, I tested that every tracked action was recording correctly in Amplitude and appearing in the charts correctly. This meant that the data would be trustworthy from day one rather than something we discovered was broken weeks later.
Being “the person who knew how it works“
The project had a complicated structure, so I spent a lot of time coordinating between departments. I worked within engineering but talked to the product and research teams daily, which made me the go-to person for how the app actually behaved and what it needed to do also. I pushed for documentation at every stage, so that knowledge was written down and not just in my head.
Across a year of testing, a combination of curiosity, structured scenarios and checking against the original intent meant a wide range of issues were found and settled before they reached users, not after.
