Hello everyone,

This week’s blog topic would be about Test-Driven Development (TTD) as this is something we recently talked about in class and it didn’t take long for me to understand the importance of it. So Test-Driven Development (TTD) is a software development process that involves writing tests for your code before you write the code. At first this was very confusing but after trying and actually working on it, I actually saw its purpose.  This approach has transformed the development of coding projects and has revolved around testing. While the more traditional way is concentrated around the waterfall model, which is a more linear approach where testing occurs near the end of a one long timeline. TDD makes testing an ongoing process, a reiterative process. It follows simple steps which cycle through the process. You first write the desired test for the desired feature, ensuring the test fails because the feature has not been written first and then you write enough code where it passes the test. This cycle repeats with further improvements and new features until the project is complete. Its core principle is rooted in Agile development, where it emphasizes iterative development with collaborative efforts based on customer feedback and the ability to change. The benefits of TTD is that it enhances collaboration through shared understanding of requirements, it is one of the best ways to detect bugs early on the development cycle of the project and it improves code design immensely. Because it is driven from testing it allows the code to evolve organically, it creates a program having the same format of coding throughout it without even trying too much. Due to its core principles, it also lowers the long term maintenance costs and this can be hugely beneficial for big projects that have a long lifespan. Not only does this blog explain what TTD is, the author also shares its best advice and practices for the developers who are trying to implement it in their work. You first start simple by writing a focused test on the fundamentals features of the project. Then you create more complex tests for specific situations. What I liked about this post and the reason why I chose it was that it has a good balance of theoretical concepts and also actual practical use. I appreciated how the author walked us over through the concepts and then immediately followed up with simple examples. This reinforces what you are trying to learn and through practice you test the concepts that you just learnt.

In conclusion, Test-Driven Development represents a new way in software development, where it highlights and prioritizes the importance of testing and the quality that it brings and you revolve it around it. By integrating testing into every step of development, TTD creates a strong and maintainable software program while supporting modern development practices. The development may be slow at first, but the long term benefits and the high quality in code make up for it.

Source: https://circleci.com/blog/test-driven-development-tdd/

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

I recently came across the article “Best Practices for Software Quality Assurance Testing” by KMS Technology. As a computer science student eager to understand the practical aspects of software development, this piece offered a clear roadmap of the QA process, breaking it down into four main stages: planning, test design, execution, and reporting.

1. Planning: The article emphasizes the importance of early-stage planning, including resource allocation, timeline estimation, and tool selection. This stage sets the foundation for the entire QA process.​

2. Test Design: Here, the focus is on defining both functional and non-functional requirements. The article suggests determining which tests can be automated and which require manual intervention, ensuring comprehensive coverage of user scenarios.​KMS Technology

3. Test Execution: This phase involves running the designed tests and evaluating any defects or issues that arise. It’s a repetitive process, ensuring that each identified problem is addressed and retested.​

4. Reporting and Maintenance: The final stage is about documenting findings, analyzing results, and ensuring that the software is ready for release. Continuous feedback loops between testers and developers are crucial here.​

Reflecting on these stages, I realize how often, in academic projects, we might overlook structured testing due to time constraints or lack of emphasis. However, this article highlights that integrating testing throughout the development cycle, rather than treating it as a final step, leads to more reliable and efficient software.

One key takeaway for me is the significance of clear communication and documentation. In group projects, miscommunication can lead to redundant work or overlooked bugs. By adopting a structured QA approach, we can mitigate these issues.

In conclusion, this article has provided me with a practical framework for approaching software testing. As I continue my studies and work on more complex projects, I plan to implement these best practices to enhance the quality and reliability of my work.

For those interested in a deeper dive, here’s the full article: Best Practices for Software Quality Assurance Testing.

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Recently, I have been learning a lot about testing code, specifically methods such as static and dynamic testing of code. For this blog post, I wanted to research deeper into static and dynamic testing methods, as well as their applications, especially given my limited experience with using them up until now. As for researching this topic, I came across a well made podcast titled, “Static Testing vs Dynamic Testing: What is the Difference?” by CTSS Academy on spotify. I found this podcast to be a perfect choice to aid in my research for the software quality assurance and testing course I am taking this semester, especially because of the speakers prior experience in a very relevant workplace that focused on software testing, and the manner in which they address their video to an intended audience of prospect software testers. 

STATIC TESTING: 

This involves looking at software without ever running it in the first place, much like looking at a blueprint. Static testing has a heavy emphasis on preventing bugs from existing in the first place, much like proofreading instructions that you have been given before investing time and resources into the task that would be unrecoverable. Initial requirement documents are involved here, as well as all other outlines for how the project will go about being constructed in the first place. Source code can also be included here, as well as test cases and scripts needed to run when testing the software, really anything generated when developing the software, except running the code itself. The most basic form of static review could be considered “informal review” or something as simple as a coworker looking over another co-worker’s code and giving feedback. Technical review is more formal and is essentially a peer-review of the technical procedures or specifications taken. Static testing also includes “walkthroughs” or presentations of a project to peers, including step-by-step processes taken when creating the project. Static code review or white-box testing itself could include specifically looking at the code written and making sure that it follows the proper syntax of whatever language it is written in, as well as looking for any obvious security flaws.

DYNAMIC TESTING:

This involves executing a software or code and understanding how it processes information and behaves. Dynamic testing is all about executing code and tracking how it behaves and responds to certain situations, more specifically whether it is performing efficiently as it should, while also using the proper amount of data it should be. If static testing refers to whether or not we are building something the right way, dynamic testing refers to whether or not we are building the right thing. Unit testing is a basic place to start with dynamic testing, as it encompasses individual units of code apart from one another, using unit tests to make sure that one job of that part of the code is functioning properly. Integration testing is one step more complex than unit testing, involving multiple unit tests and the manners in which they interact with each other. System testing refers to testing the entire system of code and how it functions as a single machine, assessing whether it meets all criteria established. Security testing, performance testing, or any other form of testing that would require running the software to figure out are all considered to be dynamic testing as well.

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

During week 12, we learned about test driven development. Test driven development is a testing method that outlines what functions need to be tested, writes the tests, then writes the code. It is an iterative process that goes through each test one at a time, building on what is already written. 

In class, we practiced the method by building a Mars Rover. We read what the rover should do and made a list of what we needed to test and build. We started with the easiest thing on the list and wrote a test for it. Then, we wrote the minimum amount of code to make the test run. We tweaked the test block, if it needed to be, and then ran the single test. Next, we repeated the process for the next easiest thing on the list. We will repeat the process until all of the tests are written. 

Test driven development focuses on just the tests before the actual code is written. It was a little confusing at first to think about how to write a test before the code, but once it clicked, it was easy. 

I found a website on test driven development and it described the process in a slightly different way. BrowserStack explains test driven development as a “red-green-refactor” cycle. The red phase is when just the test is written and it doesn’t pass because there’s no code. The green phase is when the bare minimum code is written for the test to run and it passes. The refactor phase is tweaking the tests and code so everything runs and passes. The cycle is run through every time a new test is written and repeats until all of the tests are written and pass. 

Test driven development is a very useful method for debugging. Since the tests are being run at every new addition, bugs are found as they appear and do not slip into the cracks as easily. The method also is very efficient and allows the programmer to easily add new functions later on in development. The iterative process is easy to maintain for the programmer, and provides a much larger testing scope than other methods. 

I liked working with test driven development. I think the process is very organized and straightforward. I would definitely use this in the future for projects that require thorough tests and with functions that build on each other. 

Source referenced: https://www.browserstack.com/guide/what-is-test-driven-development

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

In software development, a build has to be stable before further more comprehensive testing in a project so that the project is successful. One of the ways of guaranteeing this is smoke testing, which is otherwise known as Build Verification Testing or Build Acceptance Testing. Smoke testing is an early check-point to verify that the major features of the software are functioning as desired before other more comprehensive testing is done.

What is Smoke Testing?
Smoke testing is a form of software testing that involves executing a quick and superficial test of the most crucial features of an application to determine whether the build is stable enough for further testing. It is a minimum set of tests created to verify if the core features of the application are functioning. Smoke tests are generally executed once a new build is promoted to a quality assurance environment, and they act as an early warning system of whether the application is ready for further testing or requires correction immediately.

Important Features of Smoke Testing

-Level of Testing: Smoke tests are interested in the most important and basic features of the software, without exploring each and every functionality.
-Automation: Automated smoke testing is a common routine, especially in the case of time limitations, to perform quick, repeatable tests.
-Frequency: Smoke testing is normally run after every build or significant change in code in order to allow early identification of major issues.
-Time Management: The testing itself is quick in nature, so it is a valuable time-saver by catching critical issues early.
-Environment: Smoke testing is typically performed in an environment that mimics the production environment so that test results are as realistic as possible.

Goal of Smoke Testing

The primary objectives of smoke testing are:

-Resource Optimization: Don’t waste resources and time on testing if core functionalities are broken.
-Early Detection of Issues: Identify any significant issues early so that they can be fixed at a quicker pace.
-Refined Decision-Making: Present an open decision schema on whether or not the build is ready to go to thorough, detailed testing.
-Continuous Integration: Make every new build meet basic quality standards before it is added to the master codebase.
-Pragmatic Communication: Give rapid feedback to development teams, allowing them to communicate clearly about build stability.

Types of Smoke Testing
There are several types of smoke tests based on methodology chosen and setting where it is put to practice:
-Manual Testing: Test cases are written and executed manually for each build by testers.
-Automated Testing: Automation tools make the process work by itself best used in situations of tight deadline projects.
-Hybrid Testing: Combines a mixture of automated as well as manual tests for capitalizing on both the pros of each methodology.
Daily Smoke Testing: Conducted on a daily basis, especially in projects with frequent builds and continuous integration.
Acceptance Smoke Testing: Specifically focused on verifying whether the build meets the key acceptance criteria defined by stakeholders.
UI Smoke Testing: Tests only the user interface features of an application to verify whether basic interactions are working.

Applying Smoke Testing at Various Levels
Smoke testing can be applied at various levels of software testing:
Acceptance Testing Level: Ensures that the build meets minimum acceptance criteria established by the stakeholders or client.
System Testing Level: Ensures that the system as a whole behaves as expected when all modules work together.
Integration Testing Level: Ensures that modules that have been integrated work and communicate as expected when combined.

Advantages of Smoke Testing
Smoke testing possesses several advantages, including:
Quick Execution: It is easy and quick to run, and hence ideal for frequent builds.
Early Detection: It helps in defect detection in the initial stage, preventing wasting money on faulty builds.
Improved Quality of Software: By detecting the issues at the initial stage, smoke testing allows for improved software quality.
Risk of Failure is Minimized: Detecting core faults in earlier phases minimizes failure risk at subsequent testing phases.
Time and Effort Conservation: Time as well as effort is conserved as it prevents futile testing within unstable builds.

Disadvantages of Smoke Testing
Although smoke testing is useful in many respects, it has some disadvantages too:
Limited Coverage: It checks only the most critical functions and doesn’t cover other potential issues.
Manual Testing Drawbacks: Manually, it could be time-consuming, especially for larger projects.
Inadequate for Negative Tests: Smoke testing typically doesn’t involve negative testing or invalid input scenarios.
Minimal Test Cases: Since it only checks the basic functionality, it may fail to identify all possible issues.

Conclusion
In conclusion, smoke testing is an important practice at the early stages of software development. It decides whether a build is stable enough to go for further testing, saving time and resources. By identifying major issues early in the development stage, it facilitates an efficient and productive software testing process. However, it should be remembered that smoke testing is not exhaustive and has to be supported by other forms of testing in order to ensure complete quality assurance. 

Personal Reflection

Looking at the concept of smoke testing, I view the importance of catching issues early in the software development process.
It’s easy to get swept up in the excitement of rolling out new features and fully testing them, but if the foundation is unstable, all the subsequent tests and optimizations can be pointless. Smoke testing, in this sense, serves as a safety net, getting the critical functions running before delving further into more rigorous tests. I think the idea of early defect detection resonates with my own working style.

As I like to fix small issues as they arise rather than letting them escalate into big problems, smoke testing allows development teams to solve “show-stoppers” early on, preventing wasted time, effort, and resources in the future. Though it does not pick up everything, its simplicity and the fact that it executes fast can save developers from wasted time spent on testing a defective product, thus ending up with a smooth and efficient workflow. The process, especially in a scenario where there are frequent new builds being rolled out, seems imperative to maintain a rock-solid and healthy product.
The benefits of early problem detection not only make software better, but also stimulate a positive feedback loop of constant improvement between the development team. 

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

Week 12 – 11/30/2024

Agile Versus Waterfall: Picking the Right Tool for the Job

As a senior in college, I’m starting to think more seriously about what it will actually be like to work on projects in the real world. I recently read a blog post that compared and contrasted Agile and Waterfall project management methodologies, and it really helped me understand the importance of choosing the right approach for different types of projects. This aligns perfectly with what we’ve been discussing in my class about the need for both strategic planning and adaptability.

The blog post “Agile vs. Waterfall: Understanding the Differences” by Mike Sweeney explained that Waterfall is a very linear, sequential approach, where each phase of the project must be completed before moving on to the next. It’s kind of like building a house – you need to lay the foundation before you can put up the walls. This makes Waterfall a good choice for projects where the requirements are well-defined and unlikely to change, like in construction or manufacturing. In these industries, making changes mid-project can be super costly and impractical, so having a clear plan from the outset is essential.

Agile, on the other hand, is all about flexibility and iteration. The project is broken down into short cycles called sprints, and the team continuously reevaluates priorities and adjusts its approach based on feedback and new information. This makes Agile a great fit for projects where the requirements are likely to evolve over time, such as software development. In software development, client needs and market trends can change rapidly, so being able to adapt is crucial.

One of the biggest takeaways for me was the realization that choosing the right methodology is crucial for project success. I used to think that being flexible was always the best approach, but now I understand that structure and predictability can be equally important in certain situations. The key is to carefully assess the project requirements and choose the methodology that best aligns with those needs.

As I prepare to enter the professional workspace, I feel much more confident in my ability to approach projects strategically. Thanks to this blog post, I now have a better understanding of when to use Agile versus Waterfall. For instance, if I’m working on a software project that involves a lot of client interaction, I’d probably lean towards Agile. But if I’m managing a marketing campaign with well-defined objectives, Waterfall might be a more appropriate choice.

The real-world examples provided in the blog post were super helpful in illustrating how these methodologies are applied in different industries. This practical insight will definitely be valuable as I transition from the academic world to the professional world.

Blog link: https://clearcode.cc/blog/agile-vs-waterfall-method/

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

REST APIs are essential of todays software development, this helps applications to communicate across platforms. I read the blog post Best Practices for REST API Design on the Stack Overflow blog, which provided advice on designing APIs that are efficient, secure, and user-friendly. This post furthered my understanding of “RESTful” principles.

Summary

The blog post outlines several key principles for designing REST APIs effectively. It begins by stressing the importance of a well-defined URL structure that reflects the resource hierarchy and uses nouns instead of verbs. For instance, /users/123/posts is a clear and intuitive way to access a user’s posts.

It also highlights the necessity of using standard HTTP methods (GET, POST, PUT, DELETE) to maintain consistency, along with proper status codes to provide meaningful feedback to clients. The post delves into techniques for handling query parameters, versioning APIs to ensure backward compatibility, and implementing pagination for large datasets. Security and performance are emphasized as critical considerations, with recommendations to use HTTPS and apply caching strategies.

Why I Chose This Resource

As we did POGILs in class, I frequently ask myself scenarios where creating a robust REST API are most essential. This blog post stood out because it bridges theory and practice, directly applicable to homeworks and future projects.

Reflection

The blog post reinforced several concepts I’ve encountered, such as the importance of clear URL structures and consistent use of HTTP methods. However, it also introduced new ideas that I hadn’t fully understood as much, such as the role of API versioning in preventing disruptions for existing users when introducing updates.

One particularly impactful takeaway was the emphasis on client feedback through proper HTTP status codes. In my past in class activities, I’ve realized that it is imporetnat for an API to clearly communicate success or failure states, yet I hadn’t prioritized this aspect. The value of using codes like 201 Created for successful resource creation or 400 Bad Request for errors, enhancing user experience.

Future Work

Going forward, I plan to apply these best practices to my API design tasks. For instance, in my upcoming assignments or personal projects, I will ensure that URL structures are logical and intuitive, aligning them with its resourced relationship. Additionally, I’ll pay closer attention to implementing proper status codes and securing APIs with HTTPS to protect sensitive data, such as ID or SSNs…

This resource has also inspired me to explore tools like Postman or Swagger for testing and documenting APIs.

Conclusion

The blog post Best Practices for REST API Design not only refreshed my technical knowledge but also provided ideas for creating APIs that are robust, secure, and user-friendly.

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

A lot of developers today mistakenly think that publishing code without a license automatically makes it free for public use. However, under copyright law, code without an explicit license is still technically the property of the original owner. That means that any users cannot legally copy, modify, or distribute it without permission. This can lead to legal disputes, misuse of the code, or anything the original owner did not intend. Posting code on GitHub without a license is defaulted to GitHub’s terms, which allows for limited collaboration but restricts use at larger scale.

When it comes to software projects, making sure you have the right license that fits the needs of the project is extremely important to how others interact with your code.  Typically licenses of this nature fall under two categories, a copyleft license or a permissive license.  A copyleft license, such as the GNU General Public License (GPL), ensures that any derivative works must retain the same license.  These licenses promote transparency and guarantee that the software and its derivatives remain open-source. This is for developers who want to foster a community, make improvements from others testing, and prevent proprietary derivatives.  However, some large companies may avoid this technique, as they could be giving a competitive advantage to other competitors interested in their work.  On the other hand, permissive licenses, such as the MIT or Apache 2.0 licenses, allow derivatives to be licensed under proprietary terms. This approach provides as much “freedom” as possible, while making it easier for businesses to use the code without copyright issues. While this can lead to a large increase in usage, it could get out of hand when companies don’t submit their versions of the code.

“How Copyright Works (Part 5): Copyright Licenses in Simple Terms”, is a short video by the Youtube channel What is Law Even.  It is the last installment of a 5-part series that explains the many rigid aspects of copyright law, and how it is used in the context of today.  This installment focuses on the basics of copyright law, and specifically the license aspect of the law.  The narrator explains what a copyright license is, and the possible royalties that may be attached to that respective license.  It is a great straightforward video that is short, but filled with quick bits of knowledge important in the copyright sphere.

In short terms, copyright licensing is extremely important when it comes to software development.  Licenses are a key part of a project’s workflow, and even when they aren’t explicitly stated, there is a good chance there is still one in the background.  Always be weary of the copyright laws as they are only there to protect owners from unlawful practices against their projects.

Link: https://www.youtube.com/watch?v=XjwOTNBRFpE

• Elliot Benoit

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