1 – What is a Traceability Matrix?
A Traceability Matrix documents the relationship between two baseline documents to determine the completeness of the relationship. A requirements traceability matrix may be used to check to see if the current project requirements are being met. This matrix is usually in the form of a table.
The identifier for each of the items of one document are usually placed in the left column, and the identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column, with a higher number indicating a higher correlation between the two documents. Zero values indicate that no relationship exists; large values indicate that the relationship is too complex.
2 – If there are many bugs to be fixed, which should you resolve first?
Fix the highest-priority bugs first. The severity of a software defect may not correlate directly with the priority placed on fixing it. Severity and priority should be tracked separately, although in a small organization or on a small project, there may not be a large number of defects and you will not need to track both.
It may also be helpful to track the “urgency” of a bug fix (as determined by the client).
In larger projects, you may have a Triage team.
Triage is a medical term; it is the assessment of which patients need to be dealt with first. Some patients will die regardless of what you do; some patients will heal by themselves. The third group, the patients that will only heal with your help, are the highest-priority patients. You can assign software defects to a similar type of “triage” list, based on the defects’ priority and severity.
3 – What’s the difference between re-testing and regression testing?
Regression testing is the process of testing new bugfixes to ensure that they don’t cause problems to occur involving problems fixed earlier. This process involves running a suite of tests.
Re-testing is the process of testing a single defect that was just fixed. Only one test is performed, and the goal is to make sure that the defect that was just fixed was, in fact, fixed properly.
4 – What are the flaws in waterfall model and how to overcome it?
The major drawback that you do not test the application logic until very late in the development cycle. Although a very detailed system specification should result in a less error-prone application, a single serious error spotted late in the development cycle may be very expensive to fix. Also, the waterfall model does not adapt well to rapidly changing technology.
5 – What is the difference between Functional Testing and System Testing?
Functionality testing is based on functional requirements of the application. By contrast, system testing is end-to-end testing that covers all of an application’s functionality including usability, security and performance.
Functional testing is a subset of system testing.
6 – What is the V-Model Development Method?
The V-Model
The V-model is a software development process which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.
To see a graphical representation of the V-Model, see the image to the right.
7 – What are the pre-requisites for white-box testing?
They are the same as for black-box testing, with one major exception: during white-box testing, the testers have access to the application logic. The tester should ask for access to detailed functional specs and requirements, design documents (both high-level and detailed), and source code. The tester analyzes the source code and prepares functional tests to ensure that the application behaves in compliance with both the requirements and the specs.
8 – What is the agile manifesto?
The Agile Manifesto is a statement of the principles that underpin agile software development:
- Individuals and interactions are take priority over processes and tools
- Working software takes priority over comprehensive documentation
- Customer collaboration takes priority over contract negotiation
- Response to change takes priority over following a plan
The QA team may want to add one more principle:
- Craftsmanship takes priority over execution
The idea is to prioritize the creation of good code over the creation of code that barely works.
Have more Software Testing Interview Questions and Answers? Add them to the comments field below!
0 comments:
Post a Comment