Software Testing Beginning. www.BugHuntress.com Designed by Artyom Rozumenko
EPIGRAPH <ul><li>If you want to ask something be sure that you can’t find answer yourself. </li></ul><ul><li>For searching answers you can use google.com , wikipedia.org </li></ul>Designed by Artyom Rozumenko www.BugHuntress.com
QA, QC and Testing <ul><li>Software testing is the process used to assess the quality of computer software . Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs . </li></ul><ul><li>Quality control or QC are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements . </li></ul><ul><li>Quality assurance , or QA , is the activity of providing evidence needed to establish quality in work, and that activities that require good quality are being performed effectively. All those planned or systematic actions necessary to provide enough confidence that a product or service will satisfy the given requirements for quality . </li></ul>Designed by Artyom Rozumenko www.BugHuntress.com
Quality assurance <ul><li>Quality assurance covers all activities from design, development, production, installation, servicing, documentation, verification and validation . This introduced the rules: "fit for purpose" and "do it right the first time". It includes the regulation of the quality of raw materials, assemblies, products and components; services related to production; and management, production, and inspection processes. </li></ul><ul><li>One of the most widely used paradigms for QA management is the PDCA (Plan-Do-Check-Act) approach, also known as the Shewhart cycle </li></ul>Designed by Artyom Rozumenko www.BugHuntress.com
Quality Control Quality Control is the most necessary inspection control of all in cases where, despite statistical quality control techniques or quality improvements implemented, sales decrease. The major problem which leads to a decrease in sales was that the specifications did not include the most important factor, “What the customer required”. The major characteristics, ignored during the search to improve manufacture and overall business performance were: - Reliability - Maintainability - Safety Designed by Artyom Rozumenko www.BugHuntress.com
Software Testing <ul><li>Software testing is used in association with verification and validation : </li></ul><ul><li> Verification : Have we built the software right (i.e., does it match the specification)? </li></ul><ul><li> Validation : Have we built the right software (i.e., is this what the customer wants)? </li></ul>Problem with software testing is that testing all combinations of inputs and preconditions is not feasible when testing anything other than a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, parafunctional dimensions of quality--for example, usability, scalability, performance, compatibility, reliability--can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another. Software testing may be viewed as an important part of the software quality assurance (SQA) process. In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in defect rate. What constitutes an acceptable defect rate depends on the nature of the software. An arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than software used to control an actual airliner. Although there are close links with SQA testing departments often exist independently, and there may be no SQA areas in some companies. Designed by Artyom Rozumenko www.BugHuntress.com
Static and Dynamic Testing www.BugHuntress.com Designed by Artyom Rozumenko Static testing is a form of software testing where the software isn't actually used. This is in contrast to dynamic testing . It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors. This type of testing can be used by the developer who wrote the code, in isolation. Code reviews , inspections and walkthroughs are also used. From the black box testing point of view, static testing involves review of requirements or specifications . This is done with an eye toward completeness or appropriateness for the task at hand. This is the verification portion of Verification and Validation . Bugs discovered at this stage of development are less expensive to fix than later in the development cycle. Dynamic testing (or dynamic analysis) is a term used in software engineering to describe the testing of the dynamic behavior of code. That is, dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time. In dynamic testing the software must actually be compiled and run; this is in contrast to static testing . Dynamic testing is the validation portion of Verification and Validation . Some of dynamic testing methodologies include unit testing , integration testing , system testing and acceptance testing . Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
Testing artifacts <ul><li>Test Plan </li></ul>A test plan is a systematic approach to testing a system. The plan typically contains a detailed understanding of what the eventual workflow will be. <ul><li>Test Case </li></ul>A test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied. www.BugHuntress.com Designed by Artyom Rozumenko <ul><li>Software Requirements Specification or SRS </li></ul>A Software Requirements Specification ( SRS ) is a complete description of the behavior of the system to be developed. It includes a set of use cases , functional requirements and non-functional requirements .
Test Plan www.BugHuntress.com Designed by Artyom Rozumenko <ul><li>Test plan template, based on IEEE 829 format </li></ul><ul><li>Test Plan Identifier (TPI). </li></ul><ul><li>References </li></ul><ul><li>Introduction </li></ul><ul><li>Test Items </li></ul><ul><li>Software Risk Issue </li></ul><ul><li>Features to be Tested </li></ul><ul><li>Features not to be Tested </li></ul><ul><li>Approach </li></ul><ul><li>Item Pass/Fail Criteria </li></ul><ul><li>Entry & Exit Criteria </li></ul><ul><li>Suspension Criteria and Resumption Requirements </li></ul><ul><li>Test Deliverables </li></ul><ul><li>Remaining Test Tasks </li></ul><ul><li>Environmental Needs </li></ul><ul><li>Staffing and Training Needs </li></ul><ul><li>Responsibilities </li></ul><ul><li>Planning Risks and Contingencies </li></ul><ul><li>Approvals </li></ul><ul><li>Glossary </li></ul>
Test Case www.BugHuntress.com Designed by Artyom Rozumenko <ul><li>Formal requirement-based test cases </li></ul><ul><li>Informal requirement-based test cases </li></ul>In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub-requirements. In that situation, each sub-requirement must have at least one test case. This is frequently done using a traceability matrix . Some methodologies, like RUP , recommend creating at least two test cases for each requirement. One of them should perform positive testing of requirement and other should perform negative testing. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted. What characterizes a formal, written test case is that there is a known input and an expected output , which is worked out before the test is executed. The known input should test a precondition and the expected output should test a postcondition . For application without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class . In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.
Test Case Test suite www.BugHuntress.com Designed by Artyom Rozumenko In software engineering , a test suite , also known as a validation suite , is a collection of test cases that are intended to be used as input to a software program to show that it has some specified set of behaviors. Test suites are used to group similar test cases together. A system might e.g. have a smoke test suite that consists only of smoke tests or a test suite for some specific functionality in the system. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. Collections of test cases are sometimes incorrectly termed a test plan . They may also be called a test script , or even a test scenario .
Test Case Examples www.BugHuntress.com Designed by Artyom Rozumenko <ul><li>Informal requirement-based test cases </li></ul><ul><li>Formal requirement-based test cases </li></ul>