Your SlideShare is downloading. ×
  • Like
  • Save
stlc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply
Published

stlc

stlc

Published in Education , Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,906
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
75
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. QA –Testing Material 1 www.TransformToIT.com Prepared By: A.B Reddy STLC (Software Testing Life Cycle)  Test Planning  Test Development  Test Execution  Result Analysis  Defect Management  Summarized Reports Test Planning:  Preparation of QA or Test Strategy  Prepare Test Plans  Plan for Resources  Effort Estimation  Plan for the training needs  Evaluation of tools & technologies  Risks & Mitigation Participants: Test Manager and Test Lead Deliverables: Test Strategy Document, Test Plan Document Test Development  Preparation of Test scenarios from real time Business Scenarios or combine collection of Uses cases and derive test Scenario out of it.  Derive positive and Negative Test cases and write down Test Conditions  Preparation of test Data  Review of Test cases  Decide Test cases for Automation (Automation)  Develop Test Scripts (Automation)  Setup Test environment 1. Developer Environment (Developer develop code and perform Unit test on this) 2. QA Environment (Replica of Client Environment) 3. Staging (or) implementation Environment (Production Like Environment with Production data and External Connections) 4. Production Environment (Live Environment) Above all are Ideal Environments, but in reality no. of Environments may vary For Example If Technical Leadership decided to have one exclusive Environment for Integration testing they will come up with integration QA Environment along with QA Environment If Business Users decided they want one exclusive environment for them they request to build End User Environment for User Acceptance Testing …etc Participants: Test Lead and Testers (Test Case Designers and Test Case Executioners) Deliverables: Test Case Documents, Test Data Conduct Test Readiness Review meeting before to starting Execution
  • 2. QA –Testing Material 2 www.TransformToIT.com Prepared By: A.B Reddy Environment Team will provide Test Environment Readiness; expected figure is 100% to start execution, Test Team need to provide Test Case Design readiness to start the Execution Test Execution o Perform Manual Execution of Test cases with provided Test data Input (Manual testing) o Executioner need to follow appropriately Pre-Condition and Post-Condition of the test cases. Sometimes there should be dependency like; test case 1 is the pre-condition of the test case2. So make sure Test case1 is already executed before starting the Execution of testcase2. Testcase1: Registration of User Testcase2: Login to the website with Existing User o Perform Automated scripts Execution.(Automated Testing) o Monitor the Automation run and perform error handling manually if test script Struck With runtime Error Participants: Testers (Test Executioners) Deliverables: Test Case Results (Before Analysis) Result Analysis Result Analysis is crucial step to judge the Application Fault. In the Test Case Execution If Test case Actual result doesn’t match with Expected Result: Verify that test case has been written as per the requirements, some times there may be test case problem or requirements might have changed after the test case has been designed. If Test case Expected Result matches with requirement. Executioner should double check the Actual Behavior by executing test case one more time. If Still “Actual Result” mismatches with “Expected Result”. Verify is there any test Environment problem (note that many cases environment will be fine). If Test Environment is Fine Next step will be double check the test data provided, whether data matching with the test case requirement. If test Data is also Fine then Executioner analysis confirms that Fault is Application side, Executioner must mark the “Test Case Result” Column in test Case as “Failed” Executioner need to start gathering details to file a Defect. Participants: Test Leads and testers Deliverables: Test Case Result Reports (after Analysis) Defect Tracking Before creating new Defect ,perform Duplicate Defect Check (make sure the same Application defect hasn’t been filed by others ) • File new defect and associate enough information to help developer for further analysis Information can be o Detailed Steps to reproduce the Defect, Actual result and Expected Result o Snapshot of the User Interface Screen or Database Result Set when Error Occurred o Error Log of any Server • Assign Defect to Developer, if don’t know about exact developer then Assign to Development Lead later he can route to appropriate person. • Defect Follow-up with Developer
  • 3. QA –Testing Material 3 www.TransformToIT.com Prepared By: A.B Reddy o If Developer has concerns about opened defect, if he has concerns tester may explain and convince about the defect to resolve his concerns. o If Developer corrected code and fixed the defect, Tester need to re-test and Close the defect. Participants: Test Leads, Test managers and testers Deliverables: Defect Reports Summarized Reports • Prepare Test Case Result Documents • Create Defect Reports :Total how many no of bugs identified….etc • Create Test Case Reports : About Test Execution: Total how many no of cases executed About Pass Percentage: How many test cases Passed as result of Total test cases, based on this report Management takes the decision about postponement of the Release Participants: Test Leads and managers Deliverables: Metric Documents and Reports Test Strategy Document A Test Strategy document is a high level document and normally developed by project manager. This document defines “Testing Approach” to achieve testing objectives. A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment. The test strategy describes how the product risks of the stakeholders are mitigated at the test-level, which types of test are to be performed, and which entry and exit criteria apply. The test strategy is created based on development design documents. The Test Strategy is normally derived from the Business Requirement Specification document. The system design document is the main one used and occasionally, the conceptual design document can be referred to. The design documents describe the functionalities of the software to be enabled in the upcoming release. For every set of development design, a corresponding test strategy should be created to test the new feature sets. This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to- company. Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is usually the case for small projects. However, for larger projects, there is one Test Strategy document and different number of Test Plans for each phase or level of testing. Components of the Test Strategy document Scope and Objectives Business issues Roles and responsibilities Communication and status reporting Test deliverability Industry standards to follow Test automation and tools Testing measurements and matrices
  • 4. QA –Testing Material 4 www.TransformToIT.com Prepared By: A.B Reddy Risks and mitigation Defect reporting and tracking Change and configuration management Training plan Test Plan A test plan is a general document for the entire project that defines the scope, approach to be taken, and the schedules of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task and any risks requiring contingency planning. The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents. 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. The test planning can be done, well before the actual testing commences and can be done in parallel with the coding and design phase. The inputs for forming test plan are  Project plan  Requirement spec. Doc.  Architecture and design document. Test Plan (IEEE 829 format) • Test Plan Identifier – Test Plan Unique Number • References – have any references • Introduction – about Current Project • Test Items – Names of Modules or functionalities of Current Project • Software Risk Issues - Identify and Present Risks Involved. • Features to be Tested – Names of Functionalities to be tested in this test plan • Features not to be Tested - Names of Functionalities not to be tested in this test plan • Approach- Test Approach to be followed – like Unit, integration, Bugs calculation etc • Entry Criteria- SRS review done , Establish test environment , receive Build from developers • Item Pass/Fail Criteria- Define the Pass/Fail Criteria • Suspension Criteria- When Interrupt testing -When major defect found, Test Environment Abounded etc • Test Deliverables – List of testing docs (Test scenarios, test cases, Automation Plan, Results and Defect Logs) • Environmental Needs- Stable Environment Provided with minimum Components, pass the sanity Check
  • 5. QA –Testing Material 5 www.TransformToIT.com Prepared By: A.B Reddy • Staffing and Training Needs- names of testers in the current project and required number of training sessions to understand project requirements • Responsibilities- Work allocation to testers Module wise etc. • Schedule- Dates and Times when Testing to be started. • Planning Risks and Contingencies- List out Risks , and Risk mitigation • Approvals- Required signatures of the Leads and Managers to make test plan effective What is a Test Case? A test case is a set of conditions or variables and inputs that are developed for a particular goal or objective to be achieved on a certain application to judge its capabilities or features. It might take more than one test case to determine the true functionality of the application being tested. Every requirement or objective to be achieved needs at least one test case. Some software development methodologies like Rational Unified Process (RUP) recommend creating at least two test cases for each requirement or objective; one for performing testing through positive perspective and the other through negative perspective. Test Case Structure A formal written test case comprises of three parts - Information Information consists of general information about the test case. Information incorporates Identifier, test case creator, test case version, name of the test case, purpose or brief description and test case dependencies. Activity Activity consists of the actual test case activities. Activity contains information about the test case environment, activities to be done at test case initialization, activities to be done after test case is performed, step by step actions to be done while testing and the input data that is to be supplied for testing. Results Results are outcomes of a performed test case. Results data consist of information about expected results and the actual results. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, Actual result, Expected result etc. A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
  • 6. QA –Testing Material 6 www.TransformToIT.com Prepared By: A.B Reddy Test Case Template & Example: Defect Life Cycle
  • 7. QA –Testing Material 7 www.TransformToIT.com Prepared By: A.B Reddy Description of Various Stages: 1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”. 3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”. 4. FIXED: 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. 5. 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. 6. 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”. 7. 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”. 8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”. 9. Re-Opened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again. 10. 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. Severity What is Severity? Defines Impact Level of the Defect on the System, the importance of defect with respect to functionality point of view. Severity Levels • 1. Critical - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. 2. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component's, however, there are acceptable processing alternatives which will yield the desired result. 3. Average - The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or
  • 8. QA –Testing Material 8 www.TransformToIT.com Prepared By: A.B Reddy inconsistent results, or the defect impairs the systems usability. 4. Minor - The defect does not cause a failure, does not impair usability, and the desired processing results are easily obtained by working around the defect. 5. Exception - The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or is a request for an enhancement. Defects at this level may be deferred or even ignored. Priority What is Priority? Defines how soon the defect needs to be fixed as per business needs and priorities. Priority Levels 1. Resolve Immediately - Further development and/or testing cannot occur until the defect has been repaired. The system cannot be used until the repair has been effected. 2. Give High Attention - The defect must be resolved as soon as possible because it is impairing development/and or testing activities. System use will be severely affected until the defect is fixed. 3. Normal Queue - The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created. 4. Low Priority - The defect is an irritant which should be repaired but which can be repaired after more serious defect have been fixed. 5. Defer - The defect repair can be put of indefinitely. It can be resolved in a future major system revision or not resolved at all. Examples: High priority and high severity: The application crashes whenever a person attempts to submit valid input on the registration page. High priority and low severity: The content entered in the Terms of Use are not correct and could potentially lead to legal consequences. High severity and low priority: A system crash is an example for high severity but suppose that occurs when user enters extreme unrealistic Data, which isn’t happen in Production. Ex: The application crashes whenever a person enters 1500+ chars in a “phone number” text box. Low severity and low priority: There is a slight misspelling on one of the FAQ pages.
  • 9. QA –Testing Material 9 www.TransformToIT.com Prepared By: A.B Reddy Defect Metrics • Cost of a defect : Total effort spent on Testing/Total no of defects • Testing Efficiency : No. of test cases/No. of defects • Defect Density : No. of defects per 1000 lines of code • Defect Closure Rate : How much time takes to close a defect Sample Defect:
  • 10. QA –Testing Material 10 www.TransformToIT.com Prepared By: A.B Reddy