What colour tester are you ?

Another totally unscientific survey - how many readers of this site would consider themselves to be black box testers, white box testers or grey box testers ?

Or if you are a test manager, what colour testing do the testers you are in charge of do ?

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Jake Brake on January 14, 2009 at 11:09am: Shrini,

I have no problems with boxes.

When people happily accept the notion of black, grey, white - I think they apply the model of one box.

I suppose that depends upon the individual. What if people do not think as you think they do? I do not and I am not alone. wink I happily accept the notion just as happily as I accept many things. Am I confined by what I accept? No.

A black box tester will think that she has a black box (at times /pretending/ as though she can not see the stuff inside) and interacts with the stuff that is supposed to behave in certain way (regardless of the /structure/ stuff inside). While a whit box tester has a glass box or a transparent white box to work with .. she sees the stuff and structure inside and tests with it.

This is all speculation - correct? By "she" I presume you mean two or more genders - correct? wink

Hence in "one box" (color) analogy - all the software/hardware (application under test, operating system, all third party software etc) components are abstracted as one cohesive unit that is put inside a huge box which at times behaves clear box or opaque black box or any other color depending upon the observer (the tester) who is out side the box - an inside-out model ... (what would happen if the observer is inside the box and looks at the walls and structure of the box - boundaries etc ? how will that change the model ?) So you can see ... this a very primitive model ...
The position of the observer does not make for a primitive model - correct? I think what people here are saying is that a box is simply a way to categorize and organize. I do not see that anyone here limits themselves accordingly.

All professions have their own jargon. Software testing is no different. winkwink

Permalink Reply by Shrini on January 14, 2009 at 11:03pm: Responding to Jake ...

>>> I suppose that depends upon the individual.
That is fine ... I have no problems with that ...

>>>What if people do not think as you think they do? I do not and I am not alone.

That is fine too.... people thinking differently should be encouraged .. that is good for the testing craft ... I think differently than others ...so you do.

>>> I happily accept the notion just as happily as I accept many things.

That is perfectly fine. All I said was - people that accept notion of white/black/grey happily ARE applying "one box" model that suites their needs. We are putting that "one box" model into analysis, questioning and debate...
Are you interested in participating that discussion ...?

I suppose, one way to address Phil's question of tester's color is what model they use when accept colors?

>>> This is all speculation
Why? what made you to think so? This is inline with my experience and testing philosophy... I am telling this through my own experience of watching many testers who use the black box/white box titles....do you have a different version? Have you seen people using the color/box models in different way than I did?

>>> By "she" I presume you mean two or more genders - correct?
I could have just said "he/she" - I meant some human tester ... that is not important for this discussion, in my opinion. wink

>>> The position of the observer does not make for a primitive model - correct?

I am not sure what you mean here. I am only saying the bringing in the dimensions of "observer", "boundaries", "position of the observer" - we are making model "rich".

>>> I think what people here are saying is that a box is simply a way to categorize and organize.

I see more to this ... why people are talking about only "one" box ? I can see many boxes, many dimensions to model the test space ....I am trying to go beyond "primitive" model of "one box" ... so that I can learn more about constraints, system interactions and hence make testing more informative.

>>>> I do not see that anyone here limits themselves accordingly.

If that is the case ... why I see very few people challenging the notion of boxes? That to me, looks like a hint that people /might be/ getting limited by "one box" model. People might not be challenging because the model is "good enough" them. People might not be challenging because that does not contradict their model of testing. People might not be interested in challenging because they do not find problems/flaws or shortcomings of the model.

You might say .. they think differently hence "one box" model is OK or just enough to get the work done. As a tester, I challenge the model and I am open to be challenged....

>>> All professions have their own jargon. Software testing is no different.

So ... what do you suggest? ... just accept the jargon (possibly create some on your own) and move on? or ask "what does that mean", "when that is applicable", "when that is likely to be true? how true?", "what can blind (deceive) people", "what assumptions are being made", "what if those assumptions are wrong"? "what useful that I can get out this NOW? and so on .... I am on that path ... I love to challenge "jargon" and see the life beyond them ... winkwinkwink

Let us talk about problems with one box model ... can we start?

Shrini

Permalink Reply by Jake Brake on January 14, 2009 at 11:35pm: Shrini,

Thank you for your response. Back on topic... I do mostly testing that is considered gray box according to the definitions I subscribe to. Do I let it drive me or am I colored-box driven? No. Do I care or think what color or shade of gray of testing I might be involved in? No, not unless someone asks as did Phil, or - if my wife hands me some brown boxes and points at some stuff to stuff into those brown boxes - boxes that will be stored with other brown boxes containing stuff. I have no further thoughts beyond what I already contributed to this topic. (smiling)

Permalink Reply by Michele Smith on January 14, 2009 at 11:18pm: Hi Shrini,

I think I may have been misunderstood by you. I do not view the box as a model, but rather as a metaphor (as Michael Bolton states, very well I might add, in his answer to the question in this forum). I view how I test software in layers more than in boxes.

However, I do believe there is value in using the metaphor of black box, white box, grey box, etc.

Software testers have a difficult time explaining to everyone-who-isn't-a-tester-but-is-on-the-project exactly what it is we do, why we do it, to what level we do it, etc. There is value in giving others some understanding of what we do and yet at the same time removing the thought that we will be testing every conceivable system configuration out there. If we tell the "people that matter" (James Bach), we are Black Box testing,
they have a better understanding of what we are focused on - the product that matters to them.

I also believe there is value in helping other testers understand the differences between the "levels" of testing. Once they reach a certain point they will find out that testing the software is really testing the software in the system (and variants of the system they are testing on/in at the moment) on their own - if they care to. In fact, the AST, which has the BBST Foundations course available free to members, teaches about Black Box Testing. Though it is called a Black Box Software Testing course, it is not about a closed-minded model, but rather it teaches testers to open their minds. The course teaches testers to read, to understand, and to think. Thinking is never a bad thing :)

Permalink Reply by Shrini on January 15, 2009 at 12:21am: Responding to Michele,

>>>Software testers have a difficult time explaining to everyone-who-isn't-a-tester-but-is-on-the-project exactly what it is we do, why we do it, to what level we do it, etc. There is value in giving others some understanding of what we do and yet at the same time removing the thought that we will be testing every conceivable system configuration out there. If we tell the "people that matter" (James Bach), we are Black Box testing, they have a better understanding of what we are focused on - the product that matters to them.

I totally agree with you on this. I think just ran little ahead in thinking about boxes and colors. I saw it is a test modeling problem hence "one box" model appeared little basic to me. In the context that you mention (explaining other testers about level of testing) - you are right, box analogy might help in articulating.

>>> I do not view the box as a model, but rather as a metaphor
That is a interesting point ... how do you distinguish between a model and a metaphor? Pulling of little English literature I read many years back .. a metaphor is a literary construct that compares two seemingly unrelated items.It is a figure of speech that compares two or more things not using like or as. (Wikipedia).
I think that using metaphors is a modeling technique so when we talk about metaphors, we would end up in talking about models. When attempt to model a test item by comparing with another relatively well known subject (as in "The structure of this house is like a pyramid) - we are using a metaphor.

I would be interested to know if you distinguish between metaphor and model ... it seems that you do ....

Also notice that what Michael said "The metaphor of the black box is intended to represent a system for which we have no knowledge of the internals. As a tester, I'm rarely in that position unless I want to be, and I rarely want to be Simply by asking for it, I can usually pop the lid off the box entirely by asking for the source code itself, or for other useful forms of information about the internals."

So, at many times it would not be useful to stop at black box metaphor - "pop the lid off" ... get inside the box and discover many boxes that are there ... (you mentioned about "layered" testing ...).

Shall I say "boxes" are like "light" exist in dual nature (particle and wave ...) Enter Quantum theory? .... :)

Shrini

Permalink Reply by phil kirkham on January 14, 2009 at 4:39pm: But you do recommend that people take the Black Box Software Testing Course ;)

Permalink Reply by Jay Philips on January 10, 2009 at 5:54pm: I believe all the boxes should be purple.

I find myself doing more black & gey box than anything else.

Permalink Reply by Malinda on January 12, 2009 at 9:52am: black,i'm new to software test and now i'm a mobile software tester,you know mobile is so complex,there are so many things to learn.

Permalink Reply by Innes Gray on January 12, 2009 at 12:44pm: Don't think it's matter of colour.

If I need to see inside the box I disassemble.

Maybe I'm thinking about your other question on toys?

Permalink Reply by Simon Godfrey on January 12, 2009 at 1:34pm: It's an interesting question and I really enjoyed reading Michael's blog post on the topic. I find that testing is all about perspectives and therefore when testing via the black-box perspective I tend to think of a tester positioning themselves as a user. Irrespective of how the code says it should work, how does it actually work, what's the UI like, how easy is the application to use?

At the point we look at the inner workings of a program there can be a tendancy to remove that independant perspective which a user may have and we'll in turn focus on the program with a different mindset, unless we actively guard against this.

Value in both, mind.

Permalink Reply by Jonathan Kohl on January 12, 2009 at 8:25pm: I don't tend to use the testing "box" color terms much anymore. I've found that a lot of people find it confusing, and it doesn't map to the way I think about systems. I prefer to think about contexts, coverage and techniques, tools, etc. we can use in those contexts. My simple view is three contexts - code (what is developed, and unit testing, code reviews, inspections, and related code coverage), system (where the software lives, and integration, state-based and other models of coverage) and social (where the software appears in our world and is used by humans, functional testing, usability testing, on and on for coverage and techniques) I have some rambly keynote slides from '05 here: http://www.kohl.ca/presentations/automation_context_matters.pdf

We tend to often ignore what I call the system context, and focus on automated unit testing in the code context, that can get some sort of code-coverage, and functional testing in a deployed application (social context), and think of coverage as one sort of measure. I see coverage potential in many ways in each of those contexts, and there are complementary activities we can undertake in all three, that help us get more coverage, using more models more efficiently than testing in only one.

To answer your question, I don't tend to do code reviews or "white box testing" and I don't only do what is called "black box testing" and the side-door test automation I do in the system context would probably be called "grey box", but I'm with Michael B. on this one. :-)

So my thinking has shifted, and I think black boxes are best for cockpit recorders. :-) The first article I had published contained that term, and I had several emails asking me if I was testing aircraft software. That led me to start explaining how I was modeling the software in my own mind. Your mileage might vary.

-Jonathan

Permalink Reply by Michael Bolton on January 12, 2009 at 8:40pm: Note that cockpit recorders, so-called black boxes, are in fact bright orange. :)

---Michael B.