Recently in my Cs-443 class, Software Quality Assurance and Testing, we have been talking about unit testing using stubs. Honestly, I didn’t understand what stubs were during the classes themselves, but a blog called Why Stubs in Unit Testing Improve Integration Testing helped me understand what a stub is, as well as where and when it is used. In this blog written by Miroslaw Zielinski, he states ” Unit testing is more about isolating the function, method, or procedure, otherwise referred to as a unit. This isolation is done by stubbing out dependencies and forcing specific paths of execution. Stubs take the place of the code in the unit that is dependent on code outside the unit.” Stubs allow the person testing the code to test specific paths of execution within the code, allowing them to view different things such as if different parts of the code work and are reliable. I think that Zielinski gives a great example of why these stubs are used in his article. He states, “Once the stub is added, it will be consistently applied to the tested code. A user working on the “allocation failure” test case will have an easy way to install a special callback function into the stub, which will simulate the desired effect: allocation failure or do nothing since by default the stub returns a null pointer, which is expected for the test case.” This helped me understand why stubs are used, and the rest of the article helped me understand when they are used.

After reading more of the article, Zielinski began to explain why stubs are used. Although his explanation confused me a bit, I believe I got the jist of what he was trying to say. I believe that they are being used when you are trying to test lower-level modules while the upper-level modules have not been developed yet. Therefore you can use a stub, which acts like an upper-level module, in order to see how it will be treated. Zielinski also gives examples of when stubs aren’t good to use and what the limitations are “In instances where there’s not an original definition available for a stubbed function, what happens? How does the stub behave without a callback that defines the alternative behavior? The beauty of C/C++test is that it automatically detects this kind of situation. The stub will reconfigure itself during the test harness build time. It won’t call the original definition when no callback is installed and will return a safe default value.” I’m not really sure what he means by this, but I hope to learn more in the future.

Link: https://www.parasoft.com/blog/using-stubs-in-integration-level-testing/#:~:text=Unit%20testing%20is%20more%20about,on%20code%20outside%20the%20unit.

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.

System testing is a process of verifying the end behavior of a software application. System testing finds any errors, spaces, and missing requirements that could affect the software’s functionality. This is usually done after all the tests are completed, it’s important to test the software before releasing it to users. System testing main goals are to reduce risks, prevent defects, verify the design, and validate the system. System testing is an important step in ensuring the software is of great quality before it goes live. Addressing and identifying the errors or issues before making the software live can reduce any risks and make sure that it works perfectly for the users. Verifying the functionality of the completed system will help determine if it meets the requirements specified for that system. This is the best way to prevent any defects, errors, and missing requirements. System testing is also used to check if the system has been designed correctly and follows all the specifications. The process of verifying the accuracy and completeness of the system is the main objective of system testing. It’s to provide confidence that the system meets all of its requirements and will run as expected.

There are different types of system testing to look out for and plan for such as setting up the environment for the test case, creating a test case, creating test data, and running the test case. It’s important to make sure that the environment is set up so that you can write test cases by making sure that it has the right tools and frameworks that will be needed. When creating the test cases it’s important to make sure that the test case has all the necessary details about what the test case is testing for as well as how it will test it. The test data is created in thought of the inputs and outputs for the test case. While creating the test data it’s important to cover all of the critical fields and that nothing is left out. When running the test cases you want to make sure that it puts out the correct output, it should show if it passed or failed. I chose this topic because system testing is important to make sure that our system meets the requirements and runs without any problems. We started working on test cases recently so I thought getting more information on system testing would benefit our skills and any questions that anyone might have.

https://blog.qasource.com/what-is-system-testing-an-ultimate-beginners-guide

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

It’s certainly been a while since my last post. I’ve been slacking way too hard, especially with break, but now it’s time to lock in and focus on my work. 

For this blog post, I’ll be talking about Test Driven Development, or TDD for short. TDD is a “software development practice that focuses on creating unit test cases before developing the actual code.” It attempts to avoid or solve the issues that arise in “traditional testing.” TDD, rather than testing one big system, tests small chunks of code at a time. It also “follows an iterative process, where small chunks of code are developed, tested, and refined until they pass all tests.” This allows for errors to be found, debugged, and fixed as early as possible in the development process (BrowserStack).

In Kent Beck’s blogpost, “Canon TDD,” he lists the steps to properly adhering to TDD:

1. Write a list of the test scenarios you want to cover
2. Turn exactly one item on the list into an actual, concrete, runnable test
3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)
4. Optionally refactor to improve the implementation design
5. Until the list is empty, go back to #2

Being introduced to a process that differs so much from the “norm” and is also quite efficient and thorough is both refreshing and exciting to learn about. When this topic was first introduced in class, I was very lost but I picked it up not long after; but then again, the example we followed was a very simple one. Once we moved onto a more advanced one to work on within our groups, I was lost again. I understand the concept of Test Driven Development but putting it into practice, at least for now, seems pretty hard. It also seems like a skill that is easy to pick up but hard to master as some tests can be more beneficial than others when it comes to coverage or time management. 

I feel as though there are little downsides to TDD and when it comes to those downsides, they mostly lie in the capability of the individual. Forgetting to run tests, writing too many tests, writing too much for a test, and writing tests that are impractical are just some of the issues that may arise when using this practice. 

Overall, Test Driven Development is a practice that individuals and teams may want to use to try something new or to test if it’s more effective than their current one. It‘s a very different approach to the development processes that I’m familiar with but that’s not always a bad thing; and in this case, TDD seems like a great practice.

Sources Used:

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

https://tidyfirst.substack.com/p/canon-tdd

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

For this week’s blog post, I decided to discuss the article “Security Testing: Types, Tools, and Best Practices” by Oliver Moradov. I chose this article because it compliments the security testing topic in the syllabus. This article discusses the main goals of security testing and the key principles behind security testing, and several examples of security testing and testing tools. In this blog post I will be discussing the section on the main goals of security testing

The first section of this article discusses security testing. The article defines security testing as a series of tests determining if the software is vulnerable to cyber-attacks. “Security testing checks whether the software is vulnerable to cyber-attacks and tests the impact of malicious or unexpected inputs on its operations. Security testing provides evidence that systems and information are safe and reliable and that they do not accept unauthorized inputs.” The article also describes security testing as a non-functional form of testing, which means that security testing does not focus on the software’s functionality. Security testing fits more into the category of non-functionality testing, meaning that security testing tests whether or not the application is designed or configured correctly. “Security testing is a type of non-functional testing. Unlike functional testing, which focuses on whether the software’s functions are working properly (“what” the software does), non-functional testing focuses on whether the application is designed and configured correctly (“how” it does it). “

The main goals attributed to security testing mentioned in the article are: identify assets, identify threats and vulnerabilities, identify risk, and perform remediation. The article defines identify assets as: “things that need to be protected, such as software applications and computing infrastructure.” This is essentially what the name describes. It is about finding what needs to be protected. The article then defines identify threats and vulnerabilities as: “activities that can cause damage to an asset, or weaknesses in one or more assets that can be exploited by attackers.” Much like the prior goal mentioned, this one is also fairly self explanatory. It is about finding weaknesses within the software and possible threats that are present. The third main goal the article mentions, identify risk is defined as : “security testing aims to evaluate the risk that specific threats or vulnerabilities will cause a negative impact to the business. Risk is evaluated by identifying the severity of a threat or vulnerability, and the likelihood and impact of exploitation.” Unlike the prior main goals, which are more focused on finding specific instances of something, identify risk is about evaluating the risk being identified not finding it. The last main goal that the article discusses is perform remediation and it is defined as: “security testing is not just a passive evaluation of assets. It provides actionable guidance for remediating vulnerabilities discovered, and can verify that vulnerabilities were successfully fixed.” This main goal is also unique when compared to the prior goals because this goal is focused on finding a solution to a vulnerability.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The blog “Test Driven Development: The Best Thing That Has Happened to Software Design” explains the benefits of using Test Driven Development  in software development. It describes the focus on writing tests before writing the code, it emphasizes on how this approach will enhance software design, increase code quality, and allow for easier maintainability. The post highlights Test Driven Development’s ability to shift focus towards desired software behavior. I chose this blog post due to its relevance to the recently covered topics in class as well as how it can apply in writing better code. Test Driven Development is a topic that we just covered in class and I found it very interesting to see its uses and benefits.. Additionally, I am using this style of code in my CS-497 class which allowed me to further get hands-on experience with how Test Driven Development works.

After reading the blog post, I agreed with many of the points raised by the author of the blog. I found the idea of writing the tests first as a foundation of code construction seems like a great idea as when you are writing code you know how you want it to work which is how you will write the tests to make it pass. Once you have the tests you can write the code that will allow the tests that you have already created to pass. The idea of problem-solving to make the tests pass rather than troubleshooting seems like an efficient way of coding. The author highlighted an aspect of Test Driven Development that I found very beneficial as it can highly increase efficiency is how creating the tests first gives you better insight on how your code is not working properly. If you are getting the wrong output making your test fail you will know how to fix it better than without having that test in place.

This blog post allowed me to consider different aspects of solutions for coding because different styles have different benefits while developing  software. In addition, it reinforced the importance of writing clean, concise code and underscored the significance of thorough testing which are also key aspects of this class.Moving forward, I would like to and plan to incorporate the style of Test Driven Development more into my coding practices. By focusing first on test creation and then writing the code to make the tests pass, I can aim to enhance the efficiency and quality of my code. In conclusion, I believe that using Test Driven Development will increase my workflow and coding skills that will be beneficial not only in this class but potentially for the rest of my career.

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

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.

Common Defects in Software Development

In the fast-paced world of software development, the creation of bug-free software remains a significant challenge. Despite advancements in technology and methodology, software defects or bugs continue to impede the smooth functioning of applications. Understanding the reasons behind these defects is crucial for developing more reliable and efficient software systems.

1. Human Error: A Prime Culprit

Human error remains one of the primary sources of software defects. This can range from simple typos in the code to more complex errors in logic or algorithm design. Programmers, regardless of their experience level, are susceptible to making mistakes, especially when working under pressure or tight deadlines. To mitigate this, implementing a robust review process, including peer reviews and pair programming, can help in identifying and rectifying errors early in the development cycle.

2. The Complexity Conundrum

As software systems grow in complexity, the likelihood of defects increases exponentially. Complex systems require a deep understanding and meticulous handling to ensure all parts work seamlessly together. Breaking down the software into smaller, more manageable modules can aid in reducing complexity and making the system more understandable and less prone to errors.

3. The Testing Trap

A common pitfall in software development is insufficient testing. Skipping comprehensive testing phases or having inadequate test coverage can lead to defects slipping into the production environment. Adopting a continuous testing approach and utilizing automated testing tools can help ensure thorough examination and identification of potential issues before deployment.

4. Documentation Dilemmas

Inadequate or outdated documentation can significantly contribute to software defects. Proper documentation ensures that developers have a clear understanding of the software’s design and functionality, facilitating easier debugging and maintenance. Investing time in maintaining detailed and up-to-date documentation can save considerable time and effort in the long run.

5. Tool Troubles

The choice and use of software development tools can also impact the quality of the final product. Using outdated or unsuitable tools can introduce bugs into the system. It is essential to select the right tools that align with the project’s needs and ensure they are correctly integrated and used effectively.

Prevention is Better than Cure

Addressing these common causes of software defects begins with acknowledging their presence and potential impact. By taking proactive steps such as enhancing the development process, enforcing coding standards, conducting regular code reviews, and ensuring comprehensive testing, developers can significantly reduce the occurrence of defects.

Furthermore, fostering a culture that values quality and attention to detail can encourage developers to take the necessary time and care to produce higher-quality code. Investing in training and continuous learning can also equip developers with the skills and knowledge needed to avoid common pitfalls.

The link to the blog I chose : https://www.devstringx.com/why-bugs-or-defects-in-your-software

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

Summary:
The “Rubbing Elbows” pattern emphasizes the value of collaborative learning in software development. It acknowledges the limitations of solo work and advocates for the benefits of working alongside another developer. The pattern suggests that certain skills and insights can only be gained through direct collaboration with peers, leading to enhanced productivity and continuous learning.

Reaction:
The concept of “Rubbing Elbows” resonates deeply with many developers, including myself. While autonomy is cherished, there’s a unique energy that arises from collaborating with others. The ability to bounce ideas off one another, share insights, and tackle challenges together fosters a rich learning environment that is hard to replicate solo.

Interesting Insights:
What’s particularly interesting about this pattern is its emphasis on the micro-techniques and personal knowledge exchanged during collaboration. It underscores the idea that true mastery in software development extends beyond technical proficiency to encompass the subtle habits and practices observed in seasoned developers. The notion of absorbing such knowledge through proximity and shared experience is compelling.

Impact on Professional Outlook:
This pattern has certainly influenced my perspective on professional growth within the software industry. It reinforces the importance of seeking out opportunities for collaboration, whether through pair programming, open-source contributions, or project partnerships. It has shifted my focus from purely technical skills to include the creation of collaborative abilities and interpersonal dynamics.

Disagreements and Considerations:
While the benefits of collaborative learning are evident, the pattern acknowledges that it’s not always a seamless experience. Instances of feeling lost or outpaced by a partner are common, requiring perseverance and effective communication to overcome. Additionally, the pattern raises awareness of the need to evaluate the effectiveness of collaborative practices like pair programming and make adjustments when necessary.

In conclusion, “Rubbing Elbows” serves as a reminder of the invaluable growth opportunities that arise from collaborative attempts in software development. By embracing this pattern and actively seeking out opportunities to work alongside peers, developers can enrich their skill sets, broaden their perspectives, and ultimately thrive in their professional journeys.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.