Software Testing Question and Answers
( Suggestion : keep refreshing the page for updated content & Search Questions Using Find )
Q.1) (a) in a software testing project, the actual test execution results for Cycle 2 are as follows: Total test cases planned for Cycle 2- 120, Passed lest cases 90, Failed test cases 20, Deferred test cases 10. Calculate the test coverage percentage for Cycle 2 and identify the vanance between the actual and expected test coverage (04m)
(b) Describe the purpose and key components of a software project plan document in traditional project management methodologies (02m)
(c) Compare the approach to project documentation between traditional methodologies and Agile methodologies (02m)
(d) What sort of technical documents are required for software testing within Agile project management
Answer.
(a) Test Coverage Calculation: Test Coverage Percentage = (Passed Test Cases / Total Planned Test Cases) * 100 = (90 / 120) * 100 = 75%
Variance between Actual and Expected Test Coverage: Expected Test Coverage = 100% Variance = Expected Test Coverage – Actual Test Coverage = 100% – 75% = 25%
(b) Purpose and Key Components of a Software Project Plan Document: The purpose of a software project plan document in traditional project management methodologies is to provide a comprehensive roadmap for executing the project. Key components include:
- Project Scope: Defines the boundaries of the project, including objectives, deliverables, and constraints.
- Schedule: Outlines the timeline for project activities, milestones, and deadlines.
- Resource Allocation: Specifies the human, financial, and material resources needed for the project.
- Risk Management: Identifies potential risks to the project’s success and outlines strategies for mitigating them.
- Communication Plan: Describes how information will be disseminated among team members, stakeholders, and other relevant parties.
- Quality Assurance: Outlines the processes and procedures for ensuring the quality of the project deliverables.
- Change Management: Defines how changes to project scope, schedule, or requirements will be managed and approved.
(c) Approach to Project Documentation between Traditional Methodologies and Agile Methodologies: In traditional methodologies, project documentation is often extensive and detailed, covering all aspects of the project in a comprehensive manner. Documentation is typically created upfront and follows a predefined structure, with a focus on detailed planning and documentation.
In Agile methodologies, project documentation is more lightweight and iterative. The emphasis is on working software over comprehensive documentation, although some documentation is still necessary. Agile teams prioritize collaboration and communication, often using tools like user stories, sprint backlogs, and burndown charts to track progress and communicate project status.
(d) Technical Documents Required for Software Testing within Agile Project Management:
- User Stories: Descriptions of desired functionality from the end-user perspective, often including acceptance criteria for testing.
- Test Plans: High-level documents outlining the testing approach, objectives, and resources required for testing.
- Test Cases: Detailed descriptions of individual test scenarios, including inputs, expected outcomes, and execution steps.
- Test Scripts: Automated scripts for executing test cases and verifying software functionality.
- Defect Reports: Documentation of any issues or bugs discovered during testing, including steps to reproduce and severity level.
- Test Execution Reports: Summaries of test execution results, including pass/fail status and any relevant metrics or observations.
- Regression Test Suites: Collections of test cases designed to ensure that new changes do not negatively impact existing functionality.
Q.2) (a) Write down the object oriented testing methodology for bank account with the following classes open the account, deposit funds, withdraws funds and closes the account. The states of the account include
open with positive balance, open with negative or zero balance and closed How the methods behave depends of the state of the account?
With reference to the above case study, develop test cases for the following condition.
An account with a zero or negative balance will not allow the customer to withdraw funds If positive it might allow customer to go to overdraft once. You could introduce a new method to determine the if the account is open or closed and if balance is positive
(b) Explain Architecture and components of Test Automation with a diagram
Answer.
(a) Object-Oriented Testing Methodology for Bank Account:
1. **Classes**:
– OpenAccount
– DepositFunds
– WithdrawFunds
– CloseAccount
2. **States of the Account**:
– Open with a positive balance
– Open with a negative or zero balance
– Closed
3. **Behavior of Methods based on Account State**:
– **OpenAccount**: Initializes the account with a positive balance. Should not allow opening an account with a negative or zero balance.
– **DepositFunds**: Adds funds to the account. Can be called regardless of the account state.
– **WithdrawFunds**: Deducts funds from the account. If the account is open with a zero or negative balance, withdrawal should not be allowed. If the account is open with a positive balance, it may allow withdrawal even if it leads to an overdraft.
– **CloseAccount**: Closes the account. Can be called regardless of the account state.
4. **Test Cases**:
– **Test Case 1**:
– Scenario: Attempting to open an account with a negative or zero balance.
– Expected Result: Account should not be opened.
– **Test Case 2**:
– Scenario: Deposit funds into an account with a positive balance.
– Expected Result: Funds should be successfully deposited.
– **Test Case 3**:
– Scenario: Withdraw funds from an account with a positive balance.
– Expected Result: Withdrawal should be allowed, and the balance should reflect the deduction.
– **Test Case 4**:
– Scenario: Attempting to withdraw funds from an account with a zero or negative balance.
– Expected Result: Withdrawal should not be allowed.
– **Test Case 5**:
– Scenario: Attempting to close an account.
– Expected Result: Account should be successfully closed.
(b) **Architecture and Components of Test Automation**:
Test Automation Architecture typically consists of the following components:
1. **Test Scripts/Code**: These are the actual automated test cases written in a programming language using testing frameworks.
2. **Test Framework**: It provides the structure for test automation and includes libraries, utilities, and guidelines for writing and organizing test scripts. Examples include JUnit, NUnit, TestNG, and Robot Framework.
3. **Test Data**: Data required for test cases, including input values, expected outputs, and test configurations.
4. **Test Environment**: The hardware and software setup where testing is conducted. It may include servers, databases, browsers, operating systems, etc.
5. **Test Execution Engine**: This component executes the test scripts on the test environment and generates test reports.
6. **Test Management Tool**: Tools like JIRA, TestRail, or HP ALM are used to manage test cases, track defects, and generate reports.
Here’s a diagram illustrating the architecture:
+----------------------------------------+ | Test Automation Framework | +----------------------------------------+ | Test Scripts/Code | | | | Test Framework | | +---------------+ | | | Test Data | | | +---------------+ | | | | Test Execution Engine | | +---------------+ | | | Test Environment| | | +---------------+ | | | | Test Management Tool | +----------------------------------------+
In this architecture, test scripts are written using a test framework, which utilizes test data to perform tests. These tests are executed by the test execution engine on the test environment. Test results are then managed and reported using a test management tool.
Q.3) (a) Suppose you are tasked with estimating the number of test cases required to adequately test a new e-commerce websites checkout process. The checkout process involves multiple steps, including adding items to the cart, entering shipping and billing information, selecting payment methods, and confirming the order. Based on your analysis, you have identified the following test scenarios : 1. Add item to cart, 2 Remove item from cart Edit item quantity in cart, 4. Enter valid shipping information 5. Enter invalid shipping information, 6. Enter valid billing information 7. Enter invalid billing information, 8. Select credit card payment method 9. Select PayPal payment method & 10. Confirm order Each test scenario can have multiple test cases associated with it to cover different test conditions and inputs. You estimate that on average, each test scenario will require around 5 test cases to adequately cover all relevant test conditions. Based on this estimation, how many total test cases would you estimate are needed to thoroughly test the checkout process?
(b) What are the different estimation methods available for software project and testing?
(c) Can we use all the software project estimation techniques for sizing software testing efforts?
(d) List key attributes or columns in the test cycle report and test summary report?
Answer.
(a) To estimate the total number of test cases needed to thoroughly test the checkout process, we can multiply the number of test scenarios by the estimated average number of test cases per scenario:
Total Test Cases = Number of Test Scenarios * Average Test Cases per Scenario
Given:
Number of Test Scenarios = 10
Average Test Cases per Scenario = 5
So, Total Test Cases = 10 * 5 = 50
Therefore, an estimated 50 test cases would be needed to thoroughly test the checkout process.
(b) Different estimation methods available for software project and testing include:
1. Expert Judgment: Involves consulting with experts in the domain to estimate the effort required.
2. Analogous Estimation: Relies on historical data from similar projects to estimate the effort required for the current project.
3. Parametric Estimation: Uses mathematical models based on project parameters to estimate effort and resources required.
4. Bottom-Up Estimation: Breaks down the project into smaller tasks and estimates effort for each task, then aggregates to get overall effort.
5. Three-Point Estimation (PERT): Involves estimating optimistic, pessimistic, and most likely scenarios to calculate a weighted average.
(c) While many software project estimation techniques can be adapted for estimating testing efforts, some may not directly apply due to the unique nature of testing. For instance, while expert judgment, analogous estimation, and parametric estimation can be used for testing effort estimation, methods like Function Point Analysis might not be as suitable since it’s primarily aimed at sizing software based on functional requirements rather than testing effort.
(d) Key attributes or columns in the test cycle report and test summary report may include:
Test Cycle Report:
1. Test Case ID
2. Test Scenario
3. Test Description
4. Test Steps
5. Expected Results
6. Actual Results
7. Pass/Fail Status
8. Defect ID (if applicable)
9. Test Environment
10. Test Execution Date/Time
Test Summary Report:
1. Project Name
2. Test Phase (e.g., System Testing, Integration Testing)
3. Total Test Cases Executed
4. Total Passed
5. Total Failed
6. Pass Percentage
7. Defect Summary
8. Severity of Defects
9. Test Coverage
10. Recommendations/Conclusion
Q.4) (a) For the below faulty program, which includes test inputs that result in failure. Answer the following question about program
1.Explain what is wrong with the given code: Describe the fault precisely by proposing a modification to the code
2.If possible, give a test case that does not execute the fault. If not, briefly explain why not.
3.If possible, give a test case that executes the fault, but does not result in an error state. If not, briefly explain why not.
4.If possible, give a test case that results in an error state, but not a failure. Hint. Don’t forget about the program counter if not, briefly explain why not.
5.For the given test case, describe the first error state. Be sure to describe the complete state.
Java Program : /*Find last index of zero *@param x array to search *@return last index of 0 in x, -1 if absent *@throws NullPointerException if x is null */ public static int lastZero (int[] x) { for (int i=0;i<x.length; i++) { if (x[i]==0) { return i; } } return -1; } // test: x = [0, 1, 0]; Expected=2 //Book website: LastZero java //Book website: LastZeroTest java
Answer.
1. **Explanation of Fault:**
The issue with the given code lies in its logic for finding the last index of zero in the array. The function `lastZero` only returns the index of the first occurrence of zero instead of the last. This is because it returns immediately when it finds the first zero in the array. To fix this, the loop should continue until the end of the array to find the last occurrence of zero.
Proposed Modification:
public static int lastZero(int[] x) {
int lastIndex = -1; // Initialize to -1 to indicate zero not found
for (int i = 0; i < x.length; i++) {
if (x[i] == 0) {
lastIndex = i; // Update lastIndex whenever zero is found
}
}
return lastIndex;
}
2. **Test Case Without Fault:**
Test Case: `x = [1, 2, 0, 3, 0]`
Expected Output: 4
Explanation: In this test case, the array contains two zeros at index 2 and index 4. The modified function should correctly return the index of the last occurrence of zero, which is 4.
3. **Test Case Executing Fault Without Error State:**
It’s not possible to construct a test case that executes the fault (returning the first occurrence instead of the last) without resulting in an error state because the fault lies in the core logic of the function. Once fixed, the function will behave as intended without error.
4. **Test Case Resulting in Error State but not Failure:**
There is no test case that results in an error state without causing a failure because the error (returning the first occurrence of zero instead of the last) directly affects the correctness of the function. Any input where the last zero is not at the end of the array would cause the function to return an incorrect result.
5. **Description of First Error State:**
In the initial faulty implementation, considering the test case `x = [0, 1, 0]`, the first error state occurs when the function returns 0 instead of 2. The complete state includes:
– Input Array: `x = [0, 1, 0]`
– Index Returned: `0` (Incorrect, should be `2`)
– Expected Output: `2`
Q.5) (a)Describe the role of functional and non-functional testing.
(b) List Non Functional Testing Types?
(c) Consider an Internet banking application implemented for XYZ Bank. List and explain at least 5 critical Non Functional testing to be performed In the priority order. Justify why they were critical.
Answer.
(a) Functional testing focuses on verifying that the software functions correctly according to the specified requirements, while non-functional testing evaluates aspects like performance, usability, reliability, and security.
(b) Non-functional testing types include:
- Performance testing
- Usability testing
- Security testing
- Reliability testing
- Compatibility testing
- Scalability testing
- Maintainability testing
- Portability testing
(c) Critical non-functional testing for an Internet banking application at XYZ Bank:
- Security Testing: Given the sensitivity of financial data, ensuring robust security measures like encryption, authentication, and authorization is paramount. Any vulnerabilities could lead to unauthorized access, data breaches, and financial losses.
- Performance Testing: This ensures that the application can handle expected user loads without slowdowns or crashes. With Internet banking, users expect quick response times, especially during peak usage periods. Performance issues could lead to frustration, customer dissatisfaction, and even financial losses if transactions fail or are delayed.
- Usability Testing: A user-friendly interface is essential for customer satisfaction and retention. Usability testing ensures that the application is intuitive, easy to navigate, and accessible to users of varying technical abilities. Poor usability could lead to abandoned transactions, increased support requests, and a negative reputation for XYZ Bank.
- Reliability Testing: Customers rely on Internet banking services for timely access to their financial information and transactions. Reliability testing assesses the system’s ability to consistently perform as expected under normal and stressful conditions. Failures or downtime could erode trust in XYZ Bank’s services and drive customers to competitors.
- Compatibility Testing: This ensures that the Internet banking application functions correctly across different devices, browsers, and operating systems. With users accessing banking services from various platforms, ensuring compatibility is crucial for providing a seamless experience. Incompatibility issues could lead to usability problems, customer complaints, and ultimately, loss of business for XYZ Bank.
For More Updates Join Our Channels :
