Category Archives: Week 9

What is Model-Based Testing?

Link to blog: https://blogs.msdn.microsoft.com/specexplorer/2009/10/27/what-is-model-based-testing/

There are many different ways to test software. This blog written by Nico Kicillof defines what model-based testing is and what it is used for.

Model-Based Testing is a lightweight formal method used to validate software systems. It is considered “formal” because it works out of a formal specification or model of the software system. It is “lightweight” since it doesn’t aim at mathematically proving that the implementation matches the specification under all possible circumstances. Here is an image below from the link:

image

(In the image above, Kicillof shows the diagram that illustrates model-based testing in a nutshell.)

The difference from considering a lightweight method from a heavyweight method is that it comes between sufficient confidence vs. complete certainty as Kicillof likes to put it.

The first step of the process is that it is important to know that the method starts off as a set of requirements that could be written from the development team, or you the developer. The next step is to create a readable model that shows all the possible behaviors of a system meeting the requirements that were given to you the developer. Keep the model manageable by creating the right level of abstraction. Kicillof says this because it makes sense to keep a model manageable. If a model isn’t manageable, then it is basically a bad model to use. It would be difficult to make edits or reconfigure your model if you run into a specific type of problem where your model doesn’t clearly highlight how to fix it.

Kicillof gives the example of model based testing through the use of Microsoft Spec Explorer. He explains that in Spec Explorer, models are written as a set of rules in the mainstream language of C# which makes it less difficult to learn in comparison ad-hoc formal languages.

Kicillof’s explanation on how model-based testing works made me understand the concept better than before. The image he provides, just like the one shown above, illustrates the process of model-based testing. The numbers near each part of the process in the image made it easy to follow. I chose this blog because I wanted to know a little more on model-based testing. I wanted to think on how it would be used in my future career of video game development since it is another great way to test software. Depending on what games I’ll be creating in the workplace, knowing model-based testing is important because I think it is an easier formal way of testing in comparison to other types of testing.

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

TS>JS (For Scaling)

Before this class, I had heard of Angular before and had always heard it referred to as a JavaScript framework. I guess technically it is, because it still compiles to JavaScript but the language itself is written in the JavaScript superset, TypeScript. I had never heard of TypeScript before this class and the idea of a superset language was also a new concept. I was curious why Angular was written in TypeScript over JavaScript or other supersets. I know from outside sources that the first iteration of Angular was written in JavaScript but every iteration of the framework since, has been written in TypeScript and I wanted to know why. This post by Victor Savkin lays out the benefits of using TypeScript as a way of explaining why Google chose TypeScript for Angular.

Victor clears up my lack of understanding of what a superset is relatively simply. He explains that being a superset of JavaScript, everything you can do in JavaScript, you can do in TypeScript. With small changes to the code, a “.js” file can be renamed a “.ts” file and compile properly.

Victor emphasizes the lack of scalability in vanilla JavaScript. With JavaScript, large projects are much more difficult to manage for many reasons including the weakly typed aspect and the lack of interfaces. TypeScript solves these problems and helps create better organized code with its syntax. With its better organization, TypeScript is much easier to read through compared to JavaScript.

The lack of interfaces in JavaScript is a major reason why it doesn’t scale well for large projects. Victor uses a code example in JavaScript that shows that aspects of a class can be lost in JavaScript because of its lack of explicitly typed interfaces. The code is then reshown in TypeScript and is much more clear because you can actually see the interface. It’s that simple, in JavaScript, you have to really focus in on how every object interacts with each other because of the lack of explicitly typed interfaces. TypeScript allows you to create these interfaces so future code maintenance is less stressful and bug filled.

TypeScript offers explicit declarations, which is illustrated through some code samples in the article. The JavaScript code is a simple function signature that lacks any typing or clear information about the variables involved in the function. In the TypeScript version, it is clear what the types of the variables are, making the function much more clear in TypeScript.

There are other reasons defined in this article on why TypeScript was chosen and what makes it so great, but these are a few of the ones that stuck out to me. I’ve written JavaScript projects before and wondered how some of these concepts would affect larger projects, and now I know how they can be resolved. This article and information will prove useful for writing my final project and any future TypeScript-based projects that I decide to take on in the future.

Original Post: https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8

 

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Revisiting Polymorphism

This week I found this article on JavaWorld by Jeff Friesen that is entirely about polymorphism. Polymorphism is a core concept for all software development and a lack of strong understand will lead to weak applications and poorly written code. One can never revisit topics like polymorphism too much. This article discussing the four types of polymorphism, upcasting and late binding, abstraction, downcasting, and runtime type identification (RTTI). The article presents everything in the form of a code example and constantly revisits in the explanation process, which I find incredibly useful.

The first part of the article is an overview of the four types of polymorphism, coercion, overloading, parametric and subtype.. Of these four there are some bits that stuck out more to me than others. For coercion the obvious example is when you pass a subclass type to a method’s superclass parameter. At compilation, the subclass object is treated as the superclass to restrict operation. The simple example that is forgotten is when you perform math operations on different “number” data types like int’s and floats. The compiler converts the int’s to float’s for the same reason as the subclass to superclass object. Another piece in this first section that stood out to me was the overloading type of polymorphism. The obvious example here is overloading methods. In a class, you can have different method signatures for the same method name and each will be called depending on the context. Again, there is a simple example that is overlooked in the operators like “+”. For example, this operator can be used to add int’s, float’s, and concatenate Strings depending on the types of the operands.

The upcasting section uses our favorite example, different types of shapes and is almost entirely written in reference to one line of code, Shape s = new Circle(); This upcasts from Circle to Shape. After this happens, the object has no knowledge about the Circle specific methods and only knows about the superclass, Shape methods. When a shared method (implemented in both Shape & Circle), the object is going to use the Shape implementation as well unless it is clear through context to use Circle’s.  Similar to this section that uses superclasses and subclasses, is the section on abstraction. The article uses the Shape and Circle example again but points out that having a draw() method that does something in Shape does not make any sense from a realistic standpoint. Abstraction resolves this, meaning that in an abstract class, there is no way to instantiate a method like draw() for the superclass of Shape. This also means that every abstract superclass needs subclasses to instantiate their behaviors.

These are just a few parts of the article that stood out to me personally. The article as a whole is incredibly useful and worthy of a bookmark by every developer. I will continue to revisit this article if I find myself lacking confidence about the topic of polymorphism in the future!

Original Article: https://www.javaworld.com/article/3033445/learn-java/java-101-polymorphism-in-java.html

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Blog 5

Soft Qual Ass & Test

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

Abstraction

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

Test case Evaluation

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

Determining Which UML Diagram to Use

Link to blog: http://blog.architexa.com/2010/04/determining-which-uml-diagram-to-use/

This blog gives an overview on choosing which type of UML diagram to use when it comes to designing software. Some software designers may encounter a problem where they’re coming to a choice on whether which UML diagram to use that is most efficient for a particular task given to them. I am one of those designers because sometimes, I come to a problem where I can’t decide on which UML diagram I should use.

First, there are 3 classifications of UML diagrams: Behavior diagrams, Interaction diagrams, and Structure diagrams.

Behavior Diagrams: 

These are types of diagrams that show behavioral features of a system. This includes activity, state machine, and use case diagrams. Examples of a behavior diagram would be an Activity Diagram and a Use Case Diagram. The activity diagram shows high-level business processes, including data flow, or to model the logic within the system. To simply put it, behavior diagrams, in general, breaks down processes into individual decisions, loops and chain of events.

Interaction Diagrams: 

Interaction Diagrams are a subset of diagrams which emphasize the interaction of objects. This includes communication, interaction overview, sequence, and timing diagrams. These diagrams fulfill the need of designing a system where there are complex relationships between code elements and provides a view on how the elements interact over time. Examples of interaction diagrams include Collaboration/Communication Diagram, Sequence Diagram, Interaction Diagram, and Time Diagram. 

Structure Diagrams:

Structure Diagrams show elements of a specification that are irrespective of time. This means that the elements are not affected by the nature of time. Examples of structure diagrams include Class Diagrams, Composite Structure Diagrams, Component Diagrams, Deployment Diagrams, Object Diagrams, and Package Diagrams. Structure Diagrams, in short, help break large projects or features into parts and specify which parts do what and how they interact within the system.

I chose this blog because I wanted to know the different types of diagrams within the three classifications of UML diagrams. I was aware of the three classifications of UML diagrams, but I didn’t know certain types within each classification such as the Deployment and Composite Diagrams within the Structure Diagram Classification. The author of the blog briefly highlighted each of the three classifications in detail with links pertaining to each of the example diagrams presented within each classification. This made it easier to understand how each example operated. It is important for me to understand the different classifications and their examples of diagrams because when it comes to programming video games, which would be my future career, I would have to implement and figure which diagram is necessary for each type of game design.

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

Builder Design Pattern

Builder Design Pattern is an example of a creational pattern. Creational design patterns solves the problem/complexity of object creation in a design by somehow controlling the objects creation.

Builder design pattern is used to create objects that are made from a bunch of other objects. You use the builder design pattern when you want to build an object made out of other objects. Use it when you want the creation of these parts to be independent from the parent object. Hide creation of the parts from the client. Only the builder knows the specifics of the object and nobody else.

Intent of Builder design pattern.

  • To separate the construction of a complex object from its parent object so that the same construction process can be created differently in representations.
  • Create one of several targets

In a builder design pattern, we have the “director” which invokes the “builder” services as it interprets the external format. The “builder” then creates the object each time it is called. Then, when the product is finished, the client retrieves the results from the “builder”.

1aa5ab128c99a174fc628835260d7aeb

Example:

Say the client wants a new remote for your TV, but you know that you’ve already made a remote before and the client wants the same thing but calls it the “remoteX”. You can use your old remote object to pass it in a director to create remoteX by passing it to the remote builder without changing anything from the old remote set up.

 

Other Useful things to consider:

  • Builder can use one of the other patterns to implement which components get built. i.e Abstract Factory, Builder, and Prototype can use Singleton for implementation.
  • Builder focuses on constructing the complex object step by step.
  • Builder often builds a Composite.

 

The builder design pattern is really helpful when you are creating objects that are made out of other objects. Just like creating a menu, most menus have a drink, appetizers, and a dessert associated with the meal. You can also use other patterns to implement which components will be built.

I selected this topic because it is one of the main design patterns that is discussed in the Gang Of Four book. It is also pretty simple to understand. The builder design pattern is also a good pattern to have under your belt, since it seems like in the real world we are creating the same objects and upgrading it much more often than creating a new one.

I really think that learning the main or fundamental design patterns is beneficial when creating an application. It just always seem to pop up. Like for our final project, we were thinking of building a class schedule maker, but you can also make the class schedule maker just a regular schedule maker say for appointments or meetings.

 

https://sourcemaking.com/design_patterns/builder

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

FEW HICCUPS

This week i read the blog few hiccups by Michael Bolton which can be found here. This article is about better describing the expectations you have for your code before testing which makes it easier to find problems in the code. Also in the article is identifying and applying oracles. I could not figure out what that meant at first but in an older Michael Bolton article i found the definition to be as follows.An oracle is a principle or mechanism by which we can tell if the software is working according to someone’s criteria; an oracle provides a right answer—according to somebody. That article which is called Testing without a map can be found here.

The article is actually a mnemonic in which the blog is based around. The mnemonic is split into two parts, FEW and HICCUPS. The HICCUPS part of the mnemonic refers to a list of  the authors oracle principles. HICCUPS is designed as follows:

  • History. We expect the present version of the system to be consistent with past versions of it.
  • Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
  • Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
  • Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
  • Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
  • Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
  • Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
  • Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

Each one of these is a criteria that can be used to identify a problem in your code. We have a problem once we realize that the product or system is inconsistent with one or more of these principles. The FEW part of the mnemonic is defined as follows:

Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.

World. We expect the product to be consistent with things that we know about or can observe in the world.

Familiarity. We expect the system to be inconsistent with patterns of familiar problems.

These last 3 oracle specifications were added later on updating the mnemonic from HICCUPS to FEW HICCUPS. The way to remember this given in the article is: When we’re testing, actively seeking problems in a product, it’s because we desire… FEW HICCUPPS.

I stumbled on to this blog by accident while looking at other blogs about testing consistency but i am glad that i did. This was a very interesting read and was not like other blogs that i have read. All the different specification oracles in the article were interesting and each seems to have it’s place. These specifications i think would make you a much more consistent tester by giving you a consistent guideline for finding problems in your code. The mnemonic was my favorite part of the article and not something that i have seen to many times in software testing. This seems like it would be very helpful in memorizing these oracle principles well into the future.This is something i am going to try and remember and use in my testing. Often times it is hard to pick were to start looking for problems in your code , or how to identify those problems. This mnemonic seems like a good way to fix that.

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

Thoughts on “Six Things That Go Wrong With Discussions About Testing”

In this article, James Bach talks about the ways in which conversations about testing skew away from the reality of what it means to actually do software testing, and what it means to be a skilled tester.  As is clear from the title, he divides this broad topic into six smaller pieces:

  1. Size doesn’t matter.  The number of test cases that you run is not a meaningful number, just like the number of lines of code in a project is not meaningful.  What matters is what they cover and what they can teach us.
  2. Tests are performances.  It’s an activity, not an object.  The person implementing test cases is more important than the cases themselves.
  3. Testing strategy needs to evolve.  Testing is a process of constant interrogation (I’ve written about this before in response to other articles) of both the code and the tester.
  4. Automation does not define testing.  Automation is a tool with which to run tests.  It takes human judgment and skill to design and implement quality tests.  Automation is a way to do a lot, but it takes a tester’s skills to do a lot with as little as possible.
  5. There are many kinds of test coverage.  No one type of coverage is truly comprehensive, and making changes to tests to give additional coverage by one metric may change what is covered by another metric.
  6. Testing is not static.  It’s an activity that’s fundamentally about learning.  Some things are predictable, but many things are not.  Testing is essetially formulating and then running experiments.  Much can be gained by deviation from established procedures.

The biggest takeaway for me from this article is the notion of testing as design and execution of experiments.  It’s not something I’d ever really thought about before, and it makes a lot of sense.  Testing is the process of formulating a hypothesis (these inputs in this context should result in this output) and then trying it out to see whether it’s right.  It even involves fairly thorough hypothesis testing, so that we can claim with confidence that a particular outcome of use is guaranteed (or close enough).

This article is also a discussion of the ways in which one can have a useful conversation about testing, and the ways in which those conversations can turn useless.  I think this is important to take away too, when I’m looking for jobs in the software development field.  I want to avoid making conversational mistakes in interviews by going down the wrong path, and I also may want to avoid working at a company where those conversational mistakes are part of the corporate culture.

article link

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