• +91 9971497814
  • info@interviewmaterial.com

Manual Testing Interview Questions Answers

Question 1 : How can new Software QA processes be introduced in an existing organization?

Answer 1 : • A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary. • Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand. • For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers. • The most value for effort will be in (a) requirements management processes, with a goal of clear, complete, testable requirement specifications embodied in requirements or design documentation and (b) design inspections and code inspections.

Question 2 : What are some recent major computer system failures caused by software bugs?

Answer 2 : • A major U.S. retailer was reportedly hit with a large government fine in October of 2003 due to web site errors that enabled customers to view one anothers' online orders. • News stories in the fall of 2003 stated that a manufacturing company recalled all their transportation products in order to fix a software problem causing instability in certain circumstances. The company found and reported the bug itself and initiated the recall procedure in which a software upgrade fixed the problems. • In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage company could proceed; the lawsuit reportedly involved claims that the company was not fixing system problems that sometimes resulted in failed stock trades, based on the experiences of 4 plaintiffs during an 8-month period. A previous lower court's ruling that "...six miscues out of more than 400 trades does not indicate negligence." was invalidated. • In April of 2003 it was announced that the largest student loan company in the U.S. made a software error in calculating the monthly payments on 800,000 loans. Although borrowers were to be notified of an increase in their required payments, the company will still reportedly lose $8 million in interest. The error was uncovered when borrowers began reporting inconsistencies in their bills. • News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks. • 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. The problem was partly attibuted to the difficulty of testing the integration of multiple systems. • A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the problem, and shared the information, that U.S. officials became aware o

Question 3 : What's a 'test case'?

Answer 3 : • A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results. • Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible.

Question 4 : What kinds of testing should be considered?

Answer 4 : • Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality. • White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions. • unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses. • incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers. • integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. • functional testing - black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.) • system testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system. • end-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. • sanity testing or smoke testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corru

Question 5 : Why does software have bugs?

Answer 5 : • miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements). • software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. And the use of object-oriented techniques can complicate instead of simplify a project unless it is well-engineered. • programming errors - programmers, like anyone else, can make mistakes. • changing requirements (whether documented or undocumented) - the customer may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control - see 'What can be done if requirements are changing continuously?' in Part 2 of the FAQ. • time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made. • egos - people prefer to say things like: 'no problem' 'piece of cake' 'I can whip that out in a few hours' 'it should be easy to update that old code' instead of: 'that adds a lot of complexity and we could end up making a lot of mistakes' 'we have no idea if we can do that; we'll wing it' 'I can't estimate how long it will take, until I take a close look at it' 'we can't figure out what that old spaghetti code did i

Question 6 : What are 5 common problems in the software development process?

Answer 6 : • poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems. • unrealistic schedule - if too much work is crammed in too little time, problems are inevitable. • inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash. • featuritis - requests to pile on new features after development is underway; extremely common. • miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed.

Question 7 : What are 5 common solutions to software development problems?

Answer 7 : • solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. Use prototypes to help nail down requirements. • realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out. • adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. • stick to initial requirements as much as possible - be prepared to defend against changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, use rapid prototyping during the design phase so that customers can see what to expect. This will provide them a higher comfort level with their requirements decisions and minimize changes later on. • communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - e-mail, groupware, networked bug-tracking tools and change management tools, intranet capabilities, etc.; insure that documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use protoypes early on so that customers' expectations are clarified.

Question 8 : What can be done if requirements are changing continuously?

Answer 8 : A common problem and a major headache. • Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible. • It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch. • If the code is well-commented and well-documented this makes changes easier for the developers. • Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes. • The project's initial schedule should allow for some extra time commensurate with the possibility of changes. • Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version. • Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. • Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job. • Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes. • Try to design some flexibility into automated test scripts. • Focus initial automated testing on application aspects that are most likely to remain unchanged. • Devote appropriate effort to risk analysis of changes to minimize regression testing needs. • Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans) • Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

Question 9 : What makes a good QA or Test manager?

Answer 9 : A good QA, test, or QA/Test(combined) manager should: • be familiar with the software development process • be able to maintain enthusiasm of their team and promote a positive atmosphere, despite • what is a somewhat 'negative' process (e.g., looking for or preventing problems) • be able to promote teamwork to increase productivity • be able to promote cooperation between software, test, and QA engineers • have the diplomatic skills needed to promote improvements in QA processes • have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to • have people judgement skills for hiring and keeping skilled personnel • be able to communicate with technical and non-technical people, engineers, managers, and customers. • be able to run meetings and keep them focused

Question 10 : What makes a good test engineer?

Answer 10 : 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, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

Manual Testing Contributors

krishan

Share your email for latest updates

Name:
Email:

Our partners