A big part of testing is making sure that the product you are working on is going to be a highly reliable, quality piece of software. Quality assurance is a big part of testing as a poorly designed product could mean bad news later on down the line. Softwaretestinghelp.com recently posted a blog that dives into this subject.

The first thing that stood out to me in the blog was a formula: Quality assurance = quality control + defect prevention. This formal makes a lot of sense to be. One of the main goals of testing is making sure it works as it should and if it doesn’t making sure someone knows it needs to be fixed. That is the quality control portion of the equation. The second part, defect prevention, is preventing bugs from getting into the software in the first place or recognizing a problem before it happens. I feel if you complete testing with confidence that those two items have been completed, you have done your job as a tester.

Now, how might one go about making sure they hit the mark with the formula? First of all, reviews are a very important aspect. This includes design reviews, specification reviews, code reviews, etc. I cannot express the importance of reviews. Getting other sets of eyes on things are crucial to making sure nothing is missed. From my experience at work, reviews are done for anything and everything, and if a review isn’t done it usually sent out with a disclaimer that whatever is being sent out is a draft. It will bite you if you don’t. Another important step to meeting the requirements of the formula is logging any issues that may have been find when testing. Any issue, not matter how small, should be logged and investigated to determine the problem and if any action is needed. This relates to the next item of the list, which is finding the root of the problem. Often a bunch of little issues that have to keep being fended off are really due to some underlying issue. It is important to make sure that you find the real issue, and not just cover it up. Lastly, make sure as a tester you utilize the resources you have available to you, especially your manager. They have the ability to get you what you need and probably know that quickest way to get it. Most of the time they are more than willing to help as your work reflects on them as well.

This blog provided a nice intro into testing with quality assurance in mind.  I found their thoughts to be intriguing and will be on the lookout for more blogs like this one considering how important quality assurance is to a piece of software.

Link:

http://www.softwaretestinghelp.com/defect-prevention-methods/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Code Smells. Kind of a strange phrase, isn’t it? At least I thought so while perusing Professor Wurst’s concept diagram. I decided to look it up out of curiosity and found some interesting information on it.

Well, what exactly does it mean? In short, code smells is basically code, trends, patterns, etc. that indicate there may a be an underlying issue with the code that could cause issues later down the line and/or is already causing problems. Now, that doesn’t mean the “smelly” code will always cause problems. It could be there for a specific reason. Perhaps it has to handle an odd scenario or something similar, but the point of knowing what smelly code is to be able to determine where there my be common issues or bad habits. In his blog at codinghorror.com, Jeff Atwood dives into some signs of stinky code…

Going through his list, there are several that stuck out to me. The first couple involve length. Long methods are trouble for several reasons, but perhaps the most important is they can be hard to read and trouble shoot. Atwood mentions that methods that are significantly longer that the rest of the methods in the class/program are often trouble and it is a good idea to break it into smaller methods if possible. He also mentions lengthy parameter lists. The more parameters, the longer and more complex the method is going to be. I have to say I agree with both of these. Nothing is worse than trying to read through an endless block of code. Items can get lost and users can easily get confused or lost while trying to decrypt what is going on.

Next on the list are “oddball solutions”. If there is a problem that needs to be solved multiple times, there should only be one way of getting to that solution within the code. There may be multiple ways to get to an answer (i.e. 5*1 = 5 and 1*5 = 5), but the way of getting to the answer should be consistent throughout your code. I agree with his thoughts here. Seeing two different equations to get to one solution could certainly confuse the reader. Not to mention that if the process is the same it should probably just be put into a method anyhow.

Last on the list this week are temporary fields. Make sure that all the fields are actually needed. Unnecessary fields can cause, you guessed it, confusion. The user may think they are needed for some reason and may deem the program to not work properly or something similar. Not to mention that fields that need to be filled out each time the program is run can be extremely annoying while trying to test, so you are doing yourself a favor by keeping the number of fields down as well.

Since I have found this blog particularly useful and insightful, I plan to continue with a part two next week, so stay tuned.

Link:

https://blog.codinghorror.com/code-smells/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.