Black-box testing focuses on software's external attributes and behavior. Such testing looks at an application's expected behavior from the user's point of view. White-box testing (also known as glass-box testing), on the other end of the spectrum, tests software with knowledge of internal data structures, physical logic flow, and architecture at the source code level. White-box testing looks at testing from the developer's point of view. Both black-box and white-box testing are critically important complements of a complete testing effort. Individually, they do not allow for balanced testing. Black-box testing can be less effective at uncovering certain error types, such as data-flow errors or boundary condition errors at the source level. White-box testing does not readily highlight macrolevel quality risks in operating environment, compatibility, time-related errors, and usability.
Gray-box testing incorporates elements of both black-box and white-box testing. It considers the outcome on the user end, system-specific technical knowledge, and operating environment. It evaluates application design in the context of the interoperability of system components. The gray-box testing approach is integral to the effective testing of Web applications because Web applications comprise numerous components, both software and hardware. These components must be tested in the context of system design to evaluate their functionality and compatibility.
Gray-box testing is well suited for Web application testing because it factors in high-level design, environment, and interoperability conditions. It will reveal problems that are not as easily considered by a black-box or white-box analysis, especially problems of end-to-end information flow and distributed hardware/software system configuration and compatibility. Context-specific errors that are germane to Web systems are commonly uncovered in this process.
Another point to consider is that many of the types of errors that we run into in Web applications might be well discovered by black-box testers, if only we had a better model of the types of failures for which to look and design tests. Unfortunately, we are still developing a better understanding of the risks that are associated with the new application and communication architectures. Therefore, the wisdom of traditional books on testing [e.g., Testing Computer Software (Kaner et al., 1993)] will not fully prepare the black-box tester to search for these types of errors. If we are equipped with a better understanding of the system as a whole, we'll have an advantage in exploring the system for errors and in recognizing new problems or new variations of older problems.
As testers, we get ideas for test cases from a wide range of knowledge areas. This is partially because testing is much more effective when we know what types of bugs we are looking for. We develop ideas of what might fail, and of how to find and recognize such a failure, from knowledge of many types of things [e.g., knowledge of the application and system architecture, the requirements and use of this type of application (domain expertise), and software development and integration]. As testers of complex systems, we should strive to attain a broad balance in our knowledge, learning enough about many aspects of the software and systems being tested to create a battery of tests that can challenge the software as deeply as it will be challenged in the rough and tumble of day-to-day use.
Finally, I am not suggesting that every tester in a group be a gray-box tester. I have seen a high level of success in several test teams that have a mix of different types of testers, with different skill sets (e.g., subject matter expert, database expert, security expert, API testing expert, test automation expert, etc.). The key is, within that mix, at least some of the testers must understand the system as a collection of components that can fail in their interaction with each other, and these individuals must understand how to control and how to see those interactions in the testing and production environments.
Web Service Testing Related Interview Questions
|LoadRunner Interview Questions||Web Service Testing Interview Questions|
|ETL Testing Interview Questions||Testing Tools Interview Questions|
|QTP Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Oracle SOA suit 11g Interview Questions|
|Automation Testing Interview Questions||Soap UI Interview Questions|
|API testing Interview Questions||Test Cases Interview Questions|
|Selenium WebDriver Interview Questions||Web testing Interview Questions|
|Performance Testing Interview Questions||Test Estimation Interview Questions|
|Advanced C# Interview Questions||Embedded Testing Interview Questions|
|Middleware Interview Questions||Radar Test Engineer Interview Questions|
Web Service Testing Tutorial
Welcome To Web Testing
Web Testing Versus Traditional Testing
Software Testing Basics
Web Application Components
Test Planning Fundamentals
Sample Test Plan
User Interface Tests
Configuration And Compatibility Tests
Web Security Concerns
Performance, Load, And Stress Tests
Web Testing Tools
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.