Boundary value testing is often seen as an ineffective testing methodology in comparison to other techniques. And while other techniques such as equivalence case testing might be better at testing in some situations opposed to boundary value testing, I believe there are some situations where boundary value testing is a better solution.

For instance, in a situation where you want to test that one particular variable (ie: price of a product in a product catalog) which should exist within a certain definable range (suppose price should stay between 49.99 and 28.99 depending on sales or coupons) then you have both a minimum and a maximum value already specified, and a nominal value can be as simple as the value halfway between the minimum and maximum values. In situations similar to this, boundary value testing has the potential to be much easier than some other testing methods, such as creating partitions and going through equivalence case testing.

On the other hand, in a situation where you want to evaluate a boolean value, boundary value testing makes no sense whatsoever. Since the output will on ever be true or false, there is no obvious specified minimum or maximum. And without a minimum or maximum value it would be difficult to find a nominal value which represents typical output for the variable/function being tested.

Additionally, when working with variables, sometimes the output may have an obvious boundary in one direction (ie: maximum age of a bond is 10 years) but no specified boundary in the other direction (no specified minimum age of a bond). In these cases, a limit will often have to be chosen as a minimum or maximum based off of the functionality of the software or what it’s purpose is (ie: bond cannot be less than 0 years old, can say minimum is 0).

This can be confusing at times when the upper limit is not bounded, forcing you to choose an arbitrary upper limit (ie: price is the amount someone pays for a product, specified must be greater than 0, but no specified maximum price) such as 10,000, 50, etc. This can be somewhat subjective and might vary significantly depending on the context of the program being tested, and can often introduce complications.

In terms of concrete advantages and disadvantages, this article provides a good summary of some of the major upsides and downsides (https://qtp.blogspot.com/2009/07/boundary-value-analysis-bva-problems.html).

Regarding disadvantages, boundary value testing is a poor choice for boolean values as previously discussed, and is also ineffective when working with dependent variables (if you try to use BVT with a dependent variable, you would likely also have to test for the independent variable associated which could be better accomplished through other testing procedures).

Conversely, the advantages of boundary value testing largely involve how simple it is to implement and execute, relative ease of finding lower and upper boundaries (often specified within the program being evaluated), and ability to use more or less test cases as needed (robust boundary value testing could provide a more comprehensive analysis than normal, and worst-case robust BVT could provide even more detailed information).

Because it is often dependent on the inclusion of obvious upper and lower limits, and can’t be used effectively with boolean values, the applications of BVT are not universal, but when it can be applied effectively, boundary value testing is easy to use and can provide representation of the majority of expected inputs.

Article referenced: https://qtp.blogspot.com/2009/07/boundary-value-analysis-bva-problems.html

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Software testing often involves the process of writing tests in order to ascertain the proper functioning and capabilities of software, within expected operating conditions. When coming up with test cases for a calculator program for instance, you might find it important to test that the addition of two numbers results in a correct sum following the operation.

Testing against the expected value of two arbitrarily chosen numbers (ie: 5 + 4 should equal 9) would be able to provide insight into whether the calculator is functioning as intended, but you could also choose to test for addition of negative numbers, negative and positive numbers, addition resulting in 0 and so on. Because there could be a large number of potential cases to check for, it might seem unclear what exactly would make for an optimal or objectively “good” test in this situation.

When looking into this concept, I found an article produced by Ministry of Testing (https://www.ministryoftesting.com/) a community focused around software testing and related subjects. The article (https://www.ministryoftesting.com/dojo/lessons/designing-tests-what-s-the-difference-between-a-good-test-and-a-bad-test) discusses some attributes to look out for which could be indicative of good or bad tests during the process of creating tests for a piece of software.

The process described in this article follows a series of steps, first identifying and considering risks involved with the program, things which could go wrong and which could affect the program as well as people or entities dependent on the program (users, other programs which access the one being tested).

Following the identification of risks, forming test ideas is described in terms of asking questions. So good tests would need to answer questions about the software and it’s functionality, maybe entering in a negative number, or something which is not a number in terms of the calculator example. This allows for unexpected behaviors to be considered even when they might not seem readily apparent.

Next, the test should be conducted or executed, and depending on whether or not the test reveals any relevant information (do you learn anything from it?) the information gained can be applied to improve the program, or further testing may be required if the test did not reveal anything.

I would say that this process makes sense as a basic framework to follow when writing test cases. In some cases, such as with very simple applications or non-commercial development, the risk can be practically nonexistent; the risk aspect may not always apply to every situation. But in general, this article brings up some good points and provides a helpful sequence of processes which can be followed and repeated as needed.

Article referenced:

https://www.ministryoftesting.com/dojo/lessons/designing-tests-what-s-the-difference-between-a-good-test-and-a-bad-test

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

For this course, we were introduced to the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye as a resource and reference.

Immediately, I found this book to have an interesting approach to the way it presented information. Instead of being organized in a simple front-to-back kind of format, where content would be organized by order of foundational material followed by more advanced topics, this book is organized more similarly to a wiki, with the content presented in a relatively self contained manner for each chapter rather than as a series of introductions or tutorials followed by applications.

More specifically, I think the idea of apprenticeship discussed throughout the opening chapter and throughout this text is a genuinely useful idea relative to any kind of career or interest in software development. Rather than focusing on achievement and career progress for the sake of progression, the definition of apprenticeship is more concerned with learning and the acquisition of the knowledge with the goal of learning more and knowing more each day than the ones preceding it.

The definitions of “apprentice”, “journeyman”, and “master” used in this book are interesting because they discuss them as part of a system. Apprenticeship is presented as a step in a logical progression leading forward to being a Journeyman and eventually a Master with differing priorities and activities being attributed to each one, where the apprenticeship stage is primarily concerned with learning and self-development.

I like the idea of starting out with self development, because if you don’t develop yourself and understand how you want to work and the tools you want to use going forwards, then you proceed on unstable ground which won’t be very conducive to your future development or career.

Chapter 2, “Emptying the Cup” discusses the concept of remaining open to new ideas and knowledge, even after you feel you have learned a lot about a particular topic. It deals with the idea of acknowledging what you don’t know, and confronting those deficiencies while also maintaining a “beginner’s mind” while learning new things. While the chapter goes on to discuss how these ideas can be applied to something like learning a programming language, I think they can be relevant to learning just about anything. Activities such as cooking, painting, or even tying a knot all seem like places where it could be a good idea to approach them with a “beginner’s mindset” and not assume everything through prior knowledge.

Often going through things step-by-step as an absolute beginner might seems to produce some of the most lasting impact, in my experience. I think this chapter and the idea of keeping an open mind is very valuable, especially in a field like software development where you might be exposed to many different frameworks or languages throughout a project/development period, and might be tempted to apply knowledge from one to another (possibly leading to later difficulties).

Book Referenced: “Apprenticeship Patterns by David H. Hoover and Adewale Oshineye. Copyright 2010 David H. Hoover and Adewale Oshineye, 978-0-596-51838-7.”

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.