Software Testing Interview Questions - 1

Q1. What is Software Testing? Ans. Operation of a system or application under controlled conditions and evaluating the results. The controlled conditions must include both normal and abnormal conditions. It is oriented to detection. Q2. What is Software Quality Assurance? Ans. Software QA involves the monitoring and improving the entire software development process, making sure that any agreed-upon standards and procedures are followed. It is oriented to prevention. Q 3. What are the qualities of a good test engineer? Ans. A good test engineer has a test to break attitude. An ability to take the point of view of the customer a strong desire for quality Tactful and diplomatic Good communication skills Previous software development experience can be helpful as it provides a deeper understanding of the software development process Good judgment skills Q4. What are the qualities of a good QA engineer? Ans. The same qualities a good tester Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews. Q5. What are the qualities of a good QA or Test manager? Ans. Must be familiar with the software development process able to maintain enthusiasm of their team and promote a positive atmosphere always looking for preventing problems able to promote teamwork to increase productivity able to promote cooperation between software, test, and QA engineers have the skills needed to promote improvements in QA processes have the ability to say 'no' to other managers when quality is insufficient or QA processes are not being adhered have people judgement skills for hiring and keeping skilled personnel be able to run meetings and keep them focused Q6. What is the 'software life cycle'?

Ans. The life cycle begins when an application is first conceived and ends when it is no longer in use. Q7. Tell us about some world famous bugs Ans. 1. In December of 2007 an error occurred in a new ERP payroll system for a large urban school system. More than one third of employees had received incorrect paychecks that results in overpayments of $53 million. Inadequate testing reportedly contributed to the problems 2. A software error reportedly resulted in overbilling to 11,000 customers of a major telecommunications company in June of 2006. Making the corrections in the bills took a long time. 3. In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000 erroneous tax overcharges. Q8. What are the common problems in the software development process? Ans. Poor requirements Unrealistic schedule Inadequate testing A request to pile on new features after development is unnderway. Miscommunication Q9. What are the common solutions to software development problems? Ans. Solid requirements Realistic schedules Adequate testing stick to initial requirements where feasible require walkthroughs and inspections when appropriate Q10. What is a Quality Software? Ans. Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and / or expectations, and is maintainable. Q11. What is good code? Ans. Good code is code that works, is reasonably bug free, and is readable and maintainable. Q12. What is good design? Ans. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable. It should also be robust with sufficient error-handling and status logging capability and work correctly when implemented. And, good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. Q13. What's the role of documentation in QA? Ans. QA practices must be documented to enhance their repeatability. There should be a system for easily

finding and obtaining information and determining what documentation will have a particular piece of information. Q14. Which projects may not need independent test staff? Ans. It depends on the size & nature of the project. Then, it depends on business risks, development methodology, the skills and experience of the developers. Q15. Why does software have bugs? Ans. miscommunication or no communication software complexity programming errors changing requirements time pressures poorly documented code software development tools egos - people prefer to say things like: 'no problem' 'piece of cake' 'I can whip that out in a few hours'

Software Testing Interview Questions - 2

FRIDAY, JUNE 27, 2008

SPONSORED LINKS

Table of Contents | Subscribe to Software Testing Newsletter

inShare
`

Q15. How QA processes can be introduced in an organization? Ans. 1. It depends on the size of the organization and the risks involved. e.g. for large organizations with highrisk projects a formalized QA process is necessary. 2. If the risk is lower, management and organizational buy-in and QA implementation may be a slower. 3. The most value for effort will often be in - Requirements management processes - Design inspections and code inspections - post-mortems / retrospectives

Q16. What are the steps to perform software testing? Ans. - Understand requirements and business logic - Get budget and schedule requirements - Determine required standards and processes - Set priorities, and determine scope and limitations of tests - Determine test approaches and methods - Determine test environment, test ware, test input data requirements - Set milestones and prepare test plan document - Write test cases - Have needed reviews/inspections/approvals of test cases - Set up test environment - Execute test cases - Evaluate and report results - Bug Tracking and fixing - Retesting or regression testing if needed - Update test plans, test cases, test results, traceability matrix etc. Q17. What is a test plan? Ans. A document that describes the objectives, scope, approach, and focus of a software testing effort. Q18. What are the contents of test plan? Ans. - Title and identification of software including version etc. - Revision history - Table of Contents - Purpose of document and intended audience - Objective and software product overview - Relevant related document list and standards or legal requirements - Naming conventions - Overview of software project organization - Roles and responsibilities etc. - Assumptions and dependencies - Risk analysis - Testing priorities - Scope and limitations of testing effort - Outline of testing effort and input data - Test environment setup and configuration issues - Configuration management processes - Outline of bug tracking system - Test automation if required - Any tools to be used, including versions, patches, etc. - Project test metrics to be calculated - Testing deliverables

- Reporting plan - Testing entrance and exit criteria - Sanity testing period and criteria - Test suspension and restart criteria - Personnel pre-training needs - Relevant proprietary, classified, security and licensing issues. - Open issues if any - Appendix Q19. What is a test case? Ans. A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of a software application is working correctly. Q20. What are the components of a bug report? Ans. - Application name - The function, module, name - Bug ID - Bug reporting date - Status - Test case ID - Bug description - Steps needed to reproduce the bug - Names and/or descriptions of file/data/messages/etc. used in test - Snapshot that would be helpful in finding the cause of the problem - Severity estimate - Was the bug reproducible? - Name of tester - Description of problem cause (filled by developers) - Description of fix (filled by developers) - Code section/file/module/class/method that was fixed (filled by developers) - Date of fix (filled by developers) - Date of retest or regression testing - Any remarks or comments Q21. What is verification? Ans. It involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. It can be done with checklists, issues lists, walkthroughs, and inspection meetings etc. Q22. What is validation? Ans. It involves actual testing and takes place after verifications are completed. Q23. What is a walkthrough? Ans. An informal meeting for evaluation or informational purposes.

Q24. What's an inspection? Ans. It is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything. Q25. What is configuration management? Ans. It covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools / compilers / libraries / patches, changes made to them, and who makes the changes. Q26. When you can stop testing? Ans. - Deadlines (release deadlines, testing deadlines, etc.) - Test cases completed with certain percentage passed - Test budget depleted - Coverage of code/functionality/requirements reaches a specified point - Bug rate falls below a certain level Beta or alpha testing period ends Q27. What if there isn't enough time for thorough testing? Ans. Consider the following scenarios: - Which functionality is most important from business point of view? - Which functionality is most visible to the user? - Which functionality has the largest financial impact? - Which aspects of the application are most important to the customer? - Which parts of the code are most complex? - Which parts of the application were developed in rush? - Which aspects of similar/related previous projects caused problems? - What do the developers think are the highest-risk aspects of the application? - What kinds of problems would cause the worst publicity? - What kinds of problems would cause the most customer service complaints? - What kinds of tests could easily cover multiple functionalities? Q28. What if the project isn't big enough to justify extensive testing? Ans. Do risk analysis. See the impact of project errors, not the size of the project. Q29. How can web based applications be tested? Ans. Apart from functionality consider the following: - What are the expected loads on the server and what kind of performance is expected on the client side? - Who is the target audience? - Will down time for server and content maintenance / upgrades be allowed? - What kinds of security will be required and what is it expected to do? - How reliable are the site's Internet / intranet connections required to be? - How do the internet / intranet affect backup system or redundant connection requirements and testing?

- What variations will be allowed for targeted browsers? - Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site? - How will internal and external links be validated and updated? - How are browser caching and variations in browser option settings? - How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested? - From the usability point of view consider the following: -- Pages should be 3-5 screens longer. -- The page layouts and design elements should be consistent throughout the application / web site. --Pages should be as browser-independent or generate based on the browser-type. --There should be no dead-end pages. A link to a contact person or organization should be included on each page. Q30. What is Extreme Programming? Ans. Extreme Programming is a software development approach for risk-prone projects with unstable requirements. Unit testing is a core aspect of Extreme Programming. Programmers write unit and functional test code first - before writing the application code. Generally, customers are expected to be an integral part of the project team and to help create / design scenarios for acceptance testing.

Mercury Quality Centre

Mercury Quality Centre is a web-based test management tool. It gives you a centralized control over the entire testing life cycle. It gives an easy interface to manage and organize activities like Requirements coverage, Test Case Management, Test Execution Reporting, Defect Management, and Test Automation. All these activities are provided from a single tool, which is web-based and can be accessed from any where. Hence, making the task of the testers and managers easy. Mercury Quality Centre can be divided into two parts: - Site Administrator Bin - Quality Centre Bin Site Administration Bin: It is the starting point for the usage of Mercury Quality Centre. This part is used for all the administrative activities. Password for site admin is defined during the installation so make sure that you remember the password during installation. From this part of Mercury Quality Centre, we generally do the following activities: - Creating the projects - Assigning users to the projects - Creating specific roles - Configuring QTP or Winrunner scripts to use from Mercury Quality Centre - Configuring the mail servers - Verifying licensing information - Information about database Note: If you are using Winrunner, you need to make sure that backward compatibility property of the application to true. Quality Center Bin: This part of Mercury Quality Centre gives functionality of almost everything that as a

tester or test manager you need to do in your day to day activity apart from execution. This is the most common interface used by the customers or users. In this part, we generally do the following activities: - Creating test plans - Defining requirements - Creating test cases - Creating test labs - Associating requirements with defects in essence Mercury Quality Centre is installed as a service in Microsoft windows environment. Before start working on it, make sure that Mercury Quality Centre service is running. As soon as you access the application, the first screen is a login screen where you need to provide administrator credentials which were used during the installation of Mercury Quality Centre. Once you are logged on to the SABin, you can perform all the administrative tasks mentioned above. Note: If Mercury Quality Centre is listening to default port, then you can access the application using the following URL: http://%7Byourmachinename%7D:8080/sabin/SiteAdmin.htm Define your projects in SABin. Mercury Quality Center provides the role based accessed to the Projects. For example, A Test Manager can create projects and Test Lead can prepare test plans and tester can write the test cases. This role based access makes it very easy to control access to various artifacts of the project and also distribution of responsibility among team members. Following four things can be managed in Mercury Quality Centre: - Requirements - Test Plan - Test Lab - Defects Once you have created a project in SABin, Now log on to QCBin by providing your credentials and access the project that you have created. Here, you will notice different tabs for Requirements, TestPlan, TestLab and Defects. Under Requirements Tab, you can organize the project requirements. You can also create folder hierarchy to represent various features in your project. This can be accomplished by just right-clicking and choosing appropriate options. After creating requirements, move on to next tab Test Plan. Test Plan Tab will have information about the test cases. These test cases can also be mapped to requirements created in the earlier steps, thus makes foundation for the traceability metrics. Each requirement can be mapped to one or more than one test cases. After creating new test case you will see in the left hand pane. The right hand pane will have tabs for writing the steps, mapping to requirements, description, expected result etc. Every test case will have steps and for every step you can specify the expected behavior. The test cases written here, can also be linked to the QTP or Winrunner Scripts. This way, it is providing you better management for the automation and capability of executing automation scripts from Mercury Quality Centre itself. Once you are done with Test Plan preparation, move on to the next tab Test Lab. To manage test execution for a specific release, you have to create a Test Lab. Test Labs can be created, specific to the release and execution of test cases specific to release can be managed very easily using this concept. In the Test Lab you can identify the set of test cases already written under test plan to include for execution. If the test cases are already linked to the requirements, then after each test cycle the management will be able to trace what requirements have been tested. When you choose the option of manual test execution, a window will open up containing the steps to execute.

These steps are executed and after every step you can specify whether it is passed or not. Mercury Quality Center also allows parameterized manual test execution, where some of the default parameters like username, password etc. can automatically be read during the manual execution. If you encounter any defects during the failure of any of the steps, it will be automatically logged in to the defect tracking system of Mercury Quality Centre. Once you are done with Test Execution move on to next tab, Defects. Report generation is one of the most important part of the test management process. Once you are done with planning and execution, its REPORTING time. Mercury Quality Centre provides a very good reporting feature by providing certain pre-defined reports and also capability to create your own reports.