Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Static vs Dynamic Testing

Two common methods used for software testing are static and dynamic testing. Now, although they are both testing methods, there are a lot of differences between them. First we need to define what each of them are. Static testing is when we test the software to look for errors or defects, but we are not going to actually execute the code. Now on the other hand, for dynamic testing we test the software by executing the code and see if there is any errors with inputs and overall function of the software. Static testing is conducted with specific documents related to the software and the goal is to find errors early on in the development cycle before the software gets too advanced. Dynamic testing executes the code and analyzes things such as the input and output of the software to determine the correct results. The goal for dynamic is to test the functional behavior of the code and also takes into account memory, CPU as well as the performance of the software put together. Static testing uses manual or automated testing of the documents by examining things such as the requirements for the software, the source, necessary test cases or any thing related to the overall design. Dynamic testing is more direct testing to whether the software works by using techniques such as black or white box testing and it confirms that the code works in the way it is desired to.

The main differences between static and dynamic is one thing we stated earlier about how static won’t be executed, whereas dynamic will. Another important factors is the stages with where these tests occur, as static happens early in the process of developing software, whereas dynamic is towards the end or completion stage. The goal of static testing is to prevent any bugs or errors from being produces, but dynamic tests finds bugs or errors that were created with the development of the software. Static testing is more simply known as the verification process, whereas dynamic testing is more about the validation process. Static testing is known to generally take shorter time, whereas dynamic will take a little bit longer due to the variance of test cases that need to be implemented. Overall, both of these testing methods are important in the development of software, but they occur at different stages and can be helpful to do both efficiently to lead to the least amount of error in the software.

Resources:

https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing/ https://www.guru99.com/static-dynamic-testing.html

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Boundary Value and Equivalence Class Testing

This week in the Software Quality Assur&Test class we got the third assignment that was about Boundary Values and Equivalence Class Testing. We had worked during class time in different activities that covered this assignment so I would say I really enjoyed working in this assignment. We had to complete three parts each with a different level of difficulty. I learned to understand more of the way testing works and what exactly get tested.

What we covered in this homework:

Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values.

Robust Boundary Values. Introducing outside of boundary values.

Equivalence Class Testing, which is also known as Equivalence Class Partitioning (ECP) and Equivalence Partitioning, is an important software testing technique used by the team of testers for grouping and partitioning of the test input data, which is then used for the purpose of testing the software product into a number of different classes.

Weak Normal Equivalence Class Testing: In this first type of equivalence class testing, one variable from each equivalence class is tested by the team. Moreover, the values are identified in a systematic manner. Weak normal equivalence class testing is also known as single fault assumption.

Strong Normal Equivalence Class Testing: Termed as multiple fault assumption, in strong normal equivalence class testing the team selects test cases from each element of the Cartesian product of the equivalence. This ensures the notion of completeness in testing, as it covers all equivalence classes and offers the team one of each possible combinations of inputs.

Worst-Case boundary value analysis is a Black Box software testing technique.

In Worst case boundary value testing, we make all combinations of each value of one variable with each value of another variable.

Edge Testing is a combination of Boundary Value Analysis and Equivalence Class Testing.

Weak Robust Equivalence Class Testing: Like weak normal equivalence, weak robust testing too tests one variable from each equivalence class. However, unlike the former method, it is also focused on testing test cases for invalid values.

Strong Robust Equivalence Class Testing: Another type of equivalence class testing, strong robust testing produces test cases for all valid and invalid elements of the product of the equivalence class. However, it is incapable of reducing the redundancy in testing.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Craft over Art

This week I choose to talk about the craft over art pattern. So, what is this pattern about? The book explains that craftsmanship is built upon strong relationships. This pattern is not about doing merely what is expedient. It also encompasses the idea that a useful craft artifact always displays at least a minimal level of quality. When using this pattern, you will have to balance your customer’s desire for the immediate resolution of their problem with the internal standards that make you a craftsman. 
There are many things a developer should keep in mind when he/she develops a program but one thing that we should never forget is that you are primarily building something that serves the needs of others, not indulging in artistic expression. Developers think creatively, experimenting with different solutions to fit user needs and generally are comfortable with design systems. I have been many times in the place where I had to build something that I didn’t feel like it, but it is the customer that you need to satisfy.
Something that I really like from this pattern is when the book explains that You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.
When you are making decisions about software, you should guide yourself by always keeping this in mind: How we can help? You can even prioritize feature requests this way. Remember: the purpose of the software is not to show off how intelligent you are.  Your purpose is to help people — Max Kanat-Alexander, Code Simplicity

Reference:

Apprenticeship Patterns by Adewale Oshineye; Dave Hoover

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

The Best of Both Worlds: Edge Testing over Boundary-Value Testing or Equivalence Partition Testing

Christian Shadis

Self-Directed Blog Post #3

Two common testing techniques in Black-Box Software Testing are Boundary Value Testing (or Boundary Value Analysis) or Equivalence Partition Testing (or Equivalence Class Testing). Both techniques examine the output of a program given its inputs.

Consider a function eligibleForScholarship which accepts two inputs, SAT score (for simplicity, only considering 1600 scale) and GPA (on a 4.0 scale) and returns in dollars the total reward a student is eligible to receive. At CompUniversity, a student will receive a scholarship if their SAT score is at least 1200 and their GPA is at least 3.5. The amount of that scholarship is determined by the criteria in the table below.

SAT Score SAT Score Award
0-1199 $0
1200-1399 $1000
1400-1600 $2500

In addition to the SAT reward, additional money is given based on GPA.

GPA % of SAT award earned
0-3.49 0%
3.5-3.74 100%
3.75-3.89 120%
3.90-4.0 150%

For example, a student with an SAT score of 1450 and GPA of 3.8 will receive $2500 plus an additional 20% for a total of $3000. A student with an SAT score of 1600 and a GPA of 3.49 will receive $0.

If software tester wanted to write test bases based on Robust Boundary Value Analysis, they would arrive at the following set of test cases:

Boundaries:
SAT Score upper bound: 1600 (physical limit)
SAT Score lower bound: 0 (physical limit)
GPA upper bound: 4.00 (physical limit)
GPA lower bound: 0.00 (physical limit)

Test Case SAT Score GPA Expected Output
1 <x1min-, x2nom> -1 3.50 Exception
2 <x1min, x2nom> 0 3.50 0
3 <x1min+, x2nom> 1 3.50 0
4 <x1max-, x2nom> 1599 3.50 2500
5 <x1max, x2nom> 1600 3.50 2500
6 <x1max+, x2nom> 1601 3.50 Exception
7 <x1nom, x2nom> 1200 3.50 1000
8 <x1nom, x2min-> 1200 -0.01 Exception
9 <x1nom, x2min> 1200 0.00 0
10 <x1nom, x2min+> 1200 0.01 0
11 <x1nom, x2max-> 1200 3.99 1500
12 <x1nom, x2max> 1200 4.00 1500
13 <x1nom, x2max+> 1200 4.01 Exception

Disadvantages of Boundary Value Testing:
There are possible outputs that this set of test cases never checks (e.g. $3000, $3750). Additionally, this set of test cases fails to test the behavior inside the program, instead focusing on outermost limits.

If the software tester instead wanted to write test cases based off of Strong Normal Equivalence Partitioning, they would arrive at the following set of test cases:

Test Case SAT Score GPA Expected Output ($)
1 (0 <= sat < 1200, 0 <= gpa < 3.50) 1000 2.0 0
2 (1200 <= sat < 1400, 0 <= gpa < 3.50) 1300 2.0 0
3 (1400 <= sat <= 1600, 0 <= gpa < 3.50) 1500 2.0 0
4 (0 <= sat < 1200, 3.50 <= gpa < 3.75) 1000 3.6 0
5 (1200 <= sat < 1400, 3.50 <= gpa < 3.75) 1300 3.6 1000
6 (1400 <= sat <= 1600, 3.50 <= gpa < 3.75) 1500 3.6 2500
7 (0 <= sat < 1200, 3.75 <= gpa < 3.90) 1000 3.8 0
8 (1200 <= sat < 1400, 3.75 <= gpa < 3.90) 1300 3.8 1200
9 (1400 <= sat <= 1600, 3.75 <= gpa < 3.90) 1500 3.8 3000
10 (0 <= sat < 1200, 3.90 <= gpa <= 4.00) 1000 3.95 0
11 (1200 <= sat < 1400, 3.90 <= gpa < 4.00) 1300 3.95 1500
12 (1400 <= sat <= 1600, 3.90 <= gpa < 4.00) 1500 3.95 3750

Disadvantages of Equivalence Partitioning:
This set of test cases does not successfully account for behavior at the boundaries of valid inputs, nor does it account for the behavior of the program with every possible combination of inputs.

The disadvantages of boundary value testing and equivalence partitioning can be addressed by instead implementing edge testing.

Edge Testing

In Edge testing, we want to examine any point at which behavior changes, and create test cases for all of those ‘boundaries’, along with values close to the boundaries on either side.

The SAT edge cases can be listed as {-1, 0, 1, 1199, 1200, 1201, 1399, 1400, 1401, 1599, 1600, 1601}.
The GPA edge cases can be listed as {-0.01, 0.00, 0.01, 3.49, 3.50, 3.51, 3.74, 3.75, 3.76, 3.89, 3.90, 3.91, 3.99, 4.00, 4.01}.

Test cases can now be created by taking all pairwise combinations of edge cases (Worst-case). There are too many test cases to list here without taking up unnecessary space, but now our tests account for each and every possible combination of inputs.

Edge testing combines the best attributes from Boundary Value testing and Equivalence Partitioning into one comprehensive technique. Edge testing successfully tests the upper and lower bounds for each input, and it successfully examining inner behavior at each partition.

Edge testing has a major drawback: the number of test cases needed. In this example, there are 12 * 15 = 180 test cases, but it has unrivaled behavior coverage. The decision of which testing technique to use depends largely on the program for which the tests are being developed, but for a smaller number of partitions in the inputs, edge testing is a relatively simple but comprehensive technique for testing all possible behavior.

Articles used for my research:
https://professionalqa.com/equivalence-class-testing
https://artoftesting.com/boundary-value-analysis
https://www.mindfulqa.com/edge-cases/
Class materials from CS-443 at Worcester State University

From the blog CS@Worcester – Christian Shadis&#039; Blog by ctshadis and used with permission of the author. All other rights reserved by the author.