Testing faq page1

1.What's the difference between QA and testing?
QA stands for "Quality Assurance", deals with 'prevention' of defects in the product being developed.It is associated with process and process improvement activitiesTESTING means "quality control". Its focus is defect detection and removal. QUALITY CONTROL measures the quality of a productQUALITY ASSURANCE measures the quality of processes used to create a quality product.

2.What is black box/white box testing?
Black-box and white-box are test design methods. Black-box test design treats the system as a "black-box"(can't see what is inside the box), so you design test cases which pour the input at one end of the box and expect a certain specific output from other end of the box .To run these test cases you don't need to know how the input is transformed inside the box to output .Black-box also called as behavioral or functional or opaque-box or gray-box or closed-box. White-box test design treats the system as a transparent box which allows one to peek inside the "box", so you see how an input transforms into output.So you design test cases to test the internal logic, paths or branches of the box. white-box is also known as structural or glass-box or clear-box or translucent-box test design

3.What are unit, component and integration testing?
Unit:The smallest compilable component. A unit typically is the work of one programmer.As defined, it does not include any called sub-components or communicating components in general.
Unit Testing: In unit testing called components (or communicating components) are replaced with stubs, simulators, or trusted components. Calling components are replaced with drivers or trusted super-components. The unit is tested in isolation
component: A unit is a component. The integration of one or more components is a component.
Note: The reason for "one or more" as contrasted to "Two or more" is to allow for components that call themselves recursively.
component testing: the same as unit testing except that all stubs and simulators are replaced with the real thing.
Integration Testing: This test begins after two or more programs or application components have been successfully unit tested. It is conducted by the development team to validate the interaction or communication/flow of information between the individual components which will be integrated.

4.What's the difference between load and stress testing ?
Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.
Load testing is a test whose objective is to determine the maximum sustainable load the system can handle. Load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.

5.Why does software have bugs?
miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements).
software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Multi-tiered applications, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity.
programming errors - programmers, like anyone else, can make mistakes.
changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control
Time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read'). software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.

6.What is difference between verification and validation?
Verification is the process of determining whether the products of a given phase of the software development cycle fulfill the requirements established during theprevious phase. This involves reviewing, inspecting, checking, auditing, or otherwise establishing and documenting whether items, processes, services, or documents conform to specified requirements.Validation is the determination of the correctness of the final program or software produced from a development project with respect to the user needs and requirements.This involves actual testing of the product.