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

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 12207 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.

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

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

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.

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.

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.

STLC STLC

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 ) 

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

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.

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.

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.

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.

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)

Testing documentation Refer the documentation PDF

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?

Defect Management

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

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

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.

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

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 email address and password. Assumption: a supported browser is being used. Test Steps: Navigate to gmail.com In the ’email’ field, enter the email 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.