Author: HQW

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.

Why Testing is important:

Success Contributions:

Use appropriate test techniques with appropriate level of expertise and test level and at specific point in SDLC
To work closely with BA/BSA so the testers do requirement reviews in Waterfall and User story refinement in Agile
To work closely with Developers to understand the functionality expected in their view and create effective test cases.
To work closely with to review the design understood and in progress from their point before the application is released in the QA Environment.

The above items will help the org to get the app tested before release and get the defects detected earlier in the SDLC which saves cost of fix if it’s found later the SDLC. Let say for Ex: if a fix on the requirement needs a BSA /BA to check and update may be 4 hrs effort, for developer to fix may take 0.25 days or 3-days as well.

Static and dynamic testing create diverse types of failures.

Quality Assurance vs Testing

Quality- find as many failures as possible then fix and product goes live with quality.
QA–Quality Assurance team which defines the process measures or the steps for the quality to be achieved.
QA- define.
QC–Quality Control team involving diff test activities- like TC prep, TC Execution – Defect logging/report to control defects and improve quality.
QC- Action.
Testers come in part of Quality control- who do the ground level action which is defined by QA.

Error – Defect – Failures
Errors – same as mistakes – Human action that produces an incorrect result.
Fault – known as defect or bug (informal name) – deviation between the expected and actual
Failure – generally when a test case fails while executing the test case- testers are responsible to identify failures.

Causes of Software defects:

1. All – Time Pressure – limited timeline or sparse number of resources for the launch date of the application.
2. All – Human – error prone in general and not machine.
3. All – Inappropriate person- inexperienced project participants
4. All – Miscommunications between the participants-> conveying the correct info and making sure the other person is understood!
5. All – Code complexity – more complex the flow may go wrong, need to be more cautious on these flows
6. All – Misunderstanding intra systems- internally when the modules are connected what is the requirements, ex: Module 1-> module2, module2->module3 inter system- other systems speaking to each other
7. All – unfamiliar technologies- built and having releases every day!

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)

Introduction:

About – International Software Testing Qualifying Board – certify individuals for testing understanding and learnings across the globe can take up the exams with respective boards.

Certifications – Many new versions are added earlier only 3 were there now we have 4 paths. Foundation level certification is the pre-requisite for the rest of other certifications to be taken.

Local Body – CSTB (Canada), ISQI, ISTQB.in etc.. based on the locale/country it can be found from their website.

Who can appear – Any who has the basic understanding of the testing, no pre-requisite is there for applying for the Foundations level exam.

Cost – around 200 USD

Valid – Life time (write once use it for life time)

EXAMINATION:

40 multiple choice questions with only one correct answer no conflicts are expected.

Total time for 40 questions are 60 minutes and 65% is the pass score which is around 26 out of 40 must be correct.

Schedule can be done on any day based on what type you are scheduling, first make the payment for example in ISQI make a payment and get a code, you will receive an email and by suing the steps in the mail search for the center where u choose to write and schedule and use the code to confirm the date and time and schedule the exam!

SYLLABUS:

Chapter-1 -Fundamentals of Testing

Chapter 2 – testing throughout the Software Development Life Cycle

Chapter 3 – Static Testing

Chapter 4 – Test techniques used

Chapter 5- Test Management (Entry/Exit criteria etc..)

Chapter 6 -Tool Support for testing

Google (Google Assistant) has a nlp activity in AI approach for the searches used, top tech companies, like
Amazon (Alexa)

NLP – Machine interaction via Voice/Text/Image/Video

Translation as a business is globally valued as 50 Billion $