(Stanford users can avoid this Captcha by logging in.)

  • Send to text email RefWorks EndNote printer

Case study research in software engineering : guidelines and examples

Available online.

  • Safari Books Online

More options

  • Find it at other libraries via WorldCat
  • Contributors

Description

Creators/contributors, contents/summary.

  • FOREWORD xiii PREFACE xv ACKNOWLEDGMENTS xvii PART I CASE STUDY METHODOLOGY
  • 1 INTRODUCTION 3 1.1 What is a Case Study? 3 1.2 A Brief History of Case Studies in Software Engineering 5 1.3 Why a Book on Case Studies of Software Engineering? 6 1.4 Conclusion 9
  • 2 BACKGROUND AND DEFINITION OF CONCEPTS 11 2.1 Introduction 11 2.2 Research Strategies 11 2.3 Characteristics of Research Strategies 13 2.3.1 Purpose 13 2.3.2 Control and Data 14 2.3.3 Triangulation 15 2.3.4 Replication 16 2.3.5 Inductive and Deductive Enquiries 16 2.4 What Makes a Good Case Study? 17 2.5 When is the Case Study Strategy Feasible? 19 2.6 Case Study Research Process 20 2.7 Conclusion 21
  • 3 DESIGN OF THE CASE STUDY 23 3.1 Introduction 23 3.2 Elements of the Case Study Design 24 3.2.1 Rationale for the Study 24 3.2.2 Objective of the Study 24 3.2.3 Cases and Units of Analyses 26 3.2.4 Theoretical Framework 29 3.2.5 Research Questions 30 3.2.6 Propositions and Hypotheses 31 3.2.7 Concepts 32 3.2.8 Methods of Data Collection 32 3.2.9 Methods of Data Analysis 33 3.2.10 Case Selection 33 3.2.11 Selection of Data 35 3.2.12 Data Definition and Data Storage 36 3.2.13 Quality Control and Assurance 36 3.2.14 Maintaining the Case Study Protocol 37 3.2.15 Reporting and Disseminating the Case Study 38 3.3 Legal, Ethical, and Professional Issues 40 3.4 Conclusion 45
  • 4 DATA COLLECTION 47 4.1 Introduction 47 4.2 Different Types of Data Source 47 4.2.1 Classification of Data Sources 47 4.2.2 Data Source Selection 49 4.3 Interviews 50 4.3.1 Planning Interviews 50 4.3.2 The Interview Session 52 4.3.3 Postinterview Activities 53 4.4 Focus groups 54 4.5 Observations 56 4.6 Archival Data 57 4.7 Metrics 58 4.8 Conclusion 60
  • 5 DATA ANALYSIS AND INTERPRETATION 61 5.1 Introduction 61 5.2 Analysis of Data in Flexible Research 62 5.2.1 Introduction 62 5.2.2 Level of Formalism 64 5.2.3 Relation to Hypotheses 65 5.3 Process for Qualitative Data Analysis 65 5.3.1 Introduction 65 5.3.2 Steps in the Analysis 66 5.3.3 Techniques 68 5.3.4 Tool support 70 5.4 Validity 71 5.4.1 Construct Validity 71 5.4.2 Internal Validity 71 5.4.3 External Validity 71 5.4.4 Reliability 72 5.5 Improving Validity 72 5.6 Quantitative Data Analysis 74 5.7 Conclusion 76
  • 6 REPORTING AND DISSEMINATION 77 6.1 Introduction 77 6.2 Why Report and Disseminate 78 6.3 The Audience for the Report 79 6.4 Aspects of the Case Study to Report and Disseminate 80 6.5 When to Report and Disseminate 81 6.6 Guidelines on Reporting 82 6.6.1 The Generic Content of an Academic Report 82 6.6.2 Reporting Recommendations from Evaluative Case Studies 84 6.6.3 Reporting to Stakeholders, Including Sponsor(s) 85 6.6.4 Reporting the Context of the Case Study 87 6.6.5 Reporting to Students 89 6.6.6 Ad Hoc and Impromptu Reporting 90 6.7 Formats and Structures for a Report 91 6.8 Where to Report 94 6.9 Ethics and Confidentiality 94 6.10 Conclusion 95
  • 7 SCALING UP CASE STUDY RESEARCH TO REAL-WORLD SOFTWARE PRACTICE 97 7.1 Introduction 97 7.2 The Aims of Scaling up Case Studies 98 7.3 Dimensions of Scale 99 7.4 Longitudinal Case Studies 100 7.5 Multiple Case Studies 102 7.5.1 Multiple Cases and Replications 102 7.5.2 Selecting the Cases 104 7.6 Multiresearcher Case Studies 105 7.7 Conclusion 107
  • 8 USING CASE STUDY RESEARCH 109 8.1 Introduction 109 8.2 Reading and Reviewing Case Studies 109 8.2.1 Development of Checklists 110 8.2.2 Checklists for Conducting Case Study Research 111 8.2.3 Checklists for Reading and Reviewing Case Studies 111 8.2.4 Development of Practice 111 8.3 Identifying and Synthesizing Use Case Research 111 8.3.1 Identifying Primary Studies 112 8.3.2 Synthesis of Evidence from Multiple Case Studies 113 8.3.3 Current State of Synthesis 117 8.4 The Economics of Case Study Research 118 8.4.1 Costs and Benefits of Evaluation Techniques 119 8.4.2 Evaluation of the DESMET Methodology 119 8.4.3 Frameworks for Organizing Methods of Evaluation 119 8.5 Specializing Case Study Research for Software Engineering 121 8.5.1 The Longitudinal Chronological Case Study Research Strategy 122 8.5.2 Controlled Case Studies 123 8.6 Case Studies and Software Process Improvement 123 8.7 Conclusion 125 PART II EXAMPLES OF CASE STUDIES
  • 9 INTRODUCTION TO CASE STUDY EXAMPLES 129 9.1 Introduction 129
  • 10 CASE STUDY OF EXTREME PROGRAMMING IN A STAGE-GATE CONTEXT 133 10.1 Introduction 133 10.1.1 Methodological Status 133 10.2 Case Study Design 134 10.2.1 Rationale 134 10.2.2 Objectives 134 10.2.3 Cases and Units of Analysis 135 10.2.4 Theoretical Frame of Reference 136 10.2.5 Research Questions 136 10.3 Planning 136 10.3.1 Methods of Data Collection 136 10.3.2 Selection of Data 137 10.3.3 Case Selection Strategy 137 10.3.4 Case Study Protocol 137 10.3.5 Ethical Considerations 137 10.4 Data Collection 139 10.5 Data Analysis 139 10.5.1 Threats to Validity 144 10.6 Reporting 144 10.6.1 Academics 144 10.6.2 Practitioners 144 10.7 Lessons Learned 146
  • 11 TWO LONGITUDINAL CASE STUDIES OF SOFTWARE PROJECT MANAGEMENT 149 11.1 Introduction 149 11.2 Background to the Research Project 149 11.3 Case Study Design and Planning 150 11.3.1 Rationale 150 11.3.2 Objective 150 11.3.3 Definition of the Case 150 11.3.4 Units of Analyses 151 11.3.5 Theoretical Frame of Reference and Research Questions 151 11.3.6 Case Selection 151 11.3.7 Replication Strategy 152 11.3.8 Case Study Protocol 152 11.3.9 Quality Assurance, Validity, and Reliability 152 11.3.10 Legal, Ethical, and Professional Considerations 153 11.4 Data Collection 154 11.4.1 Sources of Data 154 11.5 Data Analysis 157 11.6 Reporting 159 11.6.1 Internal Reporting of Results 160 11.6.2 Dissemination of Artifacts 160 11.7 Lessons Learned 160
  • 12 AN ITERATIVE CASE STUDY OF QUALITY MONITORING 163 12.1 Introduction 163 12.2 Case Study Design 164 12.2.1 Objectives 164 12.2.2 Cases and Units of Analysis 165 12.2.3 Theoretical Frame of Reference 165 12.2.4 Research Questions 165 12.3 Planning 165 12.3.1 Methods of Data Collection 165 12.3.2 Case Selection Strategy 167 12.3.3 Case Study Protocol 167 12.3.4 Ethical Considerations 167 12.3.5 Data Collection 168 12.3.6 Exploratory Study 168 12.3.7 Confirmatory Study 168 12.3.8 Explanatory Study 168 12.4 Data Analysis 169 12.5 Reporting 169 12.6 Lessons Learned 169
  • 13 A CASE STUDY OF THE EVALUATION OF REQUIREMENTS MANAGEMENT TOOLS 171 13.1 Introduction 171 13.2 Design of the Case Study 172 13.2.1 Rationale 172 13.2.2 Objective 172 13.2.3 The Case and Its Context 173 13.2.4 The Units of Analyses 174 13.2.5 Theoretical Framework 175 13.2.6 Research Questions 175 13.2.7 Propositions, Concepts, and Measures 175 13.2.8 Case Study Protocol 175 13.2.9 Methods of Data Collection 176 13.2.10 Methods of Data Analysis 176 13.2.11 Case Selection Strategy 177 13.2.12 Data Selection Strategy 177 13.2.13 Replication Strategy 177 13.2.14 Quality Assurance, Validity, and Reliability 177 13.3 Data Collection 178 13.4 Data Analysis 179 13.5 Reporting and Dissemination 180 13.6 Lessons Learned 181
  • 14 A LARGE-SCALE CASE STUDY OF REQUIREMENTS AND VERIFICATION ALIGNMENT 183 14.1 Introduction 183 14.2 Case Study Design 184 14.2.1 Rationale 184 14.2.2 Objectives 184 14.2.3 Cases and Units of Analysis 185 14.2.4 Theoretical Frame of Reference 186 14.2.5 Research Questions 187 14.3 Planning 188 14.3.1 Methods of Data Collection 189 14.3.2 Case Selection Strategy 190 14.3.3 Selection of Data 191 14.3.4 Case Study Protocol 191 14.3.5 Ethical Considerations 192 14.4 Data Collection 192 14.5 Data Analysis 193 14.6 Lessons Learned 195 14.6.1 Effort Estimation Lessons 195 14.6.2 Design and Planning Lessons 196 14.6.3 Data Collection Lessons 197 14.6.4 Data Analysis Lessons 198 14.6.5 Reporting Lessons 199 14.6.6 A General Lesson 199 EPILOGUE 201 Appendix A: CHECKLISTS FOR READING AND REVIEWING CASE STUDIES 203 A.1 Design of the Case Study 203 A.2 Data Collection 204 A.3 Data Analysis and Interpretation 204 A.4 Reporting and Dissemination 204 A.5 Reader's Checklist 205 Appendix B: EXAMPLE INTERVIEW INSTRUMENT (XP) 207 Appendix C: EXAMPLE INTERVIEW INSTRUMENT (REVV) 209 Appendix D: EXAMPLE OF A CODING GUIDE 213 D.1 Coding Instructions 213 D.2 Codes 214 D.2.1 High Level Codes: Research Questions 214 D.2.2 Medium Level Codes: Categories 216 D.2.3 Coding Example 216 Appendix E: EXAMPLE OF A CONSENT INFORMATION LETTER 219 REFERENCES 221 INDEX 235.
  • (source: Nielsen Book Data)

Bibliographic information

Browse related items.

Stanford University

  • Stanford Home
  • Maps & Directions
  • Search Stanford
  • Emergency Info
  • Terms of Use
  • Non-Discrimination
  • Accessibility

© Stanford University , Stanford , California 94305 .

  • Trending Now
  • Foundational Courses
  • Data Science
  • Practice Problem
  • Machine Learning
  • System Design
  • DevOps Tutorial
  • Software Testing Tutorial
  • What is Software Testing?
  • Principles of software testing - Software Testing
  • Software Development Life Cycle (SDLC)
  • Software Testing Life Cycle (STLC)
  • Types of Software Testing
  • Levels of Software Testing
  • Test Maturity Model - Software Testing

SDLC MODELS

  • Waterfall Model - Software Engineering
  • Spiral Model - Software Engineering
  • What is a Hybrid Work Model?
  • Prototyping Model - Software Engineering
  • SDLC V-Model - Software Engineering

TYPES OF TESTING

  • Manual Testing - Software Testing
  • Automation Testing - Software Testing

TYPES OF MANUAL

  • White box Testing - Software Engineering
  • Black box testing - Software Engineering
  • Gray Box Testing - Software Testing

White Box Techniques

  • Data Flow Testing
  • Control Flow Software Testing
  • Branch Software Testing
  • Statement Coverage Testing
  • Code Coverage Testing in Software Testing

BLACK BOX Techniques

  • Decision Table Based Testing in Software Testing
  • Pairwise Software Testing
  • Cause Effect Graphing in Software Engineering
  • State Transition Testing
  • Software Testing - Use Case Testing

TYPES OF BLACK BOX

  • Functional Testing - Software Testing
  • Non-Functional Testing

Types of Functional

  • Unit Testing - Software Testing
  • Integration Testing - Software Engineering
  • System Testing

Types of Non-functional

  • Performance Testing - Software Testing
  • Usability Testing
  • Compatibility Testing in Software Engineering

Test case development

  • Testing Documentation - Software Testing
  • How to write Test Cases - Software Testing

Testing Techniques

  • Error Guessing in Software Testing
  • Equivalence Partitioning Method
  • Software Testing - Boundary Value Analysis

Test Management

  • Test plan - Software Testing
  • Software Testing - Test Case Review
  • Requirements Traceability Matrix - RTM

Defect Tracking

  • Bugs in Software Testing
  • Bug Life Cycle in Software Development
  • Severity in Testing vs Priority in Testing
  • Test Environment: A Beginner's Guide
  • Defect Management Process

Other types of Testing

  • Regression Testing - Software Engineering
  • Smoke Testing - Software Testing
  • Sanity Testing - Software Testing
  • Software Testing | Static Testing
  • Dynamic Testing - Software Testing
  • Load Testing - Software Testing
  • What is Stress Testing in Software Testing?
  • Recovery Testing in Software Testing
  • Exploratory Testing
  • Visual Testing - Software Testing
  • Acceptance Testing - Software Testing
  • Alpha Testing - Software Testing
  • Beta Testing - Software Testing
  • Database Testing - Software Testing
  • Software Testing - Mainframe Testing
  • Adhoc Testing in Software
  • Globalization Testing - Software Testing
  • Mutation Testing - Software Testing
  • Security Testing - Software Testing
  • Accessibility Testing - Software Testing
  • Structural Software Testing
  • Volume Testing
  • Scalability Testing - Software Testing
  • Stability Testing - Software Testing
  • Spike Testing - Software Testing
  • Negative Testing in Software Engineering
  • Positive Testing - Software Testing
  • Endurance Testing - Software Testing
  • Reliability Testing - Software Testing
  • Monkey Software Testing
  • Agile Software Testing
  • Component Software Testing
  • Graphical User Interface Testing (GUI) Testing
  • Test Strategy - Software Testing
  • Software Testing Tools
  • Top 20 Test Management Tools
  • Defect Testing Tools - Software Testing
  • 7 Best Automation Tools for Testing
  • Top 10 Performance Testing Tools in Software Testing
  • Cross-Browser Testing Tools - Software Testing
  • Software Testing - Integration Testing Tool
  • Software Testing - Unit Testing Tools
  • Mobile Testing Tools - Software Testing
  • GUI Testing Tool
  • Security Testing Tools - Software Testing
  • Penetration Testing - Software Engineering

DIFFERENCES

  • Manual Testing vs Automated Testing
  • Difference between Load Testing and Stress Testing
  • Sanity Testing Vs Smoke Testing - Software Engineering
  • Difference between System Testing and Acceptance Testing
  • Quality Assurance (QA) vs Quality Control (QC)
  • Difference between Static and Dynamic Testing
  • Differences between Verification and Validation
  • Difference between Alpha and Beta Testing
  • Difference between Black Box Vs White Vs Grey Box Testing
  • Difference between Globalization and Localization Testing

Test Case vs Test Scenario

  • Test Strategy vs Test Plan
  • Software Testing - Boundary Value Analysis vs Equivalence Partitioning
  • Difference between SDLC and STLC
  • Software Testing - Bug vs Defect vs Error vs Fault vs Failure
  • Differences between Testing and Debugging
  • Difference between Frontend Testing and Backend Testing
  • Difference between High Level Design(HLD) and Low Level Design(LLD)
  • Software Testing - BRS vs SRS
  • Difference between Positive Testing and Negative Testing
  • Difference between Top Down and Bottom Up Integration Testing
  • Difference between Use Case and Test Case
  • Difference between Monkey Testing and Gorilla Testing
  • Difference between Stubs and Drivers
  • Difference between Component and Unit Testing
  • Difference between Software Testing and Embedded Testing
  • Difference between GUI Testing and Usability Testing
  • Difference between Tester and SDET
  • Software Testing - Desktop vs Client-Server vs Web Application Testing
  • Active Software Testing
  • What is an API (Application Programming Interface)
  • Difference between End-to-end Testing and Unit Testing
  • Difference Between Object-Oriented Testing and Conventional Testing

How to write Test Cases – Software Testing

Software testing is known as a process for validating and verifying the working of a software/application. It makes sure that the software is working without any errors, bugs, or any other issues and gives the expected output to the user. The software testing process isn’t limited to finding faults in the present software but also finding measures to upgrade the software in various factors such as efficiency, usability, and accuracy. So, to test software the software testing provides a particular format called a Test Case . 

This article focuses on discussing the following topics in the Test Case:

What is a Test Case?

  • Test Case vs Test Scenario.
  • When do we Write Test Cases?
  • Why Write Test Cases?
  • Test Case Template.
  • Best Practice for Writing Test Cases.
  • Test Case Management Tools.
  • Formal and Informal Test Case.
  • Types of Test Cases.

A test case is a defined format for software testing required to check if a particular application/software is working or not. A test case consists of a certain set of conditions that need to be checked to test an application or software i.e. in more simple terms when conditions are checked it checks if the resultant output meets with the expected output or not. A test case consists of various parameters such as ID, condition, steps, input, expected result, result, status, and remarks.

Parameters of a Test Case: 

  • Module Name: Subject or title that defines the functionality of the test. 
  • Test Case Id: A unique identifier assigned to every single condition in a test case. 
  • Tester Name: The name of the person who would be carrying out the test. 
  • Test scenario: The test scenario provides a brief description to the tester, as in providing a small overview to know about what needs to be performed and the small features, and components of the test.  
  • Test Case Description: The condition required to be checked for a given software. for eg. Check if only numbers validation is working or not for an age input box. 
  • Test Steps: Steps to be performed for the checking of the condition. 
  • Prerequisite: The conditions required to be fulfilled before the start of the test process. 
  • Test Priority: As the name suggests gives priority to the test cases that had to be performed first, or are more important and that could be performed later. 
  • Test Data: The inputs to be taken while checking for the conditions. 
  • Test Expected Result: The output which should be expected at the end of the test. 
  • Test parameters: Parameters assigned to a particular test case. 
  • Actual Result: The output that is displayed at the end. 
  • Environment Information: The environment in which the test is being performed, such as the operating system, security information, the software name, software version, etc.  
  • Status: The status of tests such as pass, fail, NA, etc. 
  • Comments: Remarks on the test regarding the test for the betterment of the software. 

Below are some of the points of difference between a test case and a test scenario:

When do we Write Test Cases? 

Test cases are written in different situations:

  • Before development: Test cases could be written before the actual coding as that would help to identify the requirement of the product/software and carry out the test later when the product/software gets developed. 
  • After development: Test cases are also written directly after coming up with a product/software or after developing the feature but before the launching of a product/software as needed to test the working of that particular feature. 
  • During development: Test cases are sometimes written during the development time, parallelly. so whenever a part of the module/software gets developed it gets tested as well.   

So, test cases are written in such cases, as test cases help in further development and make sure that we are meeting all the needed requirements. 

Why Write Test Cases?   

Test cases are one of the most important aspects of software engineering, as they define how the testing would be carried out. Test cases are carried out for a very simple reason, to check if the software works or not. There are many advantages of writing test cases:

  • To check whether the software meets customer expectations: Test cases help to check if a particular module/software is meeting the specified requirement or not. 
  • To check software consistency with conditions: Test cases determine if a particular module/software works with a given set of conditions. 
  • Narrow down software updates: Test cases help to narrow down the software needs and required updates.
  • Better test coverage: Test cases help to make sure that all possible scenarios are covered and documented. 
  • For consistency in test execution: Test cases help to maintain consistency in test execution. A well-documented test case helps the tester to just have a look at the test case and start testing the application. 
  • Helpful during maintenance: Test cases are detailed which makes them helpful during the maintenance phase. 

Test Case Template

Let’s look at a basic test case template for the login functionality. 

  • The Test case template contains the header section which has a set of parameters that provides information about the test case such as the tester’s name, test case description, Prerequisite, etc. 
  • The body section contains the actual test case content, such as test ID, test steps, test input, expected result, etc. 

Below is the table that shows the basic template of a test case:

In the given template below it’s identifiable that the section from module name to test scenario is the header section while the table that lies below the test scenario (from test case ID to comments) is the body of the test case template.     

Here a test case template for login functionality has been created with its parameters and values. 

Test case template

Best Practice for Writing Test Case

There are certain practices that one could follow while writing the test cases that would be considered beneficial. 

  • Simple and clear: Test cases need to be very concise, clear, and transparent. They should be easy and simple to understand not only for oneself but for others as well. 
  • Maintaining the client/customer/end-user requirements must be unique : While writing the test cases, it’s necessary to make sure that they aren’t being written over and over again and that each case is different from the others. 
  • Zero Assumptions: Test cases should not contain assumed data, and don’t come up with features/modules that don’t exist. 
  • Traceability: Test cases should be traceable for future reference, so while writing it’s important to keep that in mind, 
  • Different input data: While writing test cases, all types of data must be taken into consideration. 
  • Strong module name: The module name should be self-explanatory while writing the test case.  
  • Minimal Description: The description of a test case should be small, one or two lines are normally considered good practice, but it should give the basic overview properly. 
  • Maximum conditions: All kinds of conditions should be taken into consideration while writing a test, increasing the effectiveness. 
  • Meeting requirements: While writing the test case the client/customer/end-user requirements must be met.
  • Repetitive Results: The test case must be written in such a way that it should provide the same result. 
  • Different Techniques: Sometimes testing all conditions might not be possible but using different testing with different test cases could help to check every aspect of a software. 
  • Create test cases with the end user’s perspective: Create test cases by keeping end-user in mind and the test cases must meet customer requirements.
  • Use unique Test Case ID: It is considered a good practice to use a unique Test Case ID for the test cases following a naming convention for better understanding.
  • Add proper preconditions and postconditions: Preconditions and postconditions for the test cases must be mentioned properly and clearly.
  • Test cases should be reusable: There are times when the developer updates the code, then the testers need to update the test cases to meet the changing requirements.
  • Specify the exact expected outcome: Include the exact expected result, which tells us what will be result of a particular test step.

Test Case Management Tools

Test management tools help to manage the test cases. These tools are automated tools that decrease the time and effort of a tester as compared to the traditional way. Some test case management tools include advanced dashboards, easier bug, and progress tracking as well as management, custom test case templates, integration of test cases, inviting guest testers, managing team requirements and plans, and much more.

Below are some of the test case management tools:

  • Testpad: Testpad is a simple tool that makes test case management easier. The software’s main motto says that it aims to find a bug that matters. A few features of Testpad include manual testing, reports of the test cases and software, dragging and dropping to make testing easier, inviting guest testers by email, building custom templates, and much more. 
  • TestCaseLab: TestCaseLab is easily manageable for the test cases and could swiftly integrate them with bug trackers. The features of TestCaseLab include Custom test cases, Test Runs, Integrations of test cases, Test Plans, tags and priority for test cases, search by name of test cases, description, tags, etc. 
  • TestRail: TestRail is another platform that aims to make test case management easier, it streamlines the software testing processes and along with more visibility into QA. The basic features of TestRail include management for test cases, plans, and runs, more test coverage, real-time insights into the QA progress, etc. 
  • TestLodge: TestLodge is a test case management tool that helps the entire team manage their requirements, test plans, test cases, and test runs all in one single place and with no user limit. The basic features of TestLodge include Test Plans, Test Runs, a Dashboard, a Test Suite, and many more.

Formal and Informal Test Case

  • Formal Test Cases: Formal test cases are test cases that follow the basic test case format. It contains the test case parameters such as conditions, ID, Module name, etc. Formal Test cases have set input data and expected results, they are performed as per the given order of steps. 
  • Informal Test Cases: Informal test cases are test cases that don’t follow the basic test case format. In these, as the tests are performed the test cases are written in real-time then pre-writing them, and the input and expected results are not predefined as well.

Types of Test Cases

  • Functionality Test Case: The functionality test case is to determine if the interface of the software works smoothly with the rest of the system and its users or not. Black box testing is used while checking for this test case, as we check everything externally and not internally for this test case. 
  • Unit Test Case: In unit test case is where the individual part or a single unit of the software is tested. Here each unit/ individual part is tested, and we create a different test case for each unit.  
  • User Interface Test Case: The UI test or user interface test is when every component of the UI that the user would come in contact with is tested. It is to test if the UI components requirement made by the user are fulfilled or not.  
  • Integration Test Case: Integration testing is when all the units of the software are combined and then they are tested. It is to check that each component and its units work together without any issues. 
  • Performance Test Case: The performance test case helps to determine response time as well as the overall effectiveness of the system/software. It’s to see if the application will handle real-world expectations. 
  • Database Test Case: Also known as back-end testing or data testing checks that everything works fine concerning the database. Testing cases for tables, schema, triggers, etc. are done. 
  • Security Test Case: The security test case helps to determine that the application restricts actions as well as permissions wherever necessary. Encryption and authentication are considered as main objectives of the security test case. The security test case is done to protect and safeguard the data of the software. 
  • Usability Test Case: Also known as a user experience test case, it checks how user-friendly or easy to approach a software would be. Usability test cases are designed by the User experience team and performed by the testing team. 
  • User Acceptance Test Case: The user acceptance case is prepared by the testing team but the user/client does the testing and review if they work in the real-world environment.   

Below is an example of preparing various test cases for a login page with a username and password.

Unit Test case: Here we are only checking if the username validates at least for the length of eight characters.

Here it is only checked whether the passing of input of thirteen characters is valid or not. So since the character word ‘geeksforgeeks’ is entered then the test is successful it would have failed for any other test case.  

  Functionality Test case: Here it is checked whether the username and password both work together on the login click.

Here it is being checked whether passing wrong and right inputs and if the login functionality is working or not, it’s showing login is successful for the right credentials and unsuccessful for the wrong ones, hence both tests have passed otherwise would have failed.

User Acceptance Test Case: Here the user feedback is taken if the login page is loading properly or not.

Here it is being checked in by clicking on the login button if the page is loaded and the ‘Welcome to login page’ message is displayed. The test has failed here as the page was not loaded due to a browser compatibility issue, it would have loaded if the test had passed. 

Please Login to comment...

Similar reads.

  • Manual Testing
  • Software Testing

advertisewithusBannerImg

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

IMAGES

  1. Case Study

    what is a case study in software engineering

  2. (PDF) Software Engineering Practice: A Case Study Approach

    what is a case study in software engineering

  3. 3 CASE STUDIES OF SOFTWARE ENGINEERING EXPLAINED

    what is a case study in software engineering

  4. PPT

    what is a case study in software engineering

  5. How to Customize a Case Study Infographic With Animated Data

    what is a case study in software engineering

  6. (PDF) Case studies for software engineers

    what is a case study in software engineering

VIDEO

  1. Software Architecture Case Study Overview

  2. T Level Student Placement Case Study

  3. Case Study

  4. Software Engineering

  5. Software Engineering- Use cases Identification

  6. Introduction to Software Engineering |3 rd Semester

COMMENTS

  1. CASE STUDY RESEARCH IN SOFTWARE ENGINEERING

    This book will help both experienced and novice case study researchers improve their research methodology. The authors provide comprehensive examples of case study research they, and others, have conducted. They also critique the examples. This is very useful for researchers wanting to undertake case study research and will help them to avoid ...

  2. Case Study Research in Software Engineering—It is a Case, and it is a

    1. Introduction. Case studies are common in software engineering, and guidelines have been provided, for example, byRuneson et al. [1].They based their definition of case study on definitions from other areas including the definitions byYin [2], Benbasat et al. [3] andRobson [4].Runeson et al. [1] define a case study as follows within software engineering - "Case study in software ...

  3. PDF Case Studies for Software Engineers

    Time Series Analysis. Ü The objective of time series analysis is to examine relevant "how" and "why" questions about the relationship of events over time. Ü Time series analysis can follow intricate patterns. Ü The more intricate the pattern, the firmer the foundation for conclusions of the case study.

  4. Guidelines for conducting and reporting case study research in software

    Case study is a suitable research methodology for software engineering research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims at providing an introduction to case study methodology and guidelines for researchers conducting case studies and ...

  5. PDF Tutorial: Case Studies in Software Engineering

    in software engineering. The term "case study" appears every now and then in the title of software engineer-ing research papers. However, the presented studies range from very ambitious and well organized studies in the field, to small toy examples that claim to be case studies.

  6. Case Study Research in Software Engineering: Guidelines and Examples

    Software engineering research has similar high-level objectives, that is, to better understand how and why software engineering should be undertaken and, with this knowledge, to seek to improve the software engineering process and the resultant software products. There are different taxonomies used to classify research in software engineering.

  7. Case Study Research in Software Engineering: Guidelines and Examples

    Based on their own experiences of in-depth case studies of software projects in international corporations, in this bookthe authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on thecase study research method.

  8. Case Study Research in Software Engineering: Guidelines and ...

    Description. Based on their own experiences of in-depth case studies of software projects in international corporations, in this book the authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on the case study ...

  9. computer-aided software engineering (CASE)

    CASE (computer-aided software engineering) is the use of a computer-assisted method to organize and control the development of software, especially on large, complex projects involving many software components and people. Using CASE allows designers, code writers, testers, planners, and managers to share a common view of where a project stands ...

  10. Case Study Research in Software Engineering

    2. Case Study • "Case study in software engineering is an empirical enquiry that draws on multiple sources of evidence to investigate one instance (or a small number of instances) of a contemporary software engineering phenomenon within its real-life context, especially when the boundary between phenomenon and context cannot be clearly specified" cf. Runeson et al., 2012 • A case ...

  11. Case Study Research in Software Engineering—It is a Case, and it is a

    To do so, we conducted a multiplecase study. Runeson et al. (2010) define a case study as an "empirical investigation of a software engineering phenomenon within its real-life context" where ...

  12. Case study research in software engineering : guidelines and examples

    Publisher's summary. Based on their own experiences of in-depth case studies of software projects in international corporations, in this bookthe authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on thecase ...

  13. Introduction to Software Engineering

    Software Engineering is a systematic, disciplined, quantifiable study and approach to the design, development, operation, and maintenance of a software system. There are four main Attributes of Software Engineering. Efficiency: It provides a measure of the resource requirement of a software product in an efficient way.

  14. A Case Study Project for Software Engineering Education

    This paper advocates the use of the "case study" approach to educating and training software engineers. After an account of the use of case studies in the education of professionals, there is a discussion of problems in educating software professionals and how a case teaching approach can be used to address these problems. The paper describes a project to develop a comprehensive and complete ...

  15. Use Case Diagrams

    A Use Case Diagram is a vital tool in system design, it provides a visual representation of how users interact with a system. It serves as a blueprint for understanding the functional requirements of a system from a user's perspective, aiding in the communication between stakeholders and guiding the development process.

  16. Computer Aided Software Engineering (CASE)

    Computer-aided software engineering (CASE) is the implementation of computer-facilitated tools and methods in software development. CASE is used to ensure high-quality and defect-free software. CASE ensures a check-pointed and disciplined approach and helps designers, developers, testers, managers, and others to see the project milestones during development.

  17. PDF Guidelines for conducting and reporting case study research in software

    the International Software Engineering Research Network and updated accordingly. This paper does not provide absolute statements for what is considered a "good" case study in software engineering. Rather it focuses on a set of issues that all contribute to the quality of the research. The minimum requirement for each issue must be judged in its

  18. Case Studies

    Case Studies. All of the case studies that are shown here are used in the book. I have deliberately not used a single case study throughout the book as there is no single example that can illustrate all of the topics covered in the book. ... This case study discusses the control software for a personal insulin pump, which is used by diabetics ...

  19. Case Study Research in Software Engineering: Guidelines and Examples

    Based on their own experiences of in-depth case studies of software projects in international corporations, in this book the authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on the case study research method.

  20. How to write Test Cases

    Module Name: Subject or title that defines the functionality of the test. Test Case Id: A unique identifier assigned to every single condition in a test case. Tester Name: The name of the person who would be carrying out the test. Test scenario: The test scenario provides a brief description to the tester, as in providing a small overview to know about what needs to be performed and the small ...

  21. SEA software to be tested as part of RN ASW Spearhead programme

    UK company Systems Engineering and Assessment (SEA) has been tasked to demonstrate a software application designed to enhance the performance of the UK Royal Navy's...