Software Manual testing Techniques

MANUAL TESTING means testing software manually to find the defects .The role of end user is played by the tester and use most of the features or functionality to ensure the correct behavior of the application

SDLC - SOFTWARE DEVELOPMENT LIFE CYCLE

Requirement analysis
Problem analysis
Software requirements
Requirements validation
Design
Coding
Deployment
Maintenance
Testing

SDLC Models

There are 7 SDLC Models

Built & Fix Model
Waterfall Model- Most of the people were use
Iterative Model
Prototyping Model
Spiral Model
RAD Model
V-Model

1.Built & Fix Model

This model is the worst model developing a project. In this the product or software is built without proper specifications and design steps .In essence, the product is built and modified as many times as possible until it satisfies the client or customer.
The cost of using this model is really high

2. Waterfall Model- Most of the people were use

Requirement
Design
Implementation
Testing
Maintenance

3. Iterative Model

In this model the project is divided into the release or increments and a end product is obtained.

In this until and unless we deliver the 1st release or increment we cannot start with the 2nd release or increment of product

4. Prototyping Model

The prototyping model is a system development method(SDM) in which a prototype (an early approximation of a final system or product) is built ,tested and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.

This model works best in scenarios where not the entire project requirements are known in detail ahead of time .It is an iterative, trial and error process that takes place b/w the developers and the users

Step-1 requirement gathering
Step -2 Quick designs
Step-3 Building prototype
Step-4 Customer Evolution
Step-5 Refining Prototype
Step-6 Engineer product (stop work

5. Spiral Model

Risk analysis is the main feature for Spiral Model. It is also known as spiral lifecycle model

Review
Risk Analysis
Testing
Unit Test
Integration test
Acceptance test
Validation and verification test
Requirement validation

6. RAD Model

RAD stands for Rapid Application Development Model

RAD is incremental software development process model that allows usable systems to be built in as little as 60-90 days, often with some compromises. The RAD model used for information systems development. The RAD model contains the following phases:

Business modeling
Data modeling
Process modeling
Application generation
Testing and turnover
Flow Diagram
Planning
analysis
Design
Implementation
system

7. V-Model

In V-model the testing begins as soon as possible in the project life cycle. It is always good practice to involve tester at earlier phases of product life cycle. There are varieties of test activities need to be carried out before end of the coding phase. This activity should be carried out in parallel to the development activities so that testers can produce a set of test deliverable.

The V-model illustrates that testing activities (Verification and Validation) can be integrated into each phase of the product life cycle

As the word comes verification and validation lets talk about them

Verification	Validation
It is the process of evaluating work products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase or not.And to check every phase individually is called Verification of that project	It is process of evaluating the software during or at the end of the development process to determine whether it satisfies specified business requirements .It majorly focused on User's Request and User's Needs

Testing Fundamentals:

There are two type of testing fundamentals

I. Functional Testing: It basically means Testing of all the features and function of a system to ensure requirement and specification of the client are met

I. Non Functional Testing: t basically means Testing is done on the requirement, specification and test scenarios defined by the client

now let’s talk about the different type of Functional Testing:

Unit Testing
Integeration testing

Top down approach
Bottom up approach
Bing bang approach
Hyprid approach

System testing
Smoke testing
Sanity testing
adhoc testing
Regression testing
User acceptance testing

Alpha testing
Beta testing

Localization testing
Globilaztion testing

II. Non Functional Testing:

recovery testing
combatable testing
Usability Testing
Documentation Testing
Installation Testing
Operational Readiness Testing
Security Testing
performance testing

A performance testing is a technical investigation done to determine or validate the responsiveness, speed, scalability and stability.
There are different types of performance testing.

Load Testing-

to verify application behavior under normal and peak load conditions

Endurance Testing
It is a subset of load testing. An endurance test is a type of performance test focused on determining or validating the performance characteristics of the product under test when subjected to workload .It is basically to evaluate time
lets take an example to explain what basically is load and endurance testing is
there is a website of a bank abc and transaction of money online only happens when 15 users are doing the transaction and it take 10 sec to complete the transaction.In load testing what we do we increase the number of user from 15 to 16 then 17,18 and so on then we check till how many user does the function of online transaction of money take place and till when the functionality breaks but we have to do transaction in 10seconds only no increase in time. In endurance testing we do the same by increasing the time (we can say by 5 sec) and users also

Stress testing-To determine or validate an application's behavior when it is pushed beyond normal or peak load conditions.

2.2 spike testing- The example of stress and spike testing are same as above example but in this testing we decrease the time and check when the functionality will break.

3. Capacity Testing - To determine how many user or transactions a given system will support and still meet performance goals.

4. Volume Testing - It is performed while doing the database testing

Approaches of Testing

There are 2 types of approaches

1. Static approach

2. Dynamic approach

Static approach -In this approach the software work products are examined manually, or with a set of tools but not executed. Some types of defects are easier to find in static approach. All software work products can be tested using review techniques. Review is part of static testing.

Dynamic approach -Software is executed using a set of input values and its output is then examined and compared to what is expected. Dynamic approach/testing can only be applied to the software code.

Different types of Dynamic approach/ testing

· Black box testing

· White box testing

· Gray box testing

Testing Techniques

Black box testing Techniques are following

Equivalence Partitioning
Boundary Value Analysis
Decision Tables
State Transition Diagrams

White box testing Technique – White-box technique includes :- control flow testing ,data flow testing, branch testing, path testing

Code coverage – In this each line of code is being executed

Design coverage – In this each Boolean expression like if-else, do-while, while are being executed at least once

Defect

What do you mean by a defect?

Ans: - defect is non-accordance to user behavior or a defect is a condition in a software product which does not meet a software requirement or end user's expectations

A program that contains a large number of bugs is said to be buggy.
Reports detailing bugs in software are known as bug reports.
Applications for tracking bugs are known as bug tracking tools.
The process of finding the cause of bugs is known as debugging

There are 2 types of defects

1. Defect Severity

2. Defect Priority

Defect Severity - It basically tells how bad the bug is?

Defect Priority - It indicates “How much the business is getting affected by the defect".

There are 4 classifications of defect severity and defect priority

1. High severity and High priority - example "when we are not able to login in our account" it can highly impact our business and it is a serious bug/defect.

2. Low severity and High priority - example " Spelling mistake in the name of company on company's website like airtl instead of airtel "

3. Low severity and Low Priority- example "there is drop down on second page of the website and spelling of haryana is wrong" or we can just a typo error.

4. High severity and Low priority - example " not able to take the printout from the website"

Defect Life-cycle

New - when the bug is posted for the first time , its state will be "NEW".This means that bug is not yet approved
Open - After a tester has posted a bug ,the lead of the tester approves that bug is genuine and he changes the state as "OPEN"
Assign - Once the lead changes the state as "OPEN”, he assign the bug to corresponding developer or developer team. The state of the bug now is changed to "ASSIGN".
Deferred - The bug, changed to deferred state means the bug is expected to be fixed in next releases.
Rejected - If the developer feels that the bug is not genuine, he rejects the bug. Then the state of bug is changed to "REJECTED".
Test - Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to "TEST”. It specifies that the bug has been fixed and is released to testing team.
Reopened - If the bug still exists even after the bug is fixed by the developer, the tester changed the state to "REOPENED”. The bugs traverse the life-cycle once again.
Verified -Once the bug is fixed and the status is changed to "TEST”, the tester tests the bug. If the bug is fixed and not present in software the state is changed to “VERIFIED"
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 changed the state of the bug to "CLOSED".

Defect Management Process

The typical defect management process includes the following high-level process steps. When implemented inside of a specific organization, each of these high-level steps would have more detailed standard operating procedures along with policies to carry out the details of the process.

Identification - This step involves the discovery of a defect. Hopefully, the person discovering the defect is someone on the testing team. In the real world, it can be anyone including the other individuals on the project team, or on rare occasions even the end-customer.
Categorization - When a defect is reported, it is typically assigned to a designated team member to confirm that the defect is actually a defect as opposed to an enhancement, or other appropriate category as defined by the organization. Once categorized, the defect moves on in the process to the next step which is prioritization.
Prioritization – Prioritization is typically based on a combination of the severity of impact on the user, relative effort to fix, along with a comparison against other open defects. Depending on the size and structure of the organization, the prioritization is often handled by a formal change control board. The priority should be determined with representation from management, the customer, and the project team.
Assignment - Once a defect has been prioritized, it is then assigned to a developer or other technician to fix.
Resolution - The developer fixes (resolves) the defect and follows the organization's process to move the fix to the environment where the defect was originally identified.
Verification - Depending on the environment where the defect was found and the fix was applied, the software testing team or customer typically verifies that the fix actually resolved the defect.
Closure - Once a defect has been resolved and verified, the defect is marked as closed.
Management Reporting - Management reports are provided to appropriate individuals at regular intervals as defined reporting requirements. In addition, on-demand reports are provided on an as-needed basis.

******************************************

Manual Testing Techniques

Monday, June 30, 2014