Week 4 - Answers to the Weekly Exercises

Question 2 Answers:

Here are the most appropriate black box testing techniques for testing the given requirements:

1. "The valid values for the gender code are 'M' or 'F'."
   Equivalence Partitioning: Divide the input domain into equivalence classes, which in this case would be 'M', 'F', and invalid inputs. Test cases should include one valid input from each class and one invalid input.
2. "The number of days of leave per year an employee is eligible is 10 for the first three years, 15 for the next two years, and 20 from then on."
   Boundary Value Analysis: Test the boundary values for each range of years. Test cases would include inputs for the first three years (9, 10, 11), the next two years (14, 15, 16), and beyond (19, 20, 21).
3. "Each purchase order must be initially approved by the manager of the employee and the head of purchasing. Additionally, if it is a capital expense of more than $10,000, it should also be approved by the CFO."
   Decision Table Testing: Create a decision table with conditions (manager approval, head of purchasing approval, capital expense threshold) and actions (approval by CFO). Test various combinations of conditions to ensure that the correct actions are taken.
4. "A file name should start with an alphabetic character, can have up to 30 alphanumeric characters, optionally one period followed by up to 10 other alphanumeric characters."
   State Transition Testing: Model the valid and invalid states of the file name based on the requirements. Test cases should include valid transitions (e.g., starting with an alphabetic character, including a period) and invalid transitions (e.g., starting with a numeric character, exceeding character limits).
5. "A person who comes to the bank to open the account may not have his birth certificate in English; in this case, the officer must have the discretion to manually override the requirement of entering the birth certificate number."
   Error Guessing: Develop test cases based on intuition and experience, anticipating potential error scenarios where birth certificates might not be in English and the officer needs to override the requirement. This technique relies on the tester's judgment and domain knowledge.

Question 3 Answers:

When deleting an element from a linked list, the boundary value conditions typically revolve around the position of the element to be deleted within the list. Here are some boundary value conditions and test data to consider:

1. Deleting the first element:
   Test deleting the first element in the list.
   Test deleting the first element in a list with only one element.
2. Deleting the last element:
   Test deleting the last element in the list.
   Test deleting the last element in a list with only one element.
3. Deleting an element in the middle:
   Test deleting an element from the middle of the list.
   Test deleting an element from a list with an odd number of elements.
   Test deleting an element from a list with an even number of elements.
4. Boundary conditions:
   Test deleting an element at index 0 (the first element).
   Test deleting an element at the last index (size - 1) of the list.
   Test deleting an element at an index just before and just after the midpoint of the list (if applicable).
   Test deleting an element at an index just before and just after the boundary (start or end) of the list.
5. Testing for errors:
   Test deleting from an empty list.
   Test deleting an element that does not exist in the list.

Question 4 Answers:

To calculate the number of configurations for exhaustive testing, you multiply the number of options for each component:

• Operating System: 2 options (Windows, Linux)
• Web Server: 2 options (IIS 5.0, Apache)
• Database: 2 options (Oracle, SQL Server)
• Browser: 2 options (IE 6.0, Firefox)

Exhaustively testing all 16 combinations might not be practical due to time and resource constraints. To prune the list and prioritize testing efforts, you can use techniques like:

1. Risk-based Testing: Identify which combinations are more likely to cause issues based on factors like customer usage patterns, criticality of functionalities, and historical data.
2. Equivalence Partitioning: Group configurations into equivalence classes based on similarities and differences. For example, you might find that testing on different web servers (IIS vs. Apache) may introduce different challenges, so it's important to cover at least one configuration from each group.
3. Pairwise Testing: Instead of testing all possible combinations, focus on testing pairs of components together. Pairwise testing aims to cover the most likely interactions between components while minimizing the number of test cases needed.
4. Use Case Prioritization: Prioritize testing based on common usage scenarios or critical functionalities of the application. Test configurations that are most likely to be encountered by users or that are critical to the application's functionality.

Question 5 Answers:

Testing different types of documentation requires various skill sets and expertise. Here's a breakdown of the skill sets required for testing different types of documents and who would be best equipped to perform each type of testing:

1. Installation Document:
   Skill Sets: Understanding of installation procedures, technical proficiency related to the product's environment, ability to follow and verify step-by-step instructions, attention to detail.
   Who: Quality Assurance Engineers or Testers with technical backgrounds, experience in system administration, or familiarity with software installation processes.
2. Administration Document:
   Skill Sets: Knowledge of system administration tasks related to the product, understanding of configuration settings, security considerations, troubleshooting procedures, ability to verify administrative tasks described in the document.
   Who: Technical writers with expertise in system administration, domain experts in the product's technology, or QA Engineers with experience in system administration tasks.
3. User Guide:
   Skill Sets: Understanding of end-user perspectives and needs, ability to communicate complex concepts in simple terms, clarity in writing and instructions, usability testing skills, empathy towards user experience.
   Who: Technical writers specializing in user documentation, UX/UI designers, QA Engineers with a focus on usability testing, or individuals with strong communication skills and a user-centric mindset.
4. Integration Guides/Developer Documentation:
   Skill Sets: Understanding of software development concepts, knowledge of APIs, SDKs, and integration methodologies, ability to provide code samples and examples, proficiency in technical writing.
   Who: Technical writers with software development backgrounds, developers familiar with the product's APIs and integration points, QA Engineers with experience in API testing and integration testing.
5. Compliance and Regulatory Documentation:
   Skill Sets: Knowledge of industry regulations and compliance standards, attention to detail, ability to ensure that documentation adheres to legal and regulatory requirements.
   Who: Technical writers with expertise in compliance and regulatory documentation, legal experts or compliance officers familiar with industry standards and regulations, QA Engineers with experience in compliance testing.

Question 6 Answers:

To identify the set of equivalence classes for testing the requirement that an input value for a product code in an inventory system is expected to be present in a product master table, we can consider the following equivalence classes:

1. Valid Product Codes:
   Product codes that exist in the product master table.
   These are the primary valid inputs that the system should accept.
2. Invalid Product Codes:
   Product codes that do not exist in the product master table.
   These inputs should be rejected by the system.
3. Boundary Cases:
   An empty product code field.
   A product code with the maximum allowed length.
   Special characters or symbols in the product code (if applicable).
4. Edge Cases:
   Product codes with leading and trailing spaces.
   Product codes with mixed cases (if case sensitivity is a factor).
   Product codes containing both numeric and alphabetic characters.
   Product codes containing alphanumeric characters along with special characters.
5. Null or Missing Values:
   Testing scenarios where the product code input is null or missing.
   These scenarios should be handled appropriately by the system.
6. Multiple Valid Product Codes:
   Test cases where multiple valid product codes are input simultaneously, either comma-separated or in another format if applicable.
7. Database Constraints:
   Test cases that check how the system handles database constraints related to product codes, such as unique constraints.

Question 7 Answers:

Partitioning the output space into equivalence classes can be particularly useful in scenarios where the output of a system or function falls into distinct categories or classes. Here are some situations where equivalence classes can be obtained by partitioning the output classes:

1. Error Handling and Exception Cases:
   When the system encounters errors or exceptions, the output space can be partitioned into different classes based on the type or nature of the error.
   Equivalence classes can be formed for different error codes, error messages, or error handling behaviors.
2. Validation Results:
   Outputs from validation processes, such as data validation or user input validation, can be partitioned into classes based on the validation result.
   Equivalence classes can include valid inputs, invalid inputs of different types (format, range, etc.), and borderline cases that trigger specific validation rules.
3. Response Codes or Status Codes:
   Systems often return response codes or status codes to indicate the outcome of operations.
   Equivalence classes can be formed for different response codes (e.g., success, failure, warning) or status codes (e.g., pending, processing, completed).
4. Transaction States:
   In systems that involve transactions or workflows, the output space may include different states or stages of the transaction process.
   Equivalence classes can be defined for various transaction states, such as initiated, in progress, completed, canceled, or failed.
5. Authorization and Access Control:
   Outputs related to authorization and access control mechanisms can be partitioned into classes based on the user's privileges or permissions.
   Equivalence classes can include authorized access, unauthorized access, access with different levels of permissions, and access denied due to various reasons (e.g., authentication failure, insufficient privileges).
6. Output Data Formats:
   In systems that generate output data in different formats (e.g., JSON, XML, CSV), the output space can be partitioned into classes based on the format of the output data.
   Equivalence classes can be formed for each output data format, along with considerations for data structure, encoding, and compliance with standards.

Question 8 Answers:

To derive initial test cases for the given requirements, we can utilize state transition diagrams and other techniques such as boundary value analysis and equivalence partitioning. Here's how we can approach it:

State Transition Diagram:
Let's outline the states and transitions based on the given requirements:

1. Initial State (S0): No statement has been entered.
2. Table Name Entered (S1): The CREATE TABLE statement has been started with a table name.
3. Column List Entered (S2): The open parenthesis has been entered, and the column list is being provided.
4. Column Identifier Entered (S3): Parsing through column identifiers.
5. Final State (S4): Statement is complete.

• S0 -> S1: Upon entering "CREATE TABLE <table name>"
• S1 -> S2: Upon entering an open parenthesis "("
• S2 -> S3: Upon entering column identifiers
• S3 -> S2: Upon entering another column identifier or moving to the final state
• S3 -> S4: Upon completing the column list

1. Boundary Value Analysis:
   -Test with the minimum and maximum length table names.
   -Test with the minimum and maximum length column names.
   -Test with the minimum and maximum length column width.
   -Test with each valid column type (NUMER, CHAR, DATE).
   -Test with invalid column types.
2. Equivalence Partitioning:
   -Equivalence classes for column types: NUMER, CHAR, DATE.
   -Equivalence classes for table names: valid and invalid.
   -Equivalence classes for column names: valid and invalid.
   -Equivalence classes for column width: valid and invalid.
3. State Transition Testing:
   -Verify the transition from S0 to S1 by entering a valid table name.
   -Verify the transition from S1 to S2 by entering an open parenthesis.
   -Verify the transition from S2 to S3 by providing valid column identifiers.
   -Verify the transition from S3 to S2 by adding another column identifier or moving to S4 upon completion.
   -Verify the final state S4.