A A traceability matrix is a document, usually in the form of a table that correlates the four documents that baseline requires a relationship of plenty of to plenty of to select the integrity of the relationship. It is often used with high-level requirements (these often consist of promotion requirements) & application requirements detailed product matching parts of high-level design, detailed design, check plan & check cases.For example, a requirements traceability matrix is used to check if the current project requirements are achieved & to assist in the creation of a request for proposal, several documents submitted & the project plan tasks.The common use is to take the user name for each of the elements of a document & place them in the left column. The identifiers for other papers placed in the top row. When an item in the left column relates to a topic at the top, a mark is placed at the intersection cell. The number of relationships are added to each row & each column. This value indicates the mapping of the four topics. Values of zero indicate that there is no connection. It must select if there is to do. Giant values insinuate that the relationship is complex & must be simplified.To facilitate the creation of traceability matrices, you ought to also add relations with the source documents for both traceability backward & forward traceability. In other words, when an item is changed in to a baseline document,It is easy to see what needs to change in the other.
Q Which testing Methology You are using in your company??
A Testing Process entirely differ frm company to company ....
As far my Current organization is concerned the process compromised of..
1.R given a FDD/SRS/FRS (Functional Design Document/System Requirement Specification/Functional requirement Specification) to study very carefully as its all abt d application Understanding b4 it is developed.
2.Creating DoU (Document of Understanding) and sending it to the concerned manager for further clarification.
3.Test case creation based on that document n Screen shot.
4.When build is ready start Testing n executing those Test cases.
5.If some variation is found in Build n document we intimate it to the manager n manager to client n get it verified at there end.
6.Logging BUGS into the concerned Tool as we were logging in Mantis.
7.get all those BUGS closed and hence testing continues for each product ..
Q what is the major difference quality control and quality assurance?
Quality Assurance
1. A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
2. QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project - e.g., are requirements being defined at the proper level of detail.
3. Quality Assurance makes sure you are doing the right things, the right way.
Quality Control
1. A set of activities designed to evaluate a developed work product.
2. QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements
3. Quality Control makes sure the results of what you've done are what you expected
As "V" Stands for "Verification" n "Validation".So it cannot be called as "U" model..
If more clarification needed pls ask???
Q What is the difference between Testing and debugging ?
Testing is to find errors or bugs and it is done by Tester
The appropriate definition of testing is that " Testing is the process of executing a program with the intent of finding errors."
Because never test a program to show that it works, rather start any program with valid asumption
that the program conains errors.
Debugging is a process that begins when one finds an error as a result of a successful test case.
This process consists of:
(1) the determination of the exact nature and location of an suspected error within the program.
i.e. the error locating process.
(2) fixing the errors.i.e. error- Repairing
3 Debugging is to remove errors or bugs and it is done by programmer
Both TESTING and DEBUGGING raises the RELIABILITY of the progam.
Test Planning
Q If a bug is found that is not replicable all times, does that bug should be reported to developer?
A A bug/defect according to tester is treated/accepted by developer only if he can able to reproduce it.If not,he will change the status as not reproducible.
If we log a defect that has occured once and not reproducible again,though we execute the same steps to reproduce,means for the first time execution either their may be a human error in the execution or the application might be responding differently for each execution.Here we need to investigate the issue first and should clarify that is it a defect or not,than we have to log the defect/bug.So that the time to fix the defect will be reduced and by investigating the root cause only we can log genuine defects.Investigation of the root cause shows the capability of the tester.
For the question ,answer according to me is dont log a defect.Log it as an issue and send to your TL/Manager ,if you cannot be able to investigate the issue or the issue is beyond your limits.A TL/Manager has to identify that this issue is really a defect or user mistake.If you are the manager/TL ,you can take the help of a functional designer or a developer who has developed the project.
A Testing Process entirely differ frm company to company ....
As far my Current organization is concerned the process compromised of..
1.R given a FDD/SRS/FRS (Functional Design Document/System Requirement Specification/Functional requirement Specification) to study very carefully as its all abt d application Understanding b4 it is developed.
2.Creating DoU (Document of Understanding) and sending it to the concerned manager for further clarification.
3.Test case creation based on that document n Screen shot.
4.When build is ready start Testing n executing those Test cases.
5.If some variation is found in Build n document we intimate it to the manager n manager to client n get it verified at there end.
6.Logging BUGS into the concerned Tool as we were logging in Mantis.
7.get all those BUGS closed and hence testing continues for each product ..
Q what is the major difference quality control and quality assurance?
Quality Assurance
1. A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
2. QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project - e.g., are requirements being defined at the proper level of detail.
3. Quality Assurance makes sure you are doing the right things, the right way.
Quality Control
1. A set of activities designed to evaluate a developed work product.
2. QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements
3. Quality Control makes sure the results of what you've done are what you expected
Q why V model called "V-Model" why not" U-model"?
"V" model cannot be called as a "U" model as V has a significant menaning.As "V" Stands for "Verification" n "Validation".So it cannot be called as "U" model..
If more clarification needed pls ask???
Q What is the difference between Testing and debugging ?
Testing is to find errors or bugs and it is done by Tester
The appropriate definition of testing is that " Testing is the process of executing a program with the intent of finding errors."
Because never test a program to show that it works, rather start any program with valid asumption
that the program conains errors.
Debugging is a process that begins when one finds an error as a result of a successful test case.
This process consists of:
(1) the determination of the exact nature and location of an suspected error within the program.
i.e. the error locating process.
(2) fixing the errors.i.e. error- Repairing
3 Debugging is to remove errors or bugs and it is done by programmer
Both TESTING and DEBUGGING raises the RELIABILITY of the progam.
Test Planning
Q If a bug is found that is not replicable all times, does that bug should be reported to developer?
A A bug/defect according to tester is treated/accepted by developer only if he can able to reproduce it.If not,he will change the status as not reproducible.
If we log a defect that has occured once and not reproducible again,though we execute the same steps to reproduce,means for the first time execution either their may be a human error in the execution or the application might be responding differently for each execution.Here we need to investigate the issue first and should clarify that is it a defect or not,than we have to log the defect/bug.So that the time to fix the defect will be reduced and by investigating the root cause only we can log genuine defects.Investigation of the root cause shows the capability of the tester.
For the question ,answer according to me is dont log a defect.Log it as an issue and send to your TL/Manager ,if you cannot be able to investigate the issue or the issue is beyond your limits.A TL/Manager has to identify that this issue is really a defect or user mistake.If you are the manager/TL ,you can take the help of a functional designer or a developer who has developed the project.
