Category Archives: CS-443

Equivalence Testing

hello All, after I leaned about boundary testing in class I learned about equivalence testing. Which I think does a better job at testing for correct output in a program. However it does not do as good a job of testing for edge errors like out of bounds errors and such. The idea of it is to split each variable into a range for every output. These ranges are called Equivalence classes. There are two different conditions for testing it normal/robust and weak/strong. Normal only tests valid the valid equivalence classes and robust tests the valid and invalid equivalence classes. Weak only tests each equivalence classes once and strong tests all combinations.

These are graphs of the different types

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

The Flavors of Software Testing

Recently I took a final in my Software Quality and Assurance class. While I think the final went relatively well there was one question that has been haunting my dreams, hiding in every dark corner of every dark room I find myself in. The question was one so simple yet for reasons unbeknownst to me, I froze. A concept that, at a former point in my life in the not so distant past had been second nature to me. The question was “What is the difference between static and dynamic testing?” Since I failed myself and my professor on that test I felt like I should use this blog as a way to freshen up my understanding of both types of software testing.

I found myself seeking elder guidance on the matter and landed at the doorstep of Lakshay Sharma on the ToolsQA blog. A very short and simple read later I felt the rush of knowledge come back to me and I feel comfortable that I can talk on the matter of static vs dynamic, white vs black box testing. The blog made it very easy to understand the concept because it is laid out in a simple format: the first section explains static testing, and the second black box. After both sections there is a small graphic that shows the differences between the two. So, what is static testing anyways?

Static testing refers to software testing that is done without running the program. This testing is also called white box testing and is done prior to running the code and can help sort out a multitude of issues within the program. Things such as code structure, and code pathing can be tested at this stage and without the use of unit tests. This type of testing is beneficial because it forces developers to take a step back and review the code they are writing. If you’ve ever gotten into a groove while programming and then taken a step back to see the mess you just created you would know why static testing is such a good tool to have in your software testing tool belt. Static testing is full about preventing errors in the first place, and as the age old saying goes: an ounce of prevention is worth a pound of cure. While that prevention is great, in the event that you do get sick, you are going to want that cure as fast as possible and as strong as possible to get you back on your feet. This is where dynamic testing comes in.

Dynamic testing is the act of testing code while its running. Although while creating dynamic tests you may be able to see the code, dynamic testing falls under the umbrella of black box testing because the tests themselves do not care about the inner workings of a program. Dynamic testing tests behavior such as input/output. The good thing about black box testing is that tests can be written prior to developing code and give programmers an easy way to determine if a program is working as intended. Dynamic testing requires more time to set up than static since it involves actually creating test cases.

Just as life is made up of thesis and antithesis and one cannot exist without the other, static testing and dynamic testing go hand in hand and to use only one is to cheat yourself of the best possible work you could be producing.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Good Code Reviewing

For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.

In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.

Articles Referenced:
https://www.michaelagreiler.com/code-review-blog-post-series/
https://www.michaelagreiler.com/code-review-checklist/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Junit 5 testing & testing with lambda expressions

hello all so in my software testing class I have learned about using junit 5 and using lambda expressions to test for exception throwing. I had used junit 4 before I learned this and I liked the way junit 5 makes it easier to make and test classes. I had an assignment to do testing an order system. I used the repeated test for testing auto incrementation. I also used lambda expressions to test for expressions and this was a ton easier then it was with junit 4. Below are two examples of the tests I wrote for that.

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance

Yesterday was my final class meeting for CS-443. In it, I was briefly introduced to the concept of Software Quality Assurance (SQA). The presentation on it was mostly focused on Capability Maturity Model Integration (CMMI), which is one set of standards that is often used in SQA to ensure that an organization is capable of developing software well. While I received plenty of information on CMMI from the presentation, I felt that I did not gain a great understanding of SQA in general. For this reason, I decided I would do my own research into SQA to help me prepare for the final exam tomorrow.

I eventually came across this article from softwaretestinghelp.com which I think provides a fantastic introduction to SQA. The article starts of by defining SQA as “a process which assures that all software engineering processes, methods, activities and work items are monitored and comply against the defined standards.” This definition has helped me understand exactly what SQA is much better than the class presentation, which focused on CMMI. In fact, the article’s explanation has clarified to me that SQA can use any set of standards as defined by the organization, and that CMMI is only one possible example of these standards.

While the article emphasizes that SQA is a much broader concept than I previously thought, it also lists several activities and techniques that are generally used in SQA regardless of the selected set of standards. Some of the activities listed include having multiple testing strategies, measuring change impact, and maintaining records and reports. These techniques have all been discussed either in CS-443 or in other classes that I have taken, and seeing them listed here has helped me better understand exactly what happens when SQA is used during a software’s development. The article also discusses several techniques used to enforce SQA during a development process. The main technique that is used is auditing, which involves regular inspection of the products of development to make sure they follow the standards. Other techniques discussed in the article include code inspection, design inspection, and static analysis, all of which I have also been exposed to previously.

This article has made it clear to me that SQA is not simply the enforcement of CMMI, but a much broader concept that can enforce any set of standards using a variety of techniques. Reading this article has helped me better understand what SQA is and what it looks like to use it during development, and I definitely recommend it to anyone who is also having trouble understanding SQA.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

CMMI and TMMI

After CS-443’s class this week, I decided to further investigate CMMI, Capability Maturity Model Integration, process model. I found testbytes’ article, “What is CMMI? (Capability Maturity Model Integration),” to be illuminating. This article gives an overview of CMMI and why it is used in software development.

At the end of the article is a link to another article by testbytes that caught my attention, “What is TMMI (Test Maturity Model Integration) in Software Testing?” TMMI is essentially CMMI with a focus on testing. While the two are similar, the focus of TMMI makes the implementation of CMMI on software testing smoother. TMMI has the same 5 stages of CMMI with some differences.

Level 1: Initial

  • No test processes in place
  • Failing to meet deadlines

Level 2: Managed

  • Tests are planned and monitored
  • Set test designs

Level 3: Defined

  • All projects are tested from early stages onward
  • Test reviews

Level 4: Measured

  • Properly defined test strategies set in place from beginning of development process
  • Projects tested at every stage to ensure bugless code

Level 5: Optimization

  • Testing practices are structured
  • All processes and outcomes are measured

TMMI is an interesting model that optimizes the testing process and while it is similar to CMMI, I’d still recommend a quick read through this of this article to others.

Articles Referenced:

https://www.testbytes.net/blog/what-is-cmmi/https://www.testbytes.net/blog/test-maturity-model-integration/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

A Valuable Lesson for Creating Tests

Article link: https://dzone.com/articles/why-you-should-stop-now-testing-every-class

A great article I read today goes over the importance of creating the correct kinds of tests for software. In this article, the author thoroughly explains the importance of testing the “behavior” of software versus “implementation details” and how not “every single class” needs to be tested. I think the author does a great job with both an easy to understand narrative and tons of example code that illustrate the importance of testing that software performs to specification versus testing how the code is written. The example code given in the article goes further with linking to an entire GitHub repository for the example code (which elaborates beyond what is shown in the article) which I really appreciate as it lets me see exactly how this concept aligns with a complete program. The most interesting part of this article for me was in the author’s explanation of how refactoring code can cause tests that are written (incorrectly) to a specific implementation to fail. I think it is important to see this point that putting in extra effort in developing software but on the wrong things can actually do more harm than good further down the line. Especially as the author points out if you were to further refactor the code and change how it works (even return types as the author demonstrates!), this causes bad tests to fail, which only creates even more work. I never really thought of how refactoring could create more work in a testing scenario before reading this, but I like how refactoring further helps the overall program by exposing the appearance of useless tests. One other part of the article I really enjoyed was the side narrative the author gave while working through his example of how the steps they took followed TDD (test-driven development). This is also something I wanted to learn more about, and this article also provides a good example of TDD by explaining how certain practices taken in the code example adhere to the rules of this methodology.

Overall, I think this article covered an important topic well, and serves as a great reminder at the end of our testing course to make sure we are testing the right things in our software and that we are not creating too many, and useless tests that only hinder our efforts and not help us. I will certainly keep this article in mind when writing future tests to ensure I’m not wasting my time by creating the wrong kinds of tests or making sure every line is tested in a program.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Mutation Testing

Last Thursday in CS-443, I was introduced to Mutation Testing. This is a testing method which uses tools to embed faults into a project’s code before running its tests. The idea behind it is that, if the tests are written well, then they should fail when mutations are introduced. The in-class activity introduced Mutation Testing by having us clone a Java project and running the PIT tool to test the project with mutations. While the activity effectively demonstrated how to use PIT, I felt that it did not give me a complete understanding of Mutation Testing in general. This was mainly due to some confusion I had while trying to figure out how to run PIT. For this reason, I decided to research Mutation Testing on my own to help improve my understanding of it. I eventually came across an article from softwaretestinghelp.com that I think provides a great introduction to Mutation Testing.

Link to the Article:

Mutation Testing: Testing Technique with a Simple Example

The article demonstrates Mutation Testing with an extremely simple pseudocode example consisting of a single if statement. The example has five different types of mutations applied to it (called ‘Mutation Operators’) which demonstrate how adding mutations can alter the results of tests. Some of these mutation operators, like relational and arithmetic operator replacement, were demonstrated by the class activity. Others, like statement removal and absolute value insertion, were completely new to me. This taught me that there is a much wider variety of mutation operators than the activity demonstrated.

I also found that the article made it easier to understand how the mutations affected the results of the tests. In this article, the results of the Mutation Test are listed in a table with each column representing a different mutation made to the example code. This makes it possible to see exactly which test values either kill the mutants or cause them to survive. It also makes it easier to notice syntactically incorrect, equivalent, and trivial mutants, which the article mentions should be avoided. I disliked how the Mutation Test results were reported by PIT as a generic list of mutations with vague information describing why they survived or were killed. Having the results in the article be presented in a table and being able to refer back to the actual mutated code made it much easier to understand the results of the Mutation Tests. Compared to the in-class activity on PIT, this article uses a much simpler example to demonstrate mutations and presents the results of its Mutation Tests in a much clearer way. This has helped me better understand the fundamentals of Mutation Testing, and I think I will be able to use tools like PIT more effectively as a result.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.