Before I became a QA engineer, I ran transport logistics at a delivery warehouse near Moscow. Every day 50 to 60 drivers left our gates, and together they made about 2,500 to 3,000 deliveries. Later, for a few months, I drove a delivery van myself, doing 70 to 100 drops a day.
I now test software for a living. The longer I do it, the more I think the most useful lessons about data quality came from those years, not from any testing course.
Four places, four versions of the truth
Every order lived in several places at once, and each place belonged to someone different.
- The driver carried the paper waybill.
- The driver's mobile app held the delivery status.
- Storekeepers checked the returns that came back to the warehouse in the evening.
- Accounting checked the money.
On a good day all four agreed. On a normal day, some of them didn't, and the two things that disagreed most often were the quantity and the address. A status that said "delivered" while an item came back in the van. Three boxes on the waybill, two at the customer's door. An address in one record that did not match the address in another.
Reconciliation is an investigation, not a comparison
When something didn't match, comparing the four records was the easy part. The hard part was finding out why.
That was my job. I pulled the waybills, followed the item through the warehouse, called the driver, talked to the storekeepers and to accounting. One mismatch could take two to four hours, most of it spent on calls between departments that each saw only their own piece of the picture.
It always ended in one of three ways. We found the item and arranged a second delivery to the customer. We found that it had really been lost, and the driver paid for it. Or we found a mistake in the records.
The driver paying is the part that stayed with me. The fine was the full value of the item, and the driver was the last person in a chain of systems that didn't agree with each other.
The box behind the seat
One case I still remember. A customer complained that part of the order never arrived. The waybill said it had been loaded. The app said the order was delivered. The customer said it wasn't.
I started from the waybill and worked forward. The missing item was in the van the whole time: it had slid down and was hidden where nobody could see it. The driver took it to the customer the same day. The customer was happy, and the driver was not fined.
Every system in that story was "correct" on its own. The waybill was right, the app was half right, and the customer was right. Only by putting the records side by side did the real answer appear.
The driver's side of the data
When I drove the van myself, I saw the other end of the same problem. To close a delivery I had to photograph the parcel at the door. In buildings and areas without mobile signal, the photo would not upload, so I had to walk around looking for a spot where it would go through. It made every such stop much longer.
I still delivered on time, and my returns stayed low, usually no more than five out of 70 to 100 deliveries. But I understood something I had not seen from the dispatcher's desk: a lot of "data problems" start as a person standing in a stairwell, trying to make an app accept proof of something that already happened.
The one thing I wished the software had was a route built in advance: get in the van and drive straight to the first stop, on the fastest route with traffic taken into account. Everything else, honestly, worked well.
What I took into software testing
When I moved into QA, first in FinTech and now in advertising analytics, I kept meeting the same pattern. The same order, payment or report lives in the interface, the API, an exported file and a database. Each of them passes its own tests. The bugs that cost money live between them.
So the questions I ask as a tester are the ones I used to ask in the warehouse:
- Where else does this record live? If the answer is "in three places", then there are three places to compare.
- Which source is the reference? At the warehouse it was the waybill. In software it is a business decision, and someone has to make it explicitly.
- When two sources disagree, can we tell why? A list of 3,000 mismatches is not an answer. "Items lost at the end of every page" or "times written without a timezone" is.
- Who pays for the mismatch? Usually it is not the system that caused it. It is the driver, the customer, or the accountant at the end of the month.
I have been turning these questions into an open-source tool, LogiParity, that compares the same records across an API, exported files, a user interface and a database, and groups the differences into likely causes. It is young, and I am looking for teams who would try it on their own data and tell me where it is wrong.
But the tool matters less than the habit. If you build or test logistics software, try one thing this week: pick one order and find every place it is stored. Then check whether they all agree. In my experience, they rarely do, and somewhere a driver is paying for it.
Written with AI assistance from my own notes and experience. The stories and the opinions are mine.
Top comments (0)