Software Testing Department of IT
Total Page:16
File Type:pdf, Size:1020Kb
Software Testing Department of IT Semester Code No. Subject No. SOFTWARE TESTING 18ITU27 (For the students admitted in the academic year 2016-2017 and VI onwards) Objective: To develop the skill of Software Testing. Knowledge on Software Testing and how to test the software at various levels. To inculcate knowledge on Software Testing Concepts. Unit No. Topics Hours Introduction to Testing: Principle of Testing- Context of Testing in Producing Software - A test Unit 1 in time-Test the test first-The end of pendulum- Putting all together- 14 Phases of Software project. Software development and Life cycle model: Quality Assurance and Control-Testing verification and validation- Process model to represent different phases-Life cycle model: Unit 2 15 Waterfall Model, Iterative Model or Spiral model- Rapid Application model and V model Prototyping . Testing Types White box testing (Static testing and Structural testing), Black box Unit 3 testing: What is testing? , Why testing is done? , When testing is done? 15 How testing is done? , Integration testing, Types of Integration testing, Scenario testing. System and Acceptance Testing Over View of System and Acceptance Testing-Why System Testing- Functional Vs Non Functional Testing-Functional Testing-Non Unit IV 14 Function Testing-Acceptance Testing- Performance Testing-Factors of testing-Methodology of testing- Tools of testing. Regression Testing What is Regression Testing- Types of Regression Testing - When Regression Testing is done- When Regression Testing is performed- Unit 5 14 Planning Regression Testing-Management of Regression Testing- Execution of Regression Testing- Reporting Regression Testing. 1 Software Testing Department of IT Text Books: 1. SrinivasanDesikan&Gopalswamy Ramesh, ―Software Testing Principles and Practices‖, Pearson Educatio,2006. Reference Books: 1. Renu Rajani, Pradeep Oak , ―Software Testing. – Effective Methods, Tools & Techniques‖ – Tata McGraw Hill. 2. Bob Hughes & Mike Cotterell, ―Software Project Management ―,4th ed, PHI. 3. Ron Patton,‖Software Testing‖ Second Edition, 2005 . 2 Software Testing Department of IT Software Testing Unit -1 Introduction to Testing SDLC: Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process. The following figure is a graphical representation of the various stages of a typical SDLC: Testing: This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing 3 Software Testing Department of IT only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. *Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. Testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements. Principles of Testing: 1. Testing shows presence of defects 2. Exhaustive testing is impossible 3. Early testing 4. Defect clustering 5. Pesticide paradox 6. Testing is context dependent 7. Absence of error – fallacy The common objective of testing is finding bugs as early as possible. And, once the bugs are fixed, make sure it is working as expected and not breaking any other functionality. To achieve these goals, seven basic principles are given for software testing − 4 Software Testing Department of IT 1. What Testing shows? Testing can show that defects are present but there is no way to prove that there is no defect in the product. Testing phases make sure that the application under test is working based on the given requirement and it helps to reduce the probability of undiscovered defects in the application. But, even if no defects are found, it does not mean that it is absolutely correct. We can assume that AUT is matching with our exit criteria and maintaining the requirements according to SRD. *System Requirements Document (SRD) The System Requirement Document (SRD) defines system level functional and performance requirements for a system. The SRD is derived from the Capability Development Document (CDD), Concept of Operations (CONOPS), system-level performance metrics, mission threads/use cases, and usage environment and is developed but by the program office. It should include a system level description of all software elements required by the preferred system concept. The SRD is developed during the Technology Maturation & Risk Reduction (TMRR) Phase but a draft SRD should be developed for the Analysis of Alternatives (AoA) in the Materiel Solutions Analysis (MSA) Phase. The SRD is used by the program office to provide more detailed requirements than what‘s provided in the CDD and is normally included in a solicitation package. The SRD should be finalized prior to contract award. [1] Standard: MIL-STD-961 ―Defense and Program-Unique Specifications Format and Content‖ – 9 Jan 2014 The SRD should be developed with feedback and input from the industrial base. Once the SRD is placed on contract, the contractor will further develop the specification and develop their own, more detailed requirements document; sometimes called a Weapons Systems Specification (WSS). 5 Software Testing Department of IT The term ―System Requirements Document‖ is a phrase commonly used to describe a software performance specification. If your acquisition is exclusively for software, you may call yours a ―System Performance Specification‖ or ―System Requirements Document‖. 2. Is Exhaustive Testing possible? 100% coverage or testing of all combinations of inputs and possible combinations are not possible except of trivial cases. Instead of exhaustive testing, risk analysis and priorities are used to define the scope of testing. Here, most of the real time scenarios can consider including most probable negative scenario as well. This will help us track the failure. 3. Early Testing Testing activities should start as soon as possible and be focused on defined objectives in Test Strategy and expected results. Early stage of testing helps to identify Requirement Defect or design level discrepancies. If these types of bugs are captured in initial stage, it helps us save time and is cost-effective too. The answer to why testing should start at an early stage is very simple – as soon as the SRD is received, the testers can analyze the requirement from the testing perspective and can notice a requirement discrepancy. 6 Software Testing Department of IT 4. Defect Clustering Based on previous product defect analysis, it can be said that most of the defects are identified from small set of modules which are critical for application. These modules can be identified based on complexity, different system interaction or dependency on different other modules. If testers can identify these crucial modules, they can focus more on these modules to identify all possible bugs. In a study, it is found that 8 out of 10 defects are identified from 20% functionality of AUT. 5. Pesticide Paradox What is pesticide paradox – if pesticides are frequently used on crops, there comes when the insects develop a certain kind of resistance and gradually the pesticides thus sprayed seem to be ineffective on the insects. The same concept is applicable on testing also. Here, insects are bugs while pesticides are test cases that are used to run again and again. If the same sets of test cases are executed again and again, these test cases become ineffective after certain timeframe and the testers will not be able to identify any new defect. To overcome these conditions, test cases should be revised and reviewed time to time and new and different test cases can be added. This will help in identifying new defects. 7 Software Testing Department of IT 6. Testing is Context Dependent This principle states that two different type of application can‘t be tested using same approach until both applications are of same nature. For example, if a tester uses the same approach for Web Based Application and Mobile Application, that is completely wrong and there is high risk of poor quality of product release. Testers should use different approaches, methodologies, techniques and coverage for different types and nature of applications. 8 Software Testing Department of IT *Context-driven testing: Context-driven testing is a model for developing and debugging computer software that takes into account the ways in which the programs will be used or are expected to be used in the real world. In order to successfully conduct this type of testing, software developers must identify the intended market and evaluate the environments in which people are likely to employ the product. Some adherents of context-driven testing call it a set of values rather than a process or technique. It revolves around the fact that software users are human beings with diverse preferences, needs, abilities and limitations. A program that works well for one person in a given situation might prove inadequate or inappropriate for another person or situation. For example, a word processor with mathematical symbols and a set of tools for positioning and manipulating them might be ideal for a college professor writing a physics textbook but cumbersome and annoying for a novelist. Conversely, a simple text editor may be preferred by the novelist but be rejected by the professor. 7. Absence of Error – Fallacy This principle states finding defects and fixing them until the application or system is stable, is time consuming and also eats up on the resources.