1. Testing v1.0 - Introduce Yourself???? Share your views on testing ?
What you know about testing?
Why did you guys choose testing?

2. SDLC Phases of Software Development Life Cycle
The order in which each phase is executed.
Each phase produces a deliverable to the next phase.
t is also called as Software development process.
The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process.
ISO/IEC is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.

3. Requirement Gathering Problem to Solve
Phase
Input
Output
Stake holder
Requirement Gathering
Problem to Solve
Scope : What is being considered for Development, BRD & FRD, Budgeting
Scheduling
Client, BA, Top Management
Define
Scope, BRD, FRD
Project Plan, Infrastructure Needs
QA Kick off – Test Plan, Resource, Time Lines, Scope Requirement
PM, BA, Dev, QA
Design
Requirements, Project Plan, Test Plan,
Req. Doc to FSD, Technical Design Doc – Programming Details, DB mapping (dev. purpose)
BA, Dev, QA.
Build
Dev. Coding
Code
Unit Testing
White Box Testing
Test Case Preparation
Dev Team – coding
QA Team – writing TC
Testing
Build is deployed in QA env.
Test Plan TC
Test Execution
Defect Management
UAT
BA, QA Team, Support Team
Deploy
Tested Product
 / 
Different Phases of SDLC are
Consider an example of Trademe.co.nz

4. Different SDLC Models Water Fall Model V – Model Agile Model
Spiral Model
Will discuss the different models that are useful

5. Water Fall Model Also called as Linear – Sequential Model
Advantages of waterfall model:
This model is simple and easy to understand and use.
It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
In this model phases are processed and completed one at a time. Phases do not overlap.
Waterfall model works well for smaller projects where requirements are very well understood.
 Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.
When to use the waterfall model:
This model is used only when the requirements are very well known, clear and fixed.
Product definition is stable.
Technology is understood.
There are no ambiguous requirements
Ample resources with required expertise are available freely
The project is short.
Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.

6. V-Model
V- model means Verification and Validation model. Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins.  Testing of the product is planned in parallel with a corresponding phase of development in V-model.

7. Agile Model
Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications. Extreme Programming (XP) is currently one of the most well known agile development life cycle model.
Advantages of Agile model:
Customer satisfaction by rapid, continuous delivery of useful software.
People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.
Working software is delivered frequently (weeks rather than months).
Face-to-face conversation is the best form of communication.
Close, daily cooperation between business people and developers.
Continuous attention to technical excellence and good design.
Regular adaptation to changing circumstances.
Even late changes in requirements are welcomed
Disadvantages of Agile model:
In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.
There is lack of emphasis on necessary designing and documentation.
The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.
When to use Agile model:
When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.
To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.
Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly effected or removed based on feedback. This effectively gives the customer the finished system they want or need.
Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.

8. STLC
STLC

9. STLC – Requirement Analysis
Identify the type of tests to be performed
Gather details about test priorities
Prepare RTM
Identify the test environment
Deliverable
RTM
Automation Feasibility Report
 - test team - studies the requirements from a testing point of view to identify the testable requirements. 
 interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail. 
Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) 

10. STLC – Test Planning
Prepare the test plan/ strategy doc for various type of testing
Test tool Selection
Test effort estimation
Resource Planning and determining roles & responsibilities
Training Requirement
Deliverable
Test Plan / Strategy Document
Effort Estimation document
Also called as Test Strategy
A senior manger will determine the effort and cost esitmates
Finalize the test plan

11. STLC – Test Case Development
Create Test Cases / Test Scripts (Automation)
Review test cases / test scripts
Create Test Data
Deliverable
Test cases / script
Test Data
This phase involves creation, verification and rework of test cases & test scripts. 
Test Data is identified/created and is reviewed and then reworked as well.

12. STLC – Test Environment Setup
Prepare the hardware & software requirement list for the Test Environment.
Set up the Test Environment and Test Data
Deliverable
Environment ready with test data set up.
Smoke Test Results
Decides the software and hardware conditions under which a work product is tested.
Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. 
Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.

13. STLC - Test Execution Execute tests as per plan.
Document test results & log defects for failed cases.
Map defect to test cases in RTM
Retest the defect fixes
Track the defects to closure.
Deliverables
Test case updated with results
Defect Report
During this phase test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed.

14. STLC -Test Cycle Closure
Evaluate cycle completion criteria based on Time, Test Coverage, Cost etc.
Prepare Test Metrics
Document the learning outcome
Prepare the test closure activity
Deliverables
Test Closure Report
Test Metrics
Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.

15. SDLC vs STLC S No Phase SDLC STLC 1 Req. Gathering Done by BA
Testing team review & analyse the req. On the basis of which QA team will decide the type of testing needed. 2
Design
High & Low Level Design of the software
Test Planning, Effort Estimation 3
Coding / Development
Actual coding!
Detailed Test Cases 4
Testing
In SDLC actual testing is done here
Test Execution and bug reporting 5
Deployment
Application deployed on production environment
Test Report is prepared 6
Maintenance
Post Production / support
Test cases required for maintenance testing support request etc.
There are two sides of this coin: Testing within the software development (Here, the old definition of STLC may be applicable)
Consider testing as a independent sub project of a software development project (Here, I believe, old definition no longer sustains)

16. Testing documentation
Refer the documentation PDF

17. Testing Profile - Hierarchy
Test Manager Test lead Senior Test Analyst Test Analyst Test Engineer Test Executive
Where do you want to reach 5 years down the line?

18. Defect Management

19. Testing Principles Exhaustive testing is impossible Early testing
Defect Clustering
Pesticide Paradox
Testing is context dependent
Absence of error – fallacy
Completely tested software is never BUG - FREE

20. Exhaustive testing is not possible
Case:
15 input fields(text box) with 5 possible values in each input field. Total test case – 75.
Execution time and cost will raise exponentially
Optimize the test cases based on risk assessment
Risk assessment comes with experience
Defect Clustering
With past test results, identify the module which has yielded more defects and modify the test suit accordingly to test the module which has more defect
Also, it is good to test all the modules that are impacted with the high defect modules

21. Pesticide Paradox
Executing the same test cases repeatedly would not yield new bugs
To over come this, test cases needs to regularly reviewed & revised, adding new different test cases to help find more defects.
Early Testing
Testing should start as early as possible in SDLC
This reduces the probability of finding business critical defects in the later stages of the testing phase
Testing is Context dependent
It is simple but very important
Testing a website like ‘TradeMe’ is different from testing ‘Microsoft Office’ applications
Methodologies, process and metrics should be altered accordingly. Failing this would result in testing failure.

22. Completely tested software is never BUG - FREE
Case:
Recently launched Windows 10 had lot issues with device compatibility, installation issue, system crash.
Testing reduces the probability of defects in a software
Absence of defect does not prove the correctness of the software
Always, Testing shows the presence of defects
Absence of defect - fallacy
Sometimes the software could be defect free but it might actually NOT satisfy all of the client requirement
Testing should be thoroughly requirement based

23. Test Case What is a Test Case ?
Title: Login Page – Authenticate Successfully on gmail.com
Description: A registered user should be able to successfully login at gmail.com.
Precondition: the user must already be registered with an address and password.
Assumption: a supported browser is being used.
Test Steps:
Navigate to gmail.com
In the ’ ’ field, enter the of the registered user.
Enter the password of the registered user
Click ‘Sign In’
Expected Result: A page displaying the gmail user’s inbox should load, showing any new message at the top of the page.
Test cases for software help guide the tester through a sequence of steps to validate whether a software application is free of bugs and working as required by the end user.  Learning how to write test cases for software requires basic writing skills, attention to detail, and a good understanding of the application under test (AUT).
How to write test cases for software:
Use a Strong Title
A good test case starts with a strong title.  As a best practice, it’s good to name the test case along the same lines as the module which you’re testing.  For example, if you’re testing the login page, include “Login Page” within the title of the test case.
Include a Strong Description
The description should tell the tester what they’re going to test and include any other pertinent information such as the test environment, test data, and preconditions/assumptions.
Include Assumptions and Preconditions
You should include any assumptions that apply to the test and any preconditions that must be met prior to the test being executed.  This information can include which page the user should start the test on, dependencies on the test environment, and any special setup requirements that must be done before running the test.  This information also helps keep the test steps short and concise.
Keep the Test Steps Clear and Concise
The test steps should include the data and information on how to execute the test.  This is perhaps the most important part of a test case.  Keep this section clear and concise, but don’t leave out any necessary details.
Include the Expected result
The expected result tells the tester what they should experience as a result of the test steps.  This is how the tester determines if the test case is a “pass” or “fail”.
Make it Reusable
A good test case is reusable and provides long-term value to the software testing team.  When writing a test case, keep this in mind.  You can save time down the road by re-using the test case instead of re-writing it.