Skip to main content

Spending Testing Time Effectively

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

Comments

Popular posts from this blog

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/ In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject. Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out.  The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at

Facade Design Pattern

For this week’s blog on Software Architecture and Design, I will revisit the same assignment that I have blogged about before. For the assignment, I had the option between three design patterns to write a tutorial for. I picked the proxy design pattern, and then I blogged about the decorator design pattern. Now, I would like to watch a tutorial on the third design pattern, facade, so that I might learn about all three. I chose to use the same YouTube, Derek Banas, that I used before for the other blog. I found his videos engaging and informative that I would like to learn about it again. I also like that it is fairly concise (11.5 min), which makes it much easier to rewatch sections that I don’t get the first time around.  It turns out that I did not understand it after finishing Derek’s video, so I turned to another video by another Youtube channel by Christopher Okhravi. Derek went straight into coding, whereas Christopher just drew diagrams and did not code. I needed more

Decorator Design Pattern

For this week's blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn't pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I'm going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won't be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post. The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas). Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has th