QA2 Flashcards
What is a Test Case?
Set of conditions and/or variables under which a tester will determine if a requirement upon an application is satisfied
What does Test Case include?
When planning for testing the test case:
-Test case ID
-The purpose (Title, Description) of the test case
-An instruction on how to get from the application base state to a verifiable application output or expected result
-Expected result
When execute test cases we need two more columns:
-Actual result
-PASS/FAIL indication
What is a test plan?
-Document that describes the objectives, scope, approach, and focus of a software testing effort.
-The highest level Software testing document possible
-Doesn’t include test cases
-Developed by QA team with other team possibly contributing (everybody is involved at some level)
What does Test Plan include?
- Objective of testing effort
- Software product overview
- Project risk analysis
- Testing priorities and focus
- Scope and limitations of testing
- Test tools to be used, including versions, patches, etc.
- Personnel allocation
Write test cases for a text field?
-5 test cases for capacity including 2 for each boundary and one for the class between boundaries
-3 test cases for valid/invalid input of letters, digits, special characters
-One test cases for each allowed special character (email field as an example)
-Functionality testing if there is any functionality (validation of input as an example, case sensitivity, required field, etc.)
What is Test matrix?
Data collection mechanism. It provides a structure for testing the effect of combining two or more variables, circumstances, types of hardware, or events. Row and column headings identify the test conditions. Cells keep the results of test execution.
If there are so many settings/options to choose, how to write test cases?
-Test cases should be developed for all most common potential scenarios
-They should cover most of the positive input
Beside test case & test plan, what documents are required to write?
-Check Lists
-Test matrices
-Test design specs
-End-to-end tests
-Test summary reports
-Bug reports
Describe risk analysis
Risk analysis means the actions taken to avoid things going wrong on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a ‘buck stops here’ person who can consider the relevant trade offs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities.
Testing boundary conditions? Why? How?
-Boundary value analysis is a methodology for designing test cases that concentrates software testing effort on cases near the limits of valid ranges.
-Boundary value analysis is a method which refines equivalence partitioning. It generates test cases that highlight errors better than equivalence partitioning. The trick is to concentrate software testing efforts at the extreme ends of the equivalence classes. At those points when input values change from valid to invalid errors are most likely to occur. As well, boundary value analysis broadens the portions of the business requirement document used to generate tests
What is the difference between a test case and a test plan?
-Test plan is the most comprehensive Software Testing document that describes the objectives, scope, approach, and focus of a software testing effort
-Test case is the smallest Software Testing document that describes both typical and atypical situation that may occur in the use of an application
Which documents would you refer to when creating Test Cases?
All business and technical documentation available:
-PRD – Product Requirements Document
-BRD – Business Requirements Document
-Functional Specifications
-Manuals and Help
-Use Cases
-Test Design
-Third party publications (books, published by independent authors)
What is Business Requirements Document (BRD)?
BRD is written by the Business Analysts. It details the business solution for a project including the documentation of customer needs and expectations.
-The most common objectives of the BRD are:
-To gain agreement with stakeholders
-To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
-To provide input into the next phase for this project
-To describe what not how the customer/business needs will be met by the solution