Category: ISTQB

1. ISTQB foundation level exam –Certified Tester Foundation Level (CTFL) v4.0 [NEW!] (istqb.org)
2. Cost of the exam: around 5000INR (ISTQB.in), In Canada the cost is around 300$ (CSTB.ca)
3. Total chapters of ISTQB foundations exam; six
4. Latest version of the exam update: June 5, 2018
5. Does the certificate expire on a specific date: no, its lifetime
6. Various levels of certifications – Managing the Test Team (istqb.org)
7. ISTQB foundations syllabus –ISTQB Certified Tester – Foundation Level Syllabus v4.0 (istqb-main-web-prod.s3.amazonaws.com)
8. Are there any AI ISTQB certifications –AI Testing (istqb.org)

Reviewing to start on Work product drafts

Early testing is better for the project in dev and in cost savings.

Each dev level has one testing level

Component integration testing- structural, white box,

Impact analysis is used when deciding if a fix is worthwhile.

Functional testing can be performed at any level (4 levels- unit, integration, system integration and acceptance)

ISTQB foundation does not talk about the non-functional as it’s not in scope.

Confirmation testing (retest after the fix has been made) to make sure the issue is not reproduced!

Regression testing is no other parts are impacted by the fix provided in line with the previous statement above (confirmation testing)

impact analysis – fixing the maintenance system is worthwhile.

Find as many as defects possible after some changes or updates, upgrades, migration etc..

once te ptroject is released there are some timeline for theenext rls- so small updates are made in meanwhile- so maintenance tesitng is done during those mini- releases.

Lots of regression is made during these.

1. Planned Enhancements ex: 1.1, 1.2, 1.3 needs regression
2. COTS Software – Commercial of the shelf – third party software added as new feature integrated with the existing software
3. Migration- One platform to another-> windows to Linux
4. Retired- such as application reaches the end of its life ex: WinX- window sand linux embedded

In all the above cases regression is made!

IMPACT ANALYSIS

• Impact analysis is to check whether the change should be made or not, based ont he potential consequences in other areas of the system

Impact analysis is tough if

1. Specs ae missing
2. Test cases are out of date
3. Bi-directional traceability between tests are not updates
4. Tool support is weak (needs automation)
5. The people involved do not have domain or system knowledge
6. Insufficient attention has bee paid to the software’s maintainability during developers.

Classification of testing

1. Static Testing – non executable – work products test/Review- to find – omissions- missing info-loop holes are the flaws in the document – work product can be any doc in process to create the dynamic application- main purpose is to find defects in the very early stage so avoid defects in the dynamic testing stage.
   Informal- walkthrough- Technical Review- Inspection
2. Dynamic Testing – Executable -Applications under test- validate by running the application
   Functional levels of testing
   1. Unit testing – done mostly by the developers (manual-automation)
   2. Integration Testing
   3. System testing
   4. Acceptance Testing
3. Static testing- Reviews- Verification
4. Dynamic testing – diff levels of testing – Validation
5. Difference between Functional vs Non functional
   Functional – With out core features- application is not conceded as complete- user cannot work on the application – basically its what the system does- to meet the requirement
   Non-Functional – how the system works?
   Quality characteristics- enhance compatibility, portability, reliance, etc, any other than the 4 functional levels are non functional
   Ex: recovery, security, failover – to validate quality attribute.
   Unless client says we will have non functional- so functional testing is non-mandatory.

White BOX

Done by developer by executing the application
Also called as (See through- the code structure etc)
Structure Box,
Glass Box,
Open Box,
Clear Box
Transparent Box

Black BOX

Done by the tester with out knowlege of code and structure ont eh UI created for the customer use!

Also called as (could not see thru)
Skin Box,
Closed Box,
Opaque Box

Change related testing
Adding some maintenance testing with the regular process of the testing
In few companies- they rerun the test as after the fix that us called confirmation testing – to make sure the defect has been resolved- also known as re-testing.

Regression testing is followed after the Re-testing, to make sure the fix does not impact he existing ote modules which are working fine earlier, and not impacted but the new fix added
Regression- is the best candidate for Automation
Also conducted additional when we have environment changes-migration one plat form to other- or new functionality included like updates/upgrades.

Component testing

White box testing- unit test- done by the developer at the ocde level

Test Basis (what creates the component) and Test Objects (what we test)

Test Basis-
Component requirement
Code
Detailed Design

Test Objects –
Component
Programs
Data conversion/migration
Database Modules

Integration Tetsing

interaction between modules

Component Integration Testing – data shares/interacted of components with in module – Site selection- city selection- in address page.

System Integration Testing – a small unit of system- a small transaction in a big application SIT- Several SITs put together for System testing- in few cased SIT can be converted after System testing as well,
EX: Embedded Systems – S/w -H/w or Sw/SW etc..

3 Approaches

TDA – Top Down Appraoch

BUA- Bittom Up Approach

BBA – Big Bang Approach

Test Basis: References for deriving the test cases.
Software and Sytem design
Arctitecture And Workflows
Use Caes

Test Objects

What you are testing
Sub Systems
Dtaa implementatrion
Infrastructure
Iterfaxes
System Config and
Configuration Data

Sytem Testing(K2)

E2E testing of an applciation – to handle the e2e as everyhting works as per business/system requitrments of applciation. we hangle lots of roisk- as once the app is built we can cater teh critical things as part of hte execution.

Test Basis
System,/req specs
Fnc spec
Use case
Risk Analysis

Test Objects
System user operation manuls

System configuration
Config dat

ONce afte te syateme tetsig is done- non functional testing can be started

ACCEPTANCE TETSING

once all teh testinare done- it can be declared tha tclient can come anc collec the app

ISTQB- client comes to dev primises an conducts te acceptance testing int he applciation is called as acceptance testing

Typical

User Acceptance
Operational
Regulatory
Contractual
Business

Client genrally accepts the app- they specify what criteria is met and not met- so typical form of accptanc eis amade

Levels of Tetsing
Alpa Tetsing – tested by the client
Beta testing – to provide the peice ofd app to certain group and collect valuable feedback-must be conducted
(AB Testing)- cetain places- we cannot ask te endusers ex: fantasy park, amusemnt park, aerospace, safety critical- aerospace – so we ask professionals to behave like end users and collect feedback

Test Basis
User Software req spec
Business Process
Use cases
Risk analysis Repot

Test Objects
User Procedures
Business Process, operational ptrocess
Forms
Reports
Configuration data

21. Software Development models

2.2 Test Levels

2.3 Test Types

2.4 Maintenance Testing

2.1 Software Development models
V-Model –Sequential model with each development model having a corresponding testing model and each testing level has a testing objective.
Acceptance testing – while gathering – Business requirement – so loop holes can be found early
System Testing – System requirements- System tests Plan is created- Analysis and design of the test activity
Integration testing – ITP- Architectural design
Component testing – Detailed Design – of the application

Notes:
Should not wait for the testing phase – should not wait for the finalized docs- should start while the drafts – testing team is involved while Business is initiated.

Other methologies/Models

Sequential model – V- Model- once hte previous stage completrs- we move to the next stage

Incremental- Allow to design /analyze and build in features- in a small size and smoot way- no bigger things to be dealt- only small chunk of software

Iterative – On each single iteration- we have the previous set of requiremnt an d ne wset of requiremnt involved- so testng becomes complex and hectic- choas- special measures to be taken care of

Rational Unified Process

Scrum

Kanban

Spiral

Key Areas to be considered to use teh development models

1. SDLC should be selected in terms of project and product characteristics – functionality- Small set of requirements regularly or a frozen set of requirements- risk- have worked on similar applications before etc…
2. SDLC can be combined – Hybrid model – Open to include similar approaches as part of the process
3. IOT- There are devices, products, services- diff methodologies- programming languages- – so all the challenges to be considered before we select a model to start the SDLC.

Test Case – a set of input values – steps to follow for pre-conditions- and post conditions for a particular test condition.

Major objective of testing- to prevent the defects (focus mostly on tester activity and ignore if generally mentioned as it may reflect to all the team members)

Example of failure – UI feature not working as expected from the customer point of view. (Need to see what are debugging steps and what ui issues)

Which of the following is defect and not a root cause – UI issue noticeable by the customer.

Risk Analysis- focus on areas where defects are noticed earlier – defect clustering

Pesticide paradox- repeating same test cases again and again- improvise to new test cases.

test Design – identifying the data to support test cases

Test implementation – prioritizing hte test procedures and create test data

Test Execution – Analyzing discrepancies to determine their cause

Test completion – Entering CR for open defect reports

Traceability-> test basis and test artifacts-? new test cases has increased the coverage of the requirements.

Tester mindset- ability to see what might go wrong

When we talk abt psychology- a different mind set always to find mistakes- for dev its difficult to find mistakes in his own work, its same for any author or creator to find mistakes on his own product.

So we have a separate team with the mindset of finding issues or try to break the system see or bring failures and developer has mindset of creating the content

Generally – developer as a positive approach to the system and its difficult for them to accept the system has a defect, and the tester comes with negative approach to the application.

With few practices- realization of working together in long term , the tester may see all the things negatively and see the people in negative way as well, as if one starts pointing fingers on some one else- one may forget the common goal of the org towards the application

one must have the positive attitude towards people and negative approach to the application- there are few good practices in org in a mix team of dev and tester working together.

Overall +ve mindet and approach wit the colleagues in the team so any issue so the defect created will not create any rift or criticism, WE need to collaborate rehter than battles saying this must have been taken care!

Miscommunication must be avoided- all parties must confirm that the understanding of the issue and all are in same page!

Testers and Developers Mindset

Developers- constructive and complete the functions created on time.

Testers: destructive towards the application- find all possible defects so the end user does not face any challenge!

Advice to developer/tester/BA- reduce mistakes and make use of the static testing so the app is not created wrongly i first place- time, money is saved.

Add lot of value to quality of product.

In the right mindset dev can test their own code- and in general they do not come int heat mindset for ex: Dev may consider the app created as his baby and will not be int he mindset of finding the issue!

Key momnets- no personal rivalry – certain reports must be generic and no pointing fingers that defect is due to the dev work done in a wrong way kind off- instead it must be the issue was noticed ont eh application , need help in this from the developer to fix it!

Being positive with DESTRUCTIVE approach.

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.

7 testing principles

1. Testing Shows presence of defects
2. Exhaustive testing is impossible
3. Early Testing
4. Defect Clustering
5. Pesticide paradox
6. Testing context dependent
7. Absence of error fallacy

1. Testing Shows the presence of defects – but not the absence- as we cannot make a statement at any point of time, we can say there are no more defects – difference constraints come in place.
2. Exhaustive testing is impossible – All permutation combinations of test cases are not possible as it may lead to infinite combinations. we do not have enough time or resources to complete all on time /schedule.
3. Early testing – Bring testers while Work products are being started like Business requirements and specs- if the defects found on those – it considered cheaper on the life cycle model – starting with draft reviews – it helps the project to be more successful
4. Defect clustering– in line with the defect density – defects in general cannot be assumed to be equally distributes as 2 defects for 10 modules each- could be 9 modules- may be shown more caution and less defect and 10th module not taken care much so may have one hundred defects. so all modules to be seen equally! more test cases added to mark on the defect density
5. Pesticide paradox – running same test case repeatedly is waste of time- so improvise the test cases often and if required add new test case or widen coverage based on the current understand- requirements may have changed slightly, technology may have changed. The current test cases may be outdated, to find defects.
6. Testing context dependent – online shopping cart vs safety critical system or an insurance app all 3 have different approaches or coverages /density – by which effort is proportional accordingly.
7. Absence of error is a fallacy – in general many test cases are run few defects found and got fixed, it’s not useful if the product is not useful for the end user- Requirements should be met by the developer so the product us ready for the launch! Test only stable softwares.