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.3 Seven testing Principles

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.

ISTQB – Foundation – Tutorial – 1.2 Why is testing important?

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!

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)

ISTQB – Foundation Level – Tutorial 1

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

Sample Job Postings

QA Automation Test Engineer with Cloud experience Azure /AWS

 Minimum of 7+ years of QA test experience required
· Automation experience of both UI functional tests using selenium webdriver and API tests is required
· API testing experience (developing API tests using Postman) is required.
· Python scripting experience required
· Ability to read and understand code is required
· Prior experience testing applications on cloud is preferred
· Experience with SQL and No-SQL technologies is required (e.g., Mongo DB, Dynamo DB)
· Prior experience in working with AWS is preferred
· Prior experience testing asynchronous applications and technologies is required (e.g., Rabbit MQ, Amazon SQS)
· Experience using AWS services (such as CloudWatch, SQS, EC2, S3)
· Prior experience in Agile-Scrum software development environment is required
· Robot Framework experience preferred
· Experience with Git and Bit Bucket required
· Integrating automated tests in CICD pipeline using Jenkins required
· Load and performance testing using tools like JMeter, LoadRunner required
· Experience with test case management tools –TestRail preferred
· Experience with Jira and Confluence preferred
· Experience working with scrum-agile teams preferred
· Should have worked on Insurance domain (preferably Travel Insurance)
· Expertise in frontend, backend or API and performance testing
· Experience with web services (REST), source control management (preferably Git), and continuous integration tools (preferably Jenkins)
· Good understanding of Software testing lifecycle and testing concepts.
· Should be ready to learn new skills as required and work in a short period
· Ability to work in a fast-paced environment with minimal supervision and attitude to adapt.
Technical Skills:
· Hands on using Postman for API testing. Python scripting,
· Hands on Performance Center, JMeter
· Defect Tracking using, JIRA, Test Rails.
· Ensures latest version of the executable is taken from the Version control tool.
· Working experience in Scrum Processes / Agile methodologies
Process / Innovation Skills:
· Should be able to follow industry best processes
· Should be able to bring in ideas to improve productivity and Quality of work
· A focus on high quality deliverables and meeting deadlines.
· Be someone who will bring innovation and ideas to the table
· A collaborative style and a focus on continuous improvement, quality and planning, teamwork, strong communication.
Behavioral Skills :
· Should be aggressive in making decisions and managing teams
· Should have very good communication.
· Effectively collaborates and communicates with the stakeholders and ensure client satisfaction
· Train and coach members of project groups to ensure effective knowledge management activity.
Qualification:
· Education qualification: Graduate BTech, BE, BCA, MCA, M. Tech or equivalent technical degree from a reputed college

Cypress javascript automation tool an introduction

Cypress is a test automation tool for web applications. With scripts written in JavaScript, there are many built in commands available.
Even though the tool can be used by using only JavaScript, one can use type script can be used.
Note: Cypress does not use selenium - it interacts with browser directly and is fast

Oen Source and free to use for most of the features - Dashboard (optional pricing)

There are 4 steps in Cypress one must know to start with

  1. Setup test - in IDE
  2. Write test
  3. Run test
  4. View the results (Debugging, if required)

As of now, 5 Browsers are supported Chrome, Firefox, edge, electron, brave

Cypress Features:

  1. Time Travel- snapshot is taken for every command - the screenshots can be seen from the command logs
    state of the application before and after the command are recorded.
  2. Automatic Waits- For assertions - automatic waits are added by cypress - if required one can add extra wait time for a specific step.

 

Pre-Requisite to install and use Cypress can be seen below:
OS: Windows 7 and >, Mac 10.9 and > (64 bit), Linux (ubuntu 12.4 and >, Fedora21, Debian 8(64 bit)

 

Before installing node, check whether node is already installed in the system, 
node -v or node --version to see the version of the node .js app
 

 

If not available, download the node.js from the official website, Download | Node.js (nodejs.org)

now in command prompt type node -v or npm -v for checking on the versions of node and npm(node package manager)

 

The node and npm is installed successfully in the machine.

https://www.cypress.io/blog/2022/03/28/real-world-testing-with-cypress/

https://www.youtube.com/watch?v=Gu9KdbpzSvk&list=PL6flErFppaj2TYXXee5Zt_rR_RpOTBfm1

 

AWS

Few of the services which are generally used on high level across most of the AWS involved projects, to learn the cloud computing please follow here at AWS site

AWS Cloud Practitioner, AWS Solution Architect are the common certifications to start learning on the cloud computing services in AWS.

S3 - Storage service to access data from anywhere.

SNS - simple notification service -messaging feature for A2A and A2P .

EC2 - Resizable compute facility with secure features.

to be updated...

Functional – Manual Testing (QA)

Manual testing is one of the core processes done for all the applications before it goes live.

Web, Api, database validations can be done manually for the existing ( not yet automated) and new apps( automation would be dome later once the app is stable with the new feature.

Web - Lets say if the applications are or E-commerce or Financial applications

the features for the anonymous users and registered users are to be differentiated correctly.

Ecommerce - order placement

Banking - Login and check the available balance, deposits, statements, loans, mortages etc basic necessary features.

Coverage and traceability to the requirements hold the key on what core features to be tested in lone with the time available