Estimation

1. How to do the estimation in testing? Answer: we have a standard template where we divide our testing time into X number of parts. Then determine the testing part based on the use cases. 2. How to estimate a new application? Answer: If you haven't used these scenarios before, and no historical data or experience for those scenarios available, best way is to take some samples and run them to measure the time. 3. How to estimate automation time? Answer: 1. Time taken for tool evaluation and feasibility 2. Time taken for development of a utility function * number of functions 3. Total number of test cases/steps divided by test cases /steps that you can automate in a single day. 4. How to estimate a scenario? Answer: 1 - You look at how long these scenarios took last time 2 - You look at how long these testers took last time for something similar 3. And of course my guess because I know to do validation checking of a field in DM5 takes 1/2 hr so if there were 15 fields in that profile then would take an average tester 7 and ½ hrs. 4. Manual and automation testing should be taken into account also. 5. Basic structure of the Test Case Point analysis? Answer: TCP Analysis uses a 7-step process consisting of the following stages: 1. Identify Use Cases 2. Identify Test Cases 3. Determine TCP for Test Case Generation This includes designing well-defined test cases. The deliverables here are only the test cases. 4. Determine TCP for Automation This execution model includes only automating the test cases using an automated test tool. The deliverables include the tool-generated scripts 5. Determine TCP for Manual Execution This execution model only involves executing the test cases already designed and reporting the defects. 6. Determine TCP for Automated Execution This phase includes the execution of the automated scripts and reporting the defects. 7. Determine Total TCP

Use Cases
1. What do you mean by use cases? Answer: People like stories, and from one point of view, use cases are simply stories about how people (or other things) use a system to perform some task. Each use case has pre-conditions, which need to be met for the use case to work successfully. For example, a withdrawal cannot be made without an open bank account and without a working

automated teller machine (ATM). Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. For example, after a withdrawal the account balance is expected to be debited by the withdrawn amount, and the ATM should be available and ready for the next transaction. A use case usually has a mainstream, most likely scenario, such as the successful withdrawal of funds from an ATM. The use case may also contain alternative branches, such as the disapproval of a withdrawal because (A) the user’s bank card is unrecognized, (B) there is insufficient cash in the ATM, or (C) there are insufficient funds in the bank account. Shows the process flow from real worlds point of view or how uses are going to interact with the system. 2. Write down use cases for ATM cash withdraw. 3. What are the steps involve in use case designs? 4. VSNL login use case?

Team motivation
1. How to motivate your team? Answer: 1. Appreciate good work in time and in a specific way. Kunal you gave me the report, which saves my time. Thanks you. Do it in public. 2. Give focus when something good is done. Mail to manager and copy that guy. 3. Give them the feelings how important role they are playing. Say 2 and ½ billion dollar business testing is depending on us. 4. Team lunch. 2. How to handle team conflict? Answer: 1. Create a contract between the team members stating the team rules. If a single field issue shows up every body will take the responsibility not a single person and blame each other. Once in every 15 days go out side for lunch. 2. Attack the problem, not the person. 3. Focus on what can be done, not on what can't be done. 4. Encourage different points of view and honest dialogue. 5. Express your feelings in a way that does not blame. 6. Accept ownership for your part of the problem. 7. Listen to understand the other person's point of view before giving your own. 8. Show respect for the other person's point of view. 9. Solve the problem while building the relationship.

Sign up to vote on this title
UsefulNot useful