Intro To Interoperability Testing

As the Fall semester kicks off and I begin to dive into the curriculum of Software QA and Testing I quickly realized how little I actually know and how in depth testing really needs to be. That being said I want to use my blog posts as an opportunity to learn about different types of testing. That lead me to go with the article “A Simple Guide to Interoperability Testing” written by the team over at ThinkSys. I really had no idea what Interoperability Testing was before I read this so I decided to learn. I also liked that it was written in 2017. I know a lot of software topics have remained the same for decades but there’s something refreshing about reading something that has been published more recently.

First off, interoperability testing is a type of non-functional testing. This means it is testing the way a system operates and the readiness of the system. In the most general sense interoperability is how well a system interacts with other systems and applications. A great example provided is a banking application system (seen below) where a user is transferring money. There is data/info exchange on both sides of the transfer without an interruption of functioning to finish the transaction.

Banking Application Interoperability

The testing of the functionality that takes place to allow a fluent interaction between systems is what interoperability testing really is. It ensures end to end functionality between systems based on protocols and standards. The article covers 5 steps to perform this type of testing. They consist of:

  1. Planning/Strategy: Understand each application that will be interacting in the network
  2.  Mapping/Implementing: Each requirement should have appropriate test cases associated. All test plans and test cases are developed.
  3. Execution: Running all test cases and logging and correcting defects. Also retesting and regression testing after patches have been applied.
  4. Evaluate: Determine what the test results mean and ensure you have complete coverage of requirements.
  5. Review: Document and review the testing approach, outline all test cases and practices so further testing can improve on what has been done.

Some of the challenges that can arise with interoperability testing include the wide range of interactions that can take place between systems, testing multiple system environments can be difficult, and root causes of defects can be harder to track with multiple systems involved.

After reading this article I can definitely see the complexity in interoperability testing. Taking an iterative approach seems like it would be the best method because you can use your results each iteration to create better test cases and more coverage. Trying to tackle all the test cases in one execution would be overwhelming and it would be difficult to have close to full coverage. It seems like interoperability testing would need to take place anytime an application is updated as well to make sure the systems that interact with it are still compatible. Now that I have a general understanding of interoperability testing I am certain it will play a role in future jobs and work I do. With today’s technology, it is rare to have a complete standalone application that doesn’t interact with additional systems.

In conclusion I enjoyed this article because it was simple, to the point, and I was able to retain the information.

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

Why Repeatedly Repeating Code is Bad Programming Practice

After a discussion with a friend about the recent eclipse, the subject of the apocalyptic end of the world came up. I was reminded of Y2K, and decided that it may be worth some research, as I was too young at the time to really understand what was truly going on. As a student of computer science, perhaps it would provide me with some important examples of things not to do in my own coding. On a blog post written by Steve Rowe for Microsoft Developer, he shares what he learned from an instructor about the true cause of the Y2K scare, a lack of implementation of the DRY, or the Don’t Repeat Yourself principle. Y2K was caused not by mistakenly representing a four-digit year with too few digits, but by making this error over and over throughout and across multiple files. Unless absolutely necessary, code with identical or near-identical functionality should not be duplicated. Following the DRY principle makes maintaining and repairing code easier and simpler; it is important that those striving to become excellent programmers follow this principle.

While my mistakes are not going to cause the same devastation as the mistakes of the developers that caused the Y2K scare (yet), they have certainly caused me a great deal of frustration while programming for assignments or personal projects. On more than one occasion, I’ve found myself repeatedly trying to remedy a certain piece of code, only to find out later that the error was caused by similar code that was implemented elsewhere. It was this duplicated code that was actually responsible for the error, not the unused or irrelevant piece that I had been wasting time attempting to correct. My failure to follow (or even be aware of) the DRY principle, which I was unfamiliar with before looking over the syllabus for Software Construction, Design and Architecture has resulted in countless hours of wasted time and energy. Any programmer, no matter how good he or she may think they are, could always stand to improve. Not only will following the DRY principle allow your code to be more easily understood by others, it will make writing documentation and performing any maintenance much simpler. Steve Rowe makes an interesting comment before closing his post, stating that, if duplicating code is deemed necessary, “It might not be a bad idea to put a comment in the code to let future maintainers know that there’s similar code elsewhere that they should fix.” If we all attempt to better follow DRY and Rowe’s advice, maybe we can avoid future Y2K-esque scares.

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

Object-Oriented Programming: Encapsulation

I chose a podcast for my first blog post, and the reason for that is because I find podcast the easiest for me to understand and the most interesting. While there are many great blogs, books, articles, etc., sometimes I have a hard time following along and understanding completely what is being said. With podcasts, they are usually less formal and more ‘user friendly’. So the podcast that I thought to start off was with a very simple subject. After we had gone over some words in class a couple weeks ago, I felt like i needed to brush up on the programming terms, i.e why I chose a podcast all about encapsulation for object oriented programming. This podcast consisted of three men, who wanted to get “back to the basics” and get a refresh on the basic fundamentals. Now for a quick summary of what they talked about, it was legitimately all about encapsulation, and how it is portrayed throughout the different languages, specifically java, c# & java-script. They mention in each of these what is it and why it matters. So their basic definition was “Bundling your stuff up that only affects your scope so that people don’t have access to everything you do”. What they meant by that was what does the coder want people to actually see that they can interact with. Then they go in depth of the different kinds. The three main being Public, Private and Protected which is used for both Java & c#. Public is “the process of hiding internal implementation of the coders data and only exposing behaviors and properties that are wanted to interact with the people”. It is available to anyone that links that coders library and is the most open. Private is only available to those particular things that are in the class and are only to be seen by the members of the class that the coder is in. Protected is “anything that is in that particular class or is an inherited subclass of it and can use and access that same variable”. Then they also mentioned Internal, which is part of c#, which are “classes inside one’s assembly, DLL, EXE, etc, and those that can talk to one’s class but nothing else outside”. After explaining all the different kinds, they went on to mention the importance of encapsulation and having global variables is never good. Having global variables mean that
anything can be accessed and modified in any shape or form and many things can go wrong from having them. The importance of encapsulation is really stated and that they not only protect the application, but guarantee certain enter and exit points within it. Lastly, they mention others like protected internal, private protected and seal and encapsulation in java script. Overall, this podcast was a really good start to the many blogs, articles, podcasts, etc. that I will be viewing/ reading and talking about. It was very easy to understand, and the vibe from the podcast was very laxed, which i appreciated a lot. I’m really glad i chose this subject too, because I have always had trouble understanding private, protected and public and the importance of it and it was just one of those subjects that has been overlooked a lot. So, listening to a full hour podcast about it and its functionalities and importance really helped me grasp the concepts. Overall, I am very pleased. 

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.

9/18/2017 — 1st Blog Post CS 343
I thought class diagrams were complex when first introduced, but this blog post breaks it down into simple concepts that are easier to understand. This article has helped me a lot in learning the current course materials on class diagrams. It has helped me to determining and distinguishing the different components in class diagrams and their relationships, which are applicable in object-oriented modeling.
As stated in the article class diagrams are the main building blocks in object-oriented modeling. Their main function is to show the relationship between different objects in the system. This includes their attributes, operations, and relationships among them. Classes in a class diagram are represented as boxes partitioned in three. An example of a class is the loan account with three partitions. The first is the class name, which in this case is loan account. The middle is the class attributes which are the type, accountName, dateReleased, and loanAmount. The last is the method or possible operations associated with the class. The example shows all of the relevant data of a particular object in a systematic and clear way. A class diagram is simply a collection of classes.
Relationships between classes are interrelated through different types of logical connections. The following are the different types:
Association – encompasses just about any logical connection or relationships between classes.
Directed Association – shows directionality with an arrowhead, arrowhead depicts a container-contained directional flow
Reflexive Association – occurs when classes may have multiple functions or responsibilities.
Multiplicity – active logical connection when cardinality of class in relation to another is depicted.
Aggregation – formation of particular class as result of one class being aggregated or built as a connection, directionality is a diamond shape near the parent class to the child class.
Composition – similar to aggregation, difference being emphasizing dependence of contained class to life cycle of container class, directionality line is a diamond shape adjacent to the container class and directionality arrow to the contained class.
Inheritance/Generalization one associated class is a child of another by virtue of assuming same functionality, to show relation a solid single arrowhead is drawn from the child class to the parent class, with the arrowhead unfilled
Realization – shows implementation of functionality defined in one class by another class, relationship is indicated by broken lines.
This article was a overview of class diagrams. I chose it for its simplicity in explaining design concepts. It is worth reading for someone looking for a review and it has helped me a lot in understanding the course materials.

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

WSU Blog #1 for CS443

Blog entry for CS443

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

WSU Blog #1 for CS443

Blog entry for CS443

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Effective Code Reviews

Effective Code Reviews

On my way of finding a podcast for my first assignment, I passed by this podcast about Code Review. I decided to choose it for my first blog entry because it had some interesting opinions about code reviews. By listening to this, I learned about other benefits of code reviews, beside bugs detection and code improvement. Below was the link of the podcast:

In this podcast hosted by Michael Kennedy, Dougal Matthews shared his thoughts and experience about the benefits of code reviews and the elements effective code reviews should have. Dougal gave an interesting scenario that code reviews could save the day. For example, there were two persons, one knew more about C++, one knew more about Python. Even though they might not understand deeply what the other person is doing, they should have a code review with lighter level in case that one of them was ill or left the company. He also brought up one of the reason he thought that many people did not like doing code reviews. They expected bugs detection for their codes, but they usually received code improvement more than bugs for their valid codes. Michael and Dougal also had some interesting ideas for an effective code reviews.

To be honest, I haven’t thought that code reviews could be used as a tool to back-up basic information of a project like Dougal mentioned. Usually, the first thing that came to my mind when hearing code reviews would be bugs detection. But his scenario pointed out a special case, which some small groups might have, that code reviews could help fixing it.

About one of the reasons many people did not like doing code reviews, I understood their feelings when they just wanted to test if their codes had bugs or not, not to re-do the whole project again just because they received a better solution to solve their problems. But I thought that we should be more flexible about that. If we had another solution, which was better than our original one in one or many ways, then we should choose that solution. Beside improving the code, we also gained experience from it. The next time we countered something that was similar, we could jump directly to the better solution and reduce the time we might spend for the worse solutions that we had used before.

I thought that the code review checklist which was mentioned by Michael and Dougal would be very helpful. Like they said, it kept the reviewers and the developers on the same page. This certainly reduced the time everyone spending to ask around the same question about the progress. I also agreed with their idea about having more than one people doing code review for a same project. Different people had different points of view, and people might make mistakes. By having more people involved in the reviewing process, we could increase the quality of the review, and share our knowledge to each other.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.