Testing & Agile

For this week’s blog post, I decided to find a blog post on a topic that we haven’t explicitly covered in class. I found an article on Agile Testing and my interest in Agile as a whole drew me in. This article is on QASymphony and breaks down what Agile methodology is, some examples of Agile testing, and how to align testing with the Agile delivery process. For the sake of this post, I will assume you’re familiar with the general concept of the Agile methodology for software development, hopefully you understand the general concept of Scrum and Kanban.

One of the interesting testing strategies for Agile development is the Behavior Driven Development tests (BDD). These tests are similar to the Test Driven Development (TDD) style testing systems in traditional waterfall development cycles. They are basically a replacement. Instead of writing unit tests before code is written, the BDD tests are on a much higher level. This is how user stories are written. The development of the code is based on end-user behavior and the tests need to be readable for those who might not be particularly technical as they can often replace requirement documentation. This saves time in the long run as there is no duplication of the process for those who might not be able to read user tests in the traditional TDD style of testing. The best part about BDD testing is that the tests do not necessarily need to be written by technical team members. These can, and are often written with input from business partners, scrum masters, and product owners who might not necessarily be able to contribute when it comes to writing unit tests in the TDD format. This style also allows for testing small snippets of functionality like TDD so that one aspect of TDD that is somewhat Agile remains intact for BDD testing.

After reading through the other testing strategies and how to align testing with the Agile methodology, I realized that I’ve already been working in systems that operate like this at my summer internships. We operated our testing in a format pretty much identical to the concept of BDD where everyone in the team contributed to the different testing obstacles and even came up with test cases that would need to pass by code that was written afterwards. And like the article says, it was common for not all of the tests to pass immediately, and this is part of the concept of “failing fast” that Agile is all about. I am glad I found this article to give me more insight to how businesses around the world, including the ones I interned at, are converting to Agile and utilizing these testing strategies if they haven’t already.

Link to original article: https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Journey into Software Architecture and Its Benefits

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.

Unified Modeling Language (UML)

curso-de-uml-2-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

notation_class

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.

Post #6: Quality Code Response

Hello and welcome back to Benderson’s Blog with me, Ben Anderson. This week we are discussing what is quality code for programming purposes. I grabbed a blog post from the blog Simple Programmer written by Peter Grainger where they discuss quality code and what makes up quality code.

The blog begins with what you should know to write quality software and they recommend a book to read that will give the directions more precisely, then he writes a section that is pretty interesting called “What you don’t code is more important than what you do code” and he sums it up with “The more code you write, the more potential bugs you could introduce”. I haven’t thought about it that way but that line definitely makes sense. Then he goes into setting goals and targeting a persona, you got to set what you want and what your users want from what you’re making and making quality code for that software is a mixture of the two and you go to be precise as you can. A key paragraph in the post is titled “Define the structure of the software in as much detail as possible” This is an important part of quality code as being the most detailed you can be, the more you will, and other people will, understand what is going on with the software.

The last couple sections discuss a couple things that I have talked about in past blogs such as the more tests you do, the better your code will be and the less bugs you will have, also the more reviews you have of your code the higher the quality and the fewer of errors you will find in the code and you just got to maintain your code and make sure its readable for future users and even yourself.

This blog was very informative on the subject of quality code and provided a great insight on what the writer thinks the common coder should know to write quality code. For me, an up and coming coder, its great to know how to write quality code for my future colleagues that I will be working with. The more they able to read and understand my code, the easier it will be for them and I to cooperate and work together on projects that are boss wants us to complete. In my class we are writing quality code to be tested to see if it will pass and we are doing that in groups which will already help me work in a team environment. I highly recommend checking this blog out, I provided the link at the bottom of this blog so you can go check it out. Thank you for joining me this week on Benderson’s blog and I will see you next week!

Link: https://simpleprogrammer.com/quality-code/

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

Some benefits of Angular and Typescript!

Over the past few months, I’ve been asked the same general question about Angular multiple times in onsite training classes, while helping customers with their architecture, or when talking with company leaders about the direction web technologies are heading. After hearing that general question over and over I decided it was time to put together a post … Continue reading Some benefits of Angular and Typescript! →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Unit Test vs. Integration Test

An important thing to consider for software testing is the difference between unit testing and integration testing. The purpose of a unit test in software engineering is to verify the behavior of a relatively small piece of software, independently from other parts. Unit tests are narrow in scope, and allow us to cover all cases, … Continue reading Unit Test vs. Integration Test →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

B7: Black-Box vs. Gray-Box vs. White/Clear-Box Testing

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

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.

IT IS TIME TO DECORATE THE HOUSE!

Well Halloween has come and gone and you know what holiday is next.  Thanksgiving that’s right and you need to decorate quickly before it is time to switch to Christmas decorations! Well if you had to do something similar in the coding world you would use the Decorator design pattern. The decorator design pattern is a design blueprint that seeks to eliminate complex hierarchy’s and allow the programmer to define the object at run time. The upside to the decorator pattern is the easy of adding new components. You essentially create an object as an interface and then create extensions of the object through a decorator class that implements that interface. Which allows you to set all the methods, or information that you want the object to have like price, or description and define that addition price or description with a decorator object. To visually think about this design pattern you can think of a rubber band ball. It has one bouncy ball in the core that is the interface, and each rubber band added to the ball is surrounding that interface object the ball. As you add more rubber bands the object is still a ball, but it is “decorated” in rubber bands. The rubber bands are now an additional quality of the ball, and extension of the ball.

Consider now your house the dining table if you wanted to create a decorator pattern for the table for the next two holidays you could do it easily with the decorator pattern. Your base object or interface would be the table. From there how you decorate it is up to you if you create a thanksgiving table cloth object you can at the time of creating the table add the thanksgiving table cloth in the creation of the table. Then when you are ready for Christmas on November 23 at 00:01 you can just create a Christmas table cloth decorator object and apply it at runtime for it to be added to the table. Then additionally you can create other decorations to be added and you don’t even need to delete the class for the code to work you simply just don’t need to call it at run time.

Overall the decorator pattern helps to avoid an inheritance tree that relies heavily on the parents. This lets you define objects that may or may not be used and call them at run time to decorate your object. For additional information you can check out the link below for additional research that I have done on the topic of the decorator pattern.

https://gitlab.com/AFinneran/homework3-decorator/blob/master/Homework%203/343hw.md

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

Keep Software Design Simple

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.