I chose this blog because I wanted to learn about methods for ensuring thorough test coverage while minimizing effort. During my research, I stumbled upon an intriguing article on TestSigma about decision table testing. I was particularly intrigued because it offers a structured approach to managing complex decision-making scenarios in software applications. Because I am still working on my programming and testing skills, I found this technique particularly useful for systematically identifying various input conditions and their expected outputs.

Decision table testing is a black-box testing technique that allows testers to organize input conditions and associated output values in a structured table format. This method is especially useful in software applications where multiple variables affect the output. By organizing all of the factors into a decision table, testers can ensure that all possible combinations of inputs and expected outcomes are thoroughly covered, with no gaps in test coverage.

For example, consider an online banking system in which a user can only transfer money if his or her account balance is sufficient and the authentication process is successful. In a decision table, this scenario would have four different combinations:

• Sufficient balance and successful authentication.

• Enough balance and failed authentication

• Insufficient balance with successful authentication.

• Insufficient balance and failed authentication.

Each combination would be associated with the corresponding expected outcome, ensuring that all scenarios were tested. This structured approach ensures that no critical test case is overlooked, allowing testers to avoid missing edge cases or rare conditions that could lead to system failures.

I chose the TestSigma article because it explains decision table testing in an understandable, simplified manner. Although most other methods of testing may be involved, this one is broken down in depth and includes real-life examples, making it easier for even beginners to understand. The other articles I found were either too technical or too shallow and disorganized, whereas this one managed to strike a balance between the two.

Decision tables are a simple way to solve complex decision-making scenarios in software. It is structuring the input conditions and expected outcomes in order to provide more comprehensive test coverage while avoiding redundancies. The above article provides the most lucid and applicable example of the technique, making it an extremely useful tool for students like me. I’m still honing my programming and testing skills, learning structured testing methods like the decision table, so I can create very efficient, thoroughly organized, error-free tests, preparing me for a future in software development and testing.

Blog: https://testsigma.com/blog/decision-table-testing/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

Intro

Software testing is an essential part of the development lifecycle, ensuring that applications function correctly and efficiently. The blog post “Static Testing vs. Dynamic Testing” by TatvaSoft provides an insightful comparison and description of these two fundamental testing approaches.

Summary Of The Source

The blog post explains the key differences between static and dynamic testing, their benefits, and when to use each approach:

1. What is Static Testing? This type of testing is performed without executing the code. It involves reviewing documents and conducting code inspections to detect errors early in the development process.
2. What is Dynamic Testing? Unlike static testing, dynamic testing requires running the code to identify issues related to performance, security, and functionality. It involves techniques such as unit testing, integration testing, and system testing.
3. Advantages of Static Testing: Helps detect issues early, reduces debugging costs, and ensures adherence to coding standards.
4. Advantages of Dynamic Testing: Identifies runtime errors, ensures the software behaves as expected in real-world scenarios, and validates functional correctness.
5. When to Use Each Method? Static testing is best used in the early stages of development to catch errors before execution, while dynamic testing is crucial before deployment to validate real-world performance.

Why I Chose This Blog

I chose this blog because it breaks down the question of static vs dynamic testing really well. It has clear sections that serve their purpose of answering the important details, such as what they are, their benefits and disadvantages, and even comparing them. It’s a great blog to check out for anyone new to this by keeping it clear and understandable. 

Reflection

The blog reinforced how skipping dynamic testing can lead to undetected runtime issues, which can be costly and damaging after release. One key takeaway for me is the necessity of balancing both testing methods. Relying solely on static testing may overlook execution-related issues, while dynamic testing alone can result in avoidable errors slipping into the later stages of development. A collection of both is needed or at least most optimal, but practicing good static testing early makes it so that the dynamic testing which comes later is less prone to errors.

Future Application

I think in the future, when going about testing software, I will definitely keep in mind these two methodologies and probably incorporate them both as I think static testing is very valuable to prevent any errors or bugs before running but dynamic is really useful to actually see the end functionality as you’re testing. It’s an important topic to know as correct testing methodologies and practices keep code clean and working properly.

Citation

TatvaSoft. (2022, November). Static Testing vs. Dynamic Testing. Retrieved from https://www.tatvasoft.com/outsourcing/2022/11/static-testing-vs-dynamic-testing.html.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

This week in class, we learned about test doubles. Test doubles are make-believe objects in code that take the place of actual objects for testing purposes. Test doubles are a great resource if you are working on a team project and your collaborator’s code is incomplete or not there at all. The test doubles we went over in class are dummies, fakes, stubs, and mocks. And being honest, I didn’t have the best understanding of it at first. But creating stubs in Activity 12 gave me a greater comprehension, as well as interest in it. Upon doing a little more research on stubs, I found a blog all the way from 2007 called Unit Testing with Stubs and Mocks. The blog compared stubs and mocks to each other, as well as which test double is more useful.

Stubs

Stubs are used by implementing part of your peer’s code as a concrete class. How much of the collaborator code needed depends on the minimum code needed to properly test something in the class. A stub’s job is to do nothing more than return the expected value needed for the test to pass. Stubs can also be implemented inside the test class. This saves the tester a lot of time because the stub class now becomes a separate, anonymous declaration. As a result, the same stub does not have to be reused across multiple unit tests. And since the stub becomes a separate declaration, the number of stubs used in a project becomes significantly lower.

A drawback from this however, is that the separately declared stub does not account for any changes that your peer might make to the code. This can mean a lot of work for the tester because new methods and variables may need to be declared. As a solution to this case, it is recommended that a base class is created in the test directory of your project. This way, if a collaborator makes an update to the code, you limit the amount of work you do by only updating the base class.

Mocks

Mock objects are used to obtain a high level of control over testing the given implementation. Mock object generators such as EasyMock and JMock are great tools that create mock objects based on the class being tested. If a test fails in EasyMock, it will create an obvious message. When testing with stubs, it is uncertain whether the test will fail or not. This however leads to constant changes made to the test cases. But through constant updating, the unit tester gains a greater knowledge of the implementation.

When to Use

In the case of which is better between stubs and mocks, there is no wrong answer. There are scenarios where using stubs will fit the test better, but there will also be scenarios where the usage of mocks is the better option. For example, if you need to nest a method call on the collaborator, then stub objects are the way to go. Mocks are more robust than stubs, but stubs are easier to read and maintain. However, mock users say that it is worth it to use mocks over stubs in the long term.

Reference

https://spring.io/blog/2007/01/15/unit-testing-with-stubs-and-mocks

From the blog CS@Worcester – Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

When developing robust software systems, ensuring reliable and efficient testing is paramount. Yet, testing can become challenging when the System Under Test (SUT) depends on components that are unavailable, slow, or impractical to use in the testing environment. Enter Test Doubles—a practical solution to streamline testing and simulate dependent components.

What are Test Doubles? In essence, Test Doubles are placeholders or “stand-ins” that replace real components (known as Depended-On Components, or DOCs) during tests. Much like a stunt double in a movie scene, Test Doubles emulate the behavior of the real components, enabling the SUT to function seamlessly while providing better control and visibility during testing.

The implementation of Test Doubles is tailored to the specific needs of a test. Rather than perfectly mimicking the DOC, they replicate its interface and critical functionalities required by the test. By doing so, Test Doubles make “impossible” tests feasible and expedite testing cycles.

Key Variations of Test Doubles Test Doubles come in several forms, each designed to address distinct testing challenges:

1. Test Stub: Facilitates control of the SUT’s indirect inputs, enabling tests to explore paths that might not otherwise occur.
2. Test Spy: Combines Stub functionality with the ability to record and verify outputs from the SUT for later evaluation.
3. Mock Object: Focuses on output verification by setting expectations for the SUT’s interactions and validating them during the test.
4. Fake Object: Offers simplified functionality compared to the real DOC, often used when the DOC is unavailable or unsuitable for the test environment.
5. Dummy Object: Provides placeholder objects when the test or SUT does not require the DOC’s functionality.

When to Use Test Doubles Test Doubles are particularly valuable when:

• Testing requirements exceed the capabilities of the real DOC.
• Test execution is hindered by slow or inaccessible components.
• Greater control over the test environment is necessary to assess specific scenarios.

That said, it’s crucial to balance the use of Test Doubles. Excessive reliance on them may lead to “Fragile Tests” that lack robustness and diverge from production environments. Therefore, teams should complement Test Doubles with at least one test using real DOCs to ensure alignment with production configurations.

Conclusion Test Doubles are indispensable tools for efficient and effective software testing. By offering flexibility and enhancing control, they empower developers to navigate complex testing scenarios with ease. However, judicious use is key, striking the right balance ensures tests remain meaningful and closely aligned with real-world conditions.

This information comes from this article:
Test Double at XUnitPatterns.com

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

One of the most significant ways of ensuring that an application is reliable and efficient before deployment is through software testing. One of the most powerful functional testing techniques that focuses on testing the boundary cases of a system is Boundary Value Analysis (BVA). Boundary Value Analysis finds potential defects that are apt to show themselves on input partition boundaries.

What is Boundary Value Analysis?

Boundary Value Analysis is a black-box testing method which tests the boundary values of valid and invalid partitions. Instead of testing all the possible values, the testers focus on minimum, maximum, and edge-case values, as these are the most error-prone. This is because defects often occur at the extremities of the input ranges rather than at any point within the range.

For example, if a system accepts values between 18 and 56, instead of testing all the values, testers would test the below-mentioned values:

Valid boundary values: 18, 19, 37, 55, 56

Invalid boundary values: 17 (below minimum) and 57 (above maximum)

By running these primary test cases, the testers can easily determine boundary-related faults without unnecessary repetition of in-between value testing.

Implementing BVA: A Real-World Example

To represent BVA through an example, let us take a system processing dates under the following constraints:

Day: 1 to 31

Month: 1 to 12

Year: 1900 to 2000

Under Single Fault Assumption, where one of the variables is tested while others are at nominal values, test cases like below can be written:

Boundary value checking for years (e.g., 1900, 1960, 2000)

Boundary value checking for days (e.g., 1, 31, invalid cases like 32)

Checking boundary values for months (i.e., 1, 12)

By limiting test cases to boundary values, we are able to have maximum test coverage with minimum test effort.

Equivalence Partitioning and BVA together

Another helpful technique is combining BVA and Equivalence Partitioning (EP) together. EP divides input data into equivalent partitions where every equivalence class is expected to behave in the same way. By using these techniques together, testers can reduce the number of test cases but still maintain complete coverage.

For instance, if a system would only accept passwords of 6 to 10 characters long, test cases can be:

0-5 characters: Not accepted

6-10 characters: Accepted

11-14 characters: Not accepted

This mix makes the testing more efficient, especially when using more than one variable.

Limitations of BVA

Although BVA is strong, it does face some limitations:

It works well when the system contains properly defined numeric input ranges.

It has no regard for functional dependencies of variables.

It may not be equally effective on free-form languages like COBOL, which has more flexible input processing.

Conclusion

Boundary Value Analysis is one very important test method that can help testers define most probable fault sites of a system. Merged with Equivalence Partitioning, it has highest test effectiveness at the maximum elimination of test case replication and minimum complete loss of test coverage. In as much as BVA isn’t a “catch-all”, yet it represents an essential technique of software provision quality and dependability.

Personal Reflection

Learning Boundary Value Analysis has helped me understand more about software testing and how it makes the software reliable. It has shown me that by focusing on boundary values, defects can be detected with higher efficiency without generating surplus test cases. It is a very practical approach to apply in real-world scenarios, such as form validation and number input testing, where boundary-related errors are likely to be found. In the future, I will include BVA in my testing approach to offer more test coverage in software projects that I undertake.

Citation

Geeks for Geeks. (n.d.). Software Testing – Boundary Value Analysis. Retrieved from https://www.geeksforgeeks.org/software-testing-boundary-value-analysis/

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