This week I decided to find a blog that discusses the differences between Black-Box, White-Box, and Grey-Box Testing because even I didn’t grasp it during the class activity. The article “Difference Between Black-Box, White-Box, and Grey-Box Testing” by TestFort Expert explains each way of testing in depth by using bullet points to outline the techniques of each type of testing and reviews the pros and cons of each.

The blog summarizes that the black-box testing method involves testing the software without knowledge of the internal structure and source code. You use this method to test the interface against the specifications that the client gives. The techniques that are involved are decision table testing, error guessing, all-pairs testing, and equivalence partitioning. The first technique tests with if-then-else and switch-case statements to find errors related to conditions. The second technique describes testing based on intuition, the third tests combinations of each pair of input parameters to find bugs from interacting parameters and the last technique involves splitting up parts to reduce testing time. The method tests for functionality but can only be applied to small segments of code.

White-box testing tests the internal structure of software and the logic behind it. One needs full knowledge of the code and the software for this method. It uses these techniques: control flow testing, data flow testing, and branch testing. The first technique logic of the code by executing input values and comparing for expected results. The second detects improper use of data values and data flow by coding errors. The last technique focuses on validating branches in the code. The blog mentioned that technical debt is reduced  by maintaining the code quality which is something I dint think about. Another thing I didn’t think about is that it can result in false positives because test results are strictly tied to the way the code was written. 

Grey-box testing is a combination of the previous methods. It tests for the interface, functionality, and internal structure. It requires some knowledge of the source code but takes more of a straightforward approach. The technique of this approach is matrix testing. regression testing and pattern testing. The first method involves tracing user requirements to identify missing functionality. The second technique involves testing the software after modifications, and the last technique involves analyzing the design and architecture of the software to find the root cause of a defect. This method isn’t suitable for algorithm testing. 

I think this blog is a good resource to learn about each testing method in depth. I think the lists of techniques were helpful in understanding what each method involves. I left class without truly understanding each method. I think the pros for the methods were straightforward but I didn’t think about the cons so I found that section helpful. Now that I know the techniques of each method I am better equipped to think about how to test software.

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.

https://www.testbytes.net/blog/boundary-value-analysis

This past week we began understanding and practicing boundary value testing using simple programs and, of course, simple tests. This blog post discusses that same topic, and gives multiple real life-scenarios and dives deep into the subject. Although it is not a super difficult subject to grasp (in my opinion), I feel this is a good way to reinforce those ideas we learned in class.

This blog by testbytes gives all the information one would need to give them a solid starting ground for boundary value testing. It first explains the concept of the testing model and why it would be done, such as explaining how testers hope to identify errors more proficiently. An example is given, using discount percentages that apply ONLY when purchase totals reach a certain threshold. The lower boundary of the first discount is given, testing if the total is less than $10 (which should mean a 0% discount). Then, the upper boundary of the first discount is checked, with a $10 order receiving an expected 5% discount, so on and so forth. 

Later the blog discusses the different types of boundary value testing as well as their distinctions and the disadvantages and advantages of this type of testing. 

I selected this resource because it gives a quick definition of boundary value testing but then goes into further detail on the subject with good examples and explanations. It is a well thought out post that gave me a more concrete understanding of boundary value testing and edge cases. 

Testbytes on its own is a reliable source for this specific information since it is an entire company dedicated to software testing and quality assurance. Through checking out their other posts, I see they have a variety of testing area blogs including mobile apps, web apps, games, automation, security, and more. 

Overall, this resource is great to refer back to due to its consistent information and easy to understand descriptions. 

As previously mentioned, the content in this blog post by Testbytes is a really solid basis for a good understanding of boundary value testing. I can’t say that it is the highest quality and in-depth education on the subject one can receive, but it’s useful for someone like me who is just getting started. 

Personally, I really enjoyed the material, especially the example given at the start. Although I wasn’t struggling with what we were learning in class, there were times where I had a moment of confusion. This is a quick bit of information that instilled some more confidence in me about this topic. One main thing I learned through this blog is a big disadvantage of BVA is truly how many test cases it may require to check all boundaries/edges, which can lead to a lot of effort on the system and more power/time consumption. I expect to use such advantages and disadvantages when creating test cases for my future individual and work projects.

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.

In class, we’ve been going over unit testing utilizing the JUnit Java testing framework. In the process of this, I’ve come across a couple of issues regarding classes that increment a “key” attribute, that is an class where an attribute’s value is based on the amount of previously built instances of that class. When testing to see if the attribute is assigned correctly, it isn’t consistent because of the compiler optimizations that JUnit uses. Tests run in an order which is most efficient, so the number of instances of the class may be different depending on the order the compiler goes through the tests (from what I’ve heard, at least).

I wanted to research a bit more into JUnit’s capabilities to see if I could figure out a solution to this problem, although I’ve already submitted the assignment that is relevant to this predicament. I found this blog post / guide to JUnit from Baeldung that goes through additional features from what I’ve learned in class. Perhaps here I can get some ideas as to address this issue.

What I first found interesting in this guide was the @DisplayName and @Disabled annotations. This is actually incredibly helpful, specifically @Disabled. In the assignment, I found that there were tests that weren’t possible because the functionality was not added to the classes we were working with. As a way to address it, I simply did this:

@Test
void test() {
 // Functionality has not been added!
 assertTrue(true);
}

This obviously isn’t the best approach to testing. With the @Disabled annotation, you can make a much better implementation of this test.

@Disabled
@Test
void test() {
  assertTrue(method());
}

This is a much better way of testing functionality that hasn’t been added yet.

With regards to the previous problem, I had considered having a @BeforeAll method to create a two instances of a class so that I know exactly what the keys for both instances should be (1 and 2). The problem is that if the constructor for the class isn’t set up correctly, this could result in an error. This isn’t that big of a deal for a small program, but I could imagine it’s not really best practice.

However, JUnit has an Assumptions feature. This means that the desired method will only continue if the assumption is true. With this, we could theoretically run an assumption in a @BeforeAll method, and if it passes the assumption, we create instances with keys that are more easily testable.

@BeforeAll
void setUp() {
  assumeNoException(() -> new Obj());
  Obj obj1 = new Obj();
  Obj obj2 = new Obj();
}

This way, we don’t have to worry about the test class not running all the way through due to an exception, and it’s also fairly elegant. Reminds me of why I like to code.

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.

In the realm of software development, ensuring the robustness and reliability of applications is paramount. This week, I wanted to dive deeper into boundary value testing after learning about it recently. The resource I found gave me some interesting insights into when and why you would want to use boundary value testing, specifically how it can be applied to black box testing where you dont have access to the source code.

Why This Resource?

I chose this particular resource due to its comprehensive yet digestible explanation of BVA. The technique’s potential to significantly reduce testing time while ensuring thorough coverage of potential edge cases intrigued me. As someone striving to refine my testing strategies, understanding the nuances of BVA seemed like a crucial step. This resource did a good job at explaining it clearly.

Insights and Reflections

The article offered a clear definition of BVA and its importance in black box testing. By focusing on the boundaries of input ranges, BVA aims to uncover errors where they’re most likely to occur. This approach not only streamlines the testing process but also enhances the software’s reliability.

One of the most striking takeaways was the differentiation between BVA and equivalence partitioning. While both are essential in a tester’s arsenal, understanding their distinct roles in identifying potential errors was enlightening.

The discussion on automating BVA, particularly through tools like Ranorex, opened my eyes to the efficiency gains possible with the right technology. This insight has prompted me to consider how automation can be integrated into my future testing endeavors, potentially transforming my approach to ensuring software quality.

Application in Future Practice

The knowledge gleaned from this article will undoubtedly influence my future work. The ability to effectively utilize BVA will allow me to conduct more efficient, targeted testing. Additionally, the exploration of automation tools like Ranorex has inspired me to further investigate how such technologies can be leveraged to enhance testing processes in my projects. This will especially help in scenarios where I cant see the code to make more specific.

Conclusion

The exploration of Boundary Value Analysis through Ranorex’s article has been an enriching experience, reinforcing the importance of strategic testing techniques in software development. I look forward to applying these insights to my practice, confident in the positive impact they will have on my approach to software testing, especially when combined with other techniques.

Resource Link: https://www.ranorex.com/blog/boundary-value-analysis/

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.

Having your code and programs work is one thing, ensuring the code works effectively and efficiently is another. You can write good code, but it’s nothing if it does not work properly. When I tested my code, I would just run the whole thing to see if it worked, and with different inputs. When it didn’t work, I would strip it apart, run bits and pieces individually until I found the issue. Instead of meticulously scrolling through lines of code, you could use actual testing methods, like Junit testing

JUnit is a software testing framework for Java. Through the use of method calls, annotations, and assertions, you are able to create tests that will call methods and compare the output to the supposed output that you want. That way, you can create multiple tests for possible outputs your methods and program can have. 

In this blog post, Shinji Kanai writes everything they can about JUnit testing, what it is, how it works, the benefits, and how you can get started using JUnit. They say that JUnit can be used for unit testing, functional testing, and integration testing. They also say JUnit can be used for automation testing, to find errors in your code. They go on to show how to write test files, and how to write test code. They touch upon some other topics, like troubleshooting, assertions, debugging and exceptions, and other things. 

I chose this blog post as a good reference article, something to refer back to when you can’t remember what to do. At the same time, it’s also a really good beginner blog post for those who want to get into testing their code. I think Kanai did a good job encapsulating everything, not only summarizing the overall concept of JUnit testing, but at the same time going in depth about how to do things, and going over more topics for those who may find it helpful. Personally, I was unaware of the automation testing side of JUnit, and how it may be able to remove bugs before I even fix them, which is weird because typically you only catch errors and bugs when you run the code. 

Testing is one of the spots in coding where I knew I was lacking in. Before this, I never knew how to test my code effectively, but with this, I feel more confident in my abilities to write better code that will set me apart from others. As I continue along, I can picture myself as a better developer than I did when I first started university.

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

Enhancing Your Code with Metadata

The blog from ioflood.com provides a comprehensive guide on Java Annotations, covering the basics and advanced aspects. It explains the fundamental annotations in Java, such as @Override, @Deprecated, and @SuppressWarnings, and also delves into creating custom annotations. The blog addresses how to deal with common challenges and compares Java Annotations with other metadata approaches like comments and naming conventions. It also touches upon the role of Java Annotations in larger projects and frameworks, emphasizing their importance in modern Java development.

Delving into Java’s built-in annotations, let’s begin with @Override. This annotation safeguards your method overrides, ensuring that you’re correctly extending a superclass method. Missteps in method naming or parameters can lead to subtle bugs, but @Override makes these issues immediately evident.

Next, consider @Deprecated. It’s a polite warning to developers that a particular method or class should be avoided, possibly due to security concerns or improved alternatives. Using @Deprecated helps maintain backward compatibility while steering developers towards better options.

Lastly, @SuppressWarnings plays a key role in managing compiler warnings. While it’s not advisable to ignore all warnings, this annotation is invaluable when dealing with known but unavoidable issues, particularly in cases of backward compatibility or deprecated usage.

Creating and Using Custom Annotations

Custom annotations take this utility a step further. They allow you to create tailor-made metadata suited to your specific project needs. For instance, you could define an @Configurable annotation to mark fields that should be populated from a configuration file.

Creating a custom annotation involves defining an interface with the @interface keyword. The real power lies in understanding and using retention policies effectively. These policies determine how the annotation is stored and used:

• SOURCE: Discarded by the compiler, useful for annotations processed during source code analysis.
• CLASS: Stored in the .class file but not available at runtime, ideal for annotations that don’t influence runtime behavior.
• RUNTIME: Available at runtime, these annotations can be used for runtime processing, like those in many Java frameworks.

Best practices for custom annotations include clear documentation and thoughtful consideration of their scope and retention policy. They can serve myriad purposes, from guiding framework behavior to enforcing coding standards.

Conclusion

Java Annotations, whether standard or custom, represent a powerful aspect of Java programming. They allow for cleaner code, clearer intent, and more robust software design. By understanding and utilizing annotations effectively, Java developers can ensure their code is not only efficient but also well-structured and easier to maintain.

Here is the link of the blog: https://ioflood.com/blog/java-annotations/

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