QA FUNDAMENTALS

QA FUNDAMENTALS

1. Quality

   • Degree of conformance to explicit and implicit requirements and expectations
     • Non-Functional (implicit): system inner characteristics and architecture: efficiency, security, etc,
     • Functional (explicit): practical use from the point of view of he user: features, performance, use
       • Unit
         • Individual methods
       • Interface
       • System
       • Regression
       • Integration
       • End to End
         • t verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc
       • Acceptance UAT
         • Satisfy business requirements
   • QA
     • Continuous and consistent improvement and maintenance of a process
   • QC
     • Making sure that product corresponds to the requirements and specs before it is realeased
   • Sofware Testing
     • Validation process that confirms that a system works as per business requirements
     • STLC
       • 1. Requierement analysis
       • 2. Test Planning
       • 3. Test case Development
       • 4. Environment setup
       • 5. Test execution
       • 6. Test Cycle closure
   • Fit for use and purpose
     • Validation
       • Means to confirm that developed product does not have any bugs and works as expected
         • Severity
           • Gravity/depth of a bug. App point of view
         • Priority
           • Which bug should get fixed firs. It defines users point of view
     • Verification
       • process that confirms that product development takes place as per the specifications and uses standard development procedures (Demos, review, inspections)
   • 7 PRINCIPLES
     • Testing shows presence of mistakes
     • Exhaustive testing is impossible
     • Early testing
     • Defect clustering (Pareto principle) - 80% of erros are usually found in 20% of modules
     • Pesticide paradox
     • Testing is context dependent
     • Absence of errores - fallacy

2. ASPECTS

   • Independent process
   • Invalid and unexpected inputs
   • Exhaustive and comprehensive documentation

3. WHEN TO STOP

   • Test case execution
   • Testing deadline
   • Code coverage ratio

4. TECHNIQUES

   • White box
     • Looks at code and structure of product. Unit testing phase or integration. Extensive knowledge of the technical stack
       • Data flow, branch testing, statement coverage, decision coverage
   • Black box: requires testers to assess the functionality of software as per business requierements
     • Regression
       • Assures that bug fixes do not break other parts of the app, verifies functionality of some or all modules, ensures re-execution of passed test cases
     • Smoke
       • new build delivered by the Development team is bug-free or not. CONFIDENCE
       • Verify important features work as expected and no showstopper issues that can block
       • Sanity
         • new functionalities, substet of regression
     • Functional
     • Retesting
       • Performed to verify defect fixes and involves execution of failed TCs
     • The inputs received by the system and the outputs or responses it produces are tested.
     • Equivalence partitioning, boundary and value analysis, decision table, and state transition

5. Test Plan

   • document describing the scope, approach, resources and schedule of intended test activities. It identifies, amongst others, test items, features to be tested, testing tasks, who will test the tasks, degree of tester independence, test environment, test design techniques, the entry criteria, and the exit criteria, risk factors. It is a record of the test planning process
   • Create when requirements are frozen - based on assumptions

6. Test Strategy

   • Document is a well-written document that outlines the precise methodology and goals of the testing project.

7. PYRAMID OF TESTING

   • Unit
   • Integration
   • UAT
     • E2E: Cover every possible flow

8. Test driver/ Stub

   • Driver: section of code that calls a software component under test
   • Stub: program that integrates with an application to complete

9. DoD: A checklist of criteria (unit testsm coding, AC, bugs, documentation) that must be met for a user story or product increment to be considered complete and ready for delivery.

10. DoR: A set of conditions (AC, dependencies, resources, actionable) that must be fulfilled for a user story to be considered actionable and ready to be worked on by the development team.

11. Test case: set of conditions, inputs, and expected outcomes used to verify that a software feature or functionality works as intended.

12. Error: A mistake or flaw in the code, logic, or design that causes incorrect behavior in a software program.

    • Bug: A defect or issue in the software due to an error that causes the program to behave unexpectedly or incorrectly.
      • Failure: The inability of the software to perform its intended function or meet its requirements due to an unhandled bug or defect during execution.