https://blog.testlodge.com/levels-of-testing/

          I found an interesting blog post this week that talked about Levels of Testing within Software Engineering. It explained that there were four main levels that were known as Unit Testing, Integration Testing, System Testing, and Acceptance Testing. The post used a basic diagram to help explain the ideas alongside explanations for each level. It explained that Unit Testing is usually done by developers of the code and involves testing small individual modules of code to make sure that each part works. Integration testing is explained as taking individual modules like in Unit Testing and combining them to see if they work together as a “section” of modules. The post explains System Testing as the first test that works with the entire application. This level has multiple tests that works through application scenarios from the beginning to the end. It is used for verification of multiple requirements within the software such as the technical, functional, and business aspects. Acceptance Testing is defined as the final level of testing which determines if the software can be released or not. It makes sure that the requirements set by a business are completed to make sure that the client gets what they want.

          I chose this article because I remember that the syllabus only states three main levels, excluding Acceptance Testing. This is what sparked my initial curiosity as to what these levels of testing were and what Acceptance Testing was. I found that this content was really interesting because it explains how testing can be structured into different levels with each level building off of the last one. I enjoyed how the post explained the levels sequentially while also explain how they interact with one another. I was able to grasp an understanding of these software testing levels while also understanding the importance and vital role that testing plays within the development process. The most interesting part of the blog post was the Acceptance Testing because it reminds the reader that in almost every scenario of software development there is always going to be changes to the requirements of the original project. This level builds off that idea and essentially allows the developers to make sure that the product they are working on meets the flexible criteria of a client. I found that the diagram didn’t make sense when I first looked at it before reading the post. However, as I understood the subject more, I found it to be a great source that summarized and simplified the detailed ideas within the post.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

https://www.softwaretestinghelp.com/positive-testing/#more-37401

This article explains the technique of positive testing. Positive testing is one method of testing software to make sure that it is working correctly. With this technique a valid set of test data is used to check if an application is functioning as per the specification document. For example, if you are testing a textbox that can only accept numbers, a positive test would be entering numbers into the box. This is in contrast to negative testing, which would be entering something besides numbers to see if the application breaks. The goal of this is to see if an application works as desired when it is being used correctly. For this reason, positive testing should be the first step of test execution.

There are two techniques discussed that are used in positive testing. With boundary value analysis, a tester needs to create test data which falls within a data range. With equivalence partitioning, the test input is divided into equal partitions and values from each partition are used as test data.

I thought this article was very interesting because positive testing is something that I have always done as the first step in testing without realizing there is a name for it. I think it is natural to see if your application works correctly before you test for bugs by trying to break it. The part that I found most useful was the section on equivalence partitioning. I usually just try random inputs when I am testing something, but it makes a lot more sense to divide the possible inputs into equal partitions so that data from each partition can be tested.

This article will not significantly change how I work because I have always used positive testing as the first step. Although now I will make sure to use equivalence partitioning when I am testing. I am glad I read this article because now I have a good understanding of what positive testing is and I will not be confused if I run into the term in the future. Reading this article has changed the way I think about testing because now I understand that there are different testing types and techniques that should be followed correctly to make sure that a piece of software is stable and bug-free.

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