5 ways to think about Black Box testing :

An easy way to start up a debate in a software testing forum is to ask the difference between black box and white box testing. These terms are commonly used, yet everyone seems to have a different idea of what they mean.

Black box testing begins with a metaphor. Imagine you’re testing an electronics system. It’s housed in a black box with lights, switches, and dials on the outside. You must test it without opening it up, and you can’t see beyond its surface. You have to see if it works just by flipping switches (inputs) and seeing what happens to the lights and dials (outputs). This is black box testing. Black box software testing is doing the same thing, but with software. The actual meaning of the metaphor, however, depends on how you define the boundary of the box and what kind of access the “blackness” is blocking.

An opposite test approach would be to open up the electronics system, see how the circuits are wired, apply probes internally and maybe even disassemble parts of it. By analogy, this is called white box testing, but already the metaphor is faulty. It is just as hard to see inside a white box as a black one. In the interests of logic, some people prefer the term “clear box” testing, but even a clear box keeps you from probing the internals of the system. It might be even more logical to call it “no box” testing. But the metaphor operates beyond logic. Since “white box” testing is the most common term, I’ll use it here.

To help understand the different ways that software testing can be divided between black box and white box techniques, I’ll use the Five-Fold Testing System. It lays out five dimensions that can be used for examining testing:

1. People (who does the testing)
2. Coverage (what gets tested)
3. Risks (why you are testing)
4. Activities (how you are testing)
5. Evaluation (how you know you’ve found a bug)

Let’s use this system to understand and clarify the characteristics of black box and white box testing.

People: Who does the testing?
Some people know how software works (developers) and others just use it (users). Accordingly, any testing by users or other nondevelopers is sometimes called “black box” testing. Developer testing is called “white box” testing. The distinction here is based on what the person knows or can understand.

Coverage: What is tested?
If we draw the box around the system as a whole, “black box” testing becomes another name for system testing. And testing the units inside the box becomes white box testing. This is one way to think about coverage.

Another is to contrast testing that aims to cover all the requirements with testing that aims to cover all the code. These are the two most commonly used coverage criteria. Both are supported by extensive literature and commercial tools. Requirements-based testing could be called “black box” because it makes sure that all the customer requirements have been verified. Code-based testing is often called “white box” because it makes sure that all the code (the statements, paths, or decisions) is exercised.

Risks: Why are you testing?
Sometimes testing is targeted at particular risks. Boundary testing and other attack-based techniques are targeted at common coding errors. Effective security testing also requires a detailed understanding of the code and the system architecture. Thus, these techniques might be classified as “white box.”

Another set of risks concerns whether the software will actually provide value to users. Usability testing focuses on this risk, and could be termed “black box.”

Activities: How do you test?
A common distinction is made between behavioral test design, which defines tests based on functional requirements, and structural test design, which defines tests based on the code itself. These are two design approaches. Since behavioral testing is based on external functional definition, it is often called “black box,” while structural testing—based on the code internals—is called “white box.” Indeed, this is probably the most commonly cited definition for black box and white box testing.

Another activity-based distinction contrasts dynamic test execution with formal code inspection. In this case, the metaphor maps test execution (dynamic testing) with black box testing, and maps code inspection (static testing) with white box testing.

We could also focus on the tools used. Some tool vendors refer to code-coverage tools as white box tools, and tools that facilitate applying inputs and capturing inputs—most notably GUI capture replay tools—as black box tools. Testing is then categorized based on the types of tools used.

Evaluation: How do you know if you’ve found a bug?
There are certain kinds of software faults that don’t always lead to obvious failures. They may be masked by fault tolerance or simply luck. Memory leaks and wild pointers are examples. Certain test techniques seek to make these kinds of problems more visible. Related techniques capture code history and stack information when faults occur, helping with diagnosis. Assertions are another technique for helping to make problems more visible. All of these techniques could be considered white box test techniques, since they use code instrumentation to make the internal workings of the software more visible. These contrast with black box techniques that simply look at the official outputs of a program.

To summarize, black box testing can sometimes describe user-based testing (people); system or requirements-based testing (coverage); usability testing (risk); or behavioral testing or capture replay automation (activities). White box testing, on the other hand, can sometimes describe developer-based testing (people); unit or code-coverage testing (coverage); boundary or security testing (risks); structural testing, inspection or code-coverage automation (activities); or testing based on probes, assertions, and logs (evaluation).

Mohit Wattal
Quality Analyst,
Mindfire: India's Only Company to be both Apple Premier & Microsoft Gold certified.
Feel Proud to be a part of Team Mindfire.

How to write good passwords

A good password is a system for creating codes that are easy to remember but hard to crack

A good password isn't a password at all. Instead, it's a system for creating codes that are easy to remember but hard to crack. And by codes we do mean codes, plural, so that someone who finds out one of your passwords won't know them all. Here's one methodology to help you generate unguessable but memorable gibberish.

Step 1: Choose a core phrase. Start with a phrase that's at least five words long. It could be the first line of a song, a quotation, a book title - anything that sticks in your head. Draw your core password from that, perhaps by using the first letter of each word:

tcith

These are the first letters of the book title "The Cat in the Hat," for example.

The payoff: This simple step protects you from someone who is running what's called a dictionary attack, in which every single word in the dictionary (and many proper names too) are tried until the right one is found. Computers can run through a dictionary attack in no time flat.

Step 2: Replace some lowercase letters with capital letters, numbers or symbols. Now mix things up by creating conventions around letters that you'll always make uppercase or change to symbols or numbers. Do what makes sense to you, so you don't have to write your system down:

Tc!tH

Here, we've capitalised the first and last letters of the phrase, and replaced an "i" with an exclamation point. You could also make "@" stand in for "a," "1" stand in for "l," and so on.

The payoff: This step exponentially increases the amount of time it takes for someone who is running a password cracking program that burns through every possible combination of characters until it finds the right one. Rather than guessing from the 26 lowercase letters on the keyboard, the program has to try 52 uppercase and lowercase letters, plus 10 digits and at least 10 more punctuation marks.

Step 3: Customise the password for each site or application. You can use the same core password multiple times, but add a character or three to ensure that every passphrase includes a number, and also that the passphrase is at least seven characters long. To get there, think up a system for generating an extra letter and number based on the name of the website or program you're accessing.

o5Tc!tH

Assuming that the password is for a Yahoo webmail account, we've added an "o" - for the last letter of Yahoo - and a 5, for the number of letters in Yahoo.

The payoff: We started with a password of five lowercase letters, which has 11,881,376 variations (26 to the fifth power, for math wonks). After step three, our password has more than 10 trillion combinations of characters (72 to the seventh power). Even a desktop computer that can guess a million passwords per second will need more than three months to run through all those possibilities.

Step 4: Write down your hint. As long as you understand your methodology and rules, now you can write down a mnemonic device that will jog your memory without being obvious to anyone else. You should still keep this piece of paper hidden, though. Author and security expert Bruce Schneier recommends keeping actual passwords on a piece of paper in your wallet, because you guard it closely and know when it goes missing. Keeping hints there should be even safer. This would be enough to make us remember that we used the title "The Cat in the Hat" to generate our basic password.

Step 5: Repeat. While you can use the same core phrase for multiple accounts, make sure that you establish different levels of passwords. You could use the same core phrase for all accounts that don't involve financial information, another one for accounts where you've used your credit card number and a third for online banking. In an ideal world, passwords should be changed at least every 90 days. But most of us would be doing pretty well if we changed them whenever daylight saving time starts and stops.