END TO END Manual QA TRAINING

MANUAL TESTING is a type of Software Testing where Testers manually execute test cases without using any automation tools. This material helps to become a  Professional Manual tester.

 SDLC Team

Project Manager (PM)

Business Analyst (BA)

Developer (DEV)

Quality Analyst (QA)

PROJECT MANAGER (PM)

•             The project manager is accountable for ensuring that everyone on the team knows and executes his or her role, feels empowered and supported in the role, knows the roles of the other team members and acts upon the belief that those roles will be performed Responsibilities:

•             Developing the project plan

•             Managing the project stakeholders

•             Managing Communication

•             Managing the project team

•             Managing the project risk

•             Managing the project schedule

•             Managing the project budget

•             Managing the project conflicts

•             Managing the project delivery

BUSINESS ANALYST (BA)

•      A Business Analyst is someone who analyzes an organization (real or hypothetical) and designs its processes and systems, assessing the business model and its integration with technology.

Responsibilities:

•     A bridge between the business problems and the technology solutions.

•     Requirements analysis.

•     Requirements management and communication.

•     Translating and simplifying requirements.

•     Creates Business Requirement Document (BRD) - what must be delivered to provide value.

•     Create Functional Requirement Document (FRD) - defines a function of a system or its component.

•     Creates use cases after gathering and validating a set of functional requirements.

•     Creates flow chart of the processes.

DEVELOPER (DEV)

•         Developer is a person who writes computer software.

Responsibilities:

•             Gather customer software requirements and develop related software applications and programs.

•             Develop and write high quality coding that meets customer requirements.

•             Create software documentation and update existing documentation.

QUALITY ANALYST (QA)

•             A software quality analyst is responsible for applying the principles and practices of software quality assurance throughout the software development life cycle.

•             A quality analyst helps ensure that an organization’s products or services meet its quality standards.

•             The quality analyst (QA) is in charge of ensuring that the application is built according to the plan.

•             The analyst is in charge of testing the applications to ensure that the application will work according to the expectation of users and businesses.

•             The errors in the application should be found by the analyst so that software developers could work on the errors until the application works without any difficulty.

•             Aside from testing if the application is actually working, the quality analyst should also ensure that stages in developing the application are followed.

•             Testing is used  to detect errors in a product.

SDLC TEAM

QUALITY ANALYST (QA)  - Roles and Responsibilities :

•             Analyzing client requirements

•             Understand the software application being tested

•             Prepare test plan and test strategy

•             Preparing test scenarios / test cases

•             Preparing test data (used for test cases)

•             Executing the test cases

•             Defect tracking

•             Perform necessary retesting

Providing defect information (for developers) Preparing report summaries

Conducting review meetings within the team

SDLC PROCESS 

SDLC PROCESS

SDLC Overview

•             SDLC, Software Development Life Cycle is a process used by software industry to design, develop and test high quality software. The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

A typical Software Development life cycle consists of the following stages:

•             Stage 1: Planning and Requirement Analysis

•             Stage 2: Defining Requirements

•             Stage 3: Designing the product architecture

•             Stage 4: Building or Developing the Product

•             Stage 5: Testing the Product

•             Stage 6: Deployment in the Market and Maintenance

Stage 1: Planning and Requirement Analysis

•             Requirement analysis is the most important and fundamental stage in SDLC.

•             It is performed by the senior members of the team with inputs from the customer.

•             This information is then used to plan the basic project approach .

•             Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage.

•             Plan technical approaches that can be followed to implement the project successfully with minimum risks.   

Stage 2: Defining Requirements

•             Once the requirement analysis is done the next step is to clearly define and document the product requirements

•             Get them approved from the customer /business.

•             This is done through ‘BRD’ – Business Requirement Document which consists of all the product requirements to be designed and  developed during the project life cycle.

Stage 3: Designing the product architecture

•             BRD is the reference for product architects to come out with the best architecture for the product to be developed.

•             Based on the requirements specified in BRD usually more than one design approach for the product  architecture is proposed and documented in a DDS  - Design Document Specification.

•             This DDS is reviewed by all the important stakeholders and based on various parameters as risk  assessment, product robustness, design modularity , budget and time constraints , the best  design approach is selected for the product.

Stage 4: Building or Developing the Product

•             In this stage of SDLC the actual development starts and the product is built.

•             The programming code is generated as per DDS during this stage.

•             If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

•             Developers have to follow the coding guidelines defined by their organization and

•             programming tools like compilers, interpreters, debuggers etc. are used to generate the code.

•             Different high level programming languages such as C, C++,Java, dot Net etc.  are used for coding.

•             The programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

•             This stage refers to the testing only stage of the product where products defects are reported,  tracked, fixed and retested, until the product reaches the quality standards defined in the BRD.

Stage 6: Deployment in the Market and Maintenance

•             Once the product is tested and ready  to be deployed it is released formally in the appropriate market.

•             After the product is released in the market,  its maintenance is done for the existing customer base.

SDLC METHODOLOGY

Waterfall Method

•          Waterfall model is the  earliest SDLC approach that was used for software development .

•          Any phase in  the development process begins only if the previous phase is complete.

•          In waterfall model phases do not overlap.

•          All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases

SDLC METHODOLOGY 

The sequential phases in Waterfall model are:

•            Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.

•            System Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.

•            Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.

•            Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

•            Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.

•            Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

Waterfall Method   - Pros and Cons

SDLC METHODOLOGY AGILE  PROCESS

AGILE TERMINOLOGY

Above: AGILE TERMINOLOGY

SDLC METHODOLOGY

What is  AGILE

•            Agile Methods break the  product  into small increment al builds.

•            These builds are  provided  in iterations.

•            Each iteration typically lasts from about one to three weeks.

•            Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing and acceptance testing.

•            At the end of the iteration a working product is displayed to the customer.

What is Agile Testing ?

•            Unlike the Waterfall method , Agile Testing can begin at the start of the project with continuous integration between development and testing.

•            Agile Testing is not sequential (in the sense its executed only after coding phase) but continuous.

•            Agile Testing has shorter time frames called iterations (say from One to Four weeks ).

•            Agile team works as single team towards a common objective of achieving Quality .

SDLC METHODOLOGY 

AGILE / SCRUM

Scrum is an agile project management methodology or framework used primarily for software development projects.

The Scrum methodology follows the values and principles of agile.

SDLC METHODOLOY

The Roles of the Scrum Team o Product Owner o Scrum Master o Scrum Team

The Scrum Events o Sprint o Sprint Planning o Daily Scrum o Sprint Review o Sprint Retrospective 

Scrum Artifacts o Product Backlog o Sprint Backlog

So how does Scrum Work on a Day-by-Day Basis?

•            Each day, a Daily Scrum Meeting is held to determine how the features are progressing.

•            The meeting is no longer than 15 minutes, and each team member is asked 3 questions: o What have you accomplished since the last Daily Scrum Meeting? o What will you do before the next Daily Scrum Meeting? o Is there anything that is impeding your progress (and remedies are discussed)?

User Story

•            Short description of functionality that will provide value to a user

•            Contains:

•            Title

•            Description

•            Acceptance Criteria

•            Placeholder for a conversation to occur

User Story Example

Title: Enter Personal Identification Number (PIN) Description:

As an ATM user, I want to enter my PIN

So that I can withdraw cash Acceptance Criteria:

PIN must be four digits long

PIN must not allow alpha or special characters

PIN must be entered within 30 seconds or the transaction will be canceled Sample User Story

12  Principles of Agile

§ 1 . Continuous delivery of value

§ 2 . Embrace changing requirements

§ 3 . Frequent deployment

§ 4 . Customer collaboration

§ 5 . Motivated individuals

§ 6. Face-to-face conversation

§ 7 . Working software as measure of progress

§ 8 . Sustainable development

§ 9 . Technical excellence

§ 10 . Simplicity

§ 11. Self-organization

§ 12 . Continuous improvement

SDLC METHODOLOGY

INTRODUCTION TO SOFTWARE TESTING

•            Software testing is required to check the reliability of the software

•            Software testing ensures that the system is free from any bug that can cause any kind of failure

•            Software testing ensures that the product is in line with the requirement of the client

•            It is required to make sure that the final product is user friendly

•            At the end software is developed by a team of human developers all having different viewpoints and approach. Even the smartest person has the tendency to make an error. It is not possible to create software with zero defects without incorporating software testing in the development cycle.

•            No matter how well the software design looks on paper, once the development starts and you start testing the product you will definitely find lots of defects in the design.

SOFTWARE TESTING OVERVIEW

•            You cannot achieve software quality without software testing.

•            Even if testers are not involved in actual coding they should work closely with developers to improve the quality of the code.

•            For best results it is important that software testing and coding should go hand in hand.

•            Testing helps in evaluating the quality of software.

•            All testing activities require planning.

•            Testing ensures that the software behaves and looks exactly like what is mentioned in the requirements.

•            Anything that is not in line with the requirement is a defect.

•            Testing helps in reducing the overall cost of the software development project.

•            Well tested software is of good quality and good quality means better feedback and reviews.

TESTING

What is 'Software Quality Assurance'?

•            Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon processes, standards and procedures are followed, and ensuring that problems are found and dealt with.

What is 'Software Testing'?

•            Software testing is a process used to identify the correctness, completeness, and quality of developed computer software.

•            It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users.

•            In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free.

SOFTWARE TESTING LIFE CYCLE TEST PLAN

TEST  PLAN

•            The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents.

•            A document describing the scope, approach, resources and schedule of intended test activities.

•            The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.

TYPES OF TESTING

Ø Black - Box Testing  (Software Testing- QA Dept.)

•     Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the "inner workings" of the software. You CAN learn to do black box testing, with little or no outside help.

Ø White - Box Testing (Quality Analyst- QA Dept.)

•            In using this strategy, the tester examine the internal structure of the program

•            It is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.

Ø Unit testing (Dev Dept.)

•            Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers.

•            Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

TYPES OF TESTING

Ø Integration testing (Dev & QA Dept)

•            Upon completion of unit testing, integration testing begins.

•            Integration testing is black box testing.

•            The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements.

•            Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Ø Functional testing (QA Dept)

•            Functional testing is black-box type of testing geared to functional requirements of an application.

•            This type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)

TYPES OF TESTING

Ø Regression testing (QA Dept.)

•             The purpose of regression testing is to confirm that a recent program or code change has not adversely affected existing features.

•             Regression testing is nothing but full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine.

•             This testing is done to make sure that new code changes should not have side effects on the existing functionalities.

•             It ensures that old code still works once the new code changes are done.

Need of Regression Test

Regression Testing is required when there is a :

•             Change in requirements and code is modified according to the requirement

•             New feature is added to the software

•             Defect fixing

•             Performance issue fix

TYPES OF TESTING

Ø Difference between Re-testing and regression testing:

•          Retesting means testing the functionality or bug again to ensure the code is fixed. If it is not fixed, defect needs to be re-opened. If fixed, defect is closed.

•          Regression testing means testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software.

Ø Sanity testing or Smoke testing (Dev & QA)

•            Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort.

•            For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

TYPES OF TESTING

Ø system testing (end-to-end testing) (QA)

•            System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment.

•            The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed.

•            System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input. Upon completion of integration testing, system testing is started.

•            Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved.

TYPES OF TESTING

Ø End –to- End testing

•     It is similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if  appropriate.

Ø  Ad-hoc testing

Testing the application during crunch time and will be performed in different scenarios as follows:

Scenario 1: If a issue(s) is found right before the production release (Go Live)

Scenario 2 : If a issue(s) is found in production environment (by customers)

Ø  User Acceptance testing (QA & Customer/end users)

•     Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

TYPES OF TESTING

Performance testing (QA Dept.)

•    Term often used interchangeably with 'stress' and 'load' testing. Ideally

'performance' testing (and any other 'type' of testing) is to see the response time ( sec) of functionalities under certain load conditions.

1. Load testing (Time & Resource Usage)

•            Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

2. Stress testing (Resource Usage “CPU”)

•            Term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

BUGS / DEFECTS

DEFECT / BUG

What is Defect in software testing?

•            What is Defect in software testing?

•            A programmer while designing and building the software can make mistakes or error.

•            These mistakes or errors mean that there are flaws in the software. These are called DEFECTS.

•            A Software Defect is a condition in a software product which does not meet a software requirement

•            The defect is a variance between expected results and actual results

•            The number of defects (all major ones and minor ones) found in the application is directly proportional to the quality of the application

•            The process of fixing bugs is termed "debugging“

•            Reports detailing bugs in software are known as bug reports.

DEFECTS

Logging/Reporting A Defect

•            who creates defects?

v  QA

•            Who will fix the defect?

v  Developer

•            The objective of creating a bug is to enable the developer to visualize the problem.

•            An effective bug report communicates well with the development team and avoids confusion or miscommunication.

•            A good bug report should be clear and concise without any missing key points.

DEFECT LIFE CYCLE

Defect Life Cycle (Bug Life cycle) :

•            Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime.

•            DLC starts when a tester begins testing, finds any error and  logs the defect.

•            DLC ends when tester re-tests and closes the defect fixed by the developer.

Defect Tracking:

•            Defect tracking is the process of tracking the logged defects in a product from beginning to closure.

•            QA will identify the defect(s) during their testing period and report thru a defect management tool (TFS or any Test management tool).

•            QA will assign the defect to the corresponding Developer

•            Developer will fix the defect

•            QA will re-test the fixed defects

•            If the defect is fixed , the status will be set to “Closed”

•            If the defects is not working then the status will be set to “Reopened” and assigned back to the Developer

Steps Of Logging A Defect

•            Create or log the defect in the bug tracking tools (example: TFS, Quality Center)

•            Title should be short, clear and meaningful

•            Include clear and simple description that will help the developer to understand the bug.

•            Take a screen shot of a bug or defect and attach it to the defect

•            Include steps to reproduce the defect

•            Include Expected and Actual results.

•            Include test data

Defect logging in TFS

DEFECT LIFE CYCLE - STATUS

The bug has different states in the Life Cycle:

•            New: When a defect is logged and posted for the first time. It’s state is given as new.

•            Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.

•            Open: At this state the developer has started analyzing and working on the defect fix.

•            Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

•            Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.

•            Retest: / Regression: At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.

•            Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.

DEFECT LIFE CYCLE - STATUS

•            Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.

•            Duplicate:  If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.

•            Rejected:  If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.

•            Deferred:  The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

DEFECT

Defect Logging Process

DEFECT

Severity  V/S Priority

In Software Testing, deciding how important the defect is and how soon the defect should be fixed is as important as finding a defect!

Defect Priority:

Priority is something that is defined by business rules.

It defines how important the defect is and how early it should be fixed.

Defect Severity:

Severity is defined by the extent of damage done by the defect.

It defines how badly the defect affects the functionality of the software product.

DEFECTS

DEFECTS

Priority - Severity Matrix

•            High Priority and High Severity

•            High Priority and Low Severity

•            Low Priority and Low Severity

•            Low Priority and High Severity

DEFECT

High Priority and High Severity:

Login button is not click-able on the login page of a web application. This is a high priority defect because this is stopping users from using the site. So, this should be fixed at once.

At the same time, this defect is of high severity because none of the other functionalities can be carried out.

High Priority and Low Severity:

Company logo is half cut on the home page of its website.

This is high priority defect because displaying an incomplete company logo would put bad impression on business as this would defame the company or website.

So, this defect should be fixed as soon as possible.

As far as severity is concerned, this defect has got low severity because it is not impacting any functionality of the website.

DEFECT

Low Priority and Low Severity:

Spelling mistake in any of the words on some inner pages of the website that is rarely accessed is an example of low priority defect because it doesn’t matter much to the users as business is not impacted and can be fixed later. It is also having low severity because it is not impacting any functionality of the website.

Low Priority and High Severity:

A twisted scenario which rarely occurs but makes the application crash is an example of a low priority defect because user doesn’t come across this scenario normally and can be fixed later.

On the other hand, it is having high severity because it makes the whole application break and no functionalities can be performed.

DEFECT

Types of Defects

Ø Show-stopper / critical bugs:

•    The core dumps, products abnormally shuts down and no work around will be found out, like OS automatic freezing.

Ø Major Bugs:

• The work around is found, but the implementation can be done.

Ø Medium Bugs:

• These bugs include database errors, link errors, low response time Ø Low/minor Bugs:

• These bugs are typos, simple GUI errors.

TEST CASE

What is a test case in software testing?

•         In the simplest form, a test case is a set of conditions or variables under which a tester determines whether the software satisfies requirements and functions properly.

•         A test case is a single executable test which a tester carries out. It guides them through the steps of the test.

•         You can think of a test case as a set of step-by-step instructions to verify something behaves as it is required to behave.

•         A test case will either Pass or Fail.

A test case often contains:

Test Case ID:	The ID of the test case.
Title:	The summary / objective of the test case.
Test steps:	Step-by-step procedure to execute the test.
Test Data:	The test data, or links to the test data, that are to be used while conducting the test.
Expected result:	The expected result of the test
Actual result:	The actual result of the test; to be filled after executing the test.
Status:	Pass or Fail

Test Case Template 
Who Writes Test Cases?

•          Typically, someone from the QA team writes the test cases.

•          To prepare these Test Cases each organization uses their own standard template

What is the Value of a Test Case

•          Writing test cases is almost as important as the testing process itself.

•          The activity of writing test cases helps you think through the details and ensures you’re approaching the tests from as many angles as possible.

•          The value of having test cases long-term is that anyone can go in and retest using the test case.

•          Test cases are powerful artifacts for future teammates, as well as a good source of truth for how a system and particular feature work.

•          Negative test cases are also documented, which can often be overlooked.

When Are Test Cases Used?

•          Test cases are used after development finishes a feature or a set of features.

•          While development is being done, or immediately thereafter, the testing team can prepare test cases for the upcoming tests to be ran.

•          The goal is to have test cases ready by the time testing is able to begin.

•          When testing begins, the testing team follows the test cases or “scripts” they wrote in order to execute the tests and verify the software. The sequence or group of test cases is called a test suite.

Test Case Best Practices

•          When writing test cases, consider these things:

•          Keep the title short and self explanatory • Write in simple and easy to understand language

•          Be clear and concise.

•          Include the expected result

•          Use exact and consistent names (of forms, fields, etc.)

Test Execution

•         Test execution involves actually running the specified test cases on a application either manually or by using an automated test tool.

•         Execute the test cases

•         Compare actual results with expected result.

•         If the actual results match the expected result, Pass the test case.

•         If the actual results does not match expected result, Fail the test case and log a defect

Test Closure

•            Test closure activities are done when software is ready to be delivered.

•            You have done the planning necessary, executed tests and now want to green-light your product for release

Criteria for Test Case Closure:

•            100 % requirements coverage: all business and technical requirements have to be covered by testing.

•            Minimum % pass rate: targeting 90% of all test cases to be passed is best practice.

•            All critical defects to be fixed