This week I decided to touch on static and dynamic testing. I wanted to find a blog that talks about different techniques for each type of testing. While searching I found the blog Static Testing VS Dynamic Testing – Key Differences testing by Kiruthika Devaraj. It first begins by generally defining the two types of testing. Devaraj first defines static testing as involving “testing the software without running it” and dynamic testing as involving “executing the program and testing its behavior in different scenarios”. They then go on to explicitly outline the differences in the next section. 

In the section titled “Differences Between Static Testing and Dynamic Testing”, they explain that static testing involves reviewing the documentation, design or code to check for defects and errors without executing the software. They also mention that this type of testing aims to identify issues early in software development when they are easier and less expensive to fix. They explained that dynamic testing involves executing the software and testing its behavior in different scenarios. They explain that during this process testers create test cases and run tests to identify defects and ensure the software meets the specified requirements. By testing the program against a variety of inputs, expected outputs, and error scenarios, this kind of testing essentially tries to evaluate the product’s functionality, performance, and security and ensure that it operates as predicted. In this section, the author uses bullet points and spacing to organize the information and make it easier to digest. 

The next section is a table that clearly outlines the differences in features like definitions, objectives, types of testing, timing, and results for static and dynamic testing. Static testing involves code review, walk-through, and inspection while the other involves unit, integration, system, acceptance, performance, security, and user acceptance testing. The author then explains how to choose between the two types of testing. They mention that it comes down to the specific requirements, objectives of the testing process, and desired outcomes. I enjoyed this article because the author got straight to the point when writing the article while clearly defining the use of each type of testing. I think the way they went about writing this informational piece was effective in keeping the reader’s attention by outlining the information in the simplest way possible. The use of bullet points and tables helped me to remember the information better. I am likely going to have to test my future personal projects so knowing the differences between the two types of testing and how to choose it was important to read about.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Unfortunately, just weeks after exploring test-project’s blog, it was shut down and replaced by a new blog in Tricentis. I was disappointed to find that I could no longer utilize this great resource. In searching however, I found that test-project was on its way out as far as automated testing goes, and this reaffirmed to me the ever changing world of software. In response I looked for blogs to improve my testing skills individually once more, and explored stickyminds again. The article I chose explained how practice can affect your software testing skill. The article’s title is Repetition in Practice by Justin Rohrman.

The article explores the pivotal role of repetition and practice in software testing, just as you would need in any other interest, like music. The author mentions his own experience with music in fact, and used his practice with music to inspire his software testing strategies. The article highlights the significance of deliberate practice in honing testing skills, advocating for an adaptive approach that considers the unique context of each testing scenario. A large failing of many software developers is the lack of practice, or lack of practice strategies. The article delves into some various methods for practicing software testing, to show how it connects with other interests. The most effective method introduced in the article is the ability to relate your own testing specific goals to other interests. For example: Heuristics is mentioned, and the author mentions if you like ‘Scrabble’ to play scrabble while thinking of heuristics and apply them to Scrabble. This will improve your skill in heuristics and allow you to improve it in your testing. This is an excellent strategy to help the mind focus on coding when other interests take priority. Overall the article emphasizes the importance of maintaining a growth mindset and embracing opportunities for learning and experimentation to refine testing proficiency. Outside of the article itself, there is a very valuable comment made by Michael Larsen. This comment mentions how testing is more subjective and abstract, and that it’s important to persevere when practicing. This is because unlike things like music, there are very little measurable improvements that you can see yourself, and you often have to wait for others to notice the improvements. This was an excellent thought provoking comment.

Through the CS-443 course, I have been considering how testing will play a role in my professional career and how I will develop these skills along with development. These kinds of practice strategies give me an engaging way to turn my brain into the mindset to code. This is very valuable to me, as often I can get very distracted. To be able to turn distractions into sources of thought for my own coding will be absolutely essential to developing my skills further. I chose this blog because I wanted to hone my skills but lack strategies to do so, and this applies beyond just testing for me.

Source:
https://www.stickyminds.com/article/repetition-practice?page=0%2C0

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

This week’s blog topic was chosen simply because I had zero knowledge of the term/topic. Jake Holy’s blog on Stochastic and Property-Based Testing blog covers the uses of each testing and effective tools used to implement each. Stochastic testing refers to the testing method that uses random inputs to test the behavior of the program. Rather than using predetermined inputs for test cases, stochastic utilizes various inputs to find unexpected bugs in the program. The main purpose of stochastic testing is to uncover errors through unorthodox methods. This method offers a wide testing coverage by testing all possible scenarios that might go unnoticed with traditional testing.

Property based testing refers to the method of testing by describing what the software should do rather than creating distinct test cases. Initially, testers establish properties that describes what the code should always do. This method of testing utilizes tools that automatically generate test cases to test these properties. After generating these cases, random inputs are utilized to ensure the properties are followed. The benefit of this testing method is testers are only required to declare the properties the code must follow. Instead of manually creating test cases and risking the possibility of missing a test case, these cases are generated for them. Property based testing guarantees effective test coverage. Additionally, this form of testing allows testers to focus on the abstraction and behavior of their code, allowing for a more robust product.

The blog goes in-depth with various testing tools, for example, a testing library created for the Haskell programming language called QuickCheck, which allows developers to write properties for their code which is automatically generated into test cases. QuickCheck has become a very popular tool to use for testing due to its automation, which is why it has been ported to other programming languages like Python and Scala.

The second tool that the blog mentions is Stimulant for Clojure. Similar to QuickCheck, Stimulant allows developers to define properties and it automatically generates test cases to test your program.

One thing that is mentioned in both testing libraries is shrinking. Shrinking refers to the method of finding the smallest input of a failing case, allowing developers to precisely pinpoint areas in the program that is causing the test case to fail. It is crucial that developers know their program has failed a test case, but it is even more crucial that they know why, so they can effectively fix the problem.

Blog: https://blog.jakubholy.net/2013/06/28/brief-intro-into-randomstochasticprobabilistic-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

PATH TESTING.

Path testing is an approach to testing where you can ensure that every path through a program has been executed at least once. However, testing all paths does not mean that you will find all bugs in a program. There are some steps involved in path coverage testing. Step one is code interpretation. It is important to carefully understand the code you want to test. The next step is constructing a control flow graph. It shows the nodes representing code blocks and edges for the movement of control between them. The third step is determining the paths. This entails following the control’s path from its point of entry to its point of exit while considering all potential branch outcomes. While determining paths, you’ll also consider loops, nested conditions, and recursive calls. It is important to list every route like giving each path a special name or label so you can keep track of which paths have been tested. The next step is testing case design. Create test plans for each path that has been determined, make inputs that will make the program take each path in turn. Make sure the test cases are thorough and cover all potential paths. Examine the test results to confirm all possible paths have been taken. It is important to make sure the code responds as anticipated.

Some advantages of path testing is it helps reduce redundant tests, it focuses on the logic of the programs and it is used in test case design. Some cons of using path testing is the test case increases when the code complexity is increased, it will be difficult to create a test path if the application has a high complexity of code and some test paths may skip some of the conditions in the code. There are three path testing techniques which are Control Flow Graph (CFG) – The Program is converted into Flow graphs by representing the code into nodes, regions, and edges. Decision to Decision path (D-D) – The CFG can be broken into various Decision to Decision paths and then collapsed into individual nodes. Independent (basis) paths- Independent path is a path through a DD-path graph which cannot be reproduced from other paths by other methods. I chose these two resources because they go more in depth about path testing and help explain it well. One of the sources talks about the pros and cons of using path testing, the types of path testing which I didn’t know before this.

References.

https://www.geeksforgeeks.org/path-testing-in-software-engineering

https://www.tutorialspoint.com/software_testing_dictionary/path_testing.htm

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

In the realm of software development, testing is a critical phase that ensures the quality and reliability of the product. This week, my exploration led me to a compelling resource that sheds light on an integral part of testing methodologies: the use of stubs. Stubs are simplified, replaceable components that mimic the behavior of real software modules, allowing testers to isolate and test individual parts of a program. The resource, an insightful article titled “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” provided a comprehensive overview and practical advice that I found particularly enlightening.

The reason I selected this resource was its direct relevance to our current course material on software testing methodologies. As we delve into the complexities of ensuring software reliability, understanding the role of stubs becomes indispensable. This article not only introduces the concept but also illustrates its application with clarity and precision, making it an invaluable tool for beginners and seasoned developers alike.

Upon reading, I was struck by the depth of information presented. The article begins by defining stubs and differentiating them from other testing techniques such as mocks and drivers. It then delves into practical scenarios where stubs can significantly enhance the testing process, such as in unit testing and integration testing. The step-by-step guide on implementing stubs, complete with examples in popular programming languages, was particularly useful.

Reflecting on the content, I realized the importance of stubs in creating a controlled test environment. By simulating specific components, stubs enable testers to pinpoint errors more efficiently and focus on testing the functionality of individual units without the complexity of the entire system. This not only streamlines the testing process but also improves the accuracy of test results.

The application of what I learned from this article to my future practice is clear. I anticipate using stubs to conduct more effective and efficient testing, particularly in complex software systems where isolating components can be challenging. The hands-on examples provided will serve as a reference guide as I implement stubs in my projects.

For those interested in diving deeper into the subject, I highly recommend reading “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” This resource has significantly enhanced my understanding of stubs in software testing and equipped me with practical skills that I look forward to applying in my future endeavors.

Resource Link: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

As we continue to explore the vast landscape of software testing, I am excited to share more discoveries and insights. Stay tuned for more reflections and learning experiences.

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.

Summary of the Pattern: “The Deep End” pattern is about deliberately taking on roles or projects that stretch your abilities beyond your current comfort zone. It’s predicated on the idea that significant professional growth often comes from tackling challenges that seem slightly beyond our reach. This pattern encourages individuals to seek out opportunities that demand a rapid acquisition of new skills and adaptation, thereby accelerating their learning curve and enhancing their resilience in the face of complex problems.

My Reaction: Upon first reading about “The Deep End,” I was both excited and intimidated. The idea of purposefully putting oneself in challenging situations as a strategy for growth is as daunting as it is inspiring. This pattern speaks to a deeper truth within professional and personal development: growth is not found in the comfort zone. My reaction is a mix of eagerness to apply this pattern in my own career trajectory and a cautious awareness of the balance required to avoid being overwhelmed by challenges.

Insights and Changes in Perspective: Reflecting on “The Deep End” has led me to reassess my own career path and the opportunities I’ve chosen to pursue. It made me realize that some of my most rewarding experiences came from times when I was out of my depth, forced to learn, adapt, and grow in ways I hadn’t anticipated. This pattern has shifted my perspective towards seeing high-pressure situations not as threats but as opportunities to push my boundaries and accelerate my growth. It’s a mindset shift that encourages embracing challenges as catalysts for development.

Disagreements and Critiques: A possible critique of “The Deep End” is the risk of burnout or failure when taking on too much, too soon. The balance between challenging oneself and knowing one’s limits is delicate. While I agree with the core premise of the pattern, it’s crucial to approach such situations with a clear understanding of personal and professional support systems and a realistic assessment of the risks involved. It’s about finding the right challenges that push you without pushing you over the edge.

Conclusion: “The Deep End” pattern offers a powerful framework for thinking about professional growth and development. It challenges us to redefine our relationship with discomfort and uncertainty, viewing them as necessary elements of meaningful progress. As I look to the future, I’m more open to opportunities that may initially seem daunting, with the understanding that these experiences are invaluable for developing the skills, confidence, and resilience needed to succeed in an ever-changing professional landscape.

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.

In this blog post, we will delve into the realm of copyright protection, licensing, and explore how to use content ethically on your blog.

Copyright Fundamentals

Copyright is the legal foundation asserting that creative works such as art, writing, images, and music belong to their creators. Anything you create and record in a lasting form is your intellectual property. Others cannot legally copy or profit from your work without your permission.

Types of Licensing: Traditional Copyright, Creative Commons, and Public Domain

1. Traditional Copyright: Strict protection; requires permission for use, adaptation, copying, or publishing.
2. Creative Commons: Allows usage under specific conditions set by the creator (e.g., attribution, non-commercial use, no derivative works).
3. Public Domain: Completely unrestricted use, no permission needed (applies to works published before 1923, creations of long-dead creators, or works intentionally placed in the public domain).

Using Public Domain and Creative Commons Content

Public Domain Content

No restrictions on usage, but identifying such content can be challenging. Useful sites include:

• Prelinger Archives
• U.S. Government Photos and Images

Creative Commons Content

Free to use but with conditions set by the creator. License types include attribution, non-commercial use, no derivative works, and share alike. Sites for finding such content include:

• Wikimedia Commons
• Flickr’s Creative Commons Search
• Creative Commons Search

Using Copyrighted Material

Fair Use Guidelines

Fair Use allows limited use of copyrighted material for purposes like commentary, criticism, reporting, and teaching. Guidelines include:

• Majority of content must be your own.
• Properly credit the copyright holder.
• Non-commercial use is generally safer.

Misusing Copyrighted Material

Even with good intentions, a copyright holder may disagree. Consequences may include blog shutdown or legal action. Remove contested content if requested.

Licensing Copyrighted Content

To use copyrighted material outside of Fair Use, obtain a license. Stock photo sites for licensed content include:

• iStockphoto
• Photos.com
• Fotolia

Sharing Copyrighted Videos

Embedding videos from YouTube or Vimeo is common, but beware of copyright violations. Ensure the video creator is credited. Illegally shared videos may lead to removal.

Protecting Your Intellectual Property

Your content is also protected by copyright. Safeguard it by:

• Using plagiarism search services (e.g., Copyscape).
• Setting up Google Alerts for excerpts of your posts.
• Adding watermarks to your images.

What to Do if Your Content Is Misused

Contact the blogger or site using your content, requesting removal or proper credit. If unsuccessful, consider filing a DMCA takedown request, following legal procedures outlined in the Digital Millennium Copyright Act. Remember, respecting copyright and licensing not only preserves the rights of content creators but also upholds the integrity of your blog. Happy and responsible blogging!

https://edu.gcfglobal.org/en/blogbasics/copyright-and-fair-use/1/#

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

In this week’s blog post, I will discuss the article “The Different Types of Software Testing” by Sten Pittet. This article discusses different kinds of tests, some differences between manual and automatic testing, and how to automate testing. I chose this article because it fits well with the software testing section of the syllabus. I also liked how the author went into great detail about the tests mentioned in the article. In this blog post, I will discuss some of the software testing methods in the article.

The first test discussed in the article is the unit test. “Unit tests are very low level and close to the source of an application. They consist in testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.” From what is mentioned in the article, unit tests appear to be immensely helpful in testing smaller pieces of a program. Due to their ease of automation, they could also be beneficial for parts of a program that occur often. The following tests discussed in the article are integration tests.

Integration tests are imperative to ensure different parts of your program function well together. “Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.” While these tests are very helpful, due to requiring multiple systems to be running simultaneously, this type of test can be very costly to run regularly. The next test that I will discuss is the functional test.

Functional tests are very different from the prior two tests I have discussed, wherein the first two tests check the functionality of sections of your project. In contrast, available tests explicitly check for the project’s output. “Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.” This test is beneficial for the business application of a project. In contrast, the project’s pieces must function for the customer, and the project as a whole must also do what it was designed to do, and functional tests are great for determining this.

Article: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

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.