Subjective Q&A - 1 to 5
1. Give three examples from IT organization where Pareto analysis of 80:20 holds good.
- Defect Analysis
- Failures found in production
- Cycle/Delivery Time reduction
- Employee Satisfaction/Dissatisfaction
- Customer Satisfaction/Dissatisfaction
- Help Desk problems
- Define the problem clearly using any of the tools from Quality Toolbox (e.g., Use brainstorming, affinity diagrams, or cause-and-effect diagrams)
- Collect a sufficient sample size of data over the specified time, or use historical data, if available
- Sort the data in descending order by occurrence or frequency of causes characteristics
- 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
- Determine the vital few causes on which to focus improvement efforts
- Compare and select major causes, repeating the process until the problem’s root causes are reached sufficiently to resolve the problem
- Terminal kbd locked
- Terminal 123x is hung
- Terminal shows no cursor on the screen
- Unable to start session
- Unable to print from E-mail
- Terminal 324x can’t access menu
- Model X printer not printing
- System logs user off
- Unable to print reports
- Terminal 789x unable to logon
- Transactions abending
- System drops session
- Unable to get out of application
- System accepts invalid data
- Unable to connect with host
- Users cannot catalog
- Cannot log on to e-mail
- Users hung in application
- User unable to access printer
- System sends error xxx
- Not able to logon to the system
- Printer not working
- Email server Down
- Hung system (Machine not responding)
- Keyboard/Mouse not working
Test Plan Template, according IEEE 829 standards
- Test Plan Identifier
- References
- Introduction
- Test Items
- Software Risk Issues
- Features to be Tested
- Features not to be Tested
- Approach
- Item Pass/Fail Criteria
- Suspension Criteria and Resumption Requirements
- Test Deliverables
- Remaining Test Tasks
- Environmental Needs
- Staffing and Training Needs
- Responsibilities
- Schedule
- Planning Risks and Contingencies
- Approvals
- Glossary
Or
The code has been given for regression testing. Write the process to be followed.
In simple,
- Identify the areas that are not changed
- Select the type of regression testing that needs to be done i.e unit regression, regional or full regression
- Determine if regression testing would be done with downstream applications
- Check the availability of budget, resource, time
- Select the testcases
- Use a tool to expedite regression testing (if available)
- Execute the testcases
- In case any defects are observed, close it asap.
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