When to use White box Testing in a software or a website?

Question

In a software or an website, when to use white box testing technique?

Answer 1

OK...now that a few folks have voiced their perspectives on "boxes" let me try to answer your question.

I am going to assume that we agree that by 'white box' testing you are referring to the act of designing static or dynamic tests based on the implementation of a programming language that performs some functional task or behavior in a software program; or more simply...designing tests from the program's source code (e.g. unit tests).

In my experience (with the exception of unit tests) white box testing is almost always used as an adjunct to black-box domain and exploratory testing approaches. White box testing is usu. done to support and extend other testing approaches; never in lieu of other testing approaches. In general, testers may need to perform 'white-box' testing when:

• There is a business need or goal to increase code coverage measures
  • If the team has a specific goal or need to improve the code coverage metric, the most efficient way to improve that metric is via white box testing. Black box and exploratory testing will increase the code coverage metric initially, but then quickly plateau. (Test coverage may be increasing, but the measure of new code paths being executed tends to flatten out.) So, if there is some reason to achieve some magical code coverage metric, white box testing is the most economical approach to reach that goal.
• There is a suspicion that some area of the program may be under-tested
  • Sometimes there may be indicators that an area of the program are under-tested. Low code coverage measures of a module or component, high complexity measures or a module or component, or high defect density in a module or component may indicate that area of the software needs a deeper level of investigation/testing. White box testing can sometimes be used to design additional tests to provide greater confidence in a specific area of the code base, or provide additional critical perspective of the implementation.
• Security/reduced risk
  • Some studies suggest that formal code reviews (which is white box testing - static analysis of the implemented code) are the single most effective approach to identify security flaws in software. This does not imply that additional security testing measures are not required.

Again, with the exception of unit testing, white box testing is not a starting point; it is used in addition to other testing. There may be benefits of adding white box testing to the test strategy for some software projects, but there can also be drawbacks such as additional cost, more time, and biased tests. Some types of software may benefit from white box testing, while it may be completely unnecessary for other types (e.g. games).

Answer 2

For a QA / Tester the coding knowledge will be useful during replication of bug if found in our Web application ! Being a QA I would not be willing to get into complete white box testing since we work on Black box as we cover higher end functionalities with various testing concepts involved in it. Well, we get into use of white box only during when we want to prove that our issue which is raised by QA is valid. Hopefully this summarises your questions. Please do let me know! Thanks

Answer 3

White box testing is based on internal structures of the software or website. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code or use of program source code as a test basis. While in black box testing a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.

Answer 4

Talking about testing boxes. Your application is like a big box with boxes inside and so on. For instance, a Web site can be a box consisting of two boxes (aka tiers or layers): frontend and backend.

Now when designing a test case are two decisions to be made

• What information will you use to design test cases? Application requirements, UI, backend API, UML, backend source code, etc.?
• Which box will you test? Whole app, only frontend, only backend or maybe a single class?

And here are some possible combinations:

1. Black-box testing of the whole app. You may test the whole external box from UI perspective, using only information you found in UI and requirements from end-user perspective.
2. Black-box testing of the backend. You may as well test only backend API (JSON Web services), looking at how API is defined.
3. White-box testing of the whole app. You may as well take a look at what specification (e.g. UML sequence diagrams) says about interaction between front-end and backend and try to cover all paths of the interaction protocol.
4. Grey box testing of the whole app. You may also try to mix information you have about the system by looking both at the internals (e.g. what are error states the backend can be in) and how the whole application is reacting for different internal states (e.g., are errors with very long messages correctly displayed in the UI?).

So which testing approach are you asking for? And how do you define white-box testing in your case? Think of a particular example of the application to discuss.

Answer 5

White-box testing usually involves tracing possible execution paths through the code and working out what input values would force the execution of those paths. Quite simple techniques exist by which the tester (usually the developer who wrote the code) can work out the smallest number of paths necessary to test, or "cover," all the code. Some types of static analysis tool will do the same job, more quickly and more reliably.

-Structure-based techniques(white box testing) can also be used at all levels of testing. Developers use structure-based techniques in component testing and component integration testing, especially where there is good tool support for code coverage.

-Structure-based techniques are also used in system and acceptance testing, but the structures are different. For example, the coverage of menu options or major business transactions could be the structural element in system or acceptance testing.