Please enable JavaScript.

Coggle requires JavaScript to display documents.

ISTQB 4.0, Error (also known as an mistake)—a human action that causes an…

- - - - Include: (prioritized) test conditions (e.g., acceptance criteria, see, and defect reports regarding defects in the test basis (if not fixed directly)
  - - - Include: test progress reports , documentation of control directives and risk information
    - - A defect report logged during dynamic testing typically includes:
        
        Unique identifier
        
        Title with a short summary of the anomaly being reported
        
        Date when the anomaly was observed, issuing organization, and author, including their role
        
        Identification of the test object and test environment
        
        Context of the defect (e.g., test case being run, test activity being performed, SDLC phase, and other relevant information such as the test technique, checklist or test data being used)
        
        Expected results and actual results
        
        Description of the failure to enable reproduction and resolution including the steps that detected the anomaly, and any relevant test logs, database dumps, screenshots, or recordings
        
        Severity of the defect (degree of impact)
        
        Priority to fix
        
        Status of the defect (e.g., open, deferred, duplicate, waiting to be fixed, awaiting confirmation testing, re-opened, closed, rejected)
        
        References (e.g., to the test case)
  - - - Context of testing (e.g., scope, test objectives, constraints, test basis)
        
        Assumptions and constraints of the test project
        
        Stakeholders (e.g., roles, responsibilities, relevance to testing, hiring and training needs)
        
        Communication (e.g., forms and frequency of communication, documentation templates)
        
        Risk register (e.g., product risks, project risks)
        
        Test approach (e.g., test levels, test types, test techniques, test deliverables, entry criteria and exit criteria, independence of testing, metrics to be collected, test data requirements, test environment requirements, deviations from the organizational test policy and test strategy)
        
        Budget and schedule
        
        Entry criteria define the preconditions for undertaking a given activity. If entry criteria are not met, it is likely that the activity will prove to be more difficult, time-consuming, costly, and riskier. Exit criteria (AKA Definition of Done) define what must be achieved in order to declare an activity completed
        
        Risks
        
        Main risk management activities
        
        Risk control (consisting of risk mitigation and risk monitoring)
        
        Risk analysis (consisting of risk identification and risk assessment)
        
        Risk Attributes
        Risk likehood:the probability of the risk occurrence (greater than zero and less than one)
        Risk impact (harm) : the consequences of this occurrence
    - - Release planning
        Looks ahead to the release of a product, defines and re-defines the product backlog
      - Iteration Planning
        Looks ahead to the end of a single iteration and is concerned with the iteration backlog
  - - - Include: (prioritized) test cases, test charters, coverage items, test data requirements and test environment requirements
  - - - Include: test procedures, automated test scripts, test suites, test data, test execution schedule, and test environment elements. Examples of test
        environment elements include: stubs, drivers, simulators, and service virtualizations
  - - - Include: test logs, and defect reports
  - - - Include: test completion report, action items for improvement of subsequent projects or iterations, documented lessons learned, and change requests (e.g., as product backlog items)
- - - - Modifications, such as planned enhancements (i.e., release-based), corrective changes or hot
        fixes
      - Upgrades or migrations of the operational environment
      - Retirement, such as when an application reaches the end of its life
    - - The purpose of maintenance testing is both to verify that the change has been implemented successfully and to detect possible side effects (e.g., regressions) in the unchanged parts of the system (i.e., usually in most areas of the system)
- - - - Coverage
        
        Valid transitions coverage
        
        All states coverage
        (State son los cuadritos)
        
        All transitions coverage
        (Incluye todas las transiciones validas e invalidas)
- - - - Frequent stakeholder feedback throughout the SDLC can prevent misunderstandings about requirements
        and ensure that changes to requirements are understood and implemented earlier
    - - The activities in the review process are:
        
        Planning:
        
        work product to be reviewed
        
        scope of the review
        
        exit criteria
        
        the purpose of the review (why?)
        
        quality characteristics to be reviewed (what?)
        
        Amount of work needed and schedule (where? and when?)
        
        People whi are to participate in the review are selected and roles are assigned ( who?)
        
        Review initiation
        As part of the start of the review, the work product to be reviewed is sent out to the review participants (selected in the planning phase), along with all other necessary materials, e.g., checklists, statements of procedure, and defect report templates.
        If participants have any questions, answers and explanations are provided during the review initiation phase so that everyone is well aware of what they are supposed to do and knows the timeframe for these activities.
        
        Individual review (i.e., individual preparation)
        This is the essential, central phase of any review. In this phase, substantive activities are performed, that is, the actual review of the work product by the reviewers takes place, using specific review techniques.
        The reviewers record any comments, questions, recommendations, concerns, and relevant observations made during the review of the work product
        
        Communication and analysis
        The problems found are communicated to the meeting participants or to the author of the work product if there is no meeting for this purpose.
        The meeting includes an analysis of problems (anomalies ) reported by reviewers. Since not every anomaly necessarily turns out to be a defect, all findings must be carefully reviewed at the meeting to decide whether there is a real problem (defect) or merely an apparent problem (false positive). If the anomaly turns out to be a defect, those responsible for fixing them are appointed, and parameters such as status, priority, or severity are defined.
        
        Fixing and reporting
        For every defect, a defect report should be created so that corrective actions can be followed-up. Once the exit criteria are reached, the work product can be accepted. The review results are reported
    - - Manager: decides what is to be reviewed and provides resources, such as staff and time for the review
        Author: creates and fixes the work product under review
        Moderator (also known as the facilitator): ensures the effective running of review meetings, including mediation, time management, and a safe review environment in which everyone can speak freely.
        Scribe (also known as recorder): collates (recopila) anomalies from reviewers and records review information, such as decisions and new anomalies found during the review meeting
        Reviewer: Performs reviews. A reviewer may be someone working on the project, a subject matter expert, or any other stakeholder
        Review leader: Takes overall responsibility for the review such as deciding who will be involved, and organizing when and where the review will take place
        
        For some types of reviews, one person may perform several roles, and depending on
        the type of review, the activities associated with each role may also vary
    - - Informal review
        They do not follow a defined process and do not require a formal documented output. The main objective is detecting anomalies.
        Example: a conversation between two developers, when one of them asks the other for help in finding a defect causing a
        compilation error.
      - Walkthrough
        involves the sequential review of a work product. It is conducted by the author of the work product.
        Ejemplo: Imagina que como parte de tu preparación para una entrega de software, organizas una reunión con tu equipo para revisar el diseño del sistema. Durante esta reunión, presentas el diseño, explicando la lógica detrás de tus decisiones y discutiendo los posibles puntos débiles. Los asistentes hacen preguntas y proponen mejoras. Al final, se toma nota de las sugerencias y se decide si incorporarlas al diseño.
      - Technical review
        Performed by technically qualified reviewers, are to gain consensus and make decisions on a technical problem, but also to detect potential defects, assess quality and build confidence in the work product, generate new ideas.
        Ejemplo: Supongamos que estás trabajando en un proyecto que requiere una integración de sistemas. Antes de empezar la implementación, convocas a un equipo de expertos técnicos para revisar el plan de integración. Cada uno revisa los documentos antes de la reunión. Durante la reunión, discuten las posibles incompatibilidades, los riesgos de seguridad y la eficiencia de la arquitectura propuesta, proponiendo ajustes para asegurar que la integración sea exitosa.
      - Inspection
        The main goal is to achieve maximum efficiency in finding defects.
        The author must not take the role of review leader, moderator, or scribe.
        Inspections follow a well-defined process based on rules and checklists
- - - - Different people may take on these roles at different times. For example, the test management role can be performed by a team leader, by a test manager, by a development manager, etc. It is also possible for one person to take on the roles of testing and test management at the same time
- - - - Test Results
        Are used by both (QA & QC)
        In QC they are used to fix defects while in QA they provide feedback on how well the development and test processes are performing.
- - - - Debugging is concerned with finding causes of
        this failure (defects), analyzing these causes, and eliminating them
        The typical debugging process in this case involves:
        • Reproduction of a failure
        • Diagnosis (finding the root cause)
        • Fixing the cause
    - - Debugging i concerned with removing it, no need for reproduction or diagnosis