https://www.geeksforgeeks.org/specification-based-testing

  Specification based testing is a type of software testing that directly uses a systems specification in order to design tests. WHile considered a type of black box testing specification based testing can be used on any type of system but works particularly well when testing web applications. When practicing specification based testing you would first look at the code and its documentation in order to see what must be tested based on its functionality and uses. The objectives of specification based testing are functional accuracy, conduct based compliance, error detection, reliability/robustness, full coverage and compliance with the standards.

  There are 7 types of specification based testing listed which are “state transition” which is used to uncover errors in a system when switching states, “decision table” testing which can test functional and non functional system requirements, “equivalence partitioning” which is similar to decision table testing except it is best used when testing different inputs while decision table testing is best used on different combinations of inputs. Then there is “boundary value analysis” which consists of creating a test case for each boundary value, “all pair testing” which makes a test case for every possible input, “classification tree” is based on deriving test cases from a decision tree and “use case” testing which focuses on the functionality of the entire system rather than any individual component.

  I selected this topic/source as we have been practicing specification based testing in class recently and I was interested in researching more into the topic and the different types of testing that are classified as specification based and this article from “geeksforgeeks” went in depth not only into what the definition of specification based testing is but also the different types and the objectives of this type of testing. 

  This article was very helpful in my opinion as is gave me a perspective on specification based testing as a whole and after practicing some of the different types of specification based testing in class and reading this article I have a greater understanding or not only what this type of testing is but also how to go about testing in this fashion and writing test cases which pertain to the specifications of a system. I would consider this type of testing to be one which is more self explanatory than others but being able to understand its importance and its limitations is something that will help me when testing in the future.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

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.

  The ‘Unleash your enthusiasm’ apprenticeship pattern is one which I would consider very important. The basis of this pattern is that you should not feel the need to suppress your own excitement over crafting software when you are part of a team but you should be mindful of the team’s dynamic and attitude before blindly acting on your own enthusiasm. Essentially it is completely normal for a newcomer in software development to be excited to learn or even to be working within a professional team but the newcomer should always keep in mind that their enthusiasm may be warranted but depending on your colleagues you may want to keep your enthusiasm to yourself in order to not make any negative impression which is important in many different fields not only software development. But even if you judge that your enthusiasm should be kept to yourself based on a team or individual’s dynamic you can still ask questions in order to better yourself.

  I found this pattern particularly useful as I myself along with some fellow computer science majors I know are hesitant to show excitement over software development at times as I do not know if it would be considered as unprofessional. This pattern explained to me that while you do not want to overly express your excitement throughout the learning process it can be helpful to question things and give your ideas even as a beginner when working in a team as the perspective you offer the team is fresh and can lead to helpful solutions or enhance your own learning process and the more you know about what you are developing with your team the more useful you will be when trying to work together on productive and time effective solutions. Being aware that it is for the most part encouraged to share your thoughts, question or ideas when you can at the very least so that you can get an explanation on why an idea would or would not work is something that will help me to be more open to sharing my thoughts with others whether it be colleagues, other students professors etc.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs 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.