The more I continue to browse the various blogs on testing, the more I find myself gravitating to a certain kind of blog. There are many blogs on different kinds of testing, new types of testing, etc., but I find myself often going to help/tips type blogs. I find them to be quite useful, because they are easy to apply to my job. One I found this week was “What To Do When There Isn’t Enough Time To Test?”. Well, that is a very good question, isn’t it? Testing is very important and time is almost always limited. There are deadlines to meet, people to see, and places to go. Time crunches are common for testing and seeing as the course for this blog is about testing, I felt this might be some good “real world” advice.

There are lots of reasons why time be tight when testing. They talk about several reasons why this might happen, all of which I have seen before. The three big ones discussed are a poor time estimating to being with, technical problems, and disagreements between teams. Generally, it is not a good idea to have an aggressive timeline for testing. It often backfires as it is never going to go exactly as expect. I agree that technical problems are often a cause for delays, especially if the product is new and some exploratory trouble shooting is needed. This relates back to making sure you’ve allow for enough time. I’d rather be done early than stuck working nights and weekends to meet a deadline for testing. The third, disagreements, is not very common. And when I do see it, it is often due to a miscommunication more than anything. If there is a disagreement, I’d like to think it would be worked out swiftly and in a professional manner.

The article then goes into how to make sure your team does have enough time to test. The first one mentioned, is making sure you have estimated enough time. This crucial to having a successful testing experience. Now, time estimating relates a lot to what they mentioned following this: know how long the testing has taken in the past, know what the team is capable of, keep track of your progress, etc. Do you know that there is a high probability that a certain aspect of the product is going is going to break? If so, that should be factored it. To me the easiest way to make sure there is enough time to test is to think of the worst-case scenario and make sure you have allotted enough time to complete testing should that situation take place. Granted, often teams do not have the luxury of that much time, so making sure there is enough time to test goes back to having an efficient overall operation with realistic goals and deadlines. Be ambitious, but so ambitious that it comes back to bite you.

This article provided some great advice on how properly schedule testing and is something I will be sure to reference back to time and time again.

Link:

http://www.softwaretestinghelp.com/what-if-there-isnt-enough-time-for-thorough-testing/

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

In software, there is nothing more frustrating than looking at someone else’s code for whatever reason, and having no clue what is going on. There no comments, no classes, no indentations, and ambiguous variables. If I had to bet, I’d say if the original developer had to go back and look at it they would have no idea that is going on, so how can one be expected to use that code for whatever they might need if for or are being asked to do with it. In my opinion, clean code is perhaps the most important aspect of developing software. It is vital if someone ever hopes to use the code for something else again, that the code is written in manner that is easy to read and easy to understand.

I found this blog by Bill Spooner called “10 Ways to Write Cleaner Code”. I found what he had to say to be quite useful and hope to use some of his suggests when writing code myself. Since I have a word limit, I will only discuss the ones I felt I learned the most from and or felt they were important to reiterate. The first one was about naming conventions. Naming conventions can vary from language to language are sometimes simply made up by the developer. Because of this, simply put a comment above the first time you use that type of variable. For example, for constant variables Spooner says, “constant values are in all caps and separated with underscores, not camel-case”. By adding this simple statement, it has been made clear to the user what a constant variable should look like and may have prevent confusion later. It something that only takes and extra second to do, so why not make someone’s life a bit easier. I know I am going to try and do this in the future.

The next couple are ones I just felt should be reiterated. Comments are extremely important. They allow both the original author and a new reader to know what is going on. No matter how clear you feel your code is, include comments explaining what is going on. You’ll regret it if you don’t. Another one he mentions is adding white space. Breaking up your code into logical portions makes it far easier to read than one giant continuous block. Lastly on the reiteration front is to make variable names are clear and descriptive. For example, if you were adding things together, don’t simple call the sum “total”. The total of what? It needs to be clear so it can be refence later.

The last time he mentions I wanted to talk about is a rule of thumb. He suggests automating an action if you find yourself doing that action three or more times. I think that is a pretty good rule to follow. If repetitive code can be prevented, do so as it will save time and be easier to read.

Link:

https://www.codeschool.com/blog/2015/09/29/10-ways-to-write-cleaner-code/

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

The more I continue to browse the various blogs on testing, the more I find myself gravitating to a certain kind of blog. There are many blogs on different kinds of testing, new types of testing, etc., but I find myself often going to help/tips type blogs. I find them to be quite useful, because they are easy to apply to my job. One I found this week was “What To Do When There Isn’t Enough Time To Test?”. Well, that is a very good question, isn’t it? Testing is very important and time is almost always limited. There are deadlines to meet, people to see, and places to go. Time crunches are common for testing and seeing as the course for this blog is about testing, I felt this might be some good “real world” advice.

There are lots of reasons why time be tight when testing. They talk about several reasons why this might happen, all of which I have seen before. The three big ones discussed are a poor time estimating to being with, technical problems, and disagreements between teams. Generally, it is not a good idea to have an aggressive timeline for testing. It often backfires as it is never going to go exactly as expect. I agree that technical problems are often a cause for delays, especially if the product is new and some exploratory trouble shooting is needed. This relates back to making sure you’ve allow for enough time. I’d rather be done early than stuck working nights and weekends to meet a deadline for testing. The third, disagreements, is not very common. And when I do see it, it is often due to a miscommunication more than anything. If there is a disagreement, I’d like to think it would be worked out swiftly and in a professional manner.

The article then goes into how to make sure your team does have enough time to test. The first one mentioned, is making sure you have estimated enough time. This crucial to having a successful testing experience. Now, time estimating relates a lot to what they mentioned following this: know how long the testing has taken in the past, know what the team is capable of, keep track of your progress, etc. Do you know that there is a high probability that a certain aspect of the product is going is going to break? If so, that should be factored it. To me the easiest way to make sure there is enough time to test is to think of the worst-case scenario and make sure you have allotted enough time to complete testing should that situation take place. Granted, often teams do not have the luxury of that much time, so making sure there is enough time to test goes back to having an efficient overall operation with realistic goals and deadlines. Be ambitious, but so ambitious that it comes back to bite you.

This article provided some great advice on how properly schedule testing and is something I will be sure to reference back to time and time again.

Link:

http://www.softwaretestinghelp.com/what-if-there-isnt-enough-time-for-thorough-testing/

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

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.

Link:

https://www.madetech.com/blog/5-software-anti-patterns-i-love-to-hate

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

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.

Link:

http://www.softwaretestinghelp.com/7-qualities-of-highly-effective-testers/

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

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.

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