Subjective Q&A - 1 to 5

1. Give three examples from IT organization where Pareto analysis of 80:20 holds good.
  1. Defect Analysis
  2. Failures found in production
  3. Cycle/Delivery Time reduction
  4. Employee Satisfaction/Dissatisfaction
  5. Customer Satisfaction/Dissatisfaction
  6. Help Desk problems
The process for using Pareto charts is described in the following steps:
  1. Define the problem clearly using any of the tools from Quality Toolbox (e.g., Use brainstorming, affinity diagrams, or cause-and-effect diagrams)
  2. Collect a sufficient sample size of data over the specified time, or use historical data, if available
  3. Sort the data in descending order by occurrence or frequency of causes characteristics
  4. Construct the Pareto Chart and draw bars to correspond to the sorted data in descending order, where the “x” axis is the problem category and the “y” axis is frequency
  5. Determine the vital few causes on which to focus improvement efforts
  6. Compare and select major causes, repeating the process until the problem’s root causes are reached sufficiently to resolve the problem
2. List down some Standard Helpdesk problem.
  1. Terminal kbd locked
  2. Terminal 123x is hung
  3. Terminal shows no cursor on the screen
  4. Unable to start session
  5. Unable to print from E-mail
  6. Terminal 324x can’t access menu
  7. Model X printer not printing
  8. System logs user off
  9. Unable to print reports
  10. Terminal 789x unable to logon
  11. Transactions abending
  12. System drops session
  13. Unable to get out of application
  14. System accepts invalid data
  15. Unable to connect with host
  16. Users cannot catalog
  17. Cannot log on to e-mail
  18. Users hung in application
  19. User unable to access printer
  20. System sends error xxx
  21. Not able to logon to the system
  22. Printer not working
  23. Email server Down
  24. Hung system (Machine not responding)
  25. Keyboard/Mouse not working
3. You have been asked by a systems development project leader for your help in developing a test plan. The project leader wants to know what should be included in a test plan. He has asked you to develop a brief table of contents for a test plan. What would you include in that table of contents and why?

Test Plan Template, according IEEE 829 standards
  1. Test Plan Identifier
  2. References
  3. Introduction
  4. Test Items
  5. Software Risk Issues
  6. Features to be Tested
  7. Features not to be Tested
  8. Approach
  9. Item Pass/Fail Criteria
  10. Suspension Criteria and Resumption Requirements
  11. Test Deliverables
  12. Remaining Test Tasks
  13. Environmental Needs
  14. Staffing and Training Needs
  15. Responsibilities
  16. Schedule
  17. Planning Risks and Contingencies
  18. Approvals
  19. Glossary
4. What are the steps that you would follow while doing Regression testing?
Or
The code has been given for regression testing. Write the process to be followed.

In simple,
  1. Identify the areas that are not changed
  2. Select the type of regression testing that needs to be done i.e unit regression, regional or full regression
  3. Determine if regression testing would be done with downstream applications
  4. Check the availability of budget, resource, time
  5. Select the testcases
  6. Use a tool to expedite regression testing (if available)
  7. Execute the testcases
  8. In case any defects are observed, close it asap.
Risk-based Test Case Selection for regression testing

Risk-based Test Selection approach has four main steps.
Step 1: Estimate the cost for each test case:
Cost is categorized on a one to five scale, where one is low and five is high. Two kinds of costs will be taken into consideration:
1) The consequences of a fault as seen by the customer, for example, losing market share because of faults,
2) The consequences of a fault as seen by the vendor, for example, high software maintenance costs because of faults.

Step 2: Derive severity probability for each test case:
For each test case, we compute severity probability depending on the number of defects and the severity of defects. Severity probability falls into a zero to five scale, where zero is low and five is high.
Step 3: Calculate Risk Exposure for each test case:
Risk Exposure is the multiplication of Cost and severity probability. To enhance or focus the results, we can also add weights to test cases that we need to give preference to.
Step 4: Select test cases that have the highest values of Risk Exposure as Safety Tests (Safety Tests check that serious failures do not occur).

Risk-based Test Scenario Selection

Since end-to-end scenarios involve many components of the system working together, they are highly effective at finding regression faults. Our selection strategy obeys two rules:
R1: Select scenarios to cover the most critical test cases.
R2: Ensure scenarios cover as many test cases as possible.
Based on a traceability matrix showing the relation between end-to-end test scenarios and test cases, our risk-based test scenario selection approach also has four main steps.
Step 1: Calculate Risk Exposure REs for each scenario:
Using the traceability matrix, we can simply calculate the Risk Exposure for each scenario by summing up the Risk Exposure for all test cases that this scenario covers.
Step 2: Select the scenario with highest REs
Step 3: Update the traceability matrix (remove selected scenarios and covered test cases, and re-calculate REs):
When running the chosen scenario, all test cases covered by the scenario will be executed. According to our selection rules, these test cases should not affect our selection any more. We should focus on those test cases that have not yet been executed. In our approach, we cross out the column for the chosen scenario, and rows for all the test cases covered by the scenario. All of this is easily automated.
Step 4: Repeat Steps 2 and 3 as desired.

5. What are the phases involved in SDLC? What, when, where and why do QA and Testers play a role in these phases.

First point refers to Tester role & second - QA
• Initiation
. Provide input for estimating testing efforts
QA-Kickoff meeting participation; Giving Process training to the team;
• Definition
Review of functional requirement document
Design test strategy
QA-Req Review; Project Plan Review; Giving Tailoring Guidance
• System Design
Review of system design doc, interface agreement doc etc
QA-Design Review
• Programming & Training
Test plan/specification preparation
Preparation of Test Data
Preparation of Test environment
QA-Test Plan Review; Oversee Code reviews; Ensure proper collection of review data & other metrics
• Evaluation & Acceptance
Perform various validation activities like integration testing, system testing
Test manager: oversees acceptance testing
Tracking defects
QA-Oversee integration & system testing according to the standard processes
• Installation & Operation
o Ensure properly tested code is shifted to production
QA-Ensuring Formal project closure & project data is submitted to Organizations Process Database

Role of QA other than those in SDLC(in general):
  • Developing policies, procedures and standards
  • Acquiring and implementing tools and methodologies
  • Marketing creating awareness of quality programs and concepts
  • Measuring quality
  • Defining, recording, summarizing and presenting analyses
  • Performing process analysis (statistical process control)

0 Comments:

Post a Comment

<< Home