Another important topic that we have discussed in CS-443, or Software Quality Assurance and Testing, is known as Pairwise Testing. Pairwise Testing is yet another form of testing, but this type is a little bit different than the rest. Pairwise Testing, sometimes known as all-pairs testing, tests each pair of input parameters in order to make sure that the functions in the system run correctly no matter what the input is, guaranteeing that it will run for every combination. Pairwise Testing is known as a Permutations and Combinations (P&C) based software testing technique. A blog that I found to be really helpful in explaining Pairwise Testing is known as Pairwise Testing | What It Is, When & How to Perform by Kiruthika D. In the blog, she gives an example that helped me understand more. She states “Let’s say you have an application that allows users to enter two numbers, and the application will output the sum of the two numbers. You can use pairwise testing to test all possible combinations of two numbers, such as (1, 2), (2, 3), (3, 4), (4, 5), etc. By testing all the combinations of two numbers, you can be sure that the application is working correctly and will not fail when given different numbers.” This shows that you don’t actually test every single combination, but you test every single input with another input. This way, it makes sure that all of the inputs work instead of testing a potentially infinite amount of combinations.

The actual purpose/use of Pairwise Testing is exactly what I previously stated. It is used to make sure that all combinations of inputs are possible, but you don’t need to test every single combination. It can be extremely helpful as it reduces the amount of time it takes to test the program as well as the amount of effort. While Pairwise testing is a great testing technique, you obviously can’t use it all the time as it involves pairs. As for when to use it, Kiruthika states “Pairwise testing is helpful when testing complex systems that have multiple input parameters and multiple possible values for each parameter. It can significantly reduce the number of test cases that need to be created while ensuring that all possible discrete combinations of parameters are tested. This can help reduce test case creation time and cost and improve the software’s overall quality. Pairwise testing is not appropriate for all types of software testing. As we discussed, it is most effective for systems with multiple parameters and multiple possible values for each parameter. If a system has only a few parameters and a small number of possible values for each parameter, pairwise testing may be unnecessary. Pairwise testing, also, will not be useful if the values of inputs are inappropriate.” Essentially she is saying that Pairwise testing is used for functions that have multiple parameters with multiple values, and the order of parameters doesn’t matter. On top of that, depending on the type of parameter, the technique might not work either. While I personally don’t see myself using this technique in the future, I think that it has the opportunity to be very useful in certain situations, so I’m glad that I was able to understand it more in case I ever need to use it.

Link: https://testsigma.com/blog/pairwise-testing

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

The last few weeks of class have all been about Test Driven Development. Test Driven Development is when you use tests in order to guide you into developing software. According to a website called martinfowler, there are three main steps that we follow repeatedly. Those steps are:

1. “Write a test for the next bit of functionality you want to add.
2. Write the functional code until the test passes.
3. Refactor both new and old code to make it well structured.”

Essentially what this means is you create a list of things that you want included in your test, then you create a test for just one of those items. Once you create the test, you implement the code in order to get the test to pass. Once it passes, then you move on to creating the next test and getting that test to pass. If it causes the previous test you fail, you refractor until all of the current tests pass, then you repeat until all of the items you need are done. I personally find writing the test first to be a lot easier than writing the code first. That way, while you’re creating the code, you have an example to look back at so you know exactly what you want it to do. On top of that, focusing on one part of the code at a time makes it a little easier to develop the code without making mistakes, as you aren’t focusing on the entire program at once, just one small part at a time. According to the article, this form of development has two main benefits. It says “Most obviously it’s a way to get SelfTestingCode, since we can only write some functional code in response to making a test pass. The second benefit is that thinking about the test first forces us to think about the interface to the code first. This focus on interface and how you use a class helps us separate interface from implementation, a key element of good design that many programmers struggle with.” I chose this article as my source because I thought it did it a really good job explaining what to do step by step so you don’t get confused. On top of that, it explains the benefits and consequences of this method and how to avoid/achieve them. This article helped me further understand Test Driven Development and why it is useful.

Source: https://martinfowler.com/bliki/TestDrivenDevelopment.html

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

A little while ago we learned how Define-Use Testing works as well as how to use it ourselves. However at the time, it still confused me a bit and I wasn’t really sure what it was used for. After reviewing the previous work we’ve done and coming back across this topic, I realized that I still didn’t fully understand what was going on. I decided to look further into it and to do some research in order to understand it more. As a result, I found a website called testsigma which I believe does a really good job at explaining what Define-Use case testing is, its advantages and its disadvantages, and when to use it.

With the website’s help, I’m going to explain everything that you need to know about Define-Use case testing in order to understand it and to know when to use it. As for what a use-case itself is, the website states “The concept of a Use Case can be likened to a real-life scenario in which users and their objectives are present. A Use Case outlines the events unfolding when these users interact with the system to achieve their objectives. The Use Case allows for a thorough understanding of the overall behavior and functionality of the system from the user’s point of view.” Essentially this means that a Use Case shows all of the decisions that were made while the user was trying to achieve their outcome, allowing you to understand all of the behavior and functionality from the user’s perspective. Use Case Testing was designed to make sure that the system that is currently being tested meets all of the expectations. It essentially simulates different real-life scenarios in order to make sure the software does everything that it is supposed to. While the website gives a lot of different advantages and disadvantages of Use Case testing, I’m just going to list a few. Some advantages include helping to identify and validate the functional requirements of a system or software, explaining how the software will be used in real-world scenarios, and helping uncover potential defects. Some disadvantages include it could be time-consuming and require a lot of effort, it may not cover all scenarios which could leave to gaps in test coverage, and it relies on the accuracy of the use case documentation. As for when to use Use Case testing, the website gives a checklist which I found to be extremely useful in my understanding of when to use it. I’m really glad I found this website as it further helped my understanding of the topic, and it has helped me prepare for my final exam. The checklist states:

“1. Review the software requirements, specifications, design documentation, and use case scenarios. 

2. Identify the possible scenarios related to the use case. 

3. Determine the functional requirements of the use case. 

4. Create test cases for each possible use case scenario. 

5. Define the expected results of the use case scenarios. 

6. Execute the test cases and compare them with the expected results. 

7. Retest the fixes after identifying failed test cases. 

8. Check for exceptions and errors for each use case scenario. 

9. Verify compliance and security requirements for each use case scenario. 

10. Monitor the system’s overall functionality across use scenarios. 

11. Validate the overall system performance with user expectations”

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Recently in my Cs-443 class, Software Quality Assurance and Testing, we have been talking about unit testing using stubs. Honestly, I didn’t understand what stubs were during the classes themselves, but a blog called Why Stubs in Unit Testing Improve Integration Testing helped me understand what a stub is, as well as where and when it is used. In this blog written by Miroslaw Zielinski, he states ” Unit testing is more about isolating the function, method, or procedure, otherwise referred to as a unit. This isolation is done by stubbing out dependencies and forcing specific paths of execution. Stubs take the place of the code in the unit that is dependent on code outside the unit.” Stubs allow the person testing the code to test specific paths of execution within the code, allowing them to view different things such as if different parts of the code work and are reliable. I think that Zielinski gives a great example of why these stubs are used in his article. He states, “Once the stub is added, it will be consistently applied to the tested code. A user working on the “allocation failure” test case will have an easy way to install a special callback function into the stub, which will simulate the desired effect: allocation failure or do nothing since by default the stub returns a null pointer, which is expected for the test case.” This helped me understand why stubs are used, and the rest of the article helped me understand when they are used.

After reading more of the article, Zielinski began to explain why stubs are used. Although his explanation confused me a bit, I believe I got the jist of what he was trying to say. I believe that they are being used when you are trying to test lower-level modules while the upper-level modules have not been developed yet. Therefore you can use a stub, which acts like an upper-level module, in order to see how it will be treated. Zielinski also gives examples of when stubs aren’t good to use and what the limitations are “In instances where there’s not an original definition available for a stubbed function, what happens? How does the stub behave without a callback that defines the alternative behavior? The beauty of C/C++test is that it automatically detects this kind of situation. The stub will reconfigure itself during the test harness build time. It won’t call the original definition when no callback is installed and will return a safe default value.” I’m not really sure what he means by this, but I hope to learn more in the future.

Link: https://www.parasoft.com/blog/using-stubs-in-integration-level-testing/#:~:text=Unit%20testing%20is%20more%20about,on%20code%20outside%20the%20unit.

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

During these first few weeks of class, we have been talking about JUnit and how it has features that allow us to test our code. We mainly talked about annotating methods to use as test cases as well as different assertions from Java and third-party libraries in order to help determine if a test was successful. While we kept using it throughout the week in order to help us test our code, I wasn’t exactly sure what JUnit actually was. Luckily when I was doing some research on it, I came across a blog on Parasoft by Nathan Jakubiak which gave a lot of useful information on what unit testing is, what JUnit is, as well as how to set up JUnit testing and to write different tests. I think that Jakubiak gave great descriptions as to what each of them are and what they are used for. Firstly, he stated “Unit testing is a form of white box testing in which test cases are based on internal structure. The tester chooses inputs to exercise particular paths through the code and configures assertions that validate the output. The purpose of unit testing is to examine the individual components or pieces of methods/classes to verify functionality, ensuring the behavior is as expected.” This means that unit testing is a type of testing where test cases are created based on certain parts of the program that you want to test, rather than testing the entire code in one test. For JUnit testing, Jakubiak stated “JUnit is the most popular Java unit testing framework. An open-source framework, it’s used to write and run repeatable automated tests.” Essentially he is just letting us know that it is an open-sourced framework that allows us to run different tests for our code. In his blog he also talks about how to set up JUnit testing which I personally don’t understand, probably because I just started working with it. However later in his blog he talks about all of the different parts of a JUnit test and how to write them. He also gave examples for some of the different parts, such as annotations, which I found to be really helpful in my understanding of the subject. I chose this Jakubiak’s blog because in all of the research I did on the topics of JUnit and Unit Testing, his blog did the best job of explaining them and overall gave me a much better understanding of the topics.

Link: https://www.parasoft.com/blog/junit-tutorial-setting-up-writing-and-running-java-unit-tests/

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

During this last week of class, I have been learning about clean code and how to write it as well as edit my previously written code in order to follow these guidelines. Clean code is exactly what it sounds like. It is code that is easy to read and understand, and isn’t too complicated or formatted poorly. Learning how to write clean code is going to be vital in working in the computer science industry. Everyone in this industry works with another programmer at some point in time, so having clean code will make their life and your life easier. While researching more about how to write clean code, I found a website called freecodecamp that does a great job explaining attributes of clean code while also giving examples. On top of explaining how to do it, it also has a section explaining why you should care about writing clean code. Personally, this really helped me understand why clean code is needed and why it is very important to understand.

The three main aspects of clean code are effectiveness, efficiency, and simplicity. Effectiveness is pretty self-explanatory. It means that the program should be able to solve the problem that it was designed to solve, otherwise it isn’t helpful. Once the program is considered to be effective, we need to also make sure that it is efficient. If a program solves a simple addition problem, but takes 36 hours to run, the program isn’t efficient as there are much faster and more simple solutions. If your program is post effective and efficient, then you also need to make sure that it has simplicity. While most sites will have different qualifications for simplicity, I think freecodecamp has most of them. Freecodecamp wants everyone that is trying to write clean code to ask themselves these questions about the code:

1. “Can you easily understand what the program does at each line?
2. Do functions and variables have names that clearly represent their responsibilities?
3. Is the code indented correctly and spaced with the same format all along the codebase?
4. Is there any documentation available for the code? Are comments used to explain complex parts of the program?
5. How quick can you identify in which part of the codebase are certain features of the program? Can you delete/add new features without the need of modifying many other parts of the code?
6. Does the code follow a modular approach, with different features separated in components?
7. Is code reused when possible?
8. Are the same architecture, design, and implementation decisions followed equally all along the codebase?”

While there are a ton of other ways that you can improve your code, these are the 3 main factors. Without these 3 foundational factors, you wouldn’t be able to write clean code which would make life harder for you and for everyone that reads your code.

Synopsis: https://www.freecodecamp.org/news/how-to-write-clean-code/#what-does-it-mean-to-write-clean-code-and-why-should-i-care

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

A Scrum Sprint is an event that allows a scrum team to work towards a goal in a time-boxed event that is known as a Sprint. In my class we have been talking a lot about Sprints as well as all of the different roles that each of the team members may be. On top of that, we discussed what each role does and even had a mock Sprint in order to see what they are like. I think that Sprints are really helpful in order to help get work done, and that it works a lot better with less people as long as you trust that they will get their work done successfully. As a computer science major, I feel like I will take place in a Sprint at least one time throughout my career, so I enjoyed having a mock in order to feel what it is like. However, since the mock was only one day, we didn’t get to experience the different roles in a team. But while researching, I came across a website called Atlassian which I think does a really good job at explaining all of the different steps in a Sprint, as well as what each of the roles in a Sprint team does and how they help achieve the Sprint goal.

There are three major roles in a Scrum Team. These roles are developers, the product owner, and the scrum master. In my opinion, developers are the most crucial role in a Scrum Team. Developers are the ones that do the actual work in the Sprint allowing the team to get closer to the Sprint Goal. They do things such as organize, design, test, and deliver the software. Basically, they are the workers that make the develop the software and make sure it does what it is supposed to. One of the other major roles is known as the product owner. The product owner is the member of the Scrum Team that interacts and communicates with the customer. They find out what the customer is looking for in the product and then relays it to the rest of the team, which results is finding out the product goal. According to Atlassian, “Since agile teams are, by design, flexible and responsive, it is the responsibility of the product owner to ensure that they are delivering the most value. The business is represented by the product owner who tells the development what is important to deliver.” This further shows that the product owner needs to be a trustworthy person and good at communicating with others, otherwise the Sprint could fail before it even begins. The final major role in a Scrum Team is known as the scrum master. The scrum master is the glue of the group. This role helps out the other two by helping the product owner define value, while also helping the developers deliver the value that was promised to the customer. The scrum master is like the leader of the group, helping where they can while also making sure that the work gets done on time without error.

Synopsis: https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Recently in class I have been learning about a bunch of different types of software licenses and just how important they are to include on my future projects. A software license is essentially a type of legal instrument that controls the use and redistribution of software in order to help protect the author. According to a website called TechTarget, the main use of a software license is “Software licenses typically provide end users with the right to one or more copies of the software without violating copyrights. The license also defines the responsibilities of the parties entering into the license agreement and may impose restrictions on how the software can be used.” Before taking CS-348 I didn’t know much about software licenses and how they worked. I knew there were a couple different types, but I didn’t realize how many types there are actually are and I also didn’t understand how important that they are. Personally, I think TechTarget did a great job explaining the differences between licenses and how they work. While most people think that these licenses are just to protect developers and their code, they are also used in order to protect users. They help the users avoid and protect themselves from infringement claims and also limit their legal liability if something were to happen. Sadly, these software licenses are not free. There isn’t a set price that every license costs, most of them have their own prices which depends on the type of license that it is. Some of these prices include a one time fee, some are a subscription fee, and others include a purchase fee plus a subscription fee. Although these licenses can be expensive, I think that it is worth it in order to help protect yourself and your users.

While there are a bunch of different software licenses, there are two main types that are viewed differently under copyright law. One of the main types of software licenses are free and open source software licenses, otherwise known as FOSS licenses. These types of licenses give the user a lot of freedom, and even allow them to use the source code. FOSS may allow these customers to change the software themselves if the user desires it. The other main type of software license is known as a proprietary license. These licenses are more commonly known as closed source licenses. Closed source licenses are much more strict than FOSS licenses, and don’t give the user much freedom. The users receive operational code, however they are not allowed to freely alter the software that they have been given. On top of that, these users are not allowed to obtain the source code through reverse engineering.

Synopsis: https://www.techtarget.com/searchcio/definition/software-license

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.