As we are heading into our discussion of Decision-Table-Based Testing, I thought it would be a good idea to get some insight on what it’s all about and what its relevance is in the field of software testing.  Interestingly enough, I found an article about it on the International Software Testing Qualifications Board (ISTQB) website.  To become a certified member of the board, one must be knowledgeable in the use of Decision-table based testing techniques.  As I head toward graduation, I am always pleased to know when the material being covered in class is relevant and useful in the industry.

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

In his article “Deeper Testing (3): Testability”, Michael Bolton defines the testability of a product not only in terms of how it can be manipulated (although that’s one of his categories), but as “a set of relationships between the product, the team, the tester, and the context in which the product is being developed and maintained”.  He breaks this into five somewhat overlapping regions:

• Epistemic testability — how we, as testers and developers, find the “unknown unknowns” related to the product.
• Value-related testability — understanding the goals of everyone with a stake in the product and what they intend to get out of it.
• Intrinsic testability — designing a product to facilitate easier and more meaningful testing.  This includes the ability to manipulate and view the product and its environment.
• Project-related testability — how the testing team is supported by and supports other teams or team members attached to the product.
• Subjective testability — the skills of the tester or testers.

Bolton then details how he thinks a tester on an agile team should operate: by bringing up and advocating for the testability of the product, and trying to keep the growth rate of the product sustainable in relation to testing.

As I learn more in the course, I find it increasingly important to understand not just how we test, but why and in what context.  Bolton’s article is especially helpful in understanding the context, and that is why I chose to write about it.  The article highlights aspects of the environment that surrounds a product, and the ways that those aspects contribute to or detract from the feasability of testing.  It also speaks to a tester’s role in an agile team, which is in practical terms useful to know about as many companies use some form of agile development.

With any resource I find in relation to my coursework, I look at what I can take away and what I can apply in my life (sometimes not limited to software development or computer science).  This piece gives me a better understanding of how to begin testing a product — not by writing test cases, or even determining the optimal testing tools to use, but by looking at the bigger picture.  I need to ask myself what I don’t know about the product, how it is going to be used, how it can be designed (or was designed) to facilitate testing, how I as a tester can and should engage other team members, and what skills I have that can make testing easier or what skills I need to hone that I don’t already possess.

Article link. 

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

I know many of you know much about Object Oriented programming. But still yet i wanted to give more details about it. To give you the real explanation of Object Oriented Programming  as being one of the main reason of choosing this topic.

Object-oriented programming (OOP) refers to a type of computer programming  in which programmers define not only the data type of a data structure , but also the types of operations functions that can be applied to the data structure.

Now in an object-oriented language, this program would instead be split apart into self-contained objects, almost like having several mini programs. Each object is representing a different part of the application and each object contains its own data and its own logic and they communicate between themselves. Now if that sounds like it could be a little bit confusing, the idea here is that these objects represent the way you would talk and think about the actual problem.

It’s meant to make thinking about your program easier. The objects don’t represent mysterious abstract ideas. They first represent things like employees, images, bank accounts, player objects, car objects, whatever actually exists in your program. So object orientation is an idea and it’s an idea that it’s supported in many languages. And for you it’s a shift to thinking about the objects in your program are not just the process. And while object-oriented programming can bring a lot of jargon into the table, there are really only a couple of terms we need to be comfortable with to move forward with it.

The first two terms we need to understand is the difference between a class and an object. And these two terms go hand in hand with object-oriented languages. A class is a blueprint. It’s an idea, it’s a description, it’s a definition. It describes what something is, but it isn’t the thing itself. It’s a well-defined idea, like say a blueprint for house. And classes will exist for different parts of your program. So if you are writing a restaurant review website, you might create classes that represent a restaurant and a review or a user.

Classes could also represent visual parts of your program, things like TextBox and Button and Window. And they can also represent invisible things like dates and times and anything that can be a well-defined idea. A lot of languages come with many classes already defined, even advanced things like VideoPlayer classes, and you can also define your own. Now all classes describe and define two things: Attributes and Behavior.

What are some things characteristics, its attributes, and what can it do, what’s its behavior. So in this case, let’s say we are describing a class to describe a person. We might say that the person attributes are name, height, weight, gender, and age, whereas the person’s behavior is walk, run, jump, speak, sleep. Think about it this way that the attributes are really your data, your variables. And the behavior is what can you do, your functions. And actually attributes and behavior in most object-oriented languages are actually described with other names, which is properties and methods.

These are the most common ways of describing these. But the class is describing these things in abstract. And what I mean by that is it says that a person has a name and it has a height, but it doesn’t say what the name is because the class is just the description of something. But just like there’s no point creating a blueprint if you never intend to make a house, there’s no point defining a class unless you’re going to make an object. So that’s the relationship between the two.

The class is the idea and the object is the thing itself. We create objects based on the class like creating a house based on the blueprint. Not only that, but you can create multiple objects based on one class in the same way you could create multiple houses based on one single blueprint. Now while there is a lot of jargon associated with object orientation, encapsulation is the key idea.

This the idea that classes are self- contained units that represent both the data and the code that works on that data, that we take our properties and our methods and we box them up, we encapsulate them. JavaScript is an object-oriented language. Although it is quite casual with it, there are some other languages where object orientation is very formal and you can do very little without thinking deeplyabout classes and objects. So while some languages like C are not at all object-oriented, if you’re working in Java, you can’t avoid object orientation in most modern programming languages.

From this topic i have learned a lot about Object Oriented Programming. , understand the difference between classes and objects.This will help me better understand any project given to me in java. I know now most of you have gotten the understanding of Object Oriented Programming.

Link to the site ::

https://www.edureka.co/blog/object-oriented-programming/

And

https://www.lynda.com/JavaScript-tutorials/Foundations-of-Programming-Fundamentals/83603-2.html?utm_medium=viral&utm_source=youtube&utm_campaign=videoupload-83603-1201

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

http://truptijethva.blogspot.com/2010/05/how-to-perform-decision-table-testing.html
This week we focus on decision table testing. Decision table testing is a black box testing technique, which, contrary to boundary value testing and EC class testing which tests for individual input conditions, tests for combinations of conditions. A more formal definition is that it is a table, which displays combinations of inputs and/or causes along with the associated outputs or actions. It is helpful for designing test cases. The advantage is that it ensures full coverage.
This blog post provides an example of decision table testing which takes us away from the common approach of using true or false as conditions. So, it gives a different perspective, demonstrating the versatility of the method compared to the other test methods mentioned before, which was boundary value testing and EC testing. The example is that with stub for flyer member and whether they are traveling in the business class or the economics class. The table rules uses yes and no, which is equivalent to true and false for the flyer member conditions, but business or economics class for the class condition. This shows that the conditions of whether the member is in the business or economics class can be collapsed into one condition, which is the class condition, instead of in two which would have been for example the business class and the economics class. This shows that the conditions from the assignments in class can be collapsed as well instead of creating equivalent classes which would make the rule counts more accurate and it would lessen the counts significantly as well.

For the stubs column the conditions are: for conditions we have flyer member and class. For actions we have upgrade to first and upgrade to business.

The rules are the following:
1. flyer member yes, class business, upgrade to first yes, and upgrade to business irrelevant.
2. flyer member yes, class economics, upgrade to first no, and upgrade to business yes.
3. flyer member no, class business, upgrade to first no, and upgrade to business irrelevant.
4. flyer member no, class economics, upgrade to first no, and upgrade to business no.

The question to ask is which rules follows these two test cases.
testcase1: Frequent flyer member, traveling in business class
testcase2: non-member, traveling in economics class

Matching the test conditions with the conditions and actions for the rules column, we have rules 1 and 4. This states that for testcase1 the following actions should apply: upgrade to first yes, upgrade to business irrelevant.
For testcase2 the following actions should apply: upgrade to first no, and upgrade to business no.

I chose this blog post because it is coming from a test lead in the software engineering field. So, this is an example of a real world application of decision table testing in software development. It gives an interesting perspective that decision tables can have conditions outside of the normal norm of yes or no and true or false and still provides to conditions of business and economics. This raises the question of whether or not a condition can have more than 2 variables in testing or is it more convenient to break up the solution into multiple conditions. In the latter case, this would increase the rule count. In the first case, it is using more than 2 variables in a single condition. The answer to this question probably depends on experiences with testing. But, it raises an interesting blog post topic of the advantages and disadvantages of breaking up conditions away from its normal norm of true and false. I chose this post because it gives a different perspective on decision table testing and raises some interesting questions on the topic about breaking up the conditions or not.

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

http://javarevisited.blogspot.com/2011/03/10-interview-questions-on-singleton.html
The topic for this week is on singleton patterns, but specifically for real world applications, on common interview questions that could catch any undergraduate students.
Let’s start with an introduction. Singleton pattern is a software design pattern that restricts class instantiations to one object, which implies that it restricts the class to global variables that can be accessed and changed anywhere in the code. Thus, the critics calls it an anti-pattern. Critics argues that it is overused in too many places where it is not beneficial. It introduces unnecessary restrictions where one single instantiation is not required, and it introduces global variables into the application. Thus, singleton patterns complicates the code. So, why is it useful? In Java, singleton design patterns are the most common patterns a software developer will see. It is heavily used in core Java libraries.
The article introduces 10 common interview questions and answers on singleton patterns in Java. I chose it because doing well on technical interviews is one of the most crucial aspect to landing a great career in this industry. This blog post is a learning step that any undergraduate students can reflect upon. We will only list 5 here, however.
The 1st question is the obvious: What is Singleton class? Have you used Singleton before?
The answer is the following: As stated above, Singleton is a class with only one instance. It provides global variables that are instantiated only once and can be accessed through the getInstance() method. The advantage is that it saves memory from having to instantiate the objects every time. Have I used singleton before? My background is mostly data analytics for the sciences. So, no.
The next question is: Which classes are candidates of Singleton? Which kind of class do you make Singleton in Java?
The author of this blog post commented that this is used to check whether or not the candidate has enough experiences with singleton usage or not. Are the candidates familiar with the advantages and disadvantages of singleton in Java?
The answer is the following: Any classes that would be available to the whole application and hold only one instance. An example is the Runtime class, since only one runtime environment is possible. Another is the utility classes like Popup.
The final question is, can you write code for getInstance() method of a Singleton class in Java? This tests the programmer’s ability to understand the code as well as the concept, since there can be many follow-up questions about the code that the candidate had written.
The answer is to not write the code with double checked locking until asked, since it is more complicated. Therefore, the chances of errors are greater. However, for more experienced programmers with deeper knowledge of double checked locking, volatile variable, and lazy loading, why not?
I chose this post as a reflection on interview questions that I could come across in the workplace. One of the most interesting questions I have been asked is what happens to a particle whose speed exceeds or reaches the speed of light. However, even in technical interviews for software development, I have never been asked questions about singleton patterns. So, this blog post was out of curiosity of the different interview questions that I could come across on singleton patterns in the workplace.

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

Multiton Patterns Explained

The article I chose this week explains a lot about the multiton design pattern which is very similar to the idea of the singleton pattern. It limits the number of instances a class can have by using a specific key for each instance and only one object can be made from that key. It uses a similar format to hash tables where there are values connected to specific keys. To be more specific, when an object is requested a key is passed to a static key generator method. If that key is brand new and never used before then the new object is instantiated and is returned after being linked to the key in memory. However, if that key has been used before than it will return the object that is already paired to that key. The article explains singleton as well by explaining that it ensures a class allows only one object to be created if there is only one access point. The key difference between the two being that singletons deal with one at a time while multiton allows the use of a map of named instances. The article then explains the design pattern using UML diagrams and specific examples.

I chose this article because we talk a lot about instantiation in class which is easier to digest as it involves simpler object-oriented ideas but these design patterns seemed a bit more complicated to me. The parallel this article drew to hash tables helped show off the similarities the system used with the concept of memory allocation. The content of this resource was quite dense as it was a lot of simple concepts woven together to create an intricate design which was difficult to understand at first. The first time I read the article, I didn’t understand any of it but after quite a few minutes it started to come together. The use of graphs and UML diagrams within the article helped with the basic understanding of what was happening to the objects. They also helped me learn the concept that a multiton pattern is essentially a group of singleton patterns all on a single map. This material affected me by explaining how multiton patterns work and how it uses instances of objects to create a key-object relationship. This all ties back to class where we will be learning about complicated patterns such as the multiton and singleton design patterns. These patterns will affect my future practice by helping my exposure to patterns and new ideas as this is my first time really dealing with patterns.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

http://marxsoftware.blogspot.com/2013/10/too-many-parameters-in-java-3-builder-pattern.html

This blog post details a way to reduce the number of parameters required for a constructor: the builder design pattern. In this pattern an object called a builder receives each parameter step by step and returns the resulting constructed object at once. This blog post explains the pattern by using detailed code examples. First a Person class is shown without the builder pattern to demonstrate how too many parameters in a constructor can become a problem. Then a PersonBuilder class is shown which conveys the idea behind a builder class. Each variable is set in a setter method, then a createPerson method returns a new Person with the values from the setter methods as parameters. With this implementation, the values of a Person are set with methods as opposed to the parameters of the Person constructor. There is a lot more code, but it is much more readable than having a very large parameter list. The next few code examples show how a builder class can be nested and enhanced with the use of custom types and parameter objects.

The biggest advantages of the builder pattern are usability and readability.  Parameters are reduced and are provided in easy to read method calls. This approach also lets you acquire an object in a single statement and state. Also, it is even easier to apply an IDE’s code completion feature. The biggest drawback is that the number of lines of code are essentially doubled. Despite the fact that it is easier to read, the code is much more verbose. The author included examples of client code instantiating a Person with and without builders, which I thought was a good way to highlight the difference using a builder makes.

Instantiating with builders:

final Person person1 = new Person.PersonBuilder(
   new FullName.FullNameBuilder(
      new Name("Dynamite"), new Name("Napoleon")).createFullName(),
   new Address.AddressBuilder(
      new City("Preston"), State.ID).createAddress()).createPerson();

Without:

final person = new Person("Coltrane", "Rosco", "Purvis", null, "Hazzard", "Georgia", false, true, true);

As you can see, the builder implementation is extremely verbose but it is easier to read and harder to make a mistake. The more parameters there are, the more true this is.

I selected this blog after looking up design patterns in the gang of four book that we haven’t covered in class. I thought this blog did a good job explaining why this pattern would be used and the benefits and drawbacks of using it. I chose this topic because design patterns are one of the most useful things to learn as a software developer and if we end up covering this one in class I will be well prepared. I will definitely be applying what I’ve learned from this blog, as I’m sure every programmer knows how frustrating long parameter lists can be. I’m glad that now I know a design pattern that alleviates this problem.

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