Source: http://www.satisfice.com/blog/archives/1570

The blog post Re-Inventing Testing: What is Integration Testing? by James Bach gives an interview-like approach to exploring Integration Testing. It starts with a simple question of “What is integration testing?” and goes off from there. As the respondent answers, James leaves a descriptive analysis of the answer and what he is thinking at that point in time. The objective of the interview is to test both his knowledge and interviewee.

This was an interesting read as it seems related to a topic from a previous course that discussed coupling between which showed the degree of interdependence between software modules, which is why I chose this blog post. What I found interesting about this blog post would be his chosen interviewee was a student. So that entire conversation can be viewed from a teacher and student perspective. This is useful because it allows me to see how a professional would like an answer to be crafted and presented in a clear manner. For example, the interviewee’s initial answer is text-book like which prompted James to press for details.

Some useful information about integration testing is also provided because of this conversation. Integration testing is used during an interaction between multiple software are combined and tested together in a group. In this blog post, it is noted that not all levels of integration are the same. Sometimes “weak” forms of integrations exist, an example provided from the blog would be, when a system creates a file for another system to read it. There is a slight connection between the two systems due to them interacting with the same file. But as they are independent systems, neither of the two systems knows that the other exists.

From this blog post, I can tell that any testing requires much more than textbook knowledge on the subject. As mentioned briefly in the blog, there are risks involved with integrating two independent systems together and there is a certain amount of communication between the two systems. Depending on the amount of communication determines the level of integration between the two. The stronger the communication is between the two systems means that they are highly dependent on one another to execute certain functions.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

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.