The blog post highlights the qualities as well as the differences between these two types of testing, static testing and dynamic testing. I chose this blog post because as this course covers software quality assurance and testing as well as the fact that we have spent time in class covering these two types of testing I believe that this blog post is able to highlight and reinforce core concepts that will be able to assist in gaining further knowledge withing this class. In addition, the blog post is able to explain the information regarding static and dynamic testing in a simple and easy to understand format that further compliments the idea of using this blog post as a resource to reinforce these topics.

The blog post as previously discussed covers static testing vs dynamic testing. We learn that static testing involves testing the code without actually running it while dynamic testing involves running the code to test it’s outcomes through various testing circumstances. From those two descriptions we can tell how static testing relies on testing through software documentation as well as the design of the code itself. However, dynamic testing is able to execute the program allowing the testers to test how the code will work in an assortment of testing scenarios. This concept allows testers to see how the code will work once it is released to the public to verify that it works as intended. These two types of testing are very different in their methods of achieving a successful test. Static testings wants to identify problems and improve on them early in development while dynamic testing wants to validate the performance and functionality of the code once it is in a executable state. Since they have different intents your requirements for the project is what determines what testing you will choose.

From what I have learned from the blog post I believe it was very helpful and was able to reinforce core concepts that will help me further in this class. I believe learning more about static and dynamic testing will help me when it comes to working in this class as well as assist in knowing how to test in a professional setting. Knowing the core differences between the two will allow me to know what type of testing will be best for certain circumstances when it comes to projects. In conclusion, this blog post was very helpful and will be utilized in the future.

https://testsigma.com/blog/static-testing-and-dynamic-testing

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.

A Critical Component of Software Quality Assurance

I was based to this blog: https://www.celestialsys.com/blogs/software-testing-boundary-value-analysis-equivalence-partitioning

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

Among various testing techniques, equivalence class testing stands out as an efficient method for cutting down the number of test cases required while maintaining thorough test coverage. 

Equivalence class testing is based on the principle that inputs can be grouped into equivalence classes that exhibit similar behavior. By selecting representative test cases from these classes, testers can efficiently cover various scenarios without testing every possible input value individually. This technique is the best of both worlds, optimizing test case selection all while maintaining thorough test coverage; as those from ProfessionalQA.com put it, both the quality of test cases as well as testing as a whole is enhanced “by removing the vast amount of redundancy and gaps that appear in the boundary value testing.”

Equivalence class testing has four variations, each of which have their own benefits, downsides, and uses. They are determined using the combinations of two factors, the number of test cases and whether only valid values are tested or both valid and invalid are tested Thus, in terms of equivalence classes, we have weak-normal, strong-normal, weak-robust, and strong-robust. Weak-normal has few but effective tests and only covers the valid equivalence classes, strong-normal covers every valid equivalence class, weak-robust is like weak-normal but includes an invalid equivalence class(es) as well, and strong-robust covers every valid and invalid equivalence class. One thing to note about strong-robust equivalence class testing is that there is some redundancy when it comes to testing the invalid equivalence classes.

Equivalence class testing was a bit hard to pick up initially but it really clicked thanks to some visual aid, that being the graphs of the variations of equivalence class testing. With this visual, I was able to understand how effective equivalence class testing is and why some will want to use it. It allows testers to “focus on smaller data sets, which increases the probability to uncovering more defects in the software product” and may reduce the possibility of error on the tester’s part. With other testing techniques that are more difficult or time-consuming when it comes to larger data sets, equivalence class testing is a great alternative.

https://www.professionalqa.com/equivalence-class-testing

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

Today, the next meal on my menu of headaches is Decision Table-Based Testing, which as the name suggests is a table of tests to ensure that your software is working as intended and not printing “Hello World!” when you try to generate your salary. I may be downplaying it somewhat but the truth is that it might be one of the best weapons against bugs in software development.

This approach is all about making sure your app or software doesn’t throw a tantrum under different situations by planning out every possible scenario in a neat, organized table. It’s a bit like planning a massive party and making sure you’ve thought of everything, so nothing goes wrong (well, almost nothing).

Imagine you’ve got a bunch of switches and dials that can be turned on, off, or dialed up to eleven. Decision tables help you figure out what happens to your software when you mess with those controls in every possible way. It’s a clear, visual way to lay out the “if this, then that” of your app’s behavior. This is very handy because it turns the headache of thinking through a million combinations of inputs and outcomes into something manageable.

What’s awesome about this is how it simplifies the chaos. You get this big-picture view of how different inputs play together and affect your software, making it easier to spot where things might go wrong. It’s like having a map when you’re in a maze, showing you all the paths you can take.

Starting to use Decision Table-Based Testing is pretty straightforward. You write down all the things that could change or affect your software (conditions) and what should happen in response (actions). Then, you mix and match these conditions to cover all your bases. This method is a fantastic way to find those sneaky bugs that only show up under specific conditions and to make sure your software is rock solid.

“But Ano, what if you update the app and add new stuff?”. As your app grows and gets more features, you can just update your decision table to keep up. It’s a flexible, scalable way to keep your testing game strong, no matter how advanced or complex your software gets.

Sure, it might sound a bit daunting, especially with super complicated apps. But, with the right tools and a bit of practice, it becomes a lot less scary. It’s about making the effort now to save a ton of headaches later when you’re not chasing down weird bugs half an hour before a project is due.

In the end, Decision Table-Based Testing is all about making your life easier and your software better. It’s a way to tackle the complexity head-on, with a clear plan and a cool head. And who doesn’t want that? So, if you’re in the business of making software, give it a whirl. It might just be the thing you need to keep those bug boogeymen at bay.

Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

In the vast world of computer science, there are various techniques employed to ensure the reliability and efficiency of software systems. Two such techniques that play a crucial role in software testing are Decision Tables and Program Graphs. Let’s delve into what they are and how they contribute to the realm of computer science.

Decision Tables: Decision Tables are a systematic and structured way of representing complex decision-making processes. Imagine a scenario where a software program needs to make different decisions based on various conditions. These conditions can lead to different outcomes or actions. Decision Tables provide a visual representation of all possible combinations of conditions and their corresponding actions, making it easier to analyze and test different scenarios.

To understand Decision Tables better, think of a flowchart but with a more organized and concise format. Each column represents a condition, and each row represents a combination of conditions along with the corresponding action to be taken. By systematically analyzing all possible combinations, testers can ensure that the software behaves as expected under different circumstances.

Program Graphs: Program Graphs, on the other hand, offer a graphical representation of the control flow within a program. They depict how the program transitions from one state to another based on different inputs or conditions. Program Graphs help testers visualize the execution path of a program, identifying potential areas of concern such as loops, branches, or unreachable code segments.

These graphs aid in understanding the program’s behavior and facilitate the creation of comprehensive test cases to ensure thorough testing coverage. By traversing the program graph, testers can validate different paths and verify the correctness and robustness of the software.

DD Path Testing: DD Path Testing, short for Data Flow and Control Flow Path Testing, utilizes graphs to identify and test various paths through a program. It combines both data flow and control flow aspects to ensure comprehensive testing coverage. By analyzing the flow of data and control within the program, testers can identify potential vulnerabilities, errors, or inefficiencies.

By integrating Decision Tables, Program Graphs, and DD Path Testing into the software testing process, developers and testers can enhance the quality and reliability of software systems. These techniques enable thorough testing coverage, helping to identify and address potential issues early in the development lifecycle.

Here are two web links where you can find more information about Decision Tables, Program Graphs, and DD Path Testing:

1. Decision Tables – Geeks for Geeks
2. What is Graph in Data Structure & Types of Graph?

Talking about these topics is essential because they form the backbone of effective software testing strategies. By understanding and implementing these techniques, developers and testers can ensure that software systems meet the desired quality standards, resulting in enhanced user satisfaction and trust.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

As we move onto more code-based testing in class, I wanted to review some of the black box testing techniques we’ve gone over in class, especially since the most recent homework was somewhat confusing for me.

I’ll start off with boundary value testing. According to a blog post on SDET Unicorns, boundary value testing tests valid inputs in the domain (minimum, maximum, and one below and above them respectively), invalid inputs that are close to the domain, and any special inputs, such as empty strings or null pointers. This technique’s main use is testing boundaries, that is, it’s mostly concerned with whether or not invalid inputs are properly dealt with, and valid inputs are processed as valid. The drawback, as we discussed in class, is that it doesn’t really describe the different cases of valid inputs if there is branching taking place.

Equivalence class testing addresses this issue. From the same post above, equivalence class tests (or partitions, in the author’s words) divide inputs into, well, equivalence classes, or groups of input where behavior is expected to be the same. This also means that there are multiple groups of valid inputs, meaning this approach can effectively test different cases of valid inputs based on the specifications, rather than just testing if valid and invalid inputs behave as expected.

The reason why I wanted to look at these two specifically is because they are vital to understanding the decision table-based approach. I’m fairly confident in this approach because I found it fun to work with in class. It’s essentially a visualization and simplification of both boundary value and equivalence class testing, mostly equivalence class testing though, at least in my interpretation. The reason why I find it easier to work with decision tables is because they are much more efficient with regards to the space you use, even if the amount of mental work you have to do is larger.

It’s interesting because I found, in the homework at least, writing out test cases and the like for the non-table based approaches was somewhat frustrating because you have to consider each case even if they do the same thing, and write them out. With decision tables, you can optimize values into ‘dont cares,’ meaning that if the output is solely dependent on one of multiple inputs in this specific equivalence class, so you don’t have to care about what class the other values are. I really enjoy how this cleans up the entire process of black box testing. That being said, I understand that this can become very difficult to test as the complexity of a project increases.

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

https://web.dev/articles/ta-test-cases

Last week, we tracked the path a program would take using program graphs. The program graph is good to represent the overall structure of a program; it shows all the ways the code can go. 

Afterwards, I wondered about the other types of paths a program could take, whether it be the best case, worst case, etc. That’s when I found Ramona Schwering’s article about test cases and happy paths.

Although I primarily read this article for it’s definitions and information on the different paths a software could provide, it also covers the idea of a test case and how to prioritize the right ones. Schwering first reminds us what a test case does whilst checking the results of the program: it verifies the program does what it’s intended to do, and it validates the program is what the customer or user wants. 

Next, Schwering explains what drew me to the article in the first place: test paths and their outcomes. The first path is known as the happy path, since it applies to the most common use case of your program; this is what should happen and what we want to happen. The second path is the scary path, which is used to catch errors and ugly outcomes. 

Schwering lists other test paths that aren’t used as frequently as the first two but could be important to recognize. I’ll talk about a few I find interesting.

• An angry path is supposed to get an error; making sure error handling works.

• A desolate path would be important for programs dealing with input data, as it tests to see if it’s given enough data to function correctly. 

Lastly, Schwering goes over the best practices for writing test cases, and how there are two patterns used to structure the cases: Arrange, act, assert and Given, when, then.

I selected this article because it covered my topic of interest and I also enjoyed Schwering’s straight to the point, easy to understand writing style. I decided to do a deeper dive on Schwering herself and found she’s a software developer and tester that speaks at international conferences worldwide. Reading through the post, I found the organization of the information to be helpful in my learning along with the information itself being reflective of my thoughts on our recent classes. 

The content Schwering provides in this article is great for a quick read for anyone wanting to learn more about testing. I personally believe the paths she went over are important to prioritize, especially happy and scary paths. I refreshed myself on the duties of a test case and learned multiple kinds of test paths, and how their importances varies from situation to situation. I enjoyed this article especially due to Schwering’s little illustrations and how easy it was to understand the paths. I hope to create test cases in the future with these paths in mind, using them to my advantage when possible.

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.

Once you learn to test your code, another thing you have to worry about is testing it as efficiently as possible. You can just write tests and hope that it ensures your code works effortlessly, but it may not always catch everything that can go wrong. Adopting some strategies and methods will be important in helping you determine how to go about testing your and managing that. 

There are a number of strategies that you can use and adapt. Early on in class, we went over some strategies very quickly that can be used or serve as a good base. Some of these consisted of black box and white box testing, dynamic and static testing, and some others. Each has their own way of testing, some can be better than others. Ultimately, it’s up to you to determine and figure out which one best suits you, the way you want to do things, and your code.

In this blog post, Janki Mehta writes about testing strategies, its key components, approaches, and some specific ones. They describe testing strategies as plans of “how software testing will be approached, executed, and managed throughout the software development life cycle.” They then describe the key components of the strategies, which are scope and overview, testing methodology, test environment specification, release control, risk analysis, testing tools, and review and approval. They dive into detail with the two approaches, proactive, where it focuses on detecting and catching bugs and defects before they even occur, and reactive, where it focuses on catching them afterwards. Some strategies they list were black box and white box testing, but some others too, like integration testing and regression testing, also describing what each of them are. At the end of the article, there are some final tips that can help easing the testing process and creating a comfortable environment when it comes to testing.

Knowing good strategies is important for testing code, and knowing multiple ones is even more important. It allows you to look around and figure out which fits best for your code and software, and adapt to it. Testing code can and probably will be difficult to get right all the time, learning all you can and having additional resources will be beneficial. I think that Mehta wrote a good article, it covers a lot of material, some of it can be seen as extra but it doesn’t hurt to know extra information, even if you can’t use it now. It’s clear the article is meant for a team to use as reference, but anyone can use it, not just a team. 

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