Aptitude test for testers Answers

Answer

They are both accurate! The purpose of testing is to find faults AND ensure it meats the users needs (fit for purpose).

It depends on how good your tests were and what they were testing. To have justified confidence in the software we must have confidence in our tests, data and environment.

Talk to users, developers and analysts to understand what the system is supposed to do. Document this understanding and get it reviewed and use this as a substitute for the Requirements/Design documentation. Talk with testers who have tested the system previously Read whatever is available and clarify assumptions

The tester should first establish whether the reason is because of a test fault (i.e. they have made a mistake) or whether it is an environment fault. If neither of these are true then they should then check to see whether this fault has already been raised. If not then either raise the fault or more preferable – talk to the development group to check the fault out.

Do you have a test case: 1. for a valid scalene triangle? 2. for a valid equilateral triangle? 3. for a valid isosceles triangle? 4. for each of the three permutations of two equal sides in valid isosceles triangles? 5. in which one side has a length of zero? 6. in which one side has a negative length? 7. in which the sum of the length of two sides is equal to the length of the third? 8. for each of the three permutations of case 7? 9. in which the sum of the length of two sides is less than the length of the third? 10. for each of the three permutations of case 9? 11. in which all side lengths are zero? 12. which uses non-integer input values? 13. which uses the wrong number of input values? 14. did all your test cases specify the expected output? Myers states that experienced professional programmers score on average 7.8 out of the first 14 questions. Extra points can be given for further tests such as performance, reliability and configuration This is not a serious problem. The message is being printed. The best solution would be (a) or (d) – it is essential that faults be raised as soon as possible so that Development can fix them. However this is dependent on the severity and priority of the fault. This fault is not stopping any further testing on this script – it might be that other similar problems occur with other messages and this extra information might assist development with further investigation First we should investigate the faults – is it because we had run our tests wrongly, or that we were running the tests on the wrong environment? Assuming that it is because the software has regressed – then we must establish the nature of the faults and severity of the faults. It is probably inefficient to run any further tests at this stage. We should work with development in getting a new version of the software with the faults fixed and re-tested before running test set 2.

They are as important as each other. However testers need to have a different mindset to developers and therefore should actively look for potential faults. If we only concentrate on positive tests (show that the system does what it should do) then we will potentially experience problems when the system goes live. If we only concentrate on negative tests (showing the system doesn’t do what it shouldn’t) then again we could potentially miss significant faults. However if we look primarily at breaking the system then we may find lots of faults (the what if scenarios) but we may not establish if the system is going to meet the users needs and requirements. A balance is needed with all three approaches.

A good test is one that can potentially find a fault in the system. If this test does not find a fault then it will give us a certain amount of confidence. Tests must also be efficient – we should not have tests which all do the same thing.