¡GoConqr estrena diseño! Cuéntanos qué te parece.

Regístrate gratis

Fichas

ISTQB

Menua King ISTQB Foundation Inglés 54 fichas

Fichas del conjunto (54)

  1. 1Test oracleA source to determine expected results to compare with the actual result of the software under test. An oracle may be
    a requirements specification, the existing system (for a benchmark), a user manual, or an individual's specialized knowledge, but
    should not be the code.
  2. 2Phases of a Formal Review1. Planning
    2. Kick-off
    3. Preparation
    4. Review meeting
    5. Rework
    6. Follow-up.
  3. 3Informal reviewA review not based on a formal (documented) procedure
  4. 4Formal reviewA review characterized by documented procedures and requirements, e.g. inspection
  5. 5Moderator (inspection leader)The leader and main person responsible for an inspection or other review process.
  6. 6Reviewer (inspector)The person involved in the review who identifies and describes defects in the product or project under
  7. 7Entry criteriaThe set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test
    phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort
    needed to remove the failed entry criteria.
  8. 8a scribeA separate person to do the logging in a formal review
  9. 9Exit criteriaThe set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially
    completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts
    of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing.
  10. 10Peer reviewA review of a software work product by colleagues of the producer of the product for the purpose of identifying
    defects and improvements. Examples are inspection, technical review and walkthrough
  11. 11WalkthroughA step-by-step presentation by the author of a document in order to gather information and to establish a common
    understanding of its content.
  12. 12Technical ReviewA technical review is a discussion meeting that focuses on achieving consensus about the technical content of a document.
  13. 13InspectionA type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development
    standards and non-conformance to higher-level documentation. The most formal review technique and therefore always based on
    a documented procedure.
  14. 14Static analysisAnalysis of software artifacts, e.g. requirements or code, carried out without execution of those software artifacts.
  15. 15Cyclomatic complexityThe number of independent paths through a program. Cyciomatic complexity is defined as: L-N + 2P,
    where
    L = the number of edges/links in a graph
    N = the number of nodes in a graph
    P = the number of disconnected parts of the graph (e.g. a called graph and a subroutine).
  16. 16Control flowA sequence of events (paths) in the execution through a component or system.
  17. 17Test conditionAn item or event of a component or system that could be verified by one or more test cases, e.g. a function,
    transaction, feature, quality attribute, or structural element.
  18. 18Test design techniqueA procedure used to derive and/or select test cases.
  19. 19TraceabilityThe ability to identify related items in documentation and software, such as requirements with associated tests.
  20. 20Test dataData that exists (for example, in a database) before a test is executed and that affects or is affected by the component
    or system under test.
  21. 21Test casea set of input values, execution preconditions, expected results and execution postconditions, developed for a particular
    objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
  22. 22Test design specificationA document specifying the test conditions (coverage items) for a test item, the detailed test approach
    and the associated high-level test cases.
  23. 23Test case specificationA document specifying a set of test cases (objective, inputs, test actions, expected results, and
    execution preconditions) for a test item.
  24. 24test procedureThe document that describes the steps to be taken in running a set of tests
  25. 25test execution schedulespecifies which procedures are to be run first
  26. 26SPECIFICATION-BASED OR BLACK-BOX TECHNIQUESa. equivalence partitioning;
    b. boundary value analysis;
    c. decision tables;
    d. state transition testing.
  27. 27Boundary value analysisA black-box test design technique in which test cases are designed based on boundary values
  28. 28Decision tableA table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions
    (effects), which can be used to design test cases
  29. 29State diagrama diagram that depicts the states that a component or system can assume and shows the events or circumstances
    that cause and/or result from a change from one state to another.
  30. 30Use case testingA black-box test design technique in which test cases are designed to execute user scenarios.
  31. 31Coverage (test coverage)The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
  32. 32InstrumentationThe insertion of additional code into the program in order to collect information about program behavior during
    execution, e.g. for measuring code coverage.
  33. 33Statement coverageThe percentage of executable statements that have been exercised by a test suite.
  34. 34Decision coverageThe percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage
    implies 100% statement coverage.
  35. 35Error guessingA test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.
  36. 36Exploratory testingA test design technique where the tester actively controls the design of the tests as those tests are performed
    and uses information gained while testing to design new and better tests.
  37. 37Test planA document describing the scope, approach, resources and schedule of intended test activities.
  38. 38Test strategyA high-level description of the test levels to be performed and the testing within those levels for an organization or
    program (one or more projects).
  39. 39Test approachThe implementation of the test strategy for a specific project.
  40. 40Test monitoringA test management task that deals with the activities related to periodically checking the status of a test project.
    Reports are prepared that compare the actuals to that which was planned
  41. 41Test managementThe planning, estimating, monitoring and control of test activities
  42. 42Failure rateThe ratio of the number of failures of a given category to a given unit of measure, e.g. failures per unit of time, failures
    per number of transactions, failures per number of computer runs.
  43. 43Defect densityThe number of defects identified in a component or system divided by the size of the component or system
    (expressed in standard measurement terms, e.g. lines of code, number of classes or function points).
  44. 44Test summary report (test report)A document summarizing testing activities and results. It also contains an evaluation of the
    corresponding test items against exit criteria.
  45. 45Test controlA test management task that deals with developing and applying a set of corrective actions to get a test project on
    track when monitoring shows a deviation from what was planned.
  46. 46Configuration managementA discipline applying technical and administrative direction and surveillance to identify and
    document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and
    report change processing and implementation status, and verify compliance with specified requirements.
  47. 47Configuration control (version control)An element of configuration management, consisting of the evaluation, co-ordination,
    approval or disapproval and implementation of changes to configuration items after formal establishment of their configuration
    identification.
  48. 48RiskA factor that could result in future negative consequences; usually expressed as impact and likelihood.
  49. 49Risk-based testingTesting oriented towards exploring and providing information about product risks.
  50. 50Project riskA risk related to management and control of the (test) project.
  51. 51Incident loggingRecording the details of any incident that occured, e.g. during testing.
  52. 52Incident reportA document reporting on any event that has occurred, e.g. during the testing, which requires investigation.
  53. 53PriorityThe level of (business) importance assigned to an item, e.g. defect
  54. 54SeverityThe degree of impact that a defect has on the development or operation of a component or system.

Información

Descripción
ISTQB Foundation Fichas sobre ISTQB, creado por Menua King el 23/02/2015.
Creado por
Menua King · feb 2015
Actualizado
26 jun 2016
Visitas
19
Valoración

Escríbenos

¿Sobre qué es tu mensaje?

¿Qué te parece el nuevo diseño?

¿Te gusta?