The blog post titled “Pairwise Testing: A Complete Guide” by Rajkumar (https://www.softwaretestingmaterial.com/pairwise-testing/) delves into the concept of pairwise testing, also known as all-pairs testing. I chose this blog because of its in-depth examples of  how to implement pairwise testing. These examples really made it easier to understand how pairwise testing can be used to reduce the amount of test cases while still maintaining high test coverage. The post also outlines the importance of pairwise testing and its advantages. Additionally, it compares pairwise testing with other testing techniques, highlights tools available for automating pairwise testing, and discusses its application in various scenarios.

What is Pairwise Testing?

Pairwise testing is a black-box testing technique used to reduce the number of test cases while still maintaining high test coverage. By focusing on combinations of input pairs, pairwise testing ensures that all possible pairs of input parameters are tested at least once. For example, if you had a program that took three inputs, X, Y, and Z, pairwise testing would create test cases for each combination of input pairs: (X, Y), (X,Z), and (Y,Z). At first glance this may seem like you have to create a ridiculous amount of test cases, but by following the steps for pairwise testing you can see how quickly the number of test cases is reduced.

Applying Pairwise Testing

The first step of pairwise testing is to identify all of your input variables. Next list all possible values for each variable. Variables that have numeric values may be reduced to valid and invalid to begin reducing the number of test cases needed. Then, by creating a table content columns of each variable and its possible outputs, you can get a list of each test case. 

This blog’s examples use tables to illustrate how each test case is created by filling in each column one by one.

The example from the blog uses a bookstore and creates a table of every variable. In this example you can see how each pair of variables covers all unique combinations except the book category and enquiry. These variables only test fiction with valid and non fiction with invalid. The other columns fixed this by simply reversing the order of one of the test pairs, but doing this would create the same issue for another combination of variables. In this instance two more test cases are added to the list to ensure the unique combination of book category and enquiry.

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

Summary

The long road pattern emphasizes the lifelong journey towards mastering software craftsmanship. In a culture that values quick success, it prioritizes long-term growth and continuous learning over immediate financial rewards and traditional career advancements. This path is more for those who are dedicated to mastering the craft than those seeking quick riches or executive rolls.

Reflection

With graduation behind me, it’s fitting to focus on the long road ahead. One of the lines from this pattern that stood out to me immediately was “For every step you take toward mastery, your destination moves two steps further away.” The ongoing theme through my computer sciences degree was that every time I would gain knowledge in a topic I would also gain even more knowledge about now much I don’t know. This really opened my eyes to how much it is going to take to master the craft. This started to feel daunting as it continued to happen, feeling like the destination is always getting further away. However, another key point in this pattern was that the journey is just as important as the destination.

When I think of what I know now compared to what I knew even just 2 years ago, it’s such a drastic difference. Even with the feeling of the destination getting further away, each step I took was still forward in my journey. With each step I grow and gain skills that I can continue to use. 

As I look to begin my career as a software developer, I understand that quick wealth is not feasible with my current lack of experience and knowledge in the field. This however is not something that will change overnight, which is something I am already aware of. As I look for a job, I really am looking for an opportunity to gain experience and learn while getting paid. This mindset values the knowledge and experience just as much as the monetary value gained from the position. As long as I keep this mentality moving forward I see the experience and knowledge paying for itself down the long road ahead. 

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

I recently read quite a few blogs regarding test-driven development (TDD), with many of them referencing behavior-driven development (BDD). This left me curious to learn about BDD and how it was different from TDD. Phillip Rogers does a great job breaking down what BDD is, the three principles of BDD, and some examples of BDD with Gherkin in his blog: “Behavior-driven development principles and practices.” (https://blog.logrocket.com/product-management/behavior-driven-development-principles-practices/#:~:text=Behavior%2Ddriven%20development%20(BDD),%2C%20domain%2Dspecific%20scripting%20language.) 

What is Behavior-Driven Development?

Behavior-driven development (BDD) is a product management approach focusing on defining system behavior from the user’s perspective. It emphasizes user interaction, collaboration among stakeholders, and aligning the product with user needs. BDD is a test-first development method.

3 Principles of Behavior-Driven Development:

1. What the software could do: Discovering and understanding customers needs to avoid building the wrong features. Techniques like impact mapping help prioritize features based on customer value.

2. What the software should do: Collaboratively writing structured documentation (executable specifications) articulating user needs. This involves using scenarios and examples in a given-when-then format to describe user behaviors.

3. What the software does: Automating desired behavior based on specifications, writing code, and iteratively improving both code and tests. This aligns with the test-driven development (TDD) process of writing failing tests, writing code to pass tests, and refactoring.

Behavior-Driven Development practices:

Impact mapping: A visual technique that reinforces what user outcomes are most important and are therefore more important to the project.

Story mapping: A visual technique that is used to maintain an understanding of what specifications are needed for a feature.

Three amigos: Forming sub-groups with different skill sets to work together. This brings different perspectives and thought processes into groups that may not have been there otherwise.

Benefits of Behavior-Driven Development

BDD being focused on the users’ perspective gives an improved understanding of the users’ goals. The tests created for BDD are typically higher level tests covering user scenarios. This ensures a high test coverage. Other benefits include enhanced collaboration, code reuse, and reduced rework as required changes are more likely to be seen early on.

Behavior-Driven Development vs Test-Driven Development

BDD and TDD are both test-first development methods that require planning and understanding of the project before beginning development. So, how are they different? TTD is mainly focused on the functionality of a feature. Whereas, BDD is focused on the users’ experience with that feature. BDD is more focused on testing specific scenarios a user may encounter. One notable difference is the fact that a single developer can do TDD where-as the amount of insight needed to do BDD requires everyone from developers to stakeholders,

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

Summary:

Retreat into competence is a pattern that involves taking a break from a challenging task to work on something you are more comfortable or confident in. This helps a developer reflect on how far they have come and can keep them motivated to move forward. Patterns may emerge that show how you got proficient in that task. These patterns can then be used to advance your current tasks. Motivation can also be a problem if someone is constantly getting stuck on a task, or just not being able to progress a project forward. Being able to step back and complete a more familiar task can help keep up the drive during the long road.

Reflection:

This pattern really popped out at me originally for the “Context” and “Problem” sections, as I have felt very overwhelmed many times finishing up my college degree. There have been countless times that I have questioned if I have learned enough for my degree. Each semester felt like it only introduced me to a whole new branch of computer science that I didn’t know. Even the classes that had focused on more advanced topics still felt like it was only just the tip of the iceberg.

There have been a few times this semester that I have been stuck on an issue and just could not figure out where to start looking for a solution. It can be really demotivating when you are unable to complete a task that other people are relying on you to complete. Taking the time to work on another issue helped me in both ways mentioned above. Solving an issue that I was confident I could do made me realize what steps I needed to follow to work on the other issue. Not only this, but being able to actually complete an issue kept my motivation up as I felt like I was contributing to the team.

When I first read through this pattern I originally thought mostly about the motivation and satisfaction aspects of being able to complete a task that is familiar to you. However, as I read through it and began to understand more about what you could learn from working on more approachable projects. Paying attention to and understanding the patterns and steps one takes to solve familiar problems can be used to solve new or challenging issues.

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

Test-driven development (TDD) seemed odd to me when I was first introduced to it, much like the majority of others. The idea of writing tests before code felt weird in a way, as you write tests for nothing. However, the more I read about the benefits and how to properly apply TDD, the more obvious it was how useful TTD really is. Jacob Schmitt does a great job explaining TDD along with its benefits and best practices in his blog “Test-driven development (TDD) explained” (https://circleci.com/blog/test-driven-development-tdd/).

What is Test Driven Development?

Test-driven development is a software development approach where tests are written before code. It follows an iterative cycle: write a test, ensure it fails, write code to pass the test, and refactor. This means that a large amount of planning needs to go into the start of a project. Designing tests requires an understanding of what the feature you are adding should accomplish. This includes testing that things should pass when expected and fail when expected.

What Does Writing Tests First Accomplish?

As I mentioned before, it feels counterintuitive to write a test for code that does not exist. That is, until you understand the benefits of having tests. Tests are going to be required for any serious project. Having the tests written first will greatly increase your chances of finding bugs as early as possible. This also ensures that any refactoring does not break any existing functionality. This is great when working with a team, ensuring that everyone is on the same page and that changes made by anyone will be tested. TDD also ensures that all code that is written is tested. This greatly increases the code reliability and ensures functionality aligns with the user expectations.

Benefits of TDD

One of the most impactful benefits of TDD as a developer is the increased confidence that any changes you make in the code will have immediate feedback on if it passed the tests or not. This confidence extends to every developer on the team, as these tests ensure everyone’s code works as intended.

Catching bugs early can save a huge amount of time and money. It makes sense that testing code incrementally as it’s added is better than waiting until it is all developed to test. This also makes sure no code is ever added that isn’t tested. Meaning tests are being rushed near the end of deadlines, and potentially missing some.

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

The three levels of the software testing process are unit testing, integration testing, and system testing.
Unit testing tests the isolated functionality of each individual unit. 
Integration testing tests the functionality of combining units to ensure they work together as intended. 
System testing tests the software as a whole. 

In my reading about integration testing, I noticed that at some point during this testing phase the system should be tested as a whole. Is system testing just a redundant and more in depth testing methodology focused on this? Sean Coughlin answers this question in his blog “Understanding System Testing in Software Engineering” (https://blog.seancoughlin.me/understanding-system-testing-in-software-engineering) by providing a clear understanding of what system testing is and what it tests for. 

What is System Testing?

System testing is a software testing phase that assesses a fully integrated software system’s compliance with requirements, covering both functional and non-functional aspects. These non-functional aspects are what makes system testing so comprehensive compared to integration testing when testing the software as a whole. Examples of non-functional testing include; performance testing, security testing, and usability testing.

Coughlin uses an e-commerce website as an example to illustrate system testing and each of its components. Functional testing ensures each feature of the website works as intended, Performance testing ensures the website still works even during peak user times. Security testing ensures the website is robust against cyber threats and that data is handled correctly. Usability testing ensures the website is user-friendly across multiple platforms.

Testing frameworks exist that allow for automated test such as simulating heavy loads for performance testing. User testing on the other hand is typically done manually as it focuses on a user’s experience. This means having a range of people, from developers to stakeholders, testing end-to-end use of the software. 

Overall system testing is testing an application for real world use. This goes much deeper than just functionality of the software. This is the last phase of testing before the software is released to the final product for acceptance testing. Meaning it is important that developers properly system test to identify and fix issues during this phase.

The scope for system testing is even larger than I could have imagined. Coughlin states, “I like to think of system testing as more of an umbrella term that captures lots of different testing forms.” which perfectly describes how system testing encapsulates testing all aspects of a software.

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

After recently reading up on unit testing and having some exposure to it in class, I figured the next step would be to look at integration testing. With plenty of blogs to choose from, all giving pretty similar information on integration testing, I chose to highlight the blog published by Katalon (https://katalon.com/resources-center/blog/integration-testing). This blog provides more information into certain aspects of Integration testing, such as explaining some differences between low- and high-level modules. This extra insight helps piece together a lot of the questions I had while reading other blogs on the topic.

What is Integration Testing?

Integration testing is a software testing method that involves combining individual units together and testing how they interact. The main purpose of integration testing is to ensure that each module works together as intended and does not create any unforeseen bugs. Each module should be individually unit tested before integration testing.

Why is Integration Testing Useful?

Integration testing helps identify bugs that may not be seen in unit testing. These bugs can come from a multitude of places. Inconsistent logic between different programmers, modifying code, data being transferred incorrectly, poor exception handling, and incompatible versions may all lead to bugs that only appear during integration testing. Integration testing helps identify these bugs, and depending on what model is being implemented, may easily help find the locality of the bug.

What are the Primary Approaches to Integration Testing?

There are two main approaches to performing integration testing: the big bang approach, and the incremental approach. The big bang approach involves integrating and testing all modules at once. This is great for small systems that do not have much complexity however, this means finding the location of a bug will be harder with a complex system. When systems become larger and more complex it may be best to switch to incremental testing. This is an integration testing method where modules are combined and tested in smaller groups. These groups continue to combine with other groups until the system is tested. Three common incremental integration testing methods are the bottom-up approach, top-down approach, and a hybrid approach. Bottom-up starts by integrating the lowest level modules together before adding higher level modules. Top-down does the opposite where it starts by integrating the highest-level modules before adding the lower ones in as tests pass. The hybrid, also known as the sandwich approach, is a combination that may alternate between testing the top level and bottom level components.

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

Summary:

This pattern describes growing your skills by challenging yourself with any opportunity that is given to you. Whether it’s done through taking on bigger or more complex problems or working with larger teams, there is always something to learn by trying something new. This also means seeking out projects to work on to build a portfolio and expand your skills.

Reflection:

For someone who started programming java in 2007, my portfolio is pretty barren. This comes down to two factors. Lost old files, and failing to start new projects. This pattern is one that I can definitely relate to the problem of feeling like I have plateaued. My eyes are opened to the truth as I get more exposure to the world of software development. If I am going to gain new skills I need to actively seek projects that push the boundaries of what I already know. I have always wanted to develop an application, but without any clear idea of what kind of application I wanted to make. This has always paralyzed me from actually learning how to develop an application. There are two clear solutions I can think of right now based off of two other patterns I have written about in the past. Following the pattern of “Find Mentors,” I could have sought out the guidance of a mentor and asked for ideas for projects that would develop my skills. The second pattern of “Breakable Toys,” gives me the option of just making an application for the sake of having a tool I can use. Making a breakable toy for an application would be a great way for me to jump into the deep end as far as pushing my knowledge of software development.

The other part of challenging myself is working with larger teams. Up until last year all of the projects I have worked on have been solo. Last semester, where I was partnered with another classmate, was one of my first exposures to developing large projects with someone else, and the challenges that come with it. Teamwork is crucial as anywhere I go in my career I will be working on a team, so being able to work together and communicate are important skills to develop. And just like learning from actually developing code, these skills will be built by actually working in larger teams.

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