This is a placeholder blog post for my LambdaTest Conference talk.
Here are the Slides.
Table of Contents
Context
I started a new role 3 months ago (You can read on my job hunting process here). This is a story of how I’m getting involved with the process and what I’ve been helping improve from a quality and testing point of view.
The company is a small tech company that helps build an insurance based back office for companies to manage things like insurance policies. I’m the first test engineer hire and there where some problems they wanted someone in that role to help focus on.
Survey people
When meeting new people, ask them what are their biggest concerns or frustrations with quality and testing. Common answer’s will include:
- Bugs in production
- Test coverage
- Lack of realistic test data
- Flakey tests
- Build Times
Quick Wins
Early on I worked on a script to help change the IP address of a service we use. When we are in the office and on the company wifi the server has a different IP address compared to when we are working from home.
I hadn’t done much bash scripting before (I had never used the command SED) but this was a quick win to get a bit of exposure to parts of the infrastructure.
You can use you automation skills outside of testing too. Automating small repetitive tasks you do frequently is a great way to help yourself and the engineers you work with.
Improving builds
This is a common problem that comes up with engineering teams. Our chosen tech also introduces some challenges. For example we aren’t using GIT, we are using mercurial with patch based development practices instead.
When you are working on some code you create a patch. However everyone else’s patches above yours are also applied to your local repository.
It’s a great way to get stuff incidentally tested by other dev work as most people test on a snapshot patch further down the queue that includes your changes. It also encourages early integration and frequent commits. Which are great engineering practices.
However this means we can’t easily trigger a build from a single commit. Or trace back a broken build to a single code change or jira ticket.
Unit tests on every patch
One build that I set up in Jenkins goes through every patch between release and snap shot and runs the unit tests against them. These are pretty quick to run, they take a few minutes per patch. This is to help us get closer to connecting a specific patch to a broken unit test. As each patch number is connected to a Jira ticket/item of work.
There are still bugs with this script that need to be ironed out but it was a fun way to explore more shell scripting. I hadn’t done much bash/shell scripting before.
DB migration testing
This build script for DB migration testing has been a life save with our recent release. Our platform is pretty flexible and can run with multiple databases.
However somethings like booleans aren’t the same across different databases. We use liquid-base to run database migration scripts and going through each instance caught a few db migration issues in our previous release.
There are issues with running sql server and oracle DB’s locally on m1 mac chips (it’s not supported). Which means we either have to use docker containers or a dedicated server for this. This can take a long time locally to test and it’s better to have a jenkins job for it.
UI Testing Challenges
Our front end is built using GWT (Google web toolkit). It’s a Java to javascript framework. However the elements on the page have a tendency to change the ID elements each time the page renders. Making UI automation a little challenging.
We may investigate making this easier to do but it isn’t a high priority item. However synthetic tests using DataDog for alerting and monitoring does play nice with some of our front ends.
Bug backlog grooming
I don’t enjoy bug backlog grooming. However when a project has existed for over 10 years and no has revised old bugs, it can build up. I’ve been working through bugs in the backlog, either trying to reproduce them or getting them revisited. Sometimes have have been fixed as part of other work.
Summary
There’s still plenty of work to improve. I hope this blog gives you inspiration in how you can get more involved with your process.
It’s not really a shift left or shift right thing. It’s more about learning the tools and technology your team is using to help build in feedback at the right time.
If you build a bunch of tests but no one pays attention to that feedback, why did you put in all of that effort?