Test your basic knowledge |

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. Response of the application to an input






2. ID SW products - components - risks - objectives; Estimate effort; Consider approach; Ensure adherence to organization policies; Determine team structure; Set up test environment; Schedule testing tasks & activities






3. Find defects in code while the software application being tested is running.






4. Based on analysis of functional specifications of a system.






5. Separation of testing responsibilities which encourages the accomplishment of objective testing






6. A metric used to calculate the number of ALL condition or sub-expression outcomes in code that are executed by a test suite.






7. The process of finding analyzing and removing causes of failure in a software product.






8. Review documents (reqs architecture design etc.) ID conditions to be tested Design tests Assess testability of reqs ID infrastructure & tools






9. Extract data from existing databases to be used during execution of tests make data anonymous generate new records populated with random data sorting records constructing a large number of similar records from a template






10. Inputs - Expected Results - Actual Results - Anomalies - Date & Time - Procedure Step - Attempts to repeat - Testers - Observers






11. Ease with which software cna be modified to correct defects meet new requirements make future maintenance easier or adapt to a changed environment.






12. Measure & analyze results of testing; Monitor document share results of testing; Report information on testing; Initiate actions to improve processes; Make decisions about testing






13. A type of review that involves visual examination of documents to detect defects such as violations of development standards and non-conformance to higher-level documentation.






14. Black-box techniques used to derive test cases drawing on knowledge intuition and skill of individuals.






15. Testing software components that are separately testable. Also module program and unit testing.






16. Tools used to keep track of different versions variants and releases of software and test artifacts (such as design documents test plans and test cases).






17. A document that records the description of each event that occurs during the testing process and that requires further investigation






18. Behavior or response of a software application that you observe when you execute the action steps in the test case.






19. Testing an integrated system to validate it meets requirements






20. Human action that generates an incorrect result.






21. Scripting technique that uses data files to store test input expected results and keywords related to a software application being tested.






22. A test case design technique for a software component to ensure that the outcome of a decision point or branch in cod is tested.






23. Incremental rollout Adapt processes testware etc. to fit with use of tool Adequate training Define guidelines for use of tool (from pilot project) Implement continuous improvement mechanism Monitor use of tool Implement ways to learn lessons






24. A set of conditions that a system needs to meet in order to be accepted by end users






25. Check to make sure a system adheres to a defined set of standards conventions or regulations in laws and similar specifications.






26. Component - Integration - System - Acceptance






27. Special-purpose software used to simulate a component that calls the component under test






28. Simple & easy to follow Its rigidity makes it easy to follow It's typically well planned - Systematic - Freezing requirements before development begins ensures no rework later Each phase has specific deliverables






29. Black-box test design technique - test cases are designed from a decision table.






30. Linear Code Sequence and Jump.






31. All possible combinations of input values and preconditions are tested.






32. Actual inputs required to execute a test case






33. Deviation of a software system from its expected delivery services or results






34. Tools used to store and manage incidents return phone defects failures or anomalies.






35. Not related to the actual functionality e.g. reliability efficiency usability maintainability portability etc.






36. Planning & Control - Analysis and Design - Implementation and Execution - Evaluating Exit - Criteria and Reporting - Closure






37. Input or combination of inputs required to test software.






38. Sequence in which instructions are executed through a component or system






39. Process used to create a SW product from initial conception to public release






40. Scheduling Tests Manage test activities Provide interfaces to different tools provide traceability of tests Log test results Prepare progress reports






41. Develop & proiroitize test cases Create groups of test cases Set up test environment






42. A table showing combinations of inputs and their associated actions.






43. Based on the generic iterative-incremental model. Teams work by dividing project tasks into small increments involving only short-term planning to implement various iterations






44. The smallest software item that can be tested in isolation.






45. A unique identifier for each incident report generated during test execution.






46. Insertion of additional code in the existing program in order to count coverage items.






47. Informal testing technique in which test planning and execution run in parallel






48. Occurrences that happen before and after an unexpected event






49. Assessment of changes required to different layers of documentation and software to implement a given change to the original requirements.






50. Severity - Priority