A course named “Software Construction, Design, and Architecture” can certainly hit upon an endless number of topics. Due to this problem, I referred to concept map Prof. Wurst created at the beginning of the semester. Of the various topics to choose from I ended up going with anti-patterns for this week. I’ve found learning what not to do can sometimes be more useful than learning what to do. A lot of times you can infer what to do by simply being told what not do to. In a nutshell, anti patters are common patterns that occur that are known to cause problems and make life more difficult. So, I stumbled upon a blog post written by Emile Swarts in which he discusses some of the most common anti patters he has seen. I found Emile’s thoughts to be quite useful and relatable and I will be sure to factor in these common situations when developing software.
Emile discusses five of them: accidental complexity, dependency hell, catch me if you can (he made up the name for this one), blind faith, and abstractions of deceit. With the experience I have gained from my internship, accidental complexity, blind faith, and dependency hell are the three that stood out the most to me and have encountered personally. I find people are very good at making things more complicated than it needs to be under any circumstances, not just software. Complexity is often the root of all problems and can ruin projects. If it works it should probably be left alone. The biggest thing I took from what he wrote about this is that accidental complexity can basically be blanket over all anti patterns. Don’t reinvent the wheel if you don’t have to. Work with what is already given to you. The next anti-pattern I mentioned I liked was dependencies. Dependencies break things and make things more complicated. In an ideal world each piece of software and everything each piece software does would be totally non-reliant on anything else. Obviously that won’t be happening anytime soon, but I feel it something all developers should strive for. I always think of operating system specific software as an annoying overarching dependency. Granted this often on purpose, but the point is it certainly would be easier if different software wasn’t needed for different operating systems. Blind faith is the last one I wanted to discuss. He brings up valid points on how damaging an update or new piece of software can be if it doesn’t work correctly. Depending on the size of the operation, it could cost companies thousands of dollars each minute the software is still broken. This is why no one should ever assume something works. No matter how confident you are, test it, and if it works, test it again. You don’t want your software to be source of a major problem.
As I was perusing the various blogs about testing on softwaretestinghelp.com I stumbled across a blog titled “7 Qualities of Highly Effective Testers”. Seeing as I am currently taking a course on software testing I figured it might provide some useful information. The blog followed suit with what I expected; with talking point about meticulous attention to detail and whatnot, but that is not to say the article wasn’t useful. In fact, I found it to be quite useful because it justified why these seven qualities are needed.
The seven qualities discussed were: curiosity, attention to detail, imagination, logical thinking, ability to focus, discipline, and constructive communication. Having some experience testing software at my internship, a couple of these really stood out to me. Curiosity/imagination (I feel that these go hand in hand) were the first ones. Under these topics they discuss how a good tester will think of every possible scenario. This includes things like behavior that you normally wouldn’t expect a user to perform or potential flaws in the deepest, darkest corners of your code that you would never expect to be exploited. If you don’t expect it to happen, it probably will. One example they gave is “what will happen if I click on the ‘submit’ key and then hit the ‘escape’ key?”. When testing you must make sure you cover everything across the board even if you think the chances of the scenario playing out are less than zero. I can tell you a lot of the problems we have found with the product we are building at work have come from a “let just try this for the fun of it” comment while testing.
Attention to detail is the next one that stood out. To me this means that a good tester will take note of even the smallest flaws. If the tester feels that it due to his/her own mistake or some external circumstance that normally wouldn’t be there, the issue still needs to be noted. Because what if it is not? What if it has been a recurring issue, but because it is so minor other people running tests have chalked it up to the reason you think it is? Everything, no matter how minor it seems, need to be tested and recorded.
The last one that really stood out was constructive communication. Nobody wants to hear that their product doesn’t work as it should. In the case that someone other than the developer is running the test, the tester needs to be able to communicate with the proper sources to explain the issue without making seems like they are trashing the product. There needs to be a good relationship between the testers and engineers/developers.
After reading this I feel a lot of what was discussed it true and these skills are critical if you are going to be a highly effective tester.
Hi everyone! My name is Matt Foley and I am currently a senior undergrad student at Worcester State University in Worcester, MA, USA. I am computer science major with a minor in business. I created this page as it is a requirement for a couple of courses (CS343 and CS443) I am taking this semester, but I hope to continue to use this page to provide my thoughts, insights, etc. on the happenings in the tech industry well beyond this semester.