2 Ways to Know Your Work Is Actually Done
I saw a tweet that said something along the lines of, “It isn’t done until it is tested.” Pithy statements like this always sound profound at first, but then I started thinking: tested by whom, how, and how much? And even after all those questions are answered, there is still a chance that you’re not done.
Testing alone doesn’t specifically determine whether or not you are done—especially when we probably don’t mean the same thing when we all talk about testing. Here are two ways I use to know when my work is truly done.
Positive Feedback
I work on a small team of developers. No one is in a tester role full time, and yet we test constantly.
When I am building a new feature or making a change to something old, I am generally writing and changing unit tests for the back end and Cypress tests for the front end. At certain points after making changes, I import customer data and run the product locally to see how those changes are or are not working. I also continuously make small changes back and forth in the code to see if I prefer an implementation to be one way or the other. This is testing and development activities intertwined, but it doesn’t tell me when I am done.
To know that important bit of information, I generally go to the champion for my customer and show them the work in progress. They might look and say it’s not right, or look and find a bug, or suggest small changes, or just give me a thumbs up. But their positive feedback is what I am looking for. This feedback tells me that I have done enough development and enough testing.
The Change Is in Production
Sometimes I will get a request for a small data change. My product has a database table where one field is a regular expression, or regex, statement used for joining some data to display on a page. Last week I had a request to make that change. Making the regex and testing locally took a couple of hours.
I made a database change directly on a staging environment and asked the customer if that looked right. After one iteration on my initial change, we had a solution that they were happy with.
Waiting for the deploy process would have taken unneeded extra time and overhead. I decided to go ahead and make the change in the production database. I know this is not generally something you want to do, but it made sense for this one change.
This request was done when it was tested by multiple people, delivered to production, and in use by the customer—all without an official testing process or a tester on staff.
Deciding when a change is done is more nuanced than saying, “It must be tested.” Testing is something that just happens—on responsible teams, at least.
It might be worthwhile to think about the real ways you know when you are done.
