Questions: 1. What is actual testing process in practical or company environment? 2. What is a Test Plan? What does it include?

The software test plan is the primary means by which software testers communicate to the product development team what they intend to do. The purpose of the software test plan is to prescribe the scope, approach, resource, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be preformed, the personnel responsible for each task, and the risks associated with the plan. The test plan is simply a by-product of the detailed planning process thats undertaken to create it. Its the planning that matters, not the resulting documents. The ultimate goal of the test planning process is communicating the software test teams intent, its expectations, and its understanding of the testing thats to be performed. The following are the important topics/guidelines, which helps in preparation of Test plan: High-Level Expectations The first topics to address in the planning process are the ones that define the test teams high-level expectations. They are fundamental topics that must be agreed to, by everyone on the project team, but they are often overlooked. They might be considered too obvious and assumed to be understood by everyone, but a good tester knows never to assume anything. People, Places and Things Test plan needs to identify the people working on the project, what they do, and how to contact them. The test team will likely work with all of them and knowing who they are and how to contact them is very important. Similarly, where documents are stored, where the software can be downloaded from, where the test tools are located, and so on need to be identified. Inter-Group Responsibilities Inter-Group responsibilities identify tasks and deliverables that potentially affect the test effort. The test teams work is driven by many other functional groups programmers, project manages, technical writers, and so on. If the responsibilities arent planned out, the project, specifically the testing, can become a worst or resulting in important tasks been forgotten. Test phases To plan the test phases, the test team will look at the proposed development model and decide whether unique phases, or stages, of testing should be performed over the course of the project. The test planning process should identify each proposed test phase and make each phase known to the project team. This process often helps the entire team from and understands the overall development model. Test strategy The test strategy describes the approach that the test team will use to test the software both overall and in each phase. Deciding on the strategy is a complex task one that needs to be made by very experienced testers because it can determine the successes or failure of the test effort. Bug Reporting

Exactly what process will be used to manage the bugs needs to be planned so that each and every bug is tracked, from when its found to when its fixed and never, ever forgotten. Metrics and Statistics Metrics and statistics are the means by which the progress and the success of the project, and the testing, are tracked. The test planning process should identify exactly what information will be gathered, what decisions will be made with them, and who will be responsible for collecting them. Risks and Issues A common and very useful part of test planning is to identify potential problem or risky areas of the project ones that could have an impact on the test effort. 3. What is test strategy? 4. If you have n requirements and you have less time how you do prioritize the requirements? 5. What is Smoke testing and Sanity testing?
SMOKE TESTING:

Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A smoke test is scripted, either using a written set of tests or an automated test A Smoke test is designed to touch every part of the application in a cursory way. Its shallow and wide. Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification). Smoke testing is normal health check up to a build of an application before taking it to testing in depth.
SANITY TESTING:

A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. A sanity test is usually unscripted. A Sanity test is used to determine a small section of the application is still working after a minor change. Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. Sanity testing is to verify whether requirements are met or not, checking all features breadth-first. 6. How do you find the regression scenario if a defect is fixed? 7. Tell about the responsibilities of you in your current project? 8. What is RTM, and how do you use it?

9. Explain SDLC and your involvement? 10. At what phase tester role starts? 11. What are non-functional requirements? 12. How can it be known when to stop testing? 13. Give an example of high priority and low severity, low priority and high severity? 14. What is difference between Performance Testing, Load Testing and Stress Testing? 15. In an application currently in production, one module of code is being modified. Is it necessary to re-test the whole application or is it enough to just test functionality associated with that module? 16. What is the most challenging situation you had during testing? 17. What are you going to do if there is no Functional Spec or any documents related to the system and developer who wrote the code does not work in the company anymore, but you have system and need to test? 18. How is the testing process in your company? 19. Tell me bug life cycle and management tool u used? 20. What do you observe the difference in QA testing and UAT testing? Answer: The formal testing done on the system to ensure that it satisfies the acceptance criteria before the system is put into production. [Most of the times it is done by users/clients]. It is the incremental process of approving or rejecting the system during development and maintenance. Acceptance Testing checks the system against the requirements of the user. It is done by real people using real data and real documents to ensure ease of use and functionality of systems. Users who understand the business functions run the tests as given in the acceptance test plans, including installation and Online help Hardcopies of user documentation are also being reviewed for usability and accuracy. The testers/users formally document the results of each test, and provide error reports, correction requests to the developers. 21. Have you faced problem of incomplete data for testing? How you managed to create your own data then? Share your simple tips and tricks to create or use test data. 22. On which basis we give priority and severity for a bug and give one example for high priority and low severity and high severity and low priority?

Answer: Always the priority is given by team leader or Business Analyst. Severity is given by the reporter of bug. For example, High severity: hardware bugs application crash. Low severity: User interface bugs. High priority: Error message is not coming on time, calculation bugs etc. Low priority: Wrong alignment, etc 23. What do you mean by reproducing the bug? If the bug was not reproducible, what is the next step? Answer: If you find a defect, for example click the button and the corresponding action didnt happen, it is a bug. If the developer is unable to find this behaviour he will ask us to reproduce the bug. In another scenario, if the client complaints a defect in the production we will have to reproduce it in test environment. If the bug was not reproducible by developer, then bug is assigned back to reporter or goto meeting or informal meeting (like walkthrough) is arranged in order to reproduce the bug. Sometimes the bugs are inconsistent, so that that case we can mark the bugs as inconsistent and temporarily close the bug with status working fine now. 24. What is the responsibility of a tester when a bug which may arrive at the time of testing. Explain? Answer: First check the status of the bug, then check whether the bug is valid or not then forward the same bug to the team leader and then after confirmation forward it to the concern developer. If we cannot reproduce it, it is not reproducible in which case we will do further testing around it and if we cannot see it we will close it, and just hope it would never come back ever again. 25. What is the difference between use case, test case, and test plan? Answer: Use Case: It is prepared by Business analyst in the Functional Requirement Specification (FRS), which is nothing but steps which are given by the customer. Test cases: It is prepared by test engineer based on the use cases from FRS to check the functionality of an application thoroughly Test Plan: Team lead prepares test plan, in it he represents the scope of the test, what to test and what not to test, scheduling, what to test using automation etc.