Manual software testing interview questions and answers about bug is found:
Testing Interview Questions and Answers with examples on when a bug is found to clear Manual andSoftware Testing Interview. Get Tricky Interview Questions and Answers on when a bug is found.Manual Software Testing Interview Questions with. Answers. As a software tester the person should have certain qualities,if a bug is found.
Q: What should be done after a bug is found?
A: In manual testing When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
A: In manual testing When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
Q: What is configuration management?
A:In Manual testing Configuration management (CM) covers the tools and 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. Rob Davis has had experience with a full range of CM tools and concepts, and can easily adapt to your software tool and process needs.
Q: What if
the software is so buggy it can't be tested at all?
A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs.
Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
Q: What if there isn't enough time for thorough testing?
A: Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects.
Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:
A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs.
Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
Q: What if there isn't enough time for thorough testing?
A: Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects.
Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:
- Which
functionality is most important to the project's intended purpose?
- Which
functionality is most visible to the user?
- Which
functionality has the largest safety impact?
- Which
functionality has the largest financial impact on users?
- Which aspects
of the application are most important to the customer?
- Which aspects
of the application can be tested early in the development cycle?
- Which parts of
the code are most complex and thus most subject to errors?
- Which parts of
the application were developed in rush or panic mode?
- Which aspects
of similar/related previous projects caused problems?
- Which aspects
of similar/related previous projects had large maintenance expenses?
- Which parts of
the requirements and design are unclear or poorly thought out?
- 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?
- Which tests
will have the best high-risk-coverage to time-required ratio?
