Manual Ing
Manual_ing
Manual_ing
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 10
| Download | |
| Open PDF In Browser | View PDF |
MANUAL TESTING CONCEPTS What is Software Testing? Software testing is the process of evaluating a system with the intend of finding bugs. It is performed to check if the system satisfies its specified requirements. Testing measures the overall quality of the system in terms of its correctness, completeness, usability, performance and other functional and non-functional attributes. Why is Testing required? Software Testing as a separate activity in SDLC, is required because• • • • • • Testing provides an assurance to the stakeholders that product works as intended. Avoidable defects leaked to the end user/customer without proper testing adds bad reputation to the development company. Separate testing phase adds a confidence factor to the stakeholders regarding quality of the software developed. Defects detected in earlier phase of SDLC results into lesser cost and resource utilization for defect resolution. Saves development time by detecting issues in earlier phase of development. Testing team adds another dimension to the software development by providing a different view point to the product development process. Who does Testing? Software Testing is/can be done by all technical and non technical people associated with the software. Testing in its various phases is done by• • Developer - Developer does the unit testing of the software and ensure that the individual methods work correctly Tester - Testers are the face of the software testing. A tester verifies the functionality, usability of the application as functional tester, a tester checks the performance of the application as a Performance tester, a tester automates the manual-functional test cases and creates test scripts as an automation tester • • Test Managers/Lead/Architects - Define the test strategy and test plan End users - A group of end users do the User Acceptance Testing (UAT) of the application to make sure the software can work in the real world What is Software Quality? • Software quality is the conformance of a software system to its requirements. In software perspective, quality is defined by two factors - Validation and Verification. Validation checks if the process used during software development is correct or not whereas in verification the product is evaluated to check if its meets the specifications. Attributes of Software Quality • • • • • • • • Correctness - Correctness measures the software quality for the conformance of the software to its requirements Reliability - Checks if the software performs its functions without any failure within the expected conditions Robustness - Robustness is the ability of the software to not crash when provided with unexpected input Usability - Usability is the ease of operating the software Completeness - Completeness is the extent tp which the software system meets its specifications Maintainable - Maintainability is the measure of the amount of effort required for software maintenance after it has shipped to end user Portability - Ability of the software to be transformed from one platform or infrastructure to other Efficiency - Efficiency is the measure of resources required for the functioning of the software What is Test Strategy? • A Test Strategy is a high-level document describing the way testing will be carried out. In a test strategy document, we document the test objectives and set of guidelines for achieving those objectives. It is presented by the project manager to all the stakeholders in the testing process. It can have a scope of an entire organization or a particular project. Test Strategy Approaches There are different apporaches to test strategy are• • • • • • Analytical Approach - Based on the risk analysis Model-based Approach - Based on the various statistical models Consultative Approach - Based on the consultation with technology or domain experts Methodical Approach - Based on the experience Heuristic Approach - Based on the exploratory techniques Standard-compliant Approach - Based on the industry standards and processes Test Strategy Document Template A test strategy document can contain the following fields- • • • • • • • • • • • Test Strategy Id - An identifier of the test strategy document and its various versions. Introduction - A brief introduction to the purpose and scope of the document. Standards to use - The different standards or set of guidelines to be followed. Risks and Mitigations - The different risks associated with in testing and their mitigation strategies. Entry Critieria - The set of pre-requisite that must be performed before testing can start. Exit Critieria - The criteria defining when the testing can be stopped. Test design techniques - The test design techniques to be used like equivalence partitioning, boundary value analysis etc. Test environment - The test environment specifications. Configuration management of testware - Specification of the right version of testware for testing. Test process improvement - The apporaches to use for improving the test process. Approvals - The persons approving the test strategy document. What is a defect? • • A defect or a bug is an error in a program that causes the application to perform in an unintended manner, deviating from its requirements. Based on the urgency of fixing the defect, we can classify them on a scale of P0 to P3, with P0 defect having the most urgency to fix. Also, the defects can be classified based on their criticality or the impact to the functionality. To report a bug we have different Defect Management Tools like - Jira, Mantis, Bugzilla etc. Next, we will see the different components of a Defect Report. Defect Reporting Template: • • • • • • • • • • • • • • DefectId - A unique identifier of the defect. Summary - A one line summary of the defect, more like a defect title. Description - A detailed description of the defect. Build Version - Version of the build or release in which defect is found. Steps to reproduce - The steps to reproduce the defect. Expected Behavior - The expected behavior from which the application is deviating because of the defect. Actual Behavior - The current erroneous state of the application w.r.t. the defect. Priority - Based on the urgency of the defect, this field can be set on a scale of P0 to P3. Severity - Based on the criticality of the defect, this field can be set to minor, medium, major or show stopper. Reported By - Name of the QA, reporting the defect. Reported On - The date on which the defect was raised. Assigned To - The person to whom the defect is assigned in its current state. It can be the developer fixing the defect, the QA for verification of the fixed defect or the manager approving the defect. Current Status - The current status of defect (one of the states of the defect life cycle). Environment - The environment on which the defect is found - release, staging, production etc. What is a defect life cycle? • • A defect life cycle is the movement of a bug or defect in different stages of its lifetime, right from the beginning when it is first identified till the time is marked as verified and closed. Depending on the defect management tool used and the organisation, we can have different states as well different nomenclature for the states in the defect life cycle. • • • • New - A bug or defect when detected is in New state Assigned - The newly detected bug when assigned to the corresponding developer is in Assigned state Open - When the developer works on the bug, the bug lies in Open state • • • • • • Rejected/Not a bug - A bug lies in rejected state in case the developer feels the bug is not genuine Deferred - A deferred bug is one, fix of which is deferred for some time(for the next releases) based on urgency and criticality of the bug Fixed/InTest - When a bug is resolved by the developer it is marked as fixed and assigned to the tester Reopened - If the tester is not satisfied with issue resolution the bug is moved to Reopened state Verified - After the Test phase if the tester feels bug is resolved, it is marked as verified Closed - After the bug is verified, it is moved to Closed status. What is Test Strategy? • • • A Test Strategy is a high-level document describing the way testing will be carried out. In a test strategy document, we document the test objectives and set of guidelines for achieving those objectives. It is presented by the project manager to all the stakeholders in the testing process. It can have a scope of an entire organization or a particular project. Test Strategy Approaches: The are different apporaches to test strategy are- • • • • • • Analytical Approach - Based on the risk analysis Model-based Approach - Based on the various statistical models Consultative Approach - Based on the consultation with technology or domain experts Methodical Approach - Based on the experience Heuristic Approach - Based on the exploratory techniques Standard-compliant Approach - Based on the industry standards and processes Test Strategy Document Template: A test strategy document can contain the following fields- • • • • • • • • Test Strategy Id - An identifier of the test strategy document and its various versions. Introduction - A brief introduction to the purpose and scope of the document. Standards to use - The different standards or set of guidelines to be followed. Risks and Mitigations - The different risks associated with in testing and their mitigation strategies. Entry Critieria - The set of pre-requisite that must be performed before testing can start. Exit Critieria - The criteria defining when the testing can be stopped. Test design techniques - The test design techniques to be used like equivalence partitioning, boundary value analysis etc. Test environment - The test environment specifications. • • • Configuration management of testware - Specification of the right version of testware for testing. Test process improvement - The apporaches to use for improving the test process. Approvals - The persons approving the test strategy document. What is a Test Plan? • • A Test Plan is a formal document derived from requirement documents (Software Requirement Specification, Use Case documents etc.), describing in detail the scope of testing and the different activities performed in testing. It is generally prepared by a test manager and approved by the different stakeholders of the application. Features of a Test Plan A Test Plan needs to address the following• • • • • • • • Overall scope of testing Risk Analysis Test estimate Resource Requirement Tools used Scheduling, review and analysis of test design activities Creation of test cases and test data Identification of test monitoring and test control activities What is a Test Scenario? • • A Test Scenario is generally a one line statement describing a feature of application to be tested. It is used for end to end testing of a feature and is generally derived from use cases. A single test scenario can cover one or more test cases i.e. it has a one to many relationship with test cases. What is Scenario testing? • • • • Scenario testing is a type of testing carried out using scenarios derived from the use cases. Using scenario testing, complex application-logic can be tested using easy to evaluate test scenarios. Some advantages of test scenarios are Test scenarios can serve as basis for lower level test case creation. Testing using test scenarios can be carried out relatively faster than the one using test cases. Saves a lot of time, better with projects having time constraints. What is a Test Case? • A test case is a set of conditions for evaluating a particular feature of a software product to determine its compliance with the business requirements. • • • • • • • • • • • • A test case has pre-requisites, input values and expected results in a documented form which cover the different test scenarios. A test case can have following attributesTestCaseId - A unique identifier of the test case. Test Summary - Oneliner summary of the test case. Description - Detailed description of the test case. Prerequisite or pre-condition - A set of prerequisites that must be followed before executing the test steps. Test Steps - Detailed steps for performing the test case. Expected result - The expected result in order to pass the test. Actual result - The actual result after executing the test steps. Test Result - Pass/Fail status of the test execution. Automation Status - Identifier of automation - whether the application is automated or not. Date - The test execution date. Executed by - Name of the person executing the test case.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.7 Linearized : No Page Count : 10 Language : en-US Tagged PDF : Yes XMP Toolkit : 3.1-701 Producer : Microsoft® Word 2016 Creator : Kolaparthi, Srinivas Creator Tool : Microsoft® Word 2016 Create Date : 2018:07:04 14:47:55+05:30 Modify Date : 2018:07:04 14:47:55+05:30 Document ID : uuid:E25C04CF-5969-4301-9F4A-1104F1D187D3 Instance ID : uuid:E25C04CF-5969-4301-9F4A-1104F1D187D3 Author : Kolaparthi, SrinivasEXIF Metadata provided by EXIF.tools