Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
97 Cards in this Set
- Front
- Back
|
Performing analysis to determine the risks involved Defining the objectives of the test project Documenting the test approach Tester provided by operational business units Exit criteria can also help ensure that the areas of particular risk are covered |
Test planning activites |
|
|
Test leader Tester |
2 roles necessary in any test team |
|
|
Manages the test related activities and the team as a whole Creating test policies Selecting testing tools Planning and managing the test |
Tasks of test leader |
|
|
Perform the actual testing Setting up the environment Reviewing and contributing to test plans Analyzing the test specification Required to review the tests and log results, evaluate results and docunent all defects |
Tasks of testers |
|
|
Analytical approach Model based approach Methodical approach Process or standard compliant approach Dynamic and heuristic test approaches Consultive approach Regression averse approach |
Test approach |
|
|
Analytic approach |
Is based on risk or requirement analysis |
|
|
Analytical approach |
Test are planned, designed, and estimated based on the result of the analysis |
|
|
Model based approach |
Test cases are created from a model that describes some functional aspects of the software product |
|
|
Model based testing |
Is also a good candidate for automation |
|
|
Methodical approach |
Involves using a planned systematic approach |
|
|
Process or standard compliant approach |
Involves adopting an industry standard or one of the agile methodologies for your testing approach |
|
|
Dynamic and heuristic test approaches |
Are exploratory in nature and involve reative testing rather than planned testing |
|
|
Dynamic and heuristic test approaches |
With this approach, execution and evaluation typically occur at the same time |
|
|
Consultative approach |
Involves taking direction from external experts |
|
|
Regression averse approach |
Includes the automation of regression tests to run all regression test cases using standard test suites or existing tests |
|
|
Dependent testing Independent testing |
2 testing styles |
|
|
Dependent testing |
Developers testing the software that they create themselves |
|
|
Independent testing |
Are not typically involved in the development of the software |
|
|
Independent testing |
They are more likely to take an objective approach and are more likely to be critical of the software |
|
|
Independent testing |
Are relatively better suited to locate more defects and report them |
|
|
Developers Testers from within development team Test specialists Outsourced testers |
Different levels of independence of testers based on their level of intimacy with the software |
|
|
Developers |
The lowest level of testing independence |
|
|
Developers |
This level of tester independence can let defects slide through the cracks |
|
|
Testers from within development team |
Involves testers as part of an integrated test team that work alongside the developers |
|
|
Test specialists |
These are usability, security and certification testers for example |
|
|
Test specialists |
This approach provides for an effective test environment |
|
|
Outsourced testers |
Represents the highest level of testing independence |
|
|
Outsourced testers |
A third party testing team is hired to test the software application |
|
|
Estimation |
Considers the risks identified during test planning and analysis to determine the amount of testing required and the testing approach that will be used |
|
|
Size and life cycle of the test project |
The cost associated with the test project is directly proportional to this |
|
|
Metric based approach Expert based approach |
2 approaches that can be used to estimate a test project |
|
|
Metric based approach |
Involves considering test data or metrics from former projects or similar projects that have been completed in the past |
|
|
Top-down estimate Bottom-up estimate |
2 estimation techniques when using metric based approach |
|
|
Top-down estimate |
Is derived at the project level and requires an intimate history of test project estination with similar projects |
|
|
Bottom-up estimation |
Is derived by considering individual tasks or activities and accounting for effort, resource requirements including hardware and software and then working your way up |
|
|
Bottom-up estimation |
Typically more time-consuming but can be more accurate due to the nature of this technique |
|
|
Expert based approach |
This approach takes advantage of an experts experience to estimate the testing project |
|
|
Expert based approach |
These experts may be from a technical, analytical, or business background |
|
|
Expert based approach |
Based on expert guidance, the test scope and the risks involved can then be identified |
|
|
Expert based approach |
Process can involve not only the test team but management as well, with the objective being to strike the right balance between quality, schedule, budget and features |
|
|
All defects |
Are needed to be addressed by the developers |
|
|
At any phase of the software development process |
When can defects occur |
|
|
Test incident report identifier Summary Incident decription Impact that the incident had |
Structure of incident report |
|
|
Test incident report identifier |
In which a unique id is assigned to an incident |
|
|
Summary |
Which provides a brief but descriptive summary of incident |
|
|
Incident description |
With the details of the incident |
|
|
inputs provided the expected results the actual results the number of attemps that the tester made tester's comments |
Details included in incident description |
|
|
Impact that the incident had |
Describe how the end user would have been affected by this incident, and you provide the severity of the incident so that the developers can easily prioritize the order of the repair |
|
|
Risk based testing |
Involves proactive analysis and testing to identifyband reduce product risk |
|
|
Early stages of the softwate project |
When does risk based testing begins |
|
|
Can take place at any point in the project |
When can risk based testing take place? |
|
|
Include performing and analysis to identify risks in the software Assigning a value to each risk Prioritize the risks from highest severity to lowest Testing can then begin starting with the most severed |
Steps involved in performing risk based testing |
|
|
Library managenent Change control board |
2 functions involved in configuration management |
|
|
Library management |
Is the process of managing and properly documenting any changes made to the product |
|
|
Library management |
Involves managing and applying the versioning of the software and its components as well as maintaining baseline versions of the softwate |
|
|
Change control board |
Is responsible for analyzing incidents reported during testing and deciding how they should be handled |
|
|
Change control board |
Is also responsible for conflict resolution and release management |
|
|
Testers Developers End users Stakeholders of the product |
Members of change control board |
|
|
Summary report identifier Summary section Variances section Comprehensive assessment section Summary of result section Evaluation section Summary of activities sectiom Approval section |
IEEE test summary report template |
|
|
Test summary report identifier |
Provides a section that allows you to assign a numeric identifier |
|
|
Summary section |
Allows you to sunmarize all testing activities from the test level in question |
|
|
Summary section |
Allows you to provide information about test design, test cases, test procedures, and test environments |
|
|
Variances section |
Typically contains variations that occured between the actual testing strategies, specifications, procedures, and guidelines in the test plan |
|
|
Test summary report identifier |
This is useful for configuration managers, so that they can identify and track the report |
|
|
Summary section |
Its in this section that you provide enough information to allow for the identification of defect details, version numbers, and decriptions of tested components |
|
|
Variances section |
With this type of detail, future testing activities can be improved and thats called process improvement |
|
|
Comprehensive assessment section |
Testers provide the process that was made towards completing their testing activities |
|
|
Comprehensive assessment section |
It also clarifies whether or not the testing activities followed the test plan guidelines, provides detail about any steps the testers took to make sute that the testing was successful and efficient |
|
|
Comprehensive assessment section |
with the informatiin contained, it can be determined wjether exit criteria was actually met |
|
|
Summary of result section |
Is simply a summary of the output and the results of the testing process |
|
|
Summary of result section |
This section summarizes all types of defects and the defect resolution process |
|
|
Evaluation section |
An evaluation of each tested component against the specified requirements and metrucs is made |
|
|
Evaluation section |
Its also here that the scenarios under which the tested component may fail isndocumented properly |
|
|
Summary of activities section |
Is a summaryvof the major testing activities and events that occured |
|
|
Summary of activities section |
This section also documents the total resources and the time and budget allocated to testing at this level |
|
|
Summary of activities section |
This is useful infornationbecause test managers can refer to this on future testing activities to estimate requirements |
|
|
Approval section |
Provides an area where peoppe responsible for approving the report are listed and provides them within areas that they can sign off, indicating that they understand and acceot the test results |
|
|
Ignore the risk Transfer the risk to a third party Mitigate risk Create a contingency plan |
4 ways to deal with project risks that apply to testing |
|
|
The test team might expect more form the tool There are complexity and functionality limitations Possibility of underestimating time, cost, and effort when first introducing the tool Risk of over reliance on the tool Underestimate effort require to maintain Version control Tool vendor issues |
Risks of tool support |
|
|
Testing tools |
Can improve the efficiency and effectiveness of testing specially where there are repetitive tasks involved |
|
|
Test execution tools |
Consideration is use automated test scripts to execise tests and they require significant effort to achieve good result |
|
|
Test executiom tools |
Consideration is that scripting language expertise is required by testers and test automation specialists when using the tools |
|
|
Static analysis tools |
Consideration is they can be used to enforce coding standards when applied to sourve code and they can generate a large number of warning messages when applied to existing code |
|
|
Test management tools |
Consideration include that it must be able to interface with other tools or spreadsheets in order to rpovide properly formatted information that can be used to. Meet the company's requirements |
|
|
Maturity of the internal test process The tool must be able to support establishef test processes |
Considerations relating to the interaction of test tools into an organization |
|
|
Is the planning of which test to use anf the entry and exit criteria |
Central to the test approach |
|
|
Revuewing and contributing to test plans Working alongside developers To make sure that a product meets the specified requirements |
Responsibilities of a test team |
|
|
Will typically experience many changes or iterations during its life cycle |
Characteristics of software product |
|
|
Product risk |
Are potential failures in the software that can make the customer unhappy with the product |
|
|
Product risk |
This type of risk is known as quality risk |
|
|
Pinpoint where testing should begin Determine the areas of the software that should receive additional testing |
What can Identifying product risks help |
|
|
Test strategy Test approach |
The success of a testing project can be dependent on what |
|
|
Test strategy |
Provides an overview of the way testing is to be performed or approached |
|
|
Testing objectives Test methods Test environment Time frame and resources |
Test strategy typically describes these |
|
|
Risk analysis |
Needs to be performed to identify risks in the software project and decide the best approach to use |
|
|
Risk management |
It helps identify, mitigate, and manage risks |
|
|
Risk management |
Helps in the process of monitoring the project |
