Hi class,

For this blog post I decided to choose the topic software testing. Software testing is one of the topics that we went over this course and furthermore, I hope you can have some good takeaways about how software testing is implemented out in the real world.

Before going into the summary, let me provide you with the resource that I am getting this information from. https://www.youtube.com/watch?v=PqCVDGhvEFs&t=1988s This is the link to the podcast I listened to called “Beyond Coding.” Here the host Patrick Akil, a software engineer looking to gain and share interest in coding, sits down with QA, quality assurance, engineer Augustine Uzokwe to discuss what a QA engineer does in software engineering. (I really do enjoy listening to podcasts so that’s why I have chosen a podcast format for my source.)

Patrick begins the podcast off by asking Augustine what is QA, quality assurance. Augustine replies it varies depending on the work and/or field the said QA is in, but in terms of this interview he will do this in perspective to software engineering. 

Augustine then goes onto talking about QA in software engineering. He goes on to state that yes, there is a lot of unit testing, but it is more so adapting, quick thinking, and team collaboration. He takes the approach of using broad practices such as pragmatic and being flexible. Furthermore, he goes on to state that if there’s two teams, Team A and Team B, what might work for Team A, might not work for Team B. 

He stresses this is totally okay, and acknowledges that this happens, but as a QA engineer you must find a solution fairly quickly. Not only quickly, but also find a smart solution. When a unit testing doesn’t have the correct output/run, he then goes on to state that rather than going back trying to fix everything then performing an end to end unit test, there’s a smarter approach that is better and in the long run will be quicker.

This approach is team collaboration. In the instance above, he would call all participating engineers in the code and simply talk and review the code with them. From here each engineer would have an assigned part to work on, then they would dispersed to work on their said assignment. In this time of working, Augustine stresses the QA engineer needs to take the lead and create an environment of openness amongst the fellow engineers. If one engineer has a question, they shouldn’t go searching for it online for three hours, but rather ask a fellow peer. 

Once a developer has their assignment done, it should be unit tested separately (if applicable). This is very beneficial because all the bugs can be found in that moment, then developed, rather than with an end to end test. In this time, Augustine would be spreading his knowledge of QA to the engineer so that way the engineer will slowly learn how to conduct and what to look for while on their own doing a software testing. 

Augustine states in today’s world of engineering how fast it is out there, but it is more so about “removing the waste” and improving as you go with unit tests/peer testing. Not only is this the case, but he also states that team maturity is very important and key. Furthermore, if a lot of engineers come together it doesn’t necessarily mean a quicker delivery. Engineers need to have a process in place and need to know how to properly test software, of which is where the QA engineer comes in to ensure quality over speed. 

My personal comments about this is that I like the way Augustine thinks a lot; quality over speed. Furthermore, throughout the podcast he says “win the time.” Before listening to this podcast, if I heard that statement in regards to programming I would’ve thought to write out the program as quickly as possible and then test at the end when I am “done” programming. Although after listening to the podcast, I would now think let me talk with my team, write out a plan to implement the code, code, ask questions, and unit test the code along the way. Overall, this was a very interesting listen and very insightful that could be useful to programmers of all levels; or even people wanting to implement a better structure of working on a team project.

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

Estimation is a huge part of software development. It exists in many aspects of our work. The area where it is most important is estimation of development time. Many software methodologies are reliant on breaking down work into smaller parts and creating workflows. Like the famous Sprint from Agile. A common theme among all of these is estimating the time it will take to complete these tasks. And on a larger scale, how long it will take to finish a feature or product.

In this blog by Yaakov Ellis, discusses the importance of estimation. Moreover, the skills needed to make a good estimate. He first discusses the usefulness of estimation. How good estimates increase efficiency and reduce crunch time. One of the most important points of the article is the prerequisites needed to make good estimates. Such things like good and detailed specifications and understanding functionality. A point that stuck out to me is that he says that the people who do the work should do the estimates. Seems like something obvious but needed to be brought up nonetheless. There were many other points like not giving in to outside pressure to give an estimate that was unrealistic.

I chose this blog because a lot of what we talked about in class was teams deciding how much time to spend on certain things. Not only sprint lengths, but every part of Agile. Estimating the length of the project to even just a simple bug fix could take. I think it is a skill that is often overlooked. As someone who is bad at giving estimates and gives in to pressure to please people. I think that is something I will think about when making these decisions more. Some last points that I liked was the idea that you should estimate the public so everyone on the team can see them. I think that would decrease the risk of bad deadlines that force crunch on developers. 

Citation

https://stackoverflow.blog/2019/10/23/why-devs-should-like-estimates/ 

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Licensing may seem like an obscure legal detail, but it plays a critical role in scientific software development. In “The Whys and Hows of Licensing Scientific Code”, Jake VanderPlas breaks down why picking the right license is key to sharing and advancing research.

Summary of the Article

VanderPlas emphasizes three key takeaways:

Always license your code. Without a license, code is effectively closed, limiting its reuse. If you don’t, it’s basically off-limits for anyone else to use.

Use a GPL-compatible license.This makes it easier for your code to work with other open-source projects.

Prefer permissive licenses like BSD or MIT. These licenses lower barriers for collaboration, they are the most flexible and let people from both academia and industry collaborate freely.

Licensing is crucial for scientific reproducibility and collaboration. Even if you post your code publicly, without a license, it’s still “all rights reserved,” meaning others can’t legally use it. VanderPlas recommends permissive licenses because they encourage more people to adopt and improve the code. On the other hand, copyleft licenses (like GPL) keep the code open but might scare off companies from getting involved.

Personal Reflection

While reading this article, I found VanderPlas’s insights particularly relevant and important. I appreciate how licensing can help bridge the gap between innovation and real-world impact. The idea of using BSD or MIT licenses makes sense because they’re simple and open the door for more people to get involved.

This also made me think about how intentional we have to be with our work. Just like we carefully document research methods, licensing makes it clear how others can use and improve our code and/or tools. It’s a good reminder that open science isn’t just about sharing, it’s about having solid guidelines that make collaboration easier and that push science forward.

Citation

VanderPlas, J. (2014, March 10). The Whys and Hows of Licensing Scientific Code. Pythonic Perambulations.

Link of the article: https://www.astrobetter.com/blog/2014/03/10/the-whys-and-hows-of-licensing-scientific-code/

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

Link to blog: https://dzone.com/articles/java-rest-api-frameworks-1

In class, we’ve been covering REST APIs and how to use certain call methods such as GET, POST, PUT, and DELETE. Before class, I had heard of REST APIs but never had any understanding of what they were, or how to interact with them. I figured I would dive deeper into other Java REST APIs. The article Java REST API Frameworks by Farith Jose Heras García lists some REST APIs along with their advantages and disadvantages.

García begins with a simple introduction to Java REST APIs and what they do, specifically how they enable communication between applications and other software, and make the passing of data easier. Each API on the list includes pros and cons, and then a CRUD (create, read, update, and delete) example using the API. 

First on the list is the wildly popular Spring Boot. According to García, some of the benefits of Spring Boot are that it is easy to use and set up, has a lot of built-in support, and has a large library of plugins and modules. The cons are that beginners might struggle to understand it, and it might be too much for smaller projects and better for larger projects instead.

Second on the list is Jersey. Jersey is simple, ideal for microservices, and also has a decent-sized library. However, García considers it slow and difficult to debug.

Third on the list is Play Framework. It’s lightweight and flexible, high performance, and also offers a library of plugins. It’s updated and designed for modern Java applications, as it works with Java 8 and Scala. Unfortunately, it has a tough learning curve and debugging can be a challenge.

The final on the list is Vert.x. It is lightweight, flexible, and has high-performance, and also supports JavaScript. The cons are that it is difficult to debug and might be hard to understand for a first-time user.

I selected this resource because it is an article that is a good reference for an updated list of Java REST APIs currently in use. It gets the point across for each item, whilst being a short enough read to be a good refresher for those unfamiliar with the information. It’s mainly beneficial for choosing which REST API to use with your project or application.

I found this to be a solid article for learning a little bit about Java REST APIs and how to choose them. For example, I did not know that Spring Boot is too heavy for smaller applications. The formatting was simple, and it’s pretty interesting to see the frameworks in action with the CRUD code examples García provided. Choosing the right REST API framework for your project’s needs is very important since many factors can go into such a decision (size, libraries, and easy learning curve). I hope to apply this to projects of my own and perhaps jobs where REST APIs are needed.

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.

As I become a more knowledgeable developer, I hear the term ‘software framework’ being used more frequently. In my research, I’ve seen an increased interest in frameworks such as Angular and React. To understand what these are, I must first define what is a software framework.

In the article What is a Framework? Software Frameworks Definition, written by Joel Olawanle, walks through a general definition of software frameworks, comments on how they may be applied, and how they differ. Olawanle defines a framework as such, “…is a structure that you can use to build software. It acts as a foundation so you don’t have to deal with creating unnecessary extra logic from scratch.”(Olawanle). Supposing a framework is implemented correctly, developers will save time allowing them to start the project earlier. Additionally, the foundation it provides will not be prone to human error. If the components of a framework are implemented from scratch, then there could be errors that would be much more difficult to fix further in development. Since frameworks can be modified, there is less of a reason to implement their functionality from scratch.

Olawanle expands his definition to other aspects of software development. Before reading this article, I understood that there were both frontend and backend frameworks, but I was surprised to learn that mobile applications and data sciences have their respective frameworks. While reading Olawanle’s article, I noticed a framework I used a few years ago, that being Bootstrap. This qualifies as a software framework as it gathers files needed for a functioning website (.html, . css, and .js) into one structure. This allows the developer to easily make their website without having to build this structure. Angular and React both are classified as Frontend frameworks. Both of these are used for creating interfaces for websites, but each has its unique components. React can use JavaScript to create HTML and CSS files, meanwhile Angular has dependency injection allowing it to more freely communicate with other applications. Each of these creates a specialized purpose for the framework. 

Depending on where a developer is working (front end, back end, etc), there will be a framework that can create a strong foundation for their code. Before selecting their framework, the developer must weigh the tradeoffs between the various frameworks and consider which would support their project principles the most. Using a framework in this scenario would save time and reduce any human error manually implementing these components introduce. In my experience with Theas’ Pantry, the backend does not use any framework listed within Olawanle’s article. After reviewing the documentation, it seems as if the back end would not support these listed frameworks as they are not directly language-compatible. This means more time and resources would be invested into implementing the framework, than potentially implementing components of such individually. Frameworks provide a strong starting point for development teams, depending on the design choices frameworks may be incompatible with certain projects.

Link to Article:

https://www.freecodecamp.org/news/what-is-a-framework-software-frameworks-definition/

-AG

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

Communication with those who help construct it or those who will use it is an essential component of any project. Software documentation serves both these ends, as it informs anyone approaching the project of topics such as the requirements used to run said software, instructions, and myriad other facets of the project. Documentation is created for those interested in the specified software/project. The Swimm Team, in their article What is Software Documentation? Types, tools, and best practices, list two types of documentation. These are external and internal documentation.

External documentation seeks to explain all aspects of the software that are not locally accessed. Most of this documentation involves user interaction. This is seen through End-User documentation, which provides the user with instructions on using the software, or through Just-In-Time Documentation, which guides the user while the program executes. A more technical piece of documentation, API documentation, is also considered external. Although most users may not directly interact with the API, this type of documentation is targeted towards developers who may want to expand the API functionality or use it in their projects. Due to the accessibility of external functions, its documentation must be equally accessible to its audience. A level of abstraction must be provided to reach this goal, as uninformed users do not need to understand how the internal systems of the software function, but rather they must learn how to interact with it.

Internal documentation refers to everything ‘behind the scenes’ so to speak. Contrary to external documentation, this documentation is less accessible, meaning it can go into detail on how the systems of the specified software work. Due to this complexity, it serves as a great introduction to the project and can be used to onboard new developers. Internal documentation ranges from information regarding the development cycle of the software, as seen through scheduling documentation,  to design choices seen throughout, which can be found in Software design documents. During the development process, software engineers can refer to internal documentation to ensure their contributions follow the team’s vision for the software.

My experience with software documentation has been limited up until this year. My most recent experience with documentation was through the HFOSS project Theas’ Pantry. Within this project, there was API documentation, available through a .yaml file, which listed all functions and associated code with all API calls. Additionally, there was indirect documentation offered through activities introducing onboarding developers onto the project. Each of these activities introduced a broad topic, such as software architecture, which then transitioned into how it’s applied to Theas’ Pantry. This untraditional form of documentation allows the onboarding developer to interact with the components in a microcosm before they apply their knowledge on the project. Documentation is a vital component of software development. Without supporting texts such as this, clients interested in the project would be met with inaccessibility, and onboarding (in addition to current) developers may not understand the project as a whole which could jeopardize the production of such. 

Link to Article:

https://swimm.io/learn/software-documentation/what-is-software-documentation-types-tools-and-best-practices

-AG

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

I chose the blog post, “Software Documentation Best Practices” by David Oragui because it addresses the challenges in documentation and how to go about following the best practices. The blog shows us all of the best practices of documenting your work to prevent having challenges when faced with the task. In my time coding, documenting has been a struggle knowing how to document and when to do it. This is what led me to choose this blog post, so I can learn how to not make these mistakes in the future and become better when it comes to creating documentation.

The blog explained to the reader how software documentation is essential for enhancing user experience and ensuring consistent software development. Despite its benefits, developers often neglect documentation due to constraints like time, expertise, or resources. This gap can result in user difficulties and inefficiencies in development processes. The blog first described the  types of software documentation. First, project documentation which is aimed at development teams, covering technical design, project plans, and requirements. Next is product documentation, this is more user-focused, including instructional manuals, reference guides, and installation instructions. Third, the blog described process documentation which details steps for development, testing, and maintenance, ensuring consistency and clarity. Then, technical documentation which provides in-depth technical insights, such as APIs, architecture, and data models. In addition, there is system documentation which explains system architecture, components, and troubleshooting methods. Last is user documentation, this is similar to product documentation as it is user-friendly materials like how-to guides, tutorials, and reference docs. The benefits of documentation include improved user experience, enhanced collaboration, increased efficiency and improved quality. The best practices for writing documentation include prioritizing documentation, identifying the target audience, defining the scope, developing a strategy and being able to write clearly for the audience.

From the blog, I was able to rethink my use of documentation and highlighted the best practice when creating documentation. Going forward, I plan to be more thoughtful about my use of documentation and how I go about creating it. The blog taught me that well-designed documentation should cover all the necessary information to allow others to understand without being confusing.. This perspective will help me develop documentation that is easily readable and documents what work is being created. After reading, I feel like I will be able to not make as many mistakes when it comes to creating documentation.

https://helpjuice.com/blog/software-documentation

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