Category: Quality Assurance

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

 

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