The Testing Automation Pyramid (sometimes just called the “Testing Pyramid”) is an Agile methodology that involves a heavy reliance on Unit Tests as opposed to UI-based testing. It’s referred to as a “pyramid” because the width of the layers in the pyramid refers to the ideal number of tests per layer. The bottom, widest layer is Unit Testing, the middle layer consists of service-related tests, and the tip of the pyramid represents UI Tests. A picture of the structure is shown below, sourced from Martin Fowler’s blog.

Moving up the pyramid, the type of testing done costs more resources to execute and more time to assess.

Part of the reason why UI testing takes significantly more resources is because it involves interacting with and logging the operations of the interface in order to see where something may go wrong. Running through the operations of the UI to see where it breaks takes a very long time, as there are so many levels of abstraction between the UI and the underlying infrastructure, and so much functionality within User Interfaces. On top of this, as the product is updated and refactored, tests derived from the original UI interface becomes obsolete, making the lifespan of higher-level tests shorter than those aimed towards the low-level structure of the system.

This is why Unit Tests are so good. They’re a cheaper (in terms of both resources and time) alternative, and they provide a means of testing the actual root of the issue. Unit Tests are preventative and they ensure that a bug presenting itself in the UI level stays fixed, rather than allowing the bug to manifest itself in a variety of different ways.

There is quite a bit of criticism of this model, as if it goes unchecked it ends up as the so called “Ice Cream Cone” anti-pattern, where a small layer of exploratory manual testing above the UI testing layer ends up becoming mandatory manual testing, which becomes both a resource and a time sink. This is far better explained by viewing Alister Scott’s blog post on it over at his blog, WatirMelon.

Martin Fowler, whose blog I found this concept on and referenced earlier, summed it all up in a pretty wonderful way: “If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test.” Martin’s blog post elaborates on the idea much better than I’m able to, and his blog is extremely readable and has really great content. I’ll definitely be using it as a resource in the future.

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

http://thetesteye.com/blog/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

This week I read the introductory blog post from The Test Eye, written by Martin Jansson in 2017 as a description of the authors goals and intentions as he writes further posts. In the post linked above, Jansson describes the pros and cons to agile frameworks in his opinion as a professional tester.

Firstly, Jansson states that a main advantage in an agile organization is that no single person bears the blame for the overall quality of the final product, if it happens to fail or come short of expectations. It takes a team where the result is everybody contributing their own level of effort into the project, which is a very good concept for a team building environment. However, Jansson believes there can still be improvements within the framework.

Jansson expresses that these frameworks are meant to be altered and changed dynamically to fit the specific situation appropriately. If the agile transformation is followed exactly, there will be circumstances where it will fail since they have limitations, so its important to be flexible in that way with this kind of environment.

He continues by explaining that coaching in an agile organization also proves difficult fundamentally, since no one person can be an expert in all necessary fields. Rather, its more efficient for this expertise to come from within each department to guide implementation. This approach is supported by the fundamental concepts of an agile framework, where change and improvement over time are stressed.

Jansson then critically assesses the inclusion of testing in frameworks such as SAFe. He believes they could improve by including more various testing material, since currently there isn’t much of any content about testing. He also shares that testing is undervalued currently and is misrepresented as something “everyone is expected to work with.”

Although he has these criticisms, Jansson still admires many good ideas and material laced throughout the frameworks. His goal is to suggest improvements and adjust them as agile transformation continues into the future. I will continue to follow these posts since the writing style is interesting and informative, I suggest to The Test Eye to anybody who hasn’t heard of it already.

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

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

I was looking for information about REST API (Representational State Transfer), I came across on this blog “How to design a REST API”. I found this blog to be useful, simple and has examples include. The blog and Quick Reference Card divided into 4 main sections.

First section is general concept, one of the main goals of API should be able to reach out to as many developers as possible. That mean API needs to be self-describing and simple. In security, how important is Oauth to manage Authorization, that being used by many companies. Which use the token system, without showing the real Authorization. API domain names are also important that need to be clear and straightforward.

Second is URIs, RESTful API use different approach using concrete names and not action verbs. API needs to have case consistency and plurals to make the structure clear. Versioning should be mandatory in the URL. Crud-like operations explain how HTTP Verb uses (GET, POST, PUT, DELETE) as CRUD action (READ, CREATE, UPDATE/CREATE, DELETE) with examples.

Third section is about query strings, combined API design such as filters, pagination, partial responses and sort to give query better result, also to optimize bandwidth. We can use a range query parameter. API response should contain Link, Content-Range, Accept-Range.

Finally, the Status Codes, developers will come across this. We need to return error for common case, which everybody understands. The HTTP return codes is which highly recommended for this. First case is success, which mean the API accepted the request. Second is client error, when client requests but API couldn’t accept, reasons such as 401 Unauthorized, 405 Method Not Allowed … There also Server Error, where the request is correct, but a problem occurred on the server. System will return as Status 500 Internal Server Error. This return is somewhat common, the client cannot do anything about that.

I like this summary of practices, its cover a large amount of good detailed references. The Quick Reference Card is clear and always have good examples next to it. I find that much easier to understand, since they use examples from popular sites such as Google, Facebook, Twitter. Everyone is familiar with those companies and based on the instruction, that make the examples are more reliable.

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

As I take another step towards my journey in software C.D.A. I dive into Software Architecture and its importance and benefits. For this weeks blog I found a blog named “15 BENEFITS OF SOFTWARE ARCHITECTURE” by  Ekaterina Novoseltseva. This blog talks about the benefits of software architecture. I will sum the main points of that blog and what I’ve learned from it.

What is something new I learned from this blog?

From reading the blog “15 benefit of software architecture” I have learned the 15 reason why having software architecture is important. I have also learned that not only its important in a sense it can be considered as the foundation for having a strong software program.

What is Software Architecture? 

The idea of software architecture is that it is considered to be the blueprint for building a software program. Usually the software architecture is the step where deciding what design would be implemented on the software and what each team member would be implementing to the program. “Architecture is an artifact for early analysis to make sure that a design approach will yield an acceptable system. Software architecture dictates technical standards, including software coding standards, tools, and platforms.” as stated by Ekaterina Novoseltseva blog.

The following are the 15 Benefits of Software Architecture:

1. “Solid foundation” – when creating a program or project having a solid foundation is part of the Software Architecture.
2. “Makes your platform scalable.”
3. “Increase performance of the platform”
4. “Reduces cost and avoids code duplicity”
5. “Implement a vision” – where a software architecture provides the big picture.
6. “Cost saving” – helps point out areas where money can be saved within a project.
7. “Code maintainability” – helps programmers be able to maintain the code within a project.
8. “Enable quicker changes” – able to change program at a fast past as what the program must do changes.
9. “Increase quality of the platform” – making the software quality incredibility better.
10. “Helps manage complexity”
11. “Makes the platform faster.
12. “Higher adaptability”
13. “Risk management” – helps reduce the risk or chances of failure.
14. “Reduces development time.”
15. “Prioritize conflicting goals”

The list above is the benefits to software architecture. Through the benefits we can see the importance of software architecture. Reading this blog has made me realize that software architecture is a very important step when developing a software system/program. This has been YessyMer in the World Of Computer Science, until next time. Thank you for your time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Nowadays, Unified Modeling Language has made it easier to describe the software systems, business systems, and any other systems. Their graphics show an explanation with words and pictures also, which proves that UML is practical and anybody should be able to use it. UML first appeared in 1997 and its content is controlled by the Object Management Group. The primary contributors to UML are Grady Booch, James Rumbaugh, and Ivor Jacobson.

UML Basic Notation

Why UML?

UML has been able to unify the terminology and different notations, which leads to a great communication between all parties, on different departments of any company. It is also much easier for co-workers to get access or transfer information, while they are working on the same project. UML seems to be a very powerful modeling language, which makes it perfect to use, even for small projects. Stereotypes can extend its functionality if it is not sufficient for some kind of projects. UML did not come from anywhere, it started from real-world problems with existing modeling language that needed modification or transformation. This is why it is widely supported because it guarantees usability and functionality, based on real-life problems.

UML 2.0 defines 13 different types of diagrams, where each of them may be expressed with different details. They are classified into three categories: Structural diagrams, The Behavioral Diagrams, and The Interaction Diagrams.

–          The Structural Diagrams represent elements that are static in nature and they can be fundamental to the UML modeling of a system. This contains:

The Class diagram, The Component diagram, The Composite Structure diagram, The Deployment diagram, The Object diagram, The Package diagram.

–          The Behavioral Diagrams represent the modeling of how the system functions. This contains:

Use Case Diagram, Activity Diagram, State Machine Diagram.

–          The Interaction Diagrams represent how the flow of data and control work on the modeling system. This contains:

Communication Diagram, Sequence Diagram, UML Timing Diagram, Interaction Overview Diagram,

As a conclusion, the Unified Modeling Language is an internationally accepted standard that is used for Object-Oriented Modeling and can be used to represent a model that adopts the best software architecture practices.

References:

https://commons.wikimedia.org/wiki/Unified_Modeling_Language

https://en.wikipedia.org/wiki/Unified_Modeling_Language

https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

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

http://blog.qatestlab.com/2011/03/01/difference-between-white-box-black-box-and-gray-box-testing/

          I found an interesting bog post this week that talked about the differences between White Box, Black Box, and Gray Box Testing. It started with black box testing by explaining that it is an approach where the tester has no access to the source code or any part of the internal software. The basic goal of this testing type is to make sure that inputs and outputs work from the point of view of a normal user. The blog goes on to talk about the main features of this testing type by explaining that the test design is based on the software specification and detects anything from GUI errors to control flow errors. It is a short prep test which helps make the whole process much faster but lacks the needed detail to test individual parts of the software. The blog goes on to talk about white box testing which allows the tester to have access to the source code. This testing allows the tester to know which line of code corresponds with which functionality. This allows more detail for individual tests on code functionality. It allows more detailed testing with the ability to anticipate potential problems but takes more time and can be complex/expensive. As for grey box testing, the blog explains that it is an approach where testers only have a partial understanding of the internal structure. The advantages and disadvantages of this technique are incorporated from the related white and black box testing.

       I chose this article because I remember that we learned about this subject in the beginning of the year. I wanted a better knowledge about the advantages and disadvantages which is what sparked my initial curiosity. I found that this content was really interesting because it explains how testing can be when dealing with different amounts of access to data. I enjoyed how the post explained the types of testing sequentially while also explain how they can be different from each other. I was able to grasp an understanding of these testing types while also understanding the importance and vital role that they play depending on the situation. The most interesting part of the blog post was the grey box testing because it combines the aspects of black and white box testing. It also deals with regression testing and matrix testing which are very important when testing code bits of code at a time. I found that the diagrams used in the post allowed an easier flow to the readings which helped me understand it better. I found the blog to be a great source that summarized and simplified the detailed ideas within the post.

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

Visitor Design Pattern

For this week’s blogpost I will be discussing another design pattern, this time I will talk about the Visitor Design Pattern discussed on Source Making’s website. Essentially the Visitor design pattern allows you to add methods to classes of different types without much altering to those classes. Allowing you to make completely different methods depending on the class used. Because of this you can also define external classes that can then extend other classes without majorly editing them.   Its primary focus is to abstract functionality that can be applied to an aggregate hierarchy of element objects. This promotes designing lightweight element classes due to the processing functionality being removed from the list of their responsibilities. New functionality can be added later easily by creating a new Visitor subclass. The implementation of Visitor beings when you create a visitor class hierarchy that defines a pure virtual visit() method in the abstract base class for each of the concrete derived classes in the aggregated node hierarchy. Form here each visit() method accepts a single argument – a pointer or reference to an original Element derived class. In short, each operation to be supported is modelled with a concrete derived class of the visitor hierarchy. Adding a single pure virtual accept() method to the base class of the Element hierarchy allows accept() to be defined to receive a single argument. The accept method also causes flow of control to find the correct Element subclasses, once a visit method is involved the flow of control is vectored to the correct Visitor subclass. The website listed below goes into much more detail into what exactly happens but here I summed it up so that most should be able to follow. But essentially the visitor pattern makes adding new operations easy, simply add a new Visitor derived class but if subclasses are not stable keeping everything in sync can be a bit of a struggle.

Example of Visitor Design Pattern

The example they use in the article is that based around the operation of a taxi company. When somebody calls a taxi company (literally accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi, the customer, or Visitor, is no longer in control of his or own transportation but the taxi driver is.

All in all, I thought this website was really good at explaining what the Visitor Design Pattern is. I have used this website before for previous research into design patterns and more.

https://sourcemaking.com/design_patterns/visitor

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

Good day my dear reader! With it being quite deep in the semester now, one can correctly assume that I have learned quite a bit regarding Software Design and I have. With all this new information, I read an article that has helped me put all of it in perspective. This article was Simplicity in Software Design: KISS, YAGNI, and Occam’s Razor from the Effective Software Design blog.

This particular blog post is all about keeping your software design simple and details three different design principles to keep in mind while designing software and the effects of making a design too complex and conversely too simplistic.

The first principle is, “Keep it simple, stupid” more commonly known as KISS heralding that keeping designs simpler is a key to a successful design.

“The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”

The next principle is, “You Aren’t Gonna Need It” or YAGNI stating that functionality should be added only when it is actually needed and not before.

The last principle is Occam’s Razor, saying that when creating a design, we should avoid basing our designs in our own assumptions.

Not following these principles can result in complex designs that lead to feature creep, software bloat, and over-engineering. It could alternatively result in oversimplification where the design is too simplistic. This could lead to trouble down the line in areas such as maintainability, extensibility, and reusability.

Reading this blog post, made me sit back and think about my previous programming assignments. Looking back, my programs have been indeed, overly complex. A great quote provided in the blog post is from Brian Kernighan.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

This gave me a good chuckle and is something I can definitely agree with and have done in the past. I will admit, that I had never considered the consequences of oversimplification. When the majority of your programs are single use for a specific scenario, you never really have to consider the consequences outside of getting the program done. An excellent quote provided by the author in the blog is from Albert Einstein.

“Keep it simple, as simple as possible, but not simpler.”

I completely agree with the author here that this quote expresses the danger of simplistic design that must be considered. It is easier to make things too simplistic rather than hitting the sweet spot of as simple as it needs to be.

This article will be one that I intend to keep in mind whenever I sit down to start a new programming project, especially as class projects start to roll up this time of the semester and I do believe that simple software design will greatly improve any designs that I come up with, keeping KISS, YAGNI, and Occam’s Razor in mind.

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.