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.

After exploring more of testing, and different strategies, I wondered about how testing could be automated. I came across a blog for Postman, on the TestProject website explaining Postman’s use in automated API testing. This blog is focused on providing a tutorial to understand how to use Postman to automate testing, rather than understanding various testing practices as seen in my previous blogs. The article’s title is Getting Started with using Postman for API Testing by Dave Westerveld

The blog first defines what an API is, as Postman is specifically for API testing. The blog defines API as Application Programming Interfaces. These APIs are extremely important in facilitating communication between software systems. Testing them is paramount for this reason, to assure they are working properly. This is where Postman comes in. It is an automated API tester, with a fully fledged application download. The article outlines the setup of Postman, and explains how to get it to cooperate with your system: First open the app of Postman that you’ve downloaded and then sign in. After this you are allowed to make API requests, the new button is then used and an API request is created. You name the request, and create a collection, where the requests are stored. Following setup, the article explains how to execute a Postman request. During setup, the article created the collection name JsonPlaceHolder, and then used that collection as the URL for the Request URL. After this, Postman will send the request for you. This can be used to compare results from different requests of an API and assure they are the same, although some manual input IS required in automated testing. However more intricate API Testing is shown in further tutorials with Postman.

This is a topic that interested me greatly, as I have been given many suggestions to look into API testing. Through the CS-443 course, I had been looking for more options to test and explore coding. Automated testing is something immensely interesting, and I appreciate the comprehensive guide provided by TestProject for Postman. This is of great value to me as I will continue to look through this guide and potentially post more blogs on this topic, as I explore automated testing. This first blog is mainly involving setup, and the basic concept of requests, but I look forward to further automated API testing using Postman, as these articles are very well structured.

Source:
https://blog.testproject.io/2020/07/15/getting-started-with-using-postman-for-api-testing/

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.

The Concrete Skills pattern emphasizes the importance of acquiring practical, demonstrable, concrete skills in the Software Development field. By possessing the ability to complete simple tasks such as building files and having a familiarity with popular frameworks, can allow for an immediate contribution to any team. Additionally, this pattern highlights the need to go beyond theoretical knowledge and focus on building skills that can immediately be applied from day one on any team.

As I navigate through my path in the software development field, this pattern resonated with me as it aligns with my belief in the value of hands-on experience and practical application. What I found particularly interesting was the challenges that new developers come across when trying to join a new team. I feel as if every new developer goes through this as new teams may be uncertain of what knowledge you possess and what skills you can particularly contribute to the team. These teams may not want to take a chance on someone who is new in the field and may lack certain abilities. Therefore, highlighting the need for new developers to essentially bridge this gap by having concrete skills. This approach can not only enhance employability, but can also create a sense of confidence and credibility within the industry.

After learning more about this pattern, it has reinforced my belief in the value of continuous learning and skill development. It has motivated me to identify what skills are in demand for my desired position on a team, build those skills, and then directly apply them. From this, I can learn what skills I may lack, enhance my knowledge, and then contribute to my team in a positive way. Instead of relying solely on academic credentials or generic experiences, I now understand the importance of creating a portfolio of achievements or accomplishments that can effectively showcase my capabilities to potential employers.

While I completely agree with the message of the pattern, I believe that we should balance concrete skills with other soft skills like communication and adaptability. With that being said, I believe by having an approach that encompasses both technical skills along with interpersonal soft skills can be key in our ever growing field.

In conclusion, the Concrete Skills pattern can serve as a guiding light for aspiring developers. By embracing this pattern, anyone can make powerful contributions to their teams as well as pave a pathway for success in the foreseeable future.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Black box vs. White box vs. Gray box Testing

Black box testing

Black box testing focuses on the behavior of the software on a surface level. This means the tester cannot see any technical details such as code or the structure. Testers are not concerned about the inner workings of the software, rather only on the inputs and outputs. Therefore black box testing comes from the perspective of the user which allows testers to uncover any bugs and/or design flaws that would directly affect the user’s experience.

Some black box testing procedures include boundary value analysis, equivalence partitioning, and decision table testing. Boundary value analysis tests whether the software results in the correct output when the input contains the lower or upper limit of the input range. Equivalence partitioning groups all possible inputs into categories, which can reduce the number of total test cases. Finally, decision table testing involves grouping inputs into a table and testing how the software behaves when those inputs are combined.

White box testing

White box testing is the opposite of black box, meaning testers are given the internals of the system such as the code, the structure, and how its implemented. White box testing allows testers to fully understand how the software is executed. Having access to the internals of the software can help testers find issues related to security vulnerabilities, broken data paths, etc. while black box testing could not focus on those type of issues.

White box testing can be completed with a few techniques. These techniques include statement, branch, and path coverage. Statement coverage ensures that every statement in the code is run and tested at least once. Branch coverage executes all possible branches (i.e. conditional branches) in the code to be tested. Path coverage uses test cases to cover all possible execution paths throughout the software.

Gray box testing

Gray box testing combines black and white box testing into one. Therefore testing can be done from the perspective of the user, while still having access to the software’s internal code. Gray box testing is helpful when identifying problems that may otherwise be hard to find with other types of testing.

A couple techniques that are used in gray box testing are Matrix and Regression testing. Matrix testing looks at all variables in the code and assesses its risk level. Doing this can identify unused/under-optimized variables. Regression testing checks that software changes or bug fixes do not create new errors.

Reflection

This article was chosen because it clearly described the different types of box testing, and what each does. While reading the material, I realized that what we have done in class (equivalence class, boundary value testing) are actually black box testing techniques. I enjoyed learning about the different techniques that are used, and the benefits of them. Although developers and testers are two different roles, developers sometimes play the role as the end user when black box testing, so having a basic understanding of the different types of box testing will be helpful in the future.

References:

https://www.shakebugs.com/blog/black-vs-white-vs-grey-box-testing

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

Exploring the Edges: A Deep Dive into Boundary Value Testing

In the realm of software testing, Boundary Value Testing (BVT) emerges as a cornerstone, spotlighting the crucial junctures at the extremities of software modules. This method, celebrated for its strategic focus, eschews the intricacies of internal code to scrutinize the behavior at pivotal points: the minimum, maximum, and nominal value inputs. Its essence captures the high propensity for errors lurking at the fringes, thereby underscoring its indispensability, particularly for modules sprawling with vast input ranges.

BVT transcends mere error detection; it embodies efficiency. By tailoring test cases to boundary conditions — including the crucial spots just above and below the extremes — it ensures a comprehensive examination without the exhaustive effort of covering every conceivable input. This approach not only conserves resources but also sharpens the focus on those areas most likely to be fraught with defects.

The methodology behind BVT is meticulous yet straightforward. It commences with the creation of equivalence partitions, a critical step that segments input data into logically similar groups. Within this framework, the boundaries are meticulously identified, crafting a testing landscape where both valid and invalid inputs undergo rigorous scrutiny. The beauty of BVT lies in its precision — it’s a targeted strike on the software’s most vulnerable fronts.

However, the path of BVT is not devoid of obstacles. Its lens, sharply focused on boundaries, may overlook the vast terrain of non-boundary inputs, a limitation particularly pronounced in Boolean contexts where only two states exist. Moreover, its efficacy is inextricably linked to the adeptness in defining equivalence partitions — a misstep here can skew the entire testing trajectory, transforming a potential asset into a liability.

Yet, the allure of BVT remains undiminished. In the high-stakes arena of software development, it stands as a sentinel at the gates of functionality, guarding against the incursion of boundary-related errors. Its role is pivotal, especially when the clock ticks against the backdrop of tight deadlines and expansive test fields.

BVT is more than a testing technique; it’s a strategic imperative. As software landscapes continue to evolve, the demand for precision, efficiency, and effectiveness in testing methodologies will only escalate. BVT, with its focused approach and proven efficacy, is poised to meet this challenge, proving itself as an invaluable ally in the quest for flawless software. In the hands of skilled testers, armed with a deep understanding and meticulous execution, it transforms from a mere method into a beacon of quality assurance. Boundary Value Testing (BVT) is a key black box testing method targeting software’s extreme limits to identify errors without delving into internal code, focusing on boundary conditions for efficient and effective error detection. It requires meticulous planning and execution, especially in defining equivalence partitions, to ensure testing success.

I read the blog on this link:
https://testgrid.io/blog/boundary-value-testing-explained/

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

when it comes to the ever-evolving landscape of software development, i’d say it’s imperative to keep pace with methodologies that not In the ever-evolving landscape of software development, it’s imperative to keep pace with methodologies that not only foster innovation but also ensure efficiency and quality. Scrum, a natural evolution of Agile Management, emerges as a powerful ally in this quest. I wanted to try explore in this blog post some of the intricacies of Scrum, the roles it defines, its numerous benefits, and the heartbeat of the framework – Scrum ceremonies.only foster innovation but also ensure efficiency and quality. Scrum, a natural evolution of Agile Management, emerges as a powerful ally in this quest.

Our journey through Scrum begins with the understanding that it’s a flexible methodology firmly grounded in the 12 agile principles. It operates in time-bound blocks known as Sprints, where the emphasis is on delivering tangible results efficiently. A critical element is the Product Owner, who ensures alignment with the project’s goals and client priorities.

I wanted to choose this due to its holistic approach to Scrum, covering both its foundational concepts and its profound impact on software development and beyond. It’s particularly relevant to our course as it provides insights into harnessing technology for project management.

The article underscores Scrum’s suitability for modern demands – the need for quality, fast delivery at lower costs. Its ability to adapt to changing requirements is an invaluable asset. Scrum’s emphasis on the most important functionalities first ensures swift client access and timely risk management. The definition of roles, especially the Product Owner and Scrum Master, is pivotal to maintaining a balance between business priorities and agile development.

This resource served as a reminder of Scrum’s pivotal role in the software development ecosystem. It reinforced my belief in the importance of flexibility, adaptability, and efficiency in project management. The incorporation of Scrum’s ceremonies ensures that every aspect of the project is aligned with the overarching goal, promoting collaboration, transparency, and improvement. I see myself applying this knowledge in future projects, advocating for scrum methodologies to achieve better results.

As we conclude our exploration of Scrum, it’s evident that its application extends beyond software development, seeping into various organizational models. The benefits of scalability, expectation compliance, flexibility, and risk reduction make Scrum a cornerstone in project management methodologies. The Scrum ceremonies, with their structured yet flexible approach, not only foster collaboration and transparency but also ensure timely progress and continuous improvement.

https://www.nimblework.com/agile/scrum-methodology/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

So what even is an anti-pattern? Well, anti-patterns are solutions to ineffective problems that eventually cause more problems than they solve them. They are often used because they seem to work very well but the long-term consequences are not usually thought of. Anti-patterns are just like a regular pattern but instead of a solution, they give a superficial solution but really isn’t one at all. Programming anti-patterns are known for common mistakes, they can lead to problems like maintainability. The spaghetti code is a good example of anti-pattern, it’s a code with no structure. There are random files scattered into random directories, the whole thing is difficult to follow and is tangled together. This usually happens when someone isn’t carefully thinking out their program and how smoothly it should be running before actually coding. It makes it basically impossible to add any new functionality, no matter how many changes you try to make and try to understand those changes you will still end up with countless issues with your code. Another example of anti-patterns is the boat anchor. The boat anchor happens when someone leaves a piece of code in the codebase because they believe that they will need it later but doing this actually can keep your project from moving forward, can cause your coding time to slow down, and mess up your codebase.

Avoid anti-patterns with better system management. You can avoid anti-patterns in your code by being more consistent with your system. By reviewing your code, looking through and making sure you have no typos and grammatical errors. These code reviews help improve the quality of your code and make it easier to find better solutions for any common problems your’re having. Always have someone else take a look at your code in case you did miss something that you didn’t see it’s always helpful to have a set of fresh eyes look at your code so it can help you tighten up your code. The process of engaging in code refactoring can also help make adjustments that will strengthen your code’s structure and framework without impacting the user experience. Refactoring is very helpful in simplifying your code construction.  It will make it easier for someone to take a look at your code and understand how you put the code together and be able to add any new functionality to the code as well. Making the code a visual can help give you as well as others a better understanding of the information presented to them. It can help you show the workflows, and analyze and brainstorm for any new improvements.

https://www.lucidchart.com/blog/what-are-software-anti-patterns

https://www.baeldung.com/cs/anti-patterns

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

This week in class we discussed the process of scrum. Scrum is an agile framework that can be applied to any project or product development effort. It promotes flexibility by encouraging openness, inspection, and adaptation. This loose framework allows teams to adopt it and make changes that benefit their team’s workflow. Unlike the waterfall development approach, where each step must be completed before moving to the next, a scrum team works in small increments over a smaller period. That period consist of the sprint, sprint planning, daily scrum, sprint review, and the sprint retrospective. The scrum event that piqued my interest after reviewing it in class was the daily scrum.

The blog, “Ten Tips for More Effective Daily Scrums” by Mike Cohn,  brought up some interesting and important points. The ten points that were mentioned were: (1) talk almost exclusively about the work of the current sprint, (2) limit discussion to what was and will be accomplished, (3) talk about impediments, not “blockers”, (4) give people something to say about their work not directed toward the sprint goal, (5) give team members a way to indicate when someone is rambling, (6) have people point to what they’re working on, (7) update the sprint backlog but don’t let numbers become the focus, (8) vary how the daily scrum is conducted, (9) keep everyone guessing as to who will speak next and (10) make it painful to ramble too long. 

During the summer, I had the chance to work on software for our university. It was my first time experiencing the scrum workflow. Our team implemented some of these tips during our daily meetings, mainly points 1, 2, 3, and 6 so it was interesting to hear the author’s perspective on what other methods make a daily standup more effective. The points that cater towards diminishing rambling were a fascinating read. While discussing methods to indicate when a member is rambling, examples of using buzzers, holding up rubber hats, and using dolls were mentioned. Although strange to me, those methods show that different teams use what’s best for them. Cohn’s ninth point about keeping everyone guessing as to who will speak next discussed more methods to make the meeting fun to help avoid tuning other members out while they are speaking. While working on software in the summer, I didn’t think about fun ways to improve daily scrum because it was all so new to me. It makes sense to implement something to make the meeting more engaging because, like he said, I did find myself zoning out at times. 

Because I have such little experience with a scrum team, I enjoyed reading about possible ways to improve a team’s process .It helped me realize just how different another team’s methods could be and what I could possibly implement in the future.

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.