This week I chose a blog post that covers the difference between black box and white box testing. In general, testing a program is a vital pillar in producing reliable software to customers. Testing helps uncover and mitigate defects in programs. Blackbox testing refers to the testing technique where the tester has zero knowledge of how the internal source code works. This technique involves the tester executing the code and analyzing the behavior and functionality. The reason why this practice is referred to as “black box testing” is because you can’t see in the box, similar to the tester not having access to the code. The benefit of black box testing is anyone can be a tester. Since the tester does not need knowledge of the internal code, there is not limit to who can be a tester. Non-programmers can execute the code and verify the results. A major disadvantage of this testing is the inability to pin point what caused the error. Since the tester has zero access to the internals, the only thing they know is the program doesn’t function as intended.

  White box testing, also referred to as clear box testing, is a testing method that involves having access to the internal workings of the code while testing it. This testing method requires the tester to have prior knowledge about programming to analyze the source code. White box testing focuses on the internal logic, code structure, and execution paths. This method of testing allows testers to pin point where the program failed, unlike black box. White box testing excels in scenarios where the accuracy and function of the program is crucial, because developers can easily debug. The main disadvantage to white box testing is it can be time consuming, since testers have to first understand the code’s intended function and analyze each line.

  This information is very useful to know when we cover and simulate each type of testing method in class. It’s crucial to know the disadvantages and advantages to a testing technique before deciding the most suitable one. For example, if you’re testing the user experience of a website, white box testing wouldn’t be the best option because the user isn’t going to access your websites source code. Black box testing would be the most effective technique because it focuses on the functionality of the website. Both of these testing techniques help developers and organizations deliver software that is reliable, meets user expectations, and complies with industry standards and regulations.

Blog Post: https://www.bairesdev.com/blog/black-box-vs-white-box-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

https://unstop.com/blog/structural-testing

  Structural testing is one of many types of software testing, although structural testing is directly testing the internal structure of the code which means it is important that the individual performing structural tests is very familiar with the language used for the code. This type of testing uses white box testing techniques and it is more concerned with how a system is running rather than its functionality which is the more common reason for testing. There are four different types of structural testing which are mutation, data flow, control flow and slice-based testing. Mutation testing is a type of structural testing which relies on changing small parts of the code’s structure in order to test for errors, there are different types of mutation testing which are based on changing different parts of the code’s structure in order to find possible errors. Data flow testing is used to analyze how data flows through a program and control flow is used to show the order in which statements will be executed. Slice-based testing takes a portion of statements which may affect the final value of a variable and uses those slices to test the change. There are three different techniques used while doing structural testing which are called statement, branch and path coverage. Some common open source tools for structural testing include Cucumber, JBehave, Cfix and JUnit.

  I found this article interesting as it not only gives an in-depth explanation on structural testing but it also provides you with both techniques and tools which can be used to perform such testing. The advantages and disadvantages section particularly piqued my interest as one of the first advantages listed is that early defects can be easily identified which I would infer is due to the direct testing of the code structure versus testing its sole functionality. The cost of this type of testing however is a huge disadvantage as the time and money it takes to go through all of the testing necessary is much more than other types of testing. This article did teach me a lot about structural testing as most of the testing I have personally done has been testing what inputs get a certain output and testing direct implementation of a body of code versus actually testing the structure and being able to see how a piece of data flows through code which is a very important aspect of testing even if this testing is very expensive.

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

After getting through a couple weeks of my classes, and looking through blogs online about testing, I found the stickyminds blog. In my first week I was given setup tasks for CS-443 Software Quality Assurance and Testing, and one of those tasks was to discover blogs and podcasts related to the course content. I used this blog for my setup tasks, and found it a useful compendium of resources. While searching through stickyminds, I focused on the area around ‘new to testing’, and found a specific article about how to improve your skills as a performance tester quite interesting. The article’s title is How to Become a Better Performance Tester 101 by Jun Zhuang.

The blog begins with a small piece of advice based on segmenting code for testing. While some people might argue that you should test and optimize after large portions of the code are complete, this blog argues instead for doing performance testing while it is still incomplete. It is also advised to learn performance testing under someone who is very experienced in the topic, as many performance testers don’t understand or know which questions they should be asking. This is why shadowing is very important, as it allows a new performance tester to pick things up quicker, and gather an understanding of the tools used more effectively. Jun Zhuang discusses Agile software development teams that are commonly used in industry. He describes them as being used to handle performance testing responsibilities. These teams use strategies such as getting developers involved in capturing performance issues early, communication between teams and testers, and holding critical team meetings more frequently. They still face occasional struggles to meet deadlines when performance issues arise, but these teams are overall described as efficient and useful. The latter half of the blog explains the importance of performance testing, and why you should put this effort into doing it. By exploring these components like applications, or databases testers can better design tests and diagnose issues. The blog also shares some personal accounts of testers utilizing their knowledge in programming to speed up testing processes, by writing stubs and generating test data. It stresses the importance that individuals with diverse technological backgrounds, even if less experienced in performance testing, can bring valuable insights and problem-solving skills to the role.

I chose this blog because I am very interested in improving my skills at all times. When I discovered the Stickyminds blog, I was excited by the amount of information it presented. This blog on performance testing I discovered in the new to testing section, which has a lot of very useful articles to help you improve your skills. Even small pieces of advice and tactics can make the difference when it comes to coding and testing especially. A personal weakness with testing in my own projects I had, was that I was worried my code was not optimized enough, and what I learned through this blog is something I will apply to improving optimization, especially seeking out someone experienced to work with and improve my skills. 

Source:

https://www.stickyminds.com/article/how-become-better-performance-tester-101

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have chosen to discuss the blog “An Overview of Unit Testing” by Kayode Adeniyi; this article discusses the importance of unit testing, what it is, the stages of the unit testing process, as well as discusses some differences between automated and manual unit testing. I chose this topic for this week’s blog post because unit testing fits well within the issues we are discussing in this class; I also like how the author discusses the differences between manual and automatic testing.

The first topic the blog discusses is what unit testing is. “Unit testing is a testing method in software development where each individual part (unit) of an application is tested to analyze its proper working. This approach is pretty common and used by most development teams to verify the accuracy of each software component.” In my opinion, understanding what unit testing is is imperative, especially understanding that each test tests a part of a system, not the whole system.

The blog then mentions some key aspects of unit testing, which are, in part, why they are so helpful for developers in all fields of software development. The key aspects mentioned are debugging errors from the root, having reliable testing procedures, repeatability at every stage, and simplicity over complexity. The article also mentions that separating each part of a program makes it much easier to find and correct errors that appear as you are working on a project. The blog also discusses the steps in developing unit tests.

The first step of the test development process is planning the test. The blog describes this first step as “… [T]he developer defines the objective and scope of the testing. Once the unit of application is identified, the developer also defines the criteria for testing it. Critical thinking and effective planning is needed at this stage to ensure focused testing.” Due to this step’s importance in determining the functionality of the final test, it is one of the most essential parts of the test development process.

The next phase of creating unit tests is the creation of test cases. The blog describes test cases as scenarios where the units’ functionality is being tested. The blog also discusses edge cases or scenarios in which an unlikely event is to occur but still needs to be tested in the event where this unlikely event happens. The article defines an edge case as “… an occurrence of an extreme scenario during the normal expected working of any software. They are often the rare events that can happen when a user uses the software application.” While these events are unlikely to occur, if your project will be used by many people over a long enough period of time, these edge cases are an inevitability.

Blog: https://blog.logrocket.com/product-management/unit-testing-guide/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Over the past few classes of the semester, we’ve gone over some of the terms as well as the methods used in software testing. Two of the methods that stood out to me were Black Box Testing and White Box Testing, mainly because I assumed they were methods that were closely related. We didn’t go in depth with these terms and methods but from what I researched and discussed with my group, my assumption was correct.

Black Box Testing is a method in which the software is tested without looking into how it works internally. Testers provide inputs then observe the outputs produced by the system. The goal is to evaluate how the system responds to “user actions that are both expected and unexpected.” This method can help identify defects, errors, and the like from a user’s perspective, as they usually have no knowledge of the inner workings of the software. This also means that testers don’t need a deep understanding of software testing or the particular code of the software; and as such, qualifications are not so important.

White Box Testing is a method in which the internals of the software are examined and tested. Testers examine everything within the software, such as the structure, logic, and code, and create test cases that assess that. This method is effective at uncovering issues with code quality and structure, bugs, and more that can’t be seen or evaluated with Black Box Testing. Like Black Box Testing, testers must ensure that the software meets specification. Unlike Black Box Testing, testers need a deep understanding of coding and software testing as well as that particular software being tested. 

I believe that both will be very important in the software development process, although I do lean towards White Box Testing having more impact. Those with specialized knowledge and skills will likely sort things out faster looking at the internals of the code than those without looking at just the inputs and outputs. It’ll generally be more effective as well as tests are done on the code and thus developers can quickly fix and solve those issues; whereas with Black Box Testing, it’s more of a way to acknowledge that there is some issue. I can only imagine Black Box Testing to be a very tedious and monotonous process although I could be completely wrong. It may be most effective to implement White Box Testing first and Black Box Testing afterward, as a double check of sorts.

Source: https://www.ranorex.com/blog/black-box-vs-white-box-testing-understanding-the-differences/

From the blog CS@Worcester – Kyler's Blog by kylerlai 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.