Course Content

1) Fundamentals of Testing

• Definitions
• Software Testing Myths
• Objectives Of Testing
• Impossibility Of Complete Testing
• When to Stop Testing

2) Software Development Life Cycle

• Planning
• Requirement Analysis
• Design
• Coding
• Testing
• Implementation
• Maintenance

3) Models

• Waterfall Model
• V Model
• Agile Development

4) Levels of Testing

• Unit Testing
• Integration Testing
• Top  Down Testing
• Bottom Up Testing 
• System Testing
• Functional Testing
• Performance Testing
• Acceptance Testing
• Alpha Testing
• Beta Testing

5) Type Of Testing

• White Box Testing
• Black Box Testing
• Hand On Exercises

6) Techniques of Black Box Testing

• Equivalence Partitioning
• Boundary Value Analysis
• State-Transition Testing
• Error guessing

7) Smoke & Sanity Testing

8) Regression & Retesting

9) Software Testing Life Cycle

• Planning
• Requirement Analysis
• Test Cases Creation
• Test Cases Review
• Execution
• Report Analysis
• Bug Reporting

10) Test Plan

• Purpose of the document
• Product description
• Test Items
• Feature to be tested
• Feature not to be tested
• Testing Strategy
• Test Approach
• Test Entry and Exit Criteria
• Test Deliverables
• Criteria for Success
• Risk and Contingencies
• Dependencies and Assumptions
• Responsibilities
• Staff and training
• Schedule

11) Bug Life Cycle

12) Acceptance Testing

Trainer Profile

Manish

• Currently working as IT Manager in one of the renown IT firm
• Conducted trainings at different places in Noida & Delhi on topics Software Testing
• Conducted multiple trainings in HCL, NIIT and other IT companies
• Conducted trainings for both Manual & Automation Testing
• Conducted online trainings on above given topics at both Fiserv India & NIIT
• Experience in all phases of Software Development Life Cycle (Requirements Analysis, Design Testing, Implementation and Support) to perform QA activities
• Experience in Functional Testing, Database Testing using SQL queries, Regression Testing, GUI testing
• Knowledge of SQL (SQL Server 2008) to validate Transaction Testing for front end testing to validate data in back end database

Interview Questions & Answer

1) What is Software Testing?

Software testing is a validation process that confirms that a system works as per the business requirements. It measures the overall quality of the system on attributes like usability, accuracy, completeness, efficiency, etc. The ANSI/IEEE 1059 is the global standard that defines the basic principles of testing.

Basically, it is used for ensuring the quality of software to the stakeholders of the application.

2) What do u mean by Quality Assurance Mean In Software Testing?

Quality assurance is a process-oriented approach to certify a software development (SDLC) method that it is correct and follows the standard procedures. It may bring changes in the process and cause to replace the weak practices if it identifies any. So, it is considered as a preventive measure. It involves activities such as documents review, test cases review, source code, and automation, etc.

3) What is SDLC?

SDLC stands for Software Development Life Cycle. It refers to all the activities performed during software development. It includes requirement gathering, requirement analysis, designing, coding or implementation, testing, deployment, and maintenance.

4) What is the difference between functional and non-functional testing?

5) Define White Box Testing?

White box testing is also called as Glass Box, Clear Box, or Structural Testing.  It is based on applications internal code structure

It requires the testers to gain a code-level perspective, design cases to exploit code, and find potential bugs.

6) Define Black Box Testing?

Black box testing is a standard software testing approach which requires testers to assess the functionality of the software as per the business requirements. They treat the software as a black box and validate it as per the end-user point of view.

It applies to all levels of software testing such as Unit, Integration, System, or Acceptance Testing.

7) What is a test plan?

A test plan is a formal document which describes:

• the scope of testing,
• the approach to be used,
• resources required
• time estimate of carrying out the testing process.

 It is derived from the requirement documents(Software Requirement Specifications).

8) What is a test case?

A test case is used to test the conformance of an application with its requirement specifications. It is a set of conditions or variables with pre-requisites, input values and expected results in a documented form.

 9) What is a test scenario?

 Test Scenario represents a condition or a possibility which defines what to test. A test scenario is derived from a use case.  It is used for end to end testing of a feature of an application. A single test scenario can cater to multiple test cases. The scenario testing is particularly useful when there is time constraint while testing.

10) What is unit testing?

it is the first level of testing and it involves testing individual modules of the software. It is generally performed by developers.

 11) What is integration testing?

In integration testing, we test the group of related modules. Integration testing is performed after unit testing. It aims at finding interfacing issues between the modules.

12) What is performance testing?

 Performance testing is a type of non-functional testing.in this type of testing the performance of the system is evaluated under expected or higher load. The various performance parameters evaluated during performance testing are – response time, reliability, resource usage, scalability, etc.

13) What is Top-Down Approach?

In this the testing takes place from top to bottom. First the High-level modules are tested  and then low-level modules and finally integrating the low-level modules to a high level to ensure the system is working as intended. Stubs are used as a temporary module if a module is not ready for integration testing.

14)  What is Bottom-Up Approach?

It is a reciprocate of the Top-Down Approach. Testing takes place from bottom to up. Lowest level modules are tested first and then high-level modules and finally integrating the high-level modules to a low level to ensure the system is working as intended.  Drivers are used as a temporary module for integration testing.

15) What are the types of defects?

  Three types of defect are there: Wrong, missing, and extra.

Wrong: These defects are occurred when the requirements have been implemented incorrectly.

Missing: It is used to specify the missing things, i.e., a specification was not implemented, or the requirement of the customer was not appropriately noted.

Extra: This is an extra facility incorporated into the product which  was not given by the end customer. It is always a variance from the specification but may be an attribute that was desired by the customer. However, it is considered as a defect because of the variance from the user requirements.

16) What is the difference between verification and validation?

Blog

In Software Testing  blog we will discuss what test strategy is ,why it is required when we would require a test strategy document and finally how to write Test strategy document

What is a Test Strategy

A Test strategy is a static document which describes how the testing activity will be done. This is like a handbook to stakeholders which describes the test approach that we undertake, how we manage risk as well as how we do testing and what all levels of testing along with entry and exit criteria of each activity. This will be a generic document that the testing team would refer to prepare their test plan for every project.

Test strategy act as a guidelines/plan at the global Organization / Business Unit level on the other hand Test plan will be specific to project and always we should ensure that we are not deviating from what we commit in Test strategy

Why Test Strategy is required

It gives an Organization a standard approach about how Quality is ensured in the SDLC. When there is any typical risk involved in a program, how to mitigate those risk and also  how can those risks be handled. When every project adopt to the same standard, quality improvement will be witnessed across the Organization and hence therefore strategy is important.

When do we need a Test Strategy

Below are some of the circumstances which would require Test Strategy:

• When an Organization is forming a separate QA wing
• When there is a change in QA Organization from normal QA model to TCoE / QCoE where the operating model and structure is changed
• When QA leadership changes who comes with different perception
• When Organization is adopting different tool approach for Automation / Performance etc

Contents of Test Strategy

Below are the contents of Test Strategy document:

1) Brief Introduction about programs covered in this Strategy

2) Testing Scope and Objective

3) Test Planning / Timeline

4) TEM Strategy

5) TDM Strategy

6) Performance Strategy

7) Automation Strategy

8) Release and Configuration Management

9) Test schedule, cycles, and reporting

10) Risk and Mitigation

11) Assumptions

Brief Introduction of programs covered in this Strategy

This section covers the overall scope this Test strategy is going to be covered with. Important engagement and programs which will run based on this Test strategy.

Testing Scope and Objective

 This section describes the following:

1. What will be the different levels of testing conducted like Integration, System, E2E, etc
2. The process of review and approval of each stage
3. Roles and Responsibility
4. Defect process and procedure till final Test sign off

Test Planning and Timeline

This section covers the following in brief;

1. What are the programs going to be executed
2. What is the timeline that each program is going to constitute
3. What will be the infrastructure and tooling needs to support this program
4. Different Environment that will be used

TEM Strategy

Prior section describes the overall requirement and this section describes in detail about the Test Environment Strategy and it covers the following:

1) How to book Environment for project purpose including booking 3rd party Environment

2) Assess to Environment to users for project requirement

3) Environment integration and stability management

4) Test data refresh co-ordination

5) Post release Environment validation

6) Support and co-ordination requirement

TDM Strategy

Similar to Environment, different project test teams would require different data requirement and some would need to mock up live data. TDM strategy would provide the below information

• What are the forms to be filled and agreement to be in place to serve this data need
• What type of data to be loaded and when it will be available
• Who will be the point of contact for each and every program
• If any 3rd party Vendor support is required, this would describe that also.

Performance Strategy

Based on various programs and its schedules listed in the prior section, performance strategy would describe how performance Testing requirements would be fulfilled and what their tool strategy, license model is and team availability. If the team also does Performance Engineering, it would describe in detail about how it is performed.

It covers details about Requirement phase (How NFR requirement will be gathered from stakeholders, Proof of concept procedure, how critical scenarios are defined.), Testing phase (How testable scripts are created, how data setup is done), Analysis and Recommendation (How performance issues are reported, sign off procedure)

Automation Strategy

Similar to Performance Strategy, Automation strategy would describe how requirements are defined, tool strategy, license model, etc and also elaborate how the Automation team conducts feasibility approach till defining framework, developing scripts till execution and Continuous Testing if it is in-scope

Release and Configuration Management

• This section describes the following areas of Release and configuration management
• Overall release and configuration strategy
• QA deployment and release calendar
• How different Test assets are loaded and tracked
• Co-ordination of QA Deployment
• How QA audit is conducted
• How production deployment is co-ordinated by the QA team
• Change Management for any CR post-release is managed

Test schedule, cycles and reporting

This section will detail out about each program, its schedules, Test timeline, Test cycles and how reporting will be carried out.

Risk and Mitigation

This section describes overall risk management and risk mitigation process along with how it will be tracked and reported.

It also classifies various risk levels like Project level and program level risk and describes how it will be handled during the execution phase

Assumption and Dependencies

During Test strategy development the timeline of program etc are in a predictive stage as it could be for a period of 1-5 years and hence there is going to be a lot of assumption which should be listed in this section. Also, there are different teams which Testing team has to co-ordinate with like TEM, TDM, vendors, etc which needs to be called out in advance in the assumption and dependencies as any change in Project-level / Program level scope will have an adverse impact and it has to be covered out in strategy as assumption and dependencies

How to write Test Strategy document

For now we have covered about what Test strategy is all about, why it is important and looked in detail about the contents of the Test strategy, then  it is now easier to define how to write better Test strategy document.

Before writing Test strategy we need to collect few information which is listed below:

•  List of programs that need to be handled in this stream
•  Programs and its releases objective and basic requirement it is going to meet
•  Criteria for Environment and Data management requirement
•  Timeline of each releases and it’s key stakeholders
•  Third party integration and vendor management details
•  Information about Test type and release frequency
•  Tool requirements/procurement process understanding
•  Basic assumption and dependency with outside QA Organization

This information will be collected by Program Test Manager after discussing with Key stakeholders of the program.

The collected information has to be discussed internally within the QA team Managers and assign responsibility to detail out further requirements to refine the Test Strategy.

If the program is going to be from the QA Transformation perspective, then further information has to be collected on the key QA levers that are going to run the program run differently.

After identifying the key levers, assign the responsibility of each lever to a dedicated person so that Strategy can be further fine-tuned and can be circulated to wider group.