Introduction
At the bottom of it all, Software Engineering, Data Engineering, or Data Science, etc are all about
problem solving. We hear this song being sung all the time. We will continue singing it
until it makes sense to everyone.
Until you realize that all other real-world problems closely relate to these
disciplines of Computer Science, it will be hard for you to appreciate problem-solving.
I want to relate the science and art of problem-solving with that of car repair. Both
have elements of art and science. If you own a car, then you will likely
understand this post quite well. If you do not, still it will be easy to relate
it to any other kind of real-world problem.
The scenario I want to share relates to a car, which I own – and I know many car owners go through the same kind of experience. My car had
two separate issues (call them problems if you like) at different times. To clarify, these are only two examples cited for this post, otherwise car owners usually
have many other similar car issues.
Car Problem 1
The first time, my car actually didn’t have a real problem as such. I just
needed to check that the brake pads we still okay after using them for quite a while. There
were no symptoms of any malfunction. I was just acting responsible.
Car Problem 2
The second time, there was a real problem. The indicator (turn-signal) lights
started behaving erratically. The indicator lights would sometimes work, but
most times they would fail to work. This was a serious safety issue that I couldn’t
take for granted.
Resolution of the Car Problems
The above problems are all too common, all the time. A critical understanding
of such problems empowers us to solve them better whenever they occur. For example,
before you hand over a car to a mechanic, try as best as you can to explain and
practically show the current state of your car so that you can validate
tests afterwards.
Resolution 1
The Car Problem 1 was “easily resolved” because there was actually no problem.
The mechanics checked the brake pads and found them okay, so they put them back.
Soon after I drove off, I started noticing a very minor issue while braking,
but I decided to ignore it for a while. The brakes were behaving as if there
was some space between the pads whenever I braked. It would emit some “tapping
sound”. As I continued driving, the annoying sound would come out once in a while,
but most times it was okay.
Resolution 2
The problem was also easily resolved because the device called “indicator
flasher unit” was spoilt. It was a matter of replacing it within 10 minutes and
all was well with the indicator lights. Unfortunately, that same evening, I was not
able to listen to the car radio or open/close the car windows unless I started
the car engine (which was very unusual, and wasn’t the case before).
Common Verdict by Mechanics
Note that in both cases, new problems were created in the course of fixing the car by the mechanics. However, the mechanics
would say that they didn’t tamper with anything else. That they just fixed the
problem, and they didn’t cause any other problem.
Meanwhile more money was being
spent in identifying the "new" problem every time I would return to the garage (repair shop).
We would later, however, confirm that indeed the mechanics
had tampered with something that caused another problem! And listen to the next section.
Tampering (Regression) 1
The Mechanics actually didn’t put back one of the two small pieces of wire that
secure the second brake pad. But this was only identified by one of the senior mechanics after many return visits to the garage (repair shop) – and after I had already painfully driven over
3,000 kms under potential safety risk. In addition, one innocent wheel nut was damaged in the process, rendering it useless.
Tampering (Regression) 2
The mechanics had forgotten to reconnect a wire while fixing the indicator
lights issue. They had left the wire dangling. In addition, they had swapped other two wires, making them go into wrong sockets.
So why the fuss?
The above scenario is exactly what happens with software or data engineering. Regression bugs occur
when an unintended and unexpected problem is unknowingly created during the process of fixing
a bug. The naïve Software Engineer or Data Engineer will react in the same way as the naïve mechanic:
“I didn’t tamper with anything else”.
If you are a Software Engineer or Data Engineer, and you
have understood the above scenarios, then you might not want to question the
relevance of the following:
- Unit Testing: Testing individual and independent units of classes, methods or functions. If a failing test case is deliberately written upfront, then we call it Test Driven Development.
- Integration Testing: After integrating units together, we use Integration Testing to test how units work together; and
- User Acceptance Testing: Here, the end users test for system functionality or business requirements.
Along the way, we should also perform Regression Testing by re-running Unit and Integration Tests. Here, we test whether a code change has broken any other units. The good news is that we do not have to write Regression Tests from scratch. We can build a Regression Test suite from the existing Unit and Integration Tests..
This whole thing couldn’t have been put better than the following extract from this page:
“ … Again, it’s important for developers
and testers to always bear in mind that even small, seemingly insignificant
alterations to an application’s source code can ripple outward in surprising
ways, breaking functions that seem completely unrelated to the new
modification. When you run regression tests, you’re checking to make sure
that your modification not only behaves as you want it to, but that it also
hasn’t inadvertently caused problems in functions that had otherwise worked
correctly when previously tested. …”
Many software developers seem to hate Unit Testing (and by extension Integration and Regression Testing) as it appears to be too time-consuming. But when tragedy strikes, it becomes too complicated to dig out and
identify the source of the tragedy, just like in the car scenarios.
To many car
owners, it’s a nightmare whenever they take their cars to a mechanic because they
fear that the car will come back with new problems created by mechanics – to the extent that many prefer to NOT take a car for repair unless the problem is of a very serious nature. The mechanics that I know simply don't do any regression or integration tests. They do only unit tests. That’s the reality.
If I find time, I will consider posting about Unit Testing with Python, either using unittest or PyTest.
So much with car repair and software update. I rest my case.
No comments:
Post a Comment