While looking for more articles online involving testing, I came across SauceLabs. This website is another compendium of blogs, similar to stickyminds mentioned in my last blog. The layout and articles on this website were an excellent selection of resources dedicated to testing and quality assurance. While running through many bugs in my most recent projects and assignments, I was searching for an article dedicated to programming bugs. I found an article that fit my needs, dedicated to the differences between severity and priority of bugs, which is something I had not previously considered. The article’s title is Understanding Bug Severity vs. Priority: Key Differences and Best Practices by Chris Tozzi

The article provides (as the title indicates) a breakdown of bug severity and bug priority in software testing. It explains that bug severity is primarily concerned with the impact of a bug on the system’s functionality. Issues are categorized into the following levels of severity: critical, major, minor, and trivial. Each of these have a different level of impact on the system. For example, critical bugs may cause system crashes, while trivial bugs have a small functionality and performance impact. Bug priority focuses on the order in which bugs should be addressed, considering various factors that will impact the job as well as the program, such as deadlines, or bugs that are caused by higher priority bugs. Bugs with high priority require immediate attention, and those with low priority can be addressed later as the program develops and is tested further. It is an extremely important skill to be able to identify the severity and priority of bugs throughout the system and its development, so as to facilitate a smoother and more efficient development cycle. The article also provides some examples, such as a critical severity bug that causes data loss. This bug would ALSO have high priority because it is causing a lot of damage to the system’s structure.The article offers very useful recommendations for bug reports such as: establishing clear classification guidelines for bugs (priority/severity levels), communicating efficiently within teams, or reassessing bug statuses frequently.

I chose this blog because of my most recent experience in my assignments and projects. I had found that many bugs relied on each other, and I had never previously taken the initiative to learn more about bugs. When working with a team in industry, I will now have an understanding of how bugs are classified, as well as how to manage bug reports. This is something I had very little experience with prior to this article, and I will make sure to put extra effort into bug reports in my own projects with peers. I will continue to look into articles about bugs, testing, and QA to further improve my knowledge.

Source:
https://saucelabs.com/resources/blog/bug-severity-vs-priority

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.

In software development, Unit Testing turns out to be a crucial phase within the software testing lifecycle, ensuring that each component or “unit” of the software performs as intended and designed. I chose this topic really because it is all we have been doing the past 2 weeks in class and the whole course is about Quality Testing and Assurance so it makes sense. Also Since I am not a software developer (I’m a Data Analytics kinda guy) I have been trying really hard to motivate and enjoy the struggle of doing this courses assignments.

The GeeksforGeeks article provides a comprehensive overview of Unit Testing, defining it as a level of software testing where the individual units/components of a software are tested. The primary goal is to validate that each unit of the software code performs as expected. Unit Testing is typically performed by developers themselves or by QA engineers, emphasizing the importance of testing small parts of the project independently for errors. The article outlines the process, benefits, and challenges of Unit Testing, along with examples of tools that facilitate this testing method, such as JUnit for java and NUnit for .NET framework applications.

I went with this specific post because of the clarity and depth in explaining Unit Testing. It aligns perfectly with out course’s focus on Software quality and Testing, providing a solid foundation for understanding the complexities and nuances of unit testing within the software development lifecycle.

Upon reflecting the content, the article really highlighted the significance of Unit Testing in early bug detection, which not only saves time but also costs in the later stages of development. The emphasis on Unit Testing as a foundation for more comprehensive testing methods resonated with my understanding of a layered system strategy. It was really interesting to learn about the various tools and frameworks that support Unit Testing (though I may not know how to use them) across different programming languages, showing the universality and critical nature of this testing approach.

The knowledge gained from the article will reinforce my commitment to integrating Unit Testing future development projects. Recognizing its rile in maintaining high quality code and facilitating agile development processes. I am motivated to delve deeper into Unit Testing frameworks.

Unit Testing emerges as an indispensable practice in software development. The article serves as a valuable resource for understanding the principles and practices of Unit Testing, leading to a deeper appreciation for meticulous testing methodologies. As I move forward the principles outlined in this resource will be guiding my approach to quality assurance and testing

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose the article “Behavior Testing | What it is, Why & How to Automate?” from testsigma.com. I selected this article because it fits within the Behavioral testing section in the course topics section of the syllabus. This article goes into great detail about behavioral testing, from discussing what it is to explain how AI could be used in its implementation. For this blog post, however, I will discuss the sections on what behavioral testing is and a couple of methods that can be used to catch errors with behavioral testing.

The article describes behavioral testing as a form of functional testing designed to test the external functionality of a system. “Behavior testing or behavioral testing is a type of testing that focuses on testing the external behavior of a software application. It is a type of functional testing. It helps ensure that software systems meet the expectations and requirements of end-users, making it a valuable part of the software development and testing process. Behavior testing is also known as black-box testing.” As described by the article, behavioral testing is essential to ensure that the systems or products you are designing work well enough so your customers can use them efficiently. There are many different methods when using behavioral testing to find errors, such as equivalence partitioning.

According to the article, one method that can be used with behavioral testing that is good at finding errors is Equivalence Partitioning. “The equivalence partitioning testing technique involves dividing the input data into different classes or partitions, such as valid and invalid data, assuming the system will behave the same for both inputs. Example – For a login form, if the password requires at least eight characters, you might test one case with a 6-character password (invalid) and another with a 10-character password (valid).” When using equivalence partitioning, because you are dividing inputs into separate groups, in a way, you can do two things at once. One is that the system functions as it should with valid inputs, and the other can catch invalid inputs. Another way behavioral testing can be implemented is through boundary value analysis.

According to the article, boundary value analysis is a form of behavioral testing focusing on the possible range of inputs, specifically numerical inputs. “It focuses on testing the boundaries of input ranges, as errors often occur at the edges of these ranges. Test cases are designed for values at the lower and upper boundaries and just above and below. Example – If an input field accepts values from 1 to 100, the test data can be 0, 1, 2, 99, 100, and 101.” This kind of testing can be very helpful in making sure that you have accounted for the possible range of inputs that a user may enter, both valid and invalid.

Article: https://testsigma.com/guides/behavior-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.

Dive into the world of JUnit, the leading Java testing framework. Learn how JUnit streamlines writing, running, and managing tests for robust Java applications.

Introduction to JUnit: Elevating Java Testing to New Heights

Testing is the backbone of any robust software development process, and when it comes to Java, JUnit is the name of the game. As a pivotal Java testing framework, JUnit simplifies the creation and management of tests, ensuring your code stands up to the rigors of use. But what makes JUnit the go-to framework for Java developers? Let’s dive in and uncover the essentials of JUnit, from its core functionalities to setting up your first test suite, ensuring you’re well-equipped to harness the full power of this testing framework.

A Deep Dive into JUnit’s Capabilities

JUnit, inspired by the xUnit architecture, provides a structured way to write and run automated tests. This flexibility extends to various types of tests, including unit, integration, and functional tests, each serving a unique purpose in the development lifecycle. Unit tests scrutinize individual components for correctness, integration tests ensure components work seamlessly together, and functional tests validate the system’s operation against requirements.

At its core, JUnit facilitates test creation through annotations, enabling straightforward test case structuring. Assertions play a critical role here, allowing developers to validate expected outcomes. Additionally, JUnit’s test runners and suites offer a streamlined approach to execute and organize tests, complemented by comprehensive reporting tools that shed light on test outcomes.

Setting the Stage for JUnit Testing

Getting started with JUnit is a breeze, especially within popular IDEs like Eclipse. Installation is straightforward, involving the addition of JUnit to your project’s build path. Once set up, creating a standard test file is your first step toward leveraging JUnit’s testing prowess. This involves defining test methods, utilizing JUnit’s annotations, and employing assertions to verify code behavior.

Crafting Your First Test Class

A well-structured test class is your blueprint for effective testing. Adherence to best practices, such as minimizing class size and focusing on relevant tests, is paramount. Utilize assertions to enforce expected outcomes, and maintain regular test runs to catch and rectify issues early. This iterative process not only enhances code quality but also bolsters your confidence in the software you develop.

Conclusion: Unlocking JUnit’s Full Potential

JUnit’s significance in Java development cannot be overstated. By facilitating efficient, reliable testing, JUnit empowers developers to produce higher-quality code. Whether you’re new to JUnit or looking to refine your testing strategy, understanding and applying JUnit’s features will undoubtedly elevate your development process. So, why not take the leap and integrate JUnit into your next Java project? With the right approach, you’re set to unlock the full potential of this powerful testing framework.

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

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.

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.