Testing. The Begining

12
Software Testing Beginning. www.BugHuntress.com Designed by Artyom Rozumenk

Transcript of Testing. The Begining

Page 1: Testing. The Begining

Software Testing Beginning.

www.BugHuntress.comDesigned by Artyom Rozumenko

Page 2: Testing. The Begining

EPIGRAPH

• If you want to ask something be sure that you can’t find answer yourself.

For searching answers you can use google.com, wikipedia.org

2

Designed by Artyom Rozumenko

www.BugHuntress.com

Page 3: Testing. The Begining

3

QA, QC and Testing• 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.

• Quality control or QC are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements.

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

Designed by Artyom Rozumenko

www.BugHuntress.com

Page 4: Testing. The Begining

Quality assurance• 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.

• One of the most widely used paradigms for QA management is the PDCA (Plan-Do-Check-Act) approach, also known as the Shewhart cycle

4

Designed by Artyom Rozumenko

www.BugHuntress.com

Page 5: Testing. The Begining

Quality Control

5

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

Page 6: Testing. The Begining

6

Software Testing

Software testing is used in association with verification and validation:• Verification: Have we built the software right (i.e., does it match the specification)?• Validation: Have we built the right software (i.e., is this what the customer wants)?

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

Page 7: Testing. The Begining

7

Static and Dynamic Testing

www.BugHuntress.comDesigned 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.

Page 8: Testing. The Begining

Testing artifacts

8

•Test PlanA test plan is a systematic approach to testing a system. The plan typically contains a detailed understanding of what the eventual workflow will be.

•Test CaseA 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.comDesigned by Artyom Rozumenko

•Software Requirements Specification or SRSA 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.

Page 9: Testing. The Begining

Test Plan

9www.BugHuntress.com

Designed by Artyom Rozumenko

Test plan template, based on IEEE 829 format1.Test Plan Identifier (TPI).2.References3.Introduction4.Test Items5.Software Risk Issue6.Features to be Tested7.Features not to be Tested8.Approach9.Item Pass/Fail Criteria10.Entry & Exit Criteria11.Suspension Criteria and Resumption Requirements12.Test Deliverables13.Remaining Test Tasks14.Environmental Needs15.Staffing and Training Needs16.Responsibilities17.Planning Risks and Contingencies18.Approvals19.Glossary

Page 10: Testing. The Begining

Test Case

10www.BugHuntress.com

Designed by Artyom Rozumenko

• Formal requirement-based test cases

• Informal requirement-based test cases

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.

Page 11: Testing. The Begining

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

11

Page 12: Testing. The Begining

Test Case Examples

www.BugHuntress.comDesigned by Artyom Rozumenko

12

• Informal requirement-based test cases

• Formal requirement-based test cases