ISTQB – Foundation – Tutorial – 1.4 Test Process

Fundamentals test process – STLC (Software Testing Life Cycle)

Test Process in context – factors influencing testing

  1. SDLC model – and project methodologies influence the entire process of testing
  2. Test levels and types considered – based on the functional and non functional
  3. Project and product risks based on BA/PO knowledge on similar projects worked or home work made on analysis of the domain.
  4. Business Domain
  5. Operational constraints
    1. Budgets
    2. Resources
    3. Timeline
    4. Complexity of the code
    5. contractual and regulatory requirements
    6. Organizational practices and practices- no remote work,
  6. Internal and external standards – each company involved on the product built may have to be considered.

Test Process

  1. Test Planning
  2. Test monitoring and Control
  3. Test Analysis
  4. Test Design
  5. Test Implementation
  6. Test Execution
  7. Test Completion
  1. Test Planning – Considers all major plan/layout steps of testing to be done
    1. Overall objective on coverage, defects, severity, risks are decided in this phase.
    2. Scheduling of the testing activities overall on all levels of testing.
    3. Assigning resources based on when the testing will start, who will be doing it – experience versus new comparison and analyze and provide accordingly- share responsibilities
    4. Documentation template- traditional heavy – agile- documentation is simple and light with
    5. Matrices for monitor and controlling
    6. Defining entry and exit criteria
    7. Deciding about automation
  2. Test Monitoring and control
    1. Test Monitoring is for the measuring the progress in the project,
      Create matrices to measure the progress of the testing activities. Ex: Coverage Matrix, Traceability Matrix, Execution summary
      Execution rate = total test cases executed/total created*100 = ex: 45%
    2. Test Control – defect closure
      When the plan is made, the control action is also defined so we are prepare whwn te things don’t go right, Steps to take to control the issues and meet the objectives of the test plan.
  3. Test Analysis
    1. Analyzing on test Basis – which is used for documentation used for reference for testing, ex: requirements, – sometimes we find defects in the documents like a spec-walk thru form the BSA, where u can see some omissions, inaccuracy etc.
    2. Identify the features to test by going thru the doc – to see what is testable and non-testable.
    3. Define test conditions while finding scenarios
    4. functional and non-functional to be analyzed and filtered separately.
  4. Test Design – Phase designing and prioritizing the test cases
    1. you have analyzed know what’s the requirement, and what test cases/scenarios can be written
    2. Test data creation to support the test cases crated
    3. Design the environment- parallelly create the template for the test bases and the test cases, to make sure the requirements are converted to test cases – can be validated either way- as it is suggested as bidirectional matrix (Requirement Traceability matrix)
  5. Test Implementation – this is the step to get prepared for Execution
    1. the pre-requisites to be done before test execution- test procedures are the set of actions to do before test execution.
    2. test suite- Collecting all test cases together and say these are the cases to be executed in the phase
    3. test scripts to automate will be prepared in this implementation phase.
    4. Execution schedule- defines the technical, logical, flow and hierarchy for the requirement
    5. Building the QA/Stage/prod environment- confirm the environment is ready and we are good to go with the execution
    6. Test data- required are confirmed and completed here
    7. Bi-directional matrix is reviewed here so all requirements are covered
  6. Test Execution – it mainly what testing is all about
    1. Start executing all test cases one by one – each will start with the order of – pre-requisite- and test steps with the test data defined
    2. results are provided as pass/fail – based on the comparison of the expected vs Actual.
    3. if the test case fails- a defect is created and sent to fix
    4. once its fixed confirmation testing is done
    5. once CT is done regression testing is done
  7. Test Completion – in traditional we call test closure- in agile we call it as retrospective
    1. In between TE and Test completion – once all te is complete like functional, non functional, upgrade, migration, test data to be added etc.. the exit criteria is evaluated
    2. Exit criteria is met is to confirm, once all the test cases are executed- like objective of the testing is met. once its met we call of testing phase and move to test completion phase- which is a post the test execution phase.
    3. Log reports for the activities done during the earlier phases
      1. defects closed
      2. deferred defects
      3. change request proposed
      4. any new updates
      5. test Summary report which generally contains the overview of all major activities
      6. Finalizing the test cases for regression for future release. this deals with lot of updates and upgrades on the existing release.
      7. Lessons learnt form the completed activities – from all contributor and tester- to improve the process- contributes to maturity- minimize defects- add value to process- more quantitative and qualitative approach.

ISTQB – Foundation – Tutorial -1.1 – What is testing?

Fundamentals of Testing – The most basic but important part of the foundation level examination. the below points marks the 5 fundamentals.

1.1 What is Testing (K2)?

1.2 Why is testing necessary?

1.3 Seven testing Principles

1.4 Test Process

1.5 The Psychology of testing

1.1 What is Testing? (K2) –

Testing has a wide range of understanding and definitions, the common one is the tester executes the steps of an application flow and check the actual behavior of the application is working as expected as per the requirement, finding bugs, there are few other things to consider as well, as provided below:

STLC starts with static testing, the document gathering like any work product (Requirement, Specifications, User story) created in the STLC. testing done form the requirement phase, the review helps in preventing the defects even before the development is started Many other activities other than test execution in STLC.

Objectives of testing:

Find defects – By writing and executing the test cases on the application under test and find maximum defects as possible.

Gain the confidence on quality – By executing the positive scenarios QA team will have the confidence, until we have confidence, we cannot give go ahead on the release.

Note: Ask for extra time if any critical info is not covered, to avoid product failure in the market that may incur losses like business or human lives etc..

Providing information – Provide status on the progress, typical defects and fix status and artifacts that covered all critical areas so the decision/ go-ahead can be taken by the Management, stake holders for release.

Preventing defects – more information in terms of review of the work products, getting involved on early stage, testers can find more defects on early stage can help in minimizing the defects during the future phases of app releases.

Review of Work products – reviewing the docs like Requirements and specifications even when they are in draft status, can be called as static testing as well.

Verify all the requirements are met and none is missed – its the base and important part , by using all the test techniques so dev team has delivered on all requirements.

Reduced risk level – critical parts covered by the test cases so the risk is reduced and measures if a risk is suddenly pops up!

Comply with legal or regulatory requirements and standards – in Business Requirement these info has to be mentioned – ex: other than functional there may be may other requirements to be taken care of, there are few non functional requirements as well. A tester should be using a diff approach while validating a Banking application or a ecommerce or a security based application.

Classification of Testing

Static – Documents created as a part of STLC, and do not involve any execution ( flow charts, algorithms, Business Requirements, Specifications) once the static testing is done, documentation for the levels of testing can be initiated. this process is called Review

  1. Formal Review
  2. Walkthrough
  3. Technical Review
  4. Inspection

Dynamic – test execution of application under test – can be called as Levels of testing

  1. Unit
  2. System
  3. Integration
  4. UAT etc..

Debugging and testing

Testing – Done by the tester, to identify the defect.

Debugging – Done by the developer, to analyze the defect, finds the root cause and remove the root cause(FIX)