The software industry is at it's a more comfortable room, and why would it not be? After all, everything is now connected with softwares. Computers are operating almost every area of human lives, whether it's education, research, health care, military-defense, or hospitality, so on. Powerful softwares are being created to make lives easier, but there can happen anomalies. These anomalies or say bugs can ruin the whole functioning of softwares; that's why software testing exists. This is quite a long quiz but very interesting and important.
The point during software development when testing should start.
The body of knowledge used for test analysis and design.
The source to determine the actual results from a set of tests.
The method used to systematically devise test conditions.
Gaining confidence.
Finding defects.
Preventing defects.
Providing information for decision making.
During the planning activities.
During the implementation and execution activities.
During the monitoring activities.
During all the activities.
A developer makes a mistake which causes a defect that may be seen as a failure during dynamic testing.
A developer makes an error which results in a failure that may be seen as a fault when the software is executed.
A developer has introduced a failure which results in a defect that may be seen as a mistake during dynamic testing.
A developer makes a mistake which causes a bug that may be seen as a defect when the software is executed.
A tester finds a defect and reports it.
A tester retests a fix from the developer and finds a regression.
A developer finds and fixes a defect.
A developer performs unit testing.
It is a form of stress testing.
It is not feasible except in the case of trivial software.
It is commonly done with test automation.
It is normally the responsibility of the developer during unit testing.
The root cause is the old equipment and the effect is the new equipment.
The root cause is the customer complaints and the effect is the social media postings.
The root cause is conducting the testing on the wrong version of the equipment and the effect is the customer complaints and postings.
The root cause is the software failing on the later model and the effect is the customer complaints.
Traceability between the test cases and the requirements.
Coverage of the risk items by test case.
Traceability between the requirements and the risk items.
Coverage of the requirements by the test cases that have been designed.
Unit and integration.
Integration and system.
System and acceptance.
All levels.
Testing involvement starts when the code is complete.
The test process is integrated with the development process.
The software is built in increments and each increment has activities for requirements, design, build and test.
All activities for development and test are completed sequentially.
Functional.
Non-functional.
Structural.
Change-related.
Unit Testing.
Integration testing.
System testing.
Acceptance testing.
Unit testing.
System testing.
Confirmation testing.
Regression testing.
Facilitator.
Author.
Scribe.
Manager.
Peer reviews.
Static analysis.
Dynamic testing.
Unit testing.
Planning.
Review initiation.
Individual review.
Fixing and reporting.
An informal development review.
A walk-through.
An inspection.
An audit.
The speed of response from the banking back-end.
The attractiveness of the application.
The size and clarity of the instruction text.
The reliability of the application when the connection is dropped.
Decision tables.
Decision testing.
Boundary value analysis.
State transition testing.
Black-box.
White-box.
Specification-based.
Behavior-based.
You can find defects that might be missed by more formal techniques.
You can test for defects that only experienced users would encounter.
You can target the developer’s efforts to the areas that users will be more likely to use.
It is supported by strong tools and can be automated.
Specification-based.
Structure-based.
Experience-based.
Reference-based.
By taking the number of decisions you have tested and dividing that by the total number of executable statements in the module.
By taking the number of decisions you have tested and dividing that by the total number of decisions in the module.
By taking the number of decisions you have tested and dividing that by the total lines of code in the module.
By taking the number of decision outcomes you have tested and dividing that by the total number of decision outcomes in the module.
Positive path and negative path.
Basic, exception and error.
Normal, error, data, and integration.
Control flow, data flow and decision paths.
6
8
10
12
Wait!
Here's an interesting quiz for you.