1. I have seen in my experience till now that position of QA is least in most of the organizations.
2. No body is aware about QA. Nobody knows the value of QA. But they can take decisons on QA tasks/plans easily.
3. Everyone thinks that any person can perform QA tasks on any project.
4. QA always dances on the fingers of Developers.
5. Developers decides who will be the QA of their project.
6. Developers decides which bug should be address to the client. because it can harm their positions.
7. When new joinies come to any organization thay do not want to become QA because of above points.
8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.
Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore
the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final
drop before 1-2 hours of product delivery.
And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.
Please forgive QAs and try to understand their feelings after all they are also human beings.
We can post the bug by email to developer and project manager.we can write the details about the bug, the situation and the condition in which it gets reproduce.
Both are Test Mangement tools. Rational clearquest is from IBM. Test Director from Mercury. Most of the difference are unknown as features wise they have different features as rarely any company will be using both tools. One differnce is cost wise, two product from different company can not have same cost.
AUT is "Application under test".After designing and coding phase of development cycle,when the application(build) comes under testing then at that time application state is under test,so at that time period that application(build) is called "Application Under test".
In quality world you can't say Bug is 100 % fix or 50 % fix . If Bug is fixed than in new verssion we do regression testing to make sure that Bug fix doesn't have any impact on old functionality.
Bug resolution meeting: It is conducted in presence of Test lead and Developers where developers gives his/her comment wheather to correct the bug at this time or later and test leader accepts or rejects developers comments and even they decide what methods should be chosen to correct the error so that in regression test no bug should be reported and it should not effect other application.
Bug review commitee:It is often conducted by test lead, project managers in presence on client, where they all decide as to what errors should be considered as bug and what severity level it shuld be treated as.
Whenever the bug is reproduced, tester can send it back to the Developer and ask him to fix it again. If the developer cannot fix the bug once again and if the tester sends the bug back to developer, the third time, the tester can make the bug as Defered ie he can reject the build (.exe)
I recommend adding small comments to the main pieces of codes and using debug messages. You can also implement a "debug mode", which can be a global variable. If that mode is enabled, the variables values will be shown in the critical places of the application. This should help tracking the variables and seing when the problem occurs. (this method can be useful when the development environment does not have a 'watch')
1. Its status is 'NEW' and assigns to the respective dev team (Team lead or Manager).
2. The team lead assign's it to the team member, so the status is 'ASSIGNED TO'
3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is 'RE-ASSIGNED'
4. The tester, check if the defect is fixed, if its fixed he changes the status to 'VERIFIED'
5. If the tester has the autority (depends on the company) he can after verifying change the status to 'FIXED'. If not the test lead can verify it and change the status to 'fixed'.
6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing.
Posting a bug through EMail is not done anywhere these days in real-time , as it would lead to miscommunication and creates lot of confusion at the long run..Hence a tool bought by the company or a tool built by our own company will be used.
The tools features would be almost same even though their GUI might vary. Some tools will have a format like Excel sheet where we can enter the details of a bug and save it ,where an email is sent to the assigned person (name and ID will be set in the tool) , when ever status of the bug is changed you will recieve an another mail..
1. Moment you get the bug, just double check in the bug DB for duplicates. I mean from the earlier build, it might've been uncovered and recorded as a bug and the release manager might've decided to fix it in later builds.
2. Not there in DB, then analyse the bug for confirmation. If you are strongly recomand that as a bug, you can proceed OR please reconfirm with peers
3. Still BUG? So, go ahead use the Bug Tracking database (if any) or use the excel bug reporting format (whatever you have) But, tell everything clear.
a. Bug Title, Bug Description, The setup you have to reproced, the Priority, Impact
b. H/W and S/W used
c. Screen shots, Log file (if any), SQL Qurey statements...If possible record the entire steps in a movie file and send the clip!!!
Test Director is Defect Tracking Tool.It also supports Test Process Management i.e it allows creating test plans,running test cases and tracking defects.
Rational Clear Quest is customized defect tracking and change request tracking tool.We can submit change requests and track change requests.
Tracability Matrix: The traceability matrix ties individual requirements in the SRS both to specific paragraphs in the SDS and to specific lines in the pseudocode. The objective of the traceability matrix is to assure that all requirements listed in the SRS have been addressed in the design.A good method for presenting the traceability matrix is as a table. Use the paragraph numbering from the documents to make the references to individual requirements and parts of the SDS unambiguous. Ideally, there will be a straightforward relationship between SRS contents and the SDS contents, with all parts of the SDS motivated by requirements in the SRS and every part of the SRS corresponding to something in the SDSCross Referance Matrix: The test-requirements cross-reference matrix shows how every requirement listed in the SRS will be tested. In some cases, this can be arranged in the form of a table. In other cases, bullet lists provide a better approach to presenting the information in a readable form. Ideally, there will be a straightforward relationship between requirements in the SRS and the tests, with every test motivated by requirements in the SRS and every part of the SRS corresponding to one or more of the tests.To ensure all functional requirements have been captured in the detailed design, cross-reference each functional requirement with it’s associated Detailed Design element.
The traceability of bug can we followed in so many ways.
*Mapping the Functional requirements scenarios (FS Doc) - test cases(ID) -- Failed test cases (Bugs)
Mapping between requirements (RS Doc) - test case (ID) - Failed Test Case
Maping between Test plan (TP Doc)- test case (ID) - Failed Test case
mapping between business requirements (BR Doc) - test Case (ID) - Failed Test case
Mapping between High Level Design (Design doc) - Test Case (ID) - Failed test case.
Usually the traceability matrix is mapping between the requirements, client requirements, function specification, test plan and test cases.
Typically, in test situations, traceability matrices are used to trace requirements to test cases in order to ensure that there are test cases for all the requirements. Some easily aviailable commercial tools like Rational Suite Enterprise, will help testing engineer/ test lead to trace requirements and then to trace from the use cases and/or requirements to test cases.
Of course, usually many types of traceability matrices may be created a just simple concept of REVERSE ENGINEERING. For example, you may trace Bug--> identify that test cases-->use cases and vice versa. The default term likely applies to tracing requirements to test cases though.
Successful Retesting the defect will ensure you that the defect is fixed and after doing successful regression for the related failed/on which defect was raised in next passes/phase will enusre that the defect is fixed.
one more method is Testing Matrix, which is nothing but a table index, which shows the result of Equivalence Range methods results, for example
assume that your application is behaving as similar for some range of values, then take the range of values on columns side and test cases on row side, show the result in matrix form
Y2kbug was recent bug which caused failed in computersystem in europe
y2k bug means after 1999 ,2000 as to come but there was a problem in system & due this bug europe had to face lot of problems in train time management system.
In some companies specially in J2EE domain, builds are delivered from development team to the testing team to start the system testing. For example a new product XXX is being released to the testing team so the dev team will deliver a build to the Testing team. Now Testing team will do the testing and then will release the product to the client. Now there is a new version of the product coming up with the name XXX.1 and is being released to the testing team, so this will be the second build and the time between these 2 builds will be called as build interval.
Defect Life Cycle is the Cycle thru which a defect goes starts when defect found & ends when defect is closed after ensuring its not reproduced.Defect Life cycle is related to Bug found during testing so it doesn depend on Manual & Automated Testing.
Phases of Defect Life Cycle is
1. New : When Defect disccovered.
2.Open: When defect is addressed to the developer. It may then be Rejected, said to be duplicate or deferred.
3. Fix : when it is fixed or defect solved by developer.
4.Close : After defect addressed by developer it comes to Tester to Test, once assured its no more a defect its is Close phase.
There are more phases to this if it is to be discussed in too details but on primary level this is the right answere.
