Software Testing

Software testing is an important process that evaluates and verifies a software application works as intended.

Types of Software Testing

There are many different types of software testing, some are:

• Acceptance – The entire system as a whole is tested and verified
• Integration – Ensuring that individual parts of a software system properly work together
• Unit – A unit is the smallest testable component of a software system. This type tests each unit and verifies correctness.
• Functional – Tests functions by emulating business scenarios
• Performance – Tests the performance of the software under different system workloads
• Regression – Tests rigidity of the software by adding new features and seeing if those new features break or impede on fucntionality
• Stress – Testing the software under maximum workload to see how much the system can handle until it fails
• Usability – Testing how well a customer can complete tasks using the system

Software Testing Best Practices

The software testing process is typically done with a common methodology. Steps to this methodology can include configuring test environments, writing test cases, analyzing test results, and submitting bug reports. Testing tasks are typically automated using tools. Automating tests is beneficial because it allows teams to quickly implement different test cases, test frequently, and get feedback on what did/didn’t work.

Some best practices include:

• Continuous testing – Testing builds as soon as they are ready. This relies heavily on automated testing, allowing software to be validated earlier in the development process. Testing often allows for bugs and errors to be found earlier; therefore, reducing the amount of time spent having to go back and redesigning.
• Configuration Management – Organizations keep test assets (code, test scripts, requirements, etc) in a central location and track what builds need to be tested. These assets allows teams to follow the organization’s testing requirements.
• Bug Tracking – Keeping track of defects is important

Why Test Software?

Testing software regularly can help teams reduce costs and time spent on developing the software. Before releasing a project, testing the software for any errors or bugs is important to give users the best possible experience. If users find that the software does not work as intended, they may stop using it and find an alternative that does work. Although testing has a cost, the cost of releasing defective software outweighs that of continuous testing.

Reflection

The resource used was chosen because it clearly breaks down the different parts to software testing such as the different types of testing, best practices, and why testing is important. Prior to reading this article, I had heard of a few types of testing like Unit Testing, but only became aware of the other types of testing such as Regression Testing. I now understand when designing software, code should be tested regularly and often as overall it will save time and headache.

Resources:

https://www.ibm.com/topics/software-testing#:~:text=Software%20testing%20is%20the%20process,Test%20management%20plan

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

This week I wanted to write a post about the last SOLID design principle, Dependency Inversion. This principle deals with the relationship between interfaces that operate at a high system level and low system level interfaces.

Composed of two parts, the Dependency Inversion Principle as stated by Robert C. Martin is:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

While the name “Dependency Inversion” might imply inverting the dependency relationship between modules, applying this principle actually involves building both high-level and low-level modules from the same abstraction. Constructing your code to abide by the previous SOLID principles, particularly the Open/Closed Principle and the Liskov Substitution Principle, should implicitly also result in code that abides by the Dependency Inversion Principle. The Open/Closed Principle states that a software module should be open for extension, but closed for modification, and the Liskov Substitution Principle states that an interface should be able to be replaced by a separate implementation of the same parent interface without compromising the functioning of the software.

The author includes another coffee machine themed example, detailing how to apply the SOLID design principles to two separate classes of coffee machine. Starting with two classes, BasicCoffeeMachine and PremiumCoffeeMachine. The classes are very similar, with the only differences being an extra class variable representing a coffee bean grinder and a method to brew espresso for the PremiumCoffeeMachine class. The author describes their process for defining suitable abstractions for a piece of software representing coffee machines, including their decision to have the methods for brewing filter coffee and espresso split into two interfaces. A potential coffee machine class representing a machine with the capability to brew either filter or ground coffee can easily be built by implementing both of these interfaces and overriding the methods within the concrete classes.

Refactoring the code this way enables independence between interfaces and implementations and makes expanding on the code base easier and safer. With fewer dependencies between modules, the effects of any changes to existing code won’t ripple out to other parts of your software.

I wanted to review this principle specifically because I wanted to refactor the interfaces from some old projects of mine. I wrote some Java classes meant to represent characters in a fantasy role-playing game, complete with character levels and statistics. As I left it though, the code is only capable of creating characters meant for the user, and not any non-playable characters or any other sort of entities. I want to go back and redesign my code so that I have fewer methods that only function with specific classes, and more functionality to create and edit characters. I remember I had a lot of trouble trying to increment a character’s level by 1 and increasing their stats accordingly, and I get the feeling that refactoring my code with the SOLID principles in mind will help me get it to a place I am happier with.

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

Hello everyone, my name is Abdullah Farouk, and this is my third blog so far this semester (hoping I can get to 6 before the semester ends). I am going to be talking about comments in this blog because I saw this interesting article about it, and I just wanted to learn more and be better educated on the topic. When I started out with coding, I always ignored typing comments in my code because I didn’t really get the point of it other than wasting my time. But as things got more advanced, and I kept getting errors in my code and I knew what the error was, but I just didn’t know where the methods were in my code and what their function was. That’s when I started thinking about comments, I told myself comments would been helpful here instead of reading every line of the method to see what it does. In the article that I tagged down below, the author explains the importance of software technical documentation and how it should be used, with some examples to show you.

I have learned a lot about software technical documentation from this article including what are some examples of unnecessary comments. You don’t need to write an English translation of your software code; you just need a high-level overview of your method or an explanation to a complex logic. Back when I started with coding, I used to comment out some of my code that I didn’t need anymore, and I just kept it there, but I learned quickly that it wasn’t good because it just makes my code look messy. Don’t put comments like “fix this bug” but instead put something more useful like what needs to be fixed. I also learned that there is a lot of redundant and excessive comments. For example, you don’t need to write a comment explaining what i++ does because that is unnecessary as the code is self-explanatory.  Add comments that add value to your code, not make it useless and just clutter the code.

Some people say that a good code should not need comments to explain it, but I just disagree because I like reading information about the method before I start reading each line of it. If you don’t like to put comments on your code, then at least make a schema for your code so others can understand the relationship between codes better. The author shows plenty of example diagrams that show you what a code schema looks like.

Reference article : https://medium.com/@VincentOliveira/how-to-write-good-software-technical-documentation-41880a0e7814

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

Over the past few weeks, we’ve learned about the importance of collaboration in a team. Whether that team is using Scrum or some other software development methodology, communicating with one another is one of the key pieces to achieving whatever goals they have. 

While going through the syllabus, I saw “Collaboration tools” as one of the course topics. I thought about what would exist under this category and the first one that came to mind were video calls. Zoom specifically was the one that came to mind and I wondered how it is or would be used in a software development environment.

In an article from Shari Cleare, they share that “video conferencing software provides powerful communication and collaboration tools that scrum masters can use to engage participants, especially those who cannot attend these meetings in person.” One of my first thoughts regarding this topic was that not every person on the team physically has to be at the meetings; or better yet, no one no one has to physically meet at all. This allows for greater flexibility in choosing members or in general as members can be anywhere or from anywhere, as long as they are able to be present for these online meetings.

The Scrum Master or whoever is hosting the meetings doesn’t even have to be present. Zoom allows for automatic meetings at a set time for the team so, If they are unable to make the meeting, in person or online, the other members can still perform their Sprint Planning, Daily Scrum, or other meeting.

If a team choses to meet online only due to location constraints or other reasons, you may think that it would be nice being able to work from home. I’m sure many people would rather work from the comfort of their own home, but that comfort could turn into the thing that holds them and the team back. 

Zoom can be a great tool for members that are unable to make the physical meeting, but as the main form of communication, I feel that it can easily go downhill over time. Personally, I get distracted with other things when I’m at home so doing work takes much longer than it needs to. It is also why I try to do my work while on campus. I feel that many people can relate to this and if they want to get work done and contribute to meetings and such, they should separate where they work and where they can relax.

I hope that I can have the option to do both in the future and am able to find a good balance. Going into the workplace to get work done before going home and having the freedom to work online should I be unable to make it would be great. I believe that this has become more commonplace as well. During Covid, people had to work from home, and now that it has died down, many companies are allowing either option.

https://blog.zoom.us/using-zoom-agile-software-development/

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

The blog I chose to write about today will be on copyright and licensing in software with that being one of the main topics in the course and to get a better understanding on licensing. In the blog “What is a software license?” by the website Synk.io, provides an in depth blog on types of software licenses, how it works, uses, as well as management of them. The blog mentions how software that is not covered by a license is categorized as “public domain software” or “private unlicensed software”. In the example Professor Wurst mentioned in class previously about wanting to implement a software in the course which had no license falls into private unlicensed software. The software although unlicensed still falls under copyright protection thus unusable for others. The blog mentions examples of when common users would see software license agreements. These are often listed in the terms of conditions prior to installing any software under a end-user license agreement (EULA).

The graphic above displays the 5 different kinds of licenses and shows the level of restrictiveness depicted by the arrow going from less restrictive to most restrictive. The article further goes in depth for each of the 5 license types software.

The article describes how software that use Public Domain Licenses typically run into the issue where the code might not follow the best procedures and standards. Which is a consequence of the nature of the license. I can see a lot of educational software or software for non profit being released under a public domain license.

The next license that the article talks about is LGPL and how “developers have rights to link open source libraries within their software”. In other words, LGPL lets you add licenses to code without completely releasing the entire source code.

Permissive licenses are what we have researched the most in class which ranged from Apache to MIT licenses that often require copy right notes within the software.

Interestingly when the article talks about Copyleft licenses it mentions how it probably is not the best license for software developers due to the reciprocal licensing of resulting code in other words, all derived code has to follow the same copyleft licensing. With that being said, copyleft licenses are probably best used for research/educational purposes or for very transparent community collaborations.

Lastly, the most restrictive licensing type proprietary are often used by large corporations and protects the owners/developers from unauthorized use. When doing further research for applications that use Proprietary licensing I found that the application Skype a proprietary license thus the source code is not provided publicly and is owned by Microsoft.

Overall, when reflecting at the different types of licensing and my personal goals. I see myself in the future using a permissive license like the MIT license for straightforwardness and simplicity. To add to that, currently for our program on Markdown to HTML my group is using a MIT license for those reasons.

https://snyk.io/learn/what-is-a-software-license/

From the blog CS@Worcester – Anthony Duong CS Blog by anthony duong and used with permission of the author. All other rights reserved by the author.

Recently in class I have been learning about a bunch of different types of software licenses and just how important they are to include on my future projects. A software license is essentially a type of legal instrument that controls the use and redistribution of software in order to help protect the author. According to a website called TechTarget, the main use of a software license is “Software licenses typically provide end users with the right to one or more copies of the software without violating copyrights. The license also defines the responsibilities of the parties entering into the license agreement and may impose restrictions on how the software can be used.” Before taking CS-348 I didn’t know much about software licenses and how they worked. I knew there were a couple different types, but I didn’t realize how many types there are actually are and I also didn’t understand how important that they are. Personally, I think TechTarget did a great job explaining the differences between licenses and how they work. While most people think that these licenses are just to protect developers and their code, they are also used in order to protect users. They help the users avoid and protect themselves from infringement claims and also limit their legal liability if something were to happen. Sadly, these software licenses are not free. There isn’t a set price that every license costs, most of them have their own prices which depends on the type of license that it is. Some of these prices include a one time fee, some are a subscription fee, and others include a purchase fee plus a subscription fee. Although these licenses can be expensive, I think that it is worth it in order to help protect yourself and your users.

While there are a bunch of different software licenses, there are two main types that are viewed differently under copyright law. One of the main types of software licenses are free and open source software licenses, otherwise known as FOSS licenses. These types of licenses give the user a lot of freedom, and even allow them to use the source code. FOSS may allow these customers to change the software themselves if the user desires it. The other main type of software license is known as a proprietary license. These licenses are more commonly known as closed source licenses. Closed source licenses are much more strict than FOSS licenses, and don’t give the user much freedom. The users receive operational code, however they are not allowed to freely alter the software that they have been given. On top of that, these users are not allowed to obtain the source code through reverse engineering.

Synopsis: https://www.techtarget.com/searchcio/definition/software-license

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Introduction

I found an article by Ibrahim Ogunbiyi called Seven Best Practices for Managing Software Licenses. Just based on the title, it seemed to be what I was looking for. It starts off with the basics; what is software license management? According to Ogunbiyi, it’s simply “a document that provides guidelines for the use and distribution of software” (Ogunbiyi). It assists with the controlling, auditing, tracking, and management of a software in an organization and ensures that users comply with the regulations set in place.

Importance

The article discusses the importance of licenses. The reasons include but aren’t limited to:

• Legal compliance with regulations set by organizations/manufacturers
• Keeps track of software due dates; leads to productivity
• Helps manage/reduce costs through enhanced planning
• Optimizes software usage through usage and license tracking data
• Ensures only the use of authorized and secure software, avoiding malware or malicious attacks/breaches

At this point, I think many of those new to software licensing have already taken a huge step forward in their knowledge of the subject. It’s easy to dismiss licensing as something that only grand organizations deal with, but it can be necessary for any small business or individual who wants to protect their work. 

Best Practices

Finally, we reach the best practices as given by Ogunbiyi. In no particular order, these practices are: 

1. Documenting the process of obtaining the software
   1. Who, where, when, how it was purchased
   2. When it is due for renewal
   3. Keep documentation up to date and to certain standards
2. Centralize your list of software licenses
   1. This practice is good for organizations with multiple departments that each have separate licenses
3. Understand the agreements for your software license(s)
   1. Read terms and conditions
4. Use a software license management tool
   1. Assists in tracking, optimizing, and managing software licenses
5. Track license usage regularly
   1. Ensures compliance with rules and regulations
6. Make sure your software license(s) are up to date
   1. Keeps them tracked
   2. Prevents them from expiring
7. Teach employees about managing software licenses
   1. Ensures correct usage of software
   2. Keeps them knowledgeable about the license process and its guidelines

Why This Topic?

I chose this topic because it’s very underappreciated and not mentioned enough in the software development community (from my experience). This could also be useful for an organization or small team that is new to software development.

Conclusion

For me, this article was quite beneficial to my learning. Personally, I previously didn’t know anything about software licensing and the entire process about it. I won’t claim to be an expert on it now, but this article has helped me become a novice in understanding the subject. Although this article didn’t recommend specific licenses, it did teach me the process I should go about when acquiring or dealing with a license. In the future, when I am working on a project either individually or with a team, I’ll be more familiar with the guidelines and process around licensing, and can help my colleagues if they are unfamiliar.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In the realm of computer science and web development, understanding the intricacies of Application Programming Interfaces (APIs) is indispensable. My recent exploration into this subject led me to an enlightening IBM article about REST APIs, a cornerstone of modern web services and architecture. This article, fittingly titled “What is a REST API?” (IBM Article Link), delves into the principles and practices of RESTful APIs, offering a comprehensive overview that resonates deeply with our course material.

Selecting this resource was a no-brainer for me. The blend of theoretical concepts and practical applications it offers aligns perfectly with our current coursework on web development and API integration. The article’s clear delineation of REST API characteristics, alongside examples of their use in microservices architecture, provided a solid foundation for understanding their role in contemporary web development.

The six foundational principles of REST APIs, as elucidated in the article, were particularly enlightening. They include uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture, and code on demand. Each principle contributes to the overall functionality and efficiency of web services, emphasizing the importance of a well-structured API.

What struck me most was the concept of statelessness in REST APIs. The idea that each request from a client to a server must contain all the information needed for the server to respond, without relying on any stored context, highlighted the need for efficient data management and transfer in web applications. This insight has reshaped my understanding of client-server interactions and will undoubtedly influence my future projects.

Furthermore, the article’s discussion on the importance of security in REST APIs, such as using OAuth 2.0 for authorization and HTTPS for secure data transmission, was particularly relevant. It underscored the critical nature of protecting data and maintaining user privacy, aspects I intend to prioritize in my future work.

In summary, this IBM article not only broadened my knowledge of REST APIs but also reinforced the importance of secure, efficient web development practices. The principles of RESTful design will be an integral part of my toolkit as I progress in my computer science career. I strongly recommend this resource to my peers for its clarity, depth, and relevance to our course.

As I continue my journey in computer science at Worcester, I am excited to apply these concepts in practical scenarios, especially in web development projects. This article has been a stepping stone in my understanding of how web technologies work in harmony to create seamless user experiences and secure, efficient web services.

Citation: “What is a REST API?” IBM. https://www.ibm.com/topics/rest-apis

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