Table of content
Well, the term “Code Breakers” conjures up visions of past wars with servicemen crouched over radios, wearing headsets, like this picture here:
Or bazaar machines designed to exude secrets embedded in cyphers.
But, no, that’s not what this article is about. I’m speaking of those individuals who are vicariously wandering around and exploring newly developed software, or modified software programs.
The need for these bit-trippers has never been more evident than today. With the litany of programming languages that would make Blaise Pascal’s head spin, we find ourselves constantly tracking down issues we never thought of. “That’s not possible, I have traps set to mitigate that scenario.” Yet, during the night, when my computer automatically updated, some system file was changed, and now the rules have changed. Guess what? My program has developed an issue.
A call from a user trying to do something the software was never designed to do. And yup, you guessed it, I never thought about someone trying to do that!
Sound familiar? Don’t feel alone. It happens every day to everyone. So the only real solution to reducing the level of insanity this may cause the developer is to employ a testing method that can result in the identification of issues that weren’t thought of.
My suggestion is to get someone who knows nothing about your program to test it. Don’t tell this person a single thing about how to use the software. Show the tester the desktop icon, the coffee pot, and the restroom. Turn this eager soul loose on your program, and let the learning begin. Undoubtedly, during the first few days, you will be inundated with questions. Think carefully – don’t answer those that might sway the learning process. Be sure to provide a tablet and pencil for note-taking.
You will be amazed at what will be found. I have often thought that another programmer could be assigned just to simply flesh out and identify problems. Unfortunately, this type of person tends to revert back to their native training when they encounter a problem. They will offer solutions and suggestions about coding.
You will likely discover the need for a developer assigned to deal with the issues the tester finds. They will only work together for a short period of time. Well, here’s why and the bad news. Once the tester gets comfortable with the software and can navigate through it well, the tester masters the tricks to get around idiosyncrasies. It becomes second nature. The volume of recorded issues drops. The tester begins to make decisions based on the experience gained during the testing.
Here is the unfortunate revelation we must face. The tester has only been testing for about 6 weeks and has become fairly proficient in the operation of the software. Consequently, the level of knowledge gained has rendered this person no longer qualified to fill the position of tester.
So, you see, the less the candidate knows, the better qualified he or she is! Sad but true.
“We are encumbered by our own knowledge.” stated by a friend and colleague has never rang more true than in this situation. But take it all in stride – as the developer dealing with the tester and the issues revealed, we learn to hone our coding skills. Our error trapping mechanisms become more effective, and we learn to view the program operation from a wider angle. Not only have we corrected the code issues, but we have advanced in our techniques. The end result is better performing code!
The above scenarios have driven CodeBright to develop methods and processes to overcome unexpected program operations. Through the use of User Acceptance Testing (UAT), our Quality Assurance (QA) team works with our clients to deliver the best program/software available! Because we understand the perils of software testing, our clients are not burdened with navigating these unknown territories.