Talk on "revolution in indian banking industry"
Define the action taken and the conditions after each individual test
For each of the above test conditions, define the action taken and the condition of file1 after each individual test is completed.The next series of questions refer to the information given on the diagram below:business background:• countries are divided into branches• various products are serviced by...
Once individual test is completed they calculated that whether it is been successfully done according to customer recquirement. If it is done then they go for new testing if not they will find the problem and trying to solve it. If it is major for customer recquirement
Need help from u guys
There is a ReportAnalyzer in quickest plus, this is utility provided by the Mercury along with the QTP. Share this folder or copy the utility folder to your local system and click on the ReportAnalyze...
Hello Ameet
Have you find a solution to your problem? I am trying to do something very similar. If you have any ideas please let me know
Thanks
Rafael
Preparing and maintaining the r&d test enviroment.
What will you (tester) do if there is miscommunication in bugs, every cycle is ignored from developer side and re-opened from tester side?
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 5th, 2009
In every test cycle, the defect is consistently 'Ignored' by the developer and 'Re-Opened' by the tester. This problem exists due to a miscommunication somewhere. What will you do as a tester to rectify this issue?
1) I would first make sure that I have entered accurate and thorough details in the defect report in order for the developer to reproduce the issue. I would include details about the test environment so the developer can duplicate it. I would also include screen shots to prove the defect does indeed exist.
If the developer 'Ignores' this, then s/he obviously believes there is no defect at all and that the application's functionality is working precisely as it is supposed to.
2) Next, I would cite the requirement in the defect report and describe my interpretation of it. Then I would describe how the existing functionality does not meet the intended requirement.
If the developer 'Ignores' this as well, then I begin to consider whether I have misinterpreted the requirement. It is possible that the developer is correct.
3) I would revisit and study the requirement to determine whether I misunderstood it when creating my test case(s). If necessary, I would meet with the Business Analyst to gain further understanding about the requirement. I would discuss my test case and the defect with the Business Analyst to determine whether my understanding and approach is correct.
If my research convinces me that I have fully understood the requirement and that my test case accurately and thoroughly tests it, then I would meet with the developer and discuss the results of my investigation with him/her. I would explain the requirement in the manner intended by the Business Analyst. I would reproduce
the issue in an attempt to prove how the defect fails to satisfy the requirement. Hopefully, the developer will be encouraged to fix the defect.
If the developer continues to 'Ignore' this issue, then I will get the Business Analyst involved.
4) I would set up a meeting with the developer, Business Analyst, and myself in attendance. I would encourage the Business Analyst to explain the requirement to the developer and explain how the test case and its results properly exercise the requirement and identify a failure.
If the developer still 'ignores' this issue, perhaps it is time to replace the developer!
To be very simple, tester should specify the functional document(FD) which tells the exact functionaly of the piece of code and explains how it deviate from the requirement which lead to a creation of...
If a developer is fixing bugs with their own ideas and schedule in mind that means he is not following the test cases, he changing the status to IGNORED, then it is an error on the part of the develop...
If tester is asked to test a build within short period, after testing, how will you (tester) react if the developers says that you have missed the bugs?
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 17th, 2009
1) I would ask the developer to identify precisely what bugs I missed.
2) I would the review the list of bugs in the build notes and compare this with the suite of test cases that I had run during the test cycle.
3) If this is not the release build, then I would add test cases for the missed bugs in the suite of test cases for the next test iteration
4) If this is the release candidate, then I would immediately raise this issue with management and let them decide how to proceed based on the bugs' priority and severity levels.
1) I would ask the developer to identify precisely what bugs I missed.2) I would the review the list of bugs in the build notes and compare this with the suite of test cases that I had run&n...
Testers need to finalize and communicate the scope of testing as well as depth of testing clearly before testing the build under pressure. This should be communicated both to developers as well ...
Which of the following statements about regression statements are true?1. Regression testing must consist of a fixed set of tests to create a base line2. Regression tests should be used to detect defects in new feature3. Regression testing can be run on every build4. Regression testing should be targeted...
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 5th, 2009
I believe the following statements are true about regression testing.
3. Regression testing can be run on every build
4. Regression testing should be targeted areas of high risk and known code change
5. Regression testing when automated, is highly effective in preventing defects.
According to me, it should be:
3. Regression testing can be run on every build
5. Regression testing when automated, is highly effective in preventing defects.
4. Regression testing should be targeted areas of high risk and known code change
5. Regression testing when automated is highly effective in preventing defects.