Please enable JavaScript.

Coggle requires JavaScript to display documents.

APU (Testing (Test strategy, Test cost-effectiveness, Test-coverage and…

- - - - Complete
        
        Cover all classes of input data in all situations
      - Unambiguous
        
        Every requirement has only one interpretation, and all statements and terms can only be interpreted one way.
      - Verifiable
        
        Verify requirements by
        
        Running tests
        
        Run experiment
        
        Inspect the code and other artifacts
      - Consistent
        
        No subset of individual requirements has conflicts in characteristics or naming of real world objects, logical or temporal conflicts between actions.
      - Correct
        
        Forward referencing
        
        Using items that are yet to be defined in the problem world
        
        Opacity
        
        Dependency of what is being described is nonexistent; freight train with passengers
        
        Noise
        
        Using items that make no sense in the problem world; transport passengers to their residence, this is not a fucking taxi service
    - - Difficulty of system testing depends on
        
        Volume of the tests needed, like response time and storage capacity
        
        What type of event should be tested, like error handling or safety mechanisms
        
        The required state of the system before testing, like a rare failure state or a certain transaction history
      - Concerns related to implementation and testability
        
        Autonomy of the system under test
        
        Observability of the testing process
        
        Re-test efficiency
        
        Test restartability
    - - Traceability "steps"
        
        Sources of the requirement
        
        Requirement
        
        Work products that implement the requirement
      - Purposes of forward traceability
        
        Ensure that all the requirements are implemented
        
        Change the impact analysis
      - Purposes of backward traceability
        
        Avoid "gold plating"
        
        Change impact analysis
        
        Defect impact analysis
        
        Root cause analysis of defects
  - - - Classes for requirements
        
        Essential
        
        Conditional
        
        Optional
      - Categories of techniques
        
        Nominal scale techniques (playing games)
        
        Must have, should have, could have, won't have, decide which category each requirement should go in
        
        Mixed empirical results, easier and faster than other methods and probably good for medium to large number of requirements. Not informative and less accurate compared to the other methods.
        
        Ordinal scale techniques (comparing lists)
        
        Binary Priority List by using bubble sort by, weighted by prioritization
        
        Disadvantages are that you need to to pair-wise comparisons, you know which requirements are more important but not to what extent, not very scalable (suitable for <100 requirements). Still more reliable than ad-hoc and nominal methods.
        
        Ratio scale techniques (voting), lets you know the importance and to what extent
        
        Cumulative voting (CV)
        
        Each stakeholder gets a number of imaginary units (100 dollars) and distributes them. Easy and fast to use but not scalable.
        
        Hierarchical cumulative voting (HCV)
        
        Addresses the scaling problem of CV by classifying the requirements into different levels of hierarchies and then do CV on each level.
        
        Analytic hierarchy process (AHP)
        
        You compare the requirements pairwise in a matrix and calculate the eigenvector of the matrix. The eigenvector summarizes to 1 and is the ranking of the requirements.
        
        Hierarchy AHP
        
        Doing AHP in hierarchies, just like with HCV to address the scalability problem
        
        Is faster than AHP but has loose reliability and fault tolerance
        
        Minimal spanning tree
        
        Redundant comparisons from AHP are not being done, this reduces the number of comparisons from n * (n-1)/2 to n-1
        
        Empirical studies are not available and Bills subjective opinion is that fault tolerance and reliability may be poor. It can be used for a large number of requirements, though.
    - - Requirement management is involved with
        
        Requirement engineering
        
        Project management
        
        Quality and test management
        
        Risk management
        
        Version and change management
      - Different users of requirement management tools have different needs
        
        Project manager, requirement administrator
        
        Database
        
        Developer and tester (DIDACTIC -B)
        
        Import
        
        Information model
        
        Each object in the database has an unique identifier
        
        Allow user to free define requirements management information models (RMIs)
        
        The RMI must be changeable during the project
        
        Traceability
        
        Baselining
        
        Change management and comments
        
        Change requests should have status, like pending, accepted and rejected
        
        Comments and review requirements
        
        Should have review, comments or discussion functions
        
        Documentation of the history
        
        All changes are tracked
        
        Version control
        
        History report
        
        Document generation
        
        Official and internal documentation
        
        Analysis function
        
        Official and internal documentation
        
        Project manager
        
        Users, roles and rights
        
        Size restriction
        
        Extensibility
- - - - Requirement specification
      - Design
      - Pseudo code
      - User manual
    - - Uninitialized variables
      - Incorrectly formulated branch conditions
      - Missing branches, including both conditionals and their embedded statements
    - - Code and change understanding
      - Knowledge transfer
      - Increased team awareness
      - Creation of alternative solutions to problems
    - - Walkthroughs w/ pros and cons
      - Informal inspection w/pros and cons
      - Formal inspection w/ pros and cons
    - - Individual expertise and training of the inspectors
      - Amount of material to process
      - Team size
      - Process and tool support
    - - Unstructured
        
        Ad-hoc reading
      - Semi-structured
        
        Checklist-based reading
        
        Property-based checklists
        
        Code standards and guidelines
        
        Standards and process compliance
        
        Artifact-based checklists
        
        Requirement specification
        
        Design documents
        
        Code files
        
        Test cases
        
        Usually developed based on analysis of past defects
        
        Active guidance
        
        Best practices when using checklists
      - Structured
        
        Defect-based reading
        
        Perspective-based reading