In this article, Manoj Verma describes (in his own words) “an exhaustive list of factors to consider” in the choice of testing technique.

But let’s back up a bit.

I chose this article to write about (and this topic) because in our work last week we were tasked with testing a small play problem; and shortly after starting I realized that for all of my practice with different testing methods, I didn’t know where to begin.  So when I went to write my weekly blog post, that’s where I looked.

Verma’s list of factors is as follows:

1. Risk assessment — how tolerant to failure is the product?
2. Client requirements — did the client specify a testing technique?
3. Time/budget constraints — how long do we have to test?  How much money can we spend on testing?
4. Industry guidelines — does the product need to fit into some kind of regulation? Which ones?
5. Documentation — does documentation for the product exist?  Does it contain testing history?  Does it contain logical constructions such as decision tables or state graphs?
6. Objective of test — what are we testing for?  What does the product need to do, or need to never do?
7. Software development lifecycle — how is the development process managed?
8. Models used to develop the system — how was the software system built?  Are there logical models that can be adapted into testing techniques or cases?
9. Tester experience — how experienced is the tester?  How accurate is their assessment likely to be?
10. Flexibility — does the devlopment process model involve a lot of flexibility?

Verma also concludes that choosing the right technique “is not child’s play”.  It isn’t easy, and he doesn’t offer hard metrics, but his guidelines serve as a way for me to ask myself a series of questions and discover the method that may work the best.

My search for answers, as it turns out, did not give me any that are truly satisfying.  It led me to more questions.  Software testing in general can be seen as the act of asking questions of both the design and implementation.  It seems natural that software testing techniques and methods should also be subject to questioning; in fact, software testers should subject themselves to similar questions.

So what can I take away from this?  How can it help me move past the brand-new-problem paralysis?  That I should start by asking questions of the problem I’ve been presented with, and of myself and my own testing experience.

Article link.

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

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Factory Design Pattern

To begin exploring Factory design pattern, first of all, we need to know what factories are. Factories are simply functions that create objects and return them. In most cases you can use factories to design to code instead of classes, and they are much simpler and more readable than classes.

Even though classes have a lot of better performance, it is a good idea to use factories unless otherwise you are in a situation that requires you to instantiates many objects.  For example, factories will take averagely 0.0004 milliseconds to create an object in most case while class will take 0.0002 milliseconds to create an object; classes will reduce the time to half way as compare to factories. This comes to matter when you are creating about thousands of classes but when your classes are not that much you will never notice the difference and hence, will not be necessary.

Why do we need factory design pattern?  Now let think of it this way; in our codes, we uses a lot of objects. We have classes that instantiate object from class and we use them in many difference ways. In a strategy pattern, we use dependency injection where we imagine ahead of time what the objects will be doing. But at some point in our programming, that imagination has to be constructed. That is we need to instantiate our objects and the question is, where do we do that? This is what factory pattern try to address. In this regards, we say, when you are about to instantiate, let encapsulate them such that it span uniformly across all places so that you can use factory whenever you want to instantiate and the factory is responsible for instantiating appropriately.

Factory pattern gives you the ability to create objects without specifying the exact class of object that will be created; a class is chosen at run time using polymorphism.

For the matter, one will want to use factory pattern design when a method returns one of several possible classes that share a common super class. It is also a good idea to use factory design pattern to design your code when you do not know ahead of time what class object you will need. It is again useful when all of the potential classes are in the same subclass hierarchy and when you do not want the user to have to know every subclass in your code.

I chose to explore this topic as because I was unable to understand it on the go when we were treating it in class and I also got confused as to which pattern to use for my upcoming project and I decided to write this blog on factory pattern because I am impressed how you can use factories instead of classes to provide a clear code. I am actually redesigning my previous code using the factory pattern and I can figure out that everything looks simple at this point.

Reference: https://airbrake.io/blog/design-patterns/factory

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

The blog that I chose this week was written by Trish Khoo.  She was previously a manager on an engineering team for Google Maps until she decided to leave and return home to Australia.  Her blog post (http://trishkhoo.com/2017/08/yes-all-testers-should-learn-how-to-code/) discusses the need for all testers to be able to effectively know how to code.  I was going through some of her blog posts when this post caught my eye.  I never realized that there was as big of a split as the poll showed that there is.  The Twitter poll showed that 55% of the voters believed that all testers should be learning how to code.  45% felt that is was not necessary.  This shocked me because up until now I was so rooted in the opinion that all testers should know how to code or be learning coding skills that I didn’t realize that it was even possible to be a software tester without having coding skills.  I believe that testers should have coding skills because it will help when writing tests and analyzing code to find the bugs.  If you don’t have coding skills then all you can really do is run pre-written tests and report back if it passed or failed.  With coding skills you can rewrite codes that may improve your test results and productivity.  Also if you are running white-box testing instead of just finding the bugs you can realize what the error is and what caused the failure.  Then while you may not be authorized to change the code at that time it can help you learn more and help advance your career.  Trish Khoo feels the same way and states her suprise that anyone would consider programming not essential in today’s software development workforce.  She has done some research and found that programming is being entered into the school curriculum in Australia, the U.K. and the U.S.  In some places even down to the elementary school level.  In a world that is constantly becoming more computerized and connected I’m glad to see that here in the U.S. we are seeing a basic level of programming as a necessary tool for entering the workforce.  At the end Trish Khoo also gives her reader two sites that are excellent starting points to start learning code.  The resources are both free and easy to navigate with step by step instructions on a wide range of languages and instructions for users of all ages.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Continuing with series of articles written by James Sugrue , taking each design pattern one by one, this week I read about the Adapter pattern.

I liked the real world analogy Sugrue gave for the easy understanding of the Pattern. The example he provided for the adapter pattern is based around AC power adapters. Say we’re visiting Europe from the US, with our laptop, which expects a US power supply. To get our laptop plugged in, we’re going to need to get a power adapter that accepts our US plug and allows it to plug in to the European power outlet. The AC adapter knows how to deal with both sides, acting as a middleman – this is the adapter pattern.

The Adapter is known as a structural pattern, as it’s used to identifying a simple way to realize relationships between entities. The definition of Adapter states: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

The classic diagram definition of the adapter pattern is given below:

The Target interface defines the domain specific interface that the Client used, so the client collaborates with objects that implement the Target interface. On the other side of things, the Adaptee is the existing interface that needs adapting in order for our client to interact with it. The Adapter adapts the Adaptee to the Target interface – in other words, it translates the request from the client to the adaptee.

The main use of this pattern is when a new system wants to interact with legacy system using new interface which is not compatible with interface of legacy system. Moreover, when a class that we need to use doesn’t meet the requirements of an interface. For a particular object to contribute to the Properties view, adapters are used display the objects data. The view itself doesn’t need to know anything about the object the it is displaying properties for.

Some say that the Adapter pattern is just a fix for a badly designed system, which didn’t consider all possibilities. While this is a fair point, it is an important part of a pluggable architecture.  It can also add a level of complexity to our code, making debugging more difficult.

After reading the article, I think in the integration aspects Adapter pattern is a time saver.  I think that the adapter gives a great solution for legacy systems, and it doesn’t imply bad design. Even with a very good design, class which was once created would become a legacy class as more and more clients start using it. So, at one point of time, we might have to use adapters. With that being said, I think it’s true that adapter adds a level of complexity to our code. If there are no proper naming conventions and comments, the code is difficult to follow through. I believe we can minimize the complexity by modularizing the legacy class and adapter in separate files.

Source: https://dzone.com/articles/design-patterns-uncovered-0

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

Today I will be discussing the adapter design pattern. According to a blog by journaldev.com, the adapter pattern is a design that is used to make two unrelated interfaces work together. The example used in the blog by journaldev.com refers to phone chargers and sockets. In this example, a phone battery needs 3V to charge, and the wall socket can either be 120V or 240V. So how do we take either 120V or 240V and convert it to 3V to charge the phone battery? The article suggests using an adapter, which would be the phone charger. In this example, the two interfaces are 120V and 240V, while the adapter interface is the phone charger. I feel it is important to note that according to the article, there are two approaches to the adapter pattern; object adapter and class adapter. The object adapter uses Java composition to adapt and the class adapter uses Java inheritance to adapt. However, the article points out that both approaches will result in the same conclusion. For this article, I want to focus on the class adapter approach.

The class adapter implements a public Class called SocketClassAdapterImp, and it extends the Socket interfaces and implements the SocketAdapter. This Class contains methods to override the different voltages using get() methods, and within the get methods it will convert the voltages supplied to the correct voltage, and return the converted voltage. The test class will check to see if the conversions were done correctly; that being if the test class calls for Volt v3 = getVolt(socketAdapter, 3);, it should return the correct voltage (3).

I chose this article because I wanted to expand on my knowledge of different design patterns, and this one seems to be rather important (especially since I didn’t know anything about it). I learned a lot from this article. I have never run into a situation where I have needed two different interfaces to communicate and work together. I think that this is a great approach, and it seems to be rather simple and straightforward. I learned that in order to “link” two different interfaces together, that all I need to do is create an adapter for them, which will provide some sort of conversion method to satisfy the subclass. I hope to implement this in my future works, should I run into a situation where this is applicable. I definitely think it will save a lot of space, time, and headache.
Here’s the link: https://www.journaldev.com/1487/adapter-design-pattern-java

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.