SOFTWARE Testing Introduction UNIT I

SOFTWARE Testing Introduction UNIT I

process of executing a program with the intent of finding errors
Software Testing process of executing a program with the intent of finding errors

Software Testing Consumes at least half of the labor
Process of testing software product Contribute to Delivery of higher quality product More satisfied users Lower maintenance cost More accurate and reliable results

TERMINOLOGY Error Fault/Defect Failure Incident Test Test Case

Error People make errors. Typographical error
Misreading of a specification Misunderstanding of functionality of a module A good Synonym is Mistake. When people make mistakes while coding we call these mistakes “bugs”

Fault/Defect Representation of an error DFD Hierarchy chart
Source Code An error may lead to one or more faults Fault of Omissions If certain specifications have not been programmed Fault of Commission If certain program behavior have not been specified

Fault/Defect.. Defects generally fall into one of the following three categories Wrong Missing Extra

Failure, Incident Incident Failure
A particular fault may cause different failures, depending on how it has been exercised Incident When a failure occurs, it may or may not readily apparent to the user Incident is the symptom associated with a failure that alerts the user to the occurrence of a failure

Test, Test Case Test: Test Case:
A test is the act of exercising S/W with test cases Test Case: A test case has an identity and is associated with a program behaviour It has a set of inputs and a list of expected outputs

Test Case Template Test Case ID: Section –I (Before Execution)
Section –II (After Execution) Purpose: Execution History: Pre Condition: (If Any) Result: Inputs: If Fails, any possible reason(Optional): Expected Outputs: Any Other observation: Post Conditions: Any Suggestions: Written by: Run By: Date:

S/W Testing Testing is the process of demonstrating that errors are not present The purpose of testing is to show that a program performs its intended functions correctly Testing is the process of establishing confidence that a program does what it is supposed to do Testing is the process of executing a program with the intent of finding errors

Limitation of Testing Can we test the program completely? Some text
Many managers Test coverage analyzer Salesperson Some tester No matter how hard we try, how cleverly we plan, how much time we spend, and how many staff and computer we use, we still cannot do enough testing. We still miss bugs

Testing Principles: Myers
A necessary part of a test case is a definition of the expected output or result A programmer should avoid testing his or her own program A programming organization should not test its own programs Thoroughly test the results of each test Test cases must be written for invalid and unexpected, as well as valid and expected input conditions.

Testing Principles: Myers
Examining a program to see if it does not do what it is supposed to do is only half of the battle. The other half is seeing whether the program does what it is not supposed to do. Avoid throw-away test cases unless the program is truly a throw-away program. Do not plan testing effort under the tacit assumption that no errors will be found. The probability of existence of more errors in a section of a program is proportional to the number of errors already found in the section

Testing Cost Curve

Testing Life Cycle

Testing Life Cycle.. Three phases Putting Bugs IN
Testing Phase Finding Bugs Last Three phases are Getting Bugs OUT The fault resolution step is another opportunity for errors. When a fix causes formerly correct software to misbehave, the fix is deficient.

Testing Process Testing Process Test Planning Test Case Development
Running Test Cases Evaluating Test results

Venn Diagram to show relationship between the set T of test cases and the sets S and P of specified and implemented behaviors. P S T The goal of tester is to make the region where these sets all intersect as large as possible

Verification & Validation
Traditionally testing used to be an End-of-the-development-cycle activity With Life-Cycle testing model there is a requirement to test deliverables of each phase. The associated activities can be classified as Verification & Validation. Thus, software testing is essentially the verification and validation processes put together. Both the processes are complementary in nature and provide their own set of error filters

Verification Verification: Are we building the product right?
Static and proactive in nature (QA). Checks if product (result of a particular phase of SDLC) conforms with its specifications. Is static in nature. Involves manual checking, doesn’t include execution of code. The target documents are Req. Specs., HLD, DB Design The methods used are Inspection, Walkthrough etc.

Validation Validation: Are we building the right product?
Dynamic and reactive in nature (QC). Checks the software to insure it meets customer’s requirements. Is dynamic in nature. Involves execution of code. The target could be a component, module, a set of integrated modules or system as a whole. The methods used are Black box, white box testing etc.

Verification & Validation
Verify Req Specs HLD (High Level Design) Verify Verify Detailed Design Code Verify & Validate Integration Prototyping Model -> Validation at Req Specs stage Verify & Validate System Testing UAT (User acceptance Testing)

Verification and Validation: IEEE
Verification: The process of evaluating a system or component to determine whether the products…satisfy the conditions imposed… Validation: The process of evaluating a system or component…to determine whether it satisfies specified requirements.

Verification vs. Validation
Verification ensures that the system complies with an organization’s standards and processes, relying on review or non-executable methods Did we build the right system? Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated Did we build the system right?

V Model The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

V Model The V-model deploys a well-structured method
where each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore Saves a huge amount of the project time and thus helps in cost reduction Assures better validation Assures involvement of people with appropriate skills.

V Model

V Model The V-Model further promotes the notion of early test preparation. finds faults in baselines and is an effective way of detecting faults early The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing.

V Model: Problems Derivative of Waterfall model => no provision for increments V Model focuses on specific dynamic test stages And has no mention of the effectiveness of static tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle. No mention of important activities like: Planning Post implementation maintenance Testing Quality Control

Modified V Addresses the parallelism in S/W development and accommodates incremental development. Introduces concept where development products go through phases of testing Each unit/component/module is given an entry / exit criteria to go through a testing stage The components that satisfy the entry criteria are moved into the corresponding testing phase The components that satisfy the exit criteria are moved out of the current testing phase

W Model W-Model focuses on the development products themselves and utilizes static testing techniques to verify intermediate deliverables. Essentially, every development activity that produces a work product is shadowed by a test activity. The purpose of the test activity specifically is to determine whether the objectives of a development activity have been met and the deliverable meets its requirements. The W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective.

W Model

Objectives In general, the objective is to insure that the product satisfies the user needs. The discovery of defects in a system The assessment of whether or not the system is usable in operational situations.

Verification Techniques

Techniques Inspection Walkthrough Pass-around Desk Checks
Pair Programming

Verification Techniques…
Inspections

Review Techniques… …Walkthrough

Walkthroughs A walkthrough is an informal way of presenting a technical document in a meeting. The author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product. After the meeting, the author should follow up with individual attendees who may have had additional information or insights. The walkthrough is preceded by preparation by designers/developers Lists of items Items not understood Items that appear to be incorrect

Managing walkthroughs
Document driven Person responsible for document walks the reviewers through the document Reviewers interrupt with comments triggered by the presentation Interactive process Not to be used for the evaluation of participants

Participants & Entry Criteria
The author selects the participants in a walkthrough. No specific roles are assigned. Entry Criteria The author selects a walkthrough review approach for the product being reviewed. The author has stated his objectives for the review.

Tasks & Responsibilities
Responsible Select review participants, obtain their agreement to participate, and schedule a walkthrough meeting. Author Distribute work product to reviewers prior to the meeting. Describe the work product to the reviewers during the meeting in any appropriate way. Lead discussion on the topics of interest or concerns about the work product. Present comments, possible defects, and improvement suggestions to the author. Reviewers Based on reviewer comments, perform any necessary rework of the work product.

Deliverables, Verification, Exit-Criteria
Modified work product Verification No verification of rework is required. Changes are made at the author’s discretion. Exit-Criteria The author has made any appropriate changes in the work product.

Inspection Vs. Walkthroughs
Adv. Circulation of Documents Not Required Yes Adv. Preparation by reviewers No Presentation in the meeting by Authors Readers

Inspection Vs. Walkthroughs
Rigor Informal to formal Formal Purpose Judge quality, find defects, training Measure/improve quality of product and process Effectiveness Low to medium Low to very high, depending on training and commitment

…Passaround

Participants & Entry-Criteria
The author selects the participants in a passaround. No specific roles are assigned. However, it can be beneficial to ask individual reviewers to examine the work product from specific perspectives like: checking internal cross-references, confirming interface definitions, checking conformance to standards, or identifying grammatical and typographical errors. Entry Criteria The author selected a passaround review approach. The author has stated his objectives for the review. The document has been spell-checked.

Responsible Either distribute a physical or electronic copy of the work product to each reviewer, or create a file to which all reviewers have read/write access. Author Notify reviewers that work product is available and indicate the date by which review comments are to be provided. Either hand-write comments directly on the work product, or enter comments into the work product file, using a revision marks convention or an annotation feature of the tool being used. If working with an individual copy of the work product, deliver the work product with comments to the author after completing the review. Reviewers

Responsible After the final date of the review period, remove work product from the shared file location and examine added comments. Author Based on reviewer comments, perform any necessary rework of the work product. If a shared file was used to accumulate comments, delete each comment from the work product as it is resolved. Leave any comments that require discussion in the work product until agreement is reached on actions to be taken.

Deliverables, Verification, Exit-Criteria
Modified work product Verification No verification of rework is required. The author is responsible for making appropriate decisions on issues and for correctly performing any rework. Exit-Criteria The author has addressed all review issues raised..

Code Review

Code Review A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved For example, it could be made more readable or its performance could be improved

Good candidates for code review
A portion of the software that only one person has the expertise to maintain Code that implements a highly abstract or tricky algorithm An object, library or API that is particularly difficult to work with Code written by someone who is inexperienced or has not written that kind of code before, or written in an unfamiliar language Code which employs a new programming technique An area of the code that will be especially catastrophic if there are defects

Checklist for Code Review: Example
Data declaration All variables declared? Default values understood? Arrays and strings initialized? Variables with similar names? Correct initialization? Control flow Each loop terminates? DO/END statements match? Input/output OPEN statements correct? Format specification correct? End-of-file case handled?

Deskchecks

Deskchecks A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. The author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author.

Deskchecks Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference. Deskchecks can be used as predecessors to inspections. In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection.

Pair Programming

Types of Review: Pair Programming
Pair programming is a technique in which two programmers work simultaneously at a single computer and continuously review each others’ work. Although many programmers were introduced to pair programming as a part of Extreme Programming, it is a practice that can be valuable in any development environment. Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software.

Types of Review: Pair Programming
In pair programming, two programmers sit at one computer to write code. Generally, one programmer will take control and write code, while the other watches and advises. Some teams have found that pair programming works best for them if the pairs are constantly rotated; this helps diffuse the shared knowledge throughout the organization. Others prefer to pair a more junior person with a more senior for knowledge sharing. The project manager should not try to force pair programming on the team; it helps to introduce the change slowly, and where it will meet the least resistance. It is difficult to implement pair programming in an organization where the programmers do not share the same nine-to-five (or ten-to-six) work schedule. Some people do not work well in pairs, and some pairs do not work well together.

Overview of Graph Theory in ST.
Cyclomatic complexity is a source code complexity measurement that is being correlated to a number of coding errors. It is calculated by developing a Control Flow Graph of the code that measures the number of linearly-independent paths through a program module. Lower the Program's cyclomatic complexity, lower the risk to modify and easier to understand. It can be represented using the below formula:

Cyclomatic complexity = E - N + 2*P
where, E = number of edges in the flow graph. N = number of nodes in the flow graph. P = number of nodes that have exit points

SRS Verification It is highly recommended to review or verify the SRS documents before start writing test cases 1. Correctness of SRS should be checked. 2. Ambiguity should be avoided. 3. Requirements should be complete. 4. Consistent requirements. 5. Verification of expected result: 6. Testing environment: 7. Pre-conditions defined clearly: 8. Security and Performance criteria: 9. Deletion of irrelevant requirements: 10. Freeze requirements:

Software Design Document Verification
Software Design Specification is a written description of a software product, that a software designer writes in order to give a software development team overall guidance to the architecture of the software project. Software Design Verification check list Unambiguous Correct Complete Consistent Testability

Constraints Task Preconditions Task Inputs Task Outputs/Deliverables Software Design Verification Methods Inspection Analysis Demonstration Test

User Documentation Verification
Technical writers prepare documents for different types of users. Typically, there are five basic types of user documents: Description Document System Installation Document System Configuration Document User Manual Systems Reference documentation.

User Document Verification Check List
• Audience • Terminology • Content and subject matter – Appropriate subjects covered? – No subjects missing? – Proper depth? – Missing features described accidentally? Just the facts Step by step • Figures and screen captures • Samples and examples • Spelling and grammar

Software Project Audits

Cont… An analogy for this could be Traffic Rules.
Just because a rash driver failed to observe traffic rule & reaches home safely does not mean traffic rules is unnecessary. Therefore a active effort is needed to ensure compliance to the defined process. The basic purpose of AUDIT is to ensure compliance to the defined process.

Cont… Audits are essential part of Quality Assurance KPA of Level 2
It is also a requirement of ISO 9000 Quality System There are many ways of Organizing AUDIT in an Organization.

Audit Process Auditing is a systematic & independent examination of various activities of project execution. It is intended to determine compliance with the quality system of a organization Its main focus is on implementing the process of an Organization. It is also used to determine the effectiveness of a process & to identify area of Improvement.

Cont… Audit can be Internal or External
External Audit is generally employed for some type of certification Internal audit is conducted by the Organization using people of the Organization. The primary goal is to ensure compliance with Organization’s process & help in process improvement.

Cont… To ensure reasonable degree of compliance with the defined process, audit must be done regularly. The people performing audit could be member of SEPG (Software Engineering Process Group) or person who has maturity & stature to assess the implementation on a project objectively. It could also be performed by other project members.

Cont… When others perform Audit, they can learn & give advice.
Since they become “Law Keepers” they also respect & appreciate “Law”. The Audit activity has three components: Planning Auditing Follow-up

Planning Before audits are conducted, they must be carefully planned to achieve optimal result. Planning of Audit operates at three level: Strategy High-level plan Detailed schedule.

Auditing A team of two people normally conduct the internal Audit who are selected from auditor’s pool. Auditor’s pool is a set of people who are trained to conduct audit. One standby Auditor is also selected A remainder is sent to Auditors & project Leaders, whose project will be Audited, one day before the audit begins.

Cont… On the day of audit, auditors meet the Quality advisor associated with the project to get views about the process used in the project The team plans out its audit strategy What question to ask Who will they interview What artifacts are needed In actual audit, the auditors focus more attention on whether the defined process is followed in the project. A check list can also be used

Sample checklist Project Planning Checklist
Is the project plan documented in the standard project plan template? Has the project plan been group reviewed? Has the project plan been approved & baselined? Is it under configuration management? Is there a signed Contract? Have the commitments to the customers or other group been reviewed?

Follow-up The audit report & NCR’s (nonconformance report) are sent to the coordinator of audits, who is a member of SEPG, at the end of AUDIT. For each NCR, corrective action are taken. The audit coordinator get approved from the auditors for each corrective action taken. An audit may also reveal weakness in process In such cases, the auditors may recommend modification to SEPG team.

Audit Analysis The data from audit of different project together offer valuable data about the state of the implementation of the process across the organization. These data can be very useful in analyzing the effectiveness of the processes and offer scope for improvement. Summaries are produced for: Number of Audits scheduled vs number conducted. Total no of NCR given Closer date of NCR Distribution of NCR by severity These summaries yield information about the health of the audit system and seriousness with which it is conducted. Its also offers visibility into the implementation of audit process.

SWOT Analysis Dr. Shivendra Goel Associate Professor,
Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi.

SWOT Analysis

Strengths High Professional Level and good patience to understand the problems of my students. Many Research papers in IEEE and other international Conferences and Journals Assistant Editor of BIJIT, International Journal of Information Technology by Springer. Reviewer of many international Journals Holds a Ph.D degree in Computer Science. A Good Teacher based on students feedback as I understood. Score:8

Weaknesses Helping in nature. Trust people easily. Family dependency.
Score:5

Opportunities Working with a brand name(Bharati Vidyapeeth’s)
Availability of resources to work with. Organizational and staff Support. Family support. Score:7.5

Threats Some of the students don't wants to do study due to their family business etc. Some times such students create nuisance in class room Additional Duties other than teaching and research etc. Score: 5

Overall Score STRENGTHS 8 WEAKNESSES 5 OPPORTUNITIES 7.5 THREATS
Total Score Positive

SOFTWARE Testing Introduction UNIT I

Similar presentations

Presentation on theme: "SOFTWARE Testing Introduction UNIT I"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SOFTWARE Testing Introduction UNIT I

Similar presentations

Presentation on theme: "SOFTWARE Testing Introduction UNIT I"— Presentation transcript:

Similar presentations

About project

Feedback