Aptitude Test
Aptitude Test
Aptitude Test
for testers
Version 1.1
Introduction
The tester’s aptitude test has been compiled to assist the test manager/team leader in the
recruiting of good quality testers. This test should be used in conjunction with other
interviewing techniques.
Structure
The test comprises of 25 questions, each carrying different marks. The questions have
been designed to test a broad knowledge of testing from scenario testing to specific
questions on testing tools.
Marking
The test should be completed in 1.5hours. However if it takes the candidates longer then
penalty points can be deducted (1 point for every extra minute for example). If the
candidates take less time then they can be awarded extra points.
The total number of points given from the test is 150 – this can be translated into a
percentage and you might want to consider having a sliding scale for the potential testers:
Acknowledgements
The first draft of the Aptitude Test was issued in June 2001. The following people were
kind enough to suggest alternative questions and comment on the content.
2. You have run all your tests and they all pass. Is this good news or bad 2
news?
3. What would you do if you were asked to test a system which is unfamiliar 4
to you has out-of-date or inadequate documentation?
4. In running a test you find the actual result does not match the expected 3
result – what would you do?
As you can see the screen consists of three text fields and a single
button. The user is expected to enter an integer value into each of the
three text fields. Upon hitting the OK button the program will print a
message in a separate dialog box stating whether the triangle is scalene
(all sides are different lengths), isosceles (two sides are the same
length), or equilateral (all three sides are the same length).
Write a set of test cases (i.e. specific sets of data) that you feel would
adequately test this program. Write the tests so that someone other than
you can run them.
8. In testing the above application you identify what you believe to be a fault 3
– instead of printing the message concerning the type of triangle in a
separate dialog box the application is printing the message in the space
between the 3 text fields and the OK button. What should your next step
be (answer and state why)?
a) Continue testing to the end of the script, and then report the bug.
b) Stop testing, report the bug immediately, then continue alternative
scripts
c) Stop testing, report the bug and await a fix.
d) Continue testing and report the bug later, along with those found in
other scripts
9. You have raised a fault, but Development are unable to reproduce it. 3
What should your next step be? (Give answer and state why)
10. Scenario: 6
You have two sets of tests to run on the new version of the software.
Test Set 1: a test set to provide confidence that software has not
regressed from the previous version.
Test Set 2: a detailed test set to investigate potential faults in the new
release of software.
Having run test set 1 you discover a number of faults in the new version
of software – what do you do?
11. Draw and explain the ‘V’ Model and how testing fits into the Development 6
Lifecycle. Indicate on the model where you would design your tests.
12. Describe the stages of testing and what the objectives are at each stage. 10
14. Scenario: 5
You have planned to run 600 tests on your own. Each test will take
approximately 10 minutes to run. Your manager has told you that you
must complete these tests within one week. What would you do?
15. Do you consider testing tools to be valuable during the testing process – 4
why/why not?
16. List 3 test tool categories and describe what each can do. 9
21. Describe what you understand about the term “Static Testing” and list 3 4
static testing techniques.
23. Scenario: 4
You are testing 2 programs and have 3 weeks to test them both. Having
run all of your tests on both programs you finish testing within 2 weeks.
You need to decide which of the 2 programs you would re-visit and run
further tests against. Choose which program you would re-test (can
choose only one!) – and state you reasons:
Program A
Programmer: A
Complexity Level: 2
Lines of Code: 2000
Number of tests: 100
Number of bugs found: 10
(1 high severity, 3 medium & 6 low)
Program B
Programmer: B
Complexity Level: 2
Lines of Code: 2000
Number of tests: 100
Number of bugs found: 50
(10 high severity, 25 medium & 15 low)
Enter a card and if the card is invalid reject the card and exit system. If it
is a valid card then enter a PIN number. Check to see if the PIN is invalid
– if it is then display a message ‘invalid pin number, please re-enter’. If 3
attempts are made with an invalid pin then the machine keeps the card. If
it is a valid PIN then the user can select one of the following transactions:
• Cash Withdrawal without receipt
• Cash Withdrawal with receipt
• Balance Enquiry
• Statement request
• Cancel
What tests would you produce to test this application? State any
assumptions when testing
25. The following is an extract from a fault log, write down any potential 10
problems or omissions with this:
Fault Log
Description:
When I log on to the screen DF342 I should be able to delete
records. However when trying to delete records an error message
appears telling me that I am not authorised.
Response:
25 Aug: Programmer - Security needs to be set up allowing you
access to the delete facility – No error.
1. They are both accurate! The purpose of testing is to find faults AND 2
ensure it meats the users needs (fit for purpose).
2. It depends on how good your tests were and what they were testing. To 2
have justified confidence in the software we must have confidence in our
tests, data and environment.
4. The tester should first establish whether the reason is because of a test 3
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.
6. A good test is one that can potentially find a fault in the system. If this 2
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.
8. This is not a serious problem. The message is being printed. The best 3
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
10. First we should investigate the faults – is it because we had run our tests 6
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.
11. 6
Business Acceptance
Requirements testing
System Testing
Functional design
The key aspect here is that testing should happen throughout the
Development Lifecycle. Also designing of the test cases should happen
as soon as possible.
14. Assuming there are 7hours per working day. This task would take you: 5
600x10 = 6000 minutes = 100 hours = 14.286 days
WE SHOULD:
Re-prioritise our tests and run the most important tests first
Assuming that not all the 600 tests would have been run within this
time, risk assessment need to be made as to the consequences of
not running the extra tests.
After this initial week and the system is implemented there is no
reason why the extra tests could not be run (assuming that you are
given the time)
15. Testing tools are very important to assist the tester in their work. Using 4
tools can also potentially make the tester more efficient in their work –
they are able to run more tests (using regression testing for example). Or
they can quickly compare 3 reports (comparison tool).
The tools in themselves however do not make good testers and also
should not be considered if the test process is in ‘chaos’.
20. 15
Positive/Valid Tests
0 Operator
7 Room Service
8 Reception
9 Outside line
Negative/In-valid Tests
1 Error
6 Error
Destructive Tests
24. 10
1. Invalid Card – reject card and exit
2. Valid Card and Invalid PIN – error message ‘invalid pin…’ (then enter
valid pin)
3. Valid Card and Invalid PIN – error message ‘invalid pin…’ (then enter
another 2 invalid Pins)
4. Valid Card, Valid Pin & Cancel (correct length pin)
5. Valid Card, Valid Pin in a large number – but the pin number contains
more than the maximum number – should error
6. Valid Card, Valid Pin & Cash Withdraw without receipt
7. Valid Card, Valid Pin & Cash Withdraw with receipt
8. Valid Card, Valid Pin & Balance enquiry
9. Valid Card, Valid Pin & Statement Request
10. Destructive tests include:
• Putting in 2 cards
• Putting correct pin, but adding an extra number to make invalid
Assumptions:
1. Can insert up to 3 invalid pins and machine retains card
2. Can only select one transaction and then have to re-insert card
3. Pressing cancel will return card
25. 10
Potential Problems/Omissions
No actual error message on the log – this may give some clue to the
developer about the nature of the fault