Aptitude Knowledge Interview Preparation Guide
Strengthen your Aptitude Knowledge interview skills with our collection of 108 important questions. These questions are specifically selected to challenge and enhance your knowledge in Aptitude Knowledge. Perfect for all proficiency levels, they are key to your interview success. Download the free PDF to have all 108 questions at your fingertips. This resource is designed to boost your confidence and ensure youre interview-ready.108 Aptitude Knowledge Questions and Answers:
1 :: What statement do you consider to be most important and why?
a) Testing has the primary intent of showing the system meets the users needs.
b) Testing has the primary intent of finding faults
b) Testing has the primary intent of finding faults
2 :: You have run all your tests and they all pass. Is this good news or bad news?
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.
3 :: What would you do if you were asked to test a system which is unfamiliar to you has out-of-date or inadequate documentation?
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
4 :: In running a test you find the actual result does not match the expected result? What would you do?
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.
5 :: Do you consider positive or negative testing to be most important or trying to break the system - and why?
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.
6 :: How would you define a good test?
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.
7 :: In testing the above application you identify what you believe to be a fault?
In testing the above application you identify what you believe to be a fault – 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
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
8 :: You have raised a fault, but Development are unable to reproduce it. What should your next step be?
You have raised a fault, but Development are unable to reproduce it. What should your next step be? (Give answer and state why)
a) Let development sign off the bug as not reproducible.br> b) Sign off the bug yourself as not reproducible.br> c) Tell development the bug definitely exists and you will not pass it unless fixed. br> d) Re-test and upon confirmation provide more detailed information to Development, talking them through each stage if necessary.
The answer is (d) – it might be our environment or it could have been fixed by some other fault fix in the new version.
a) Let development sign off the bug as not reproducible.br> b) Sign off the bug yourself as not reproducible.br> c) Tell development the bug definitely exists and you will not pass it unless fixed. br> d) Re-test and upon confirmation provide more detailed information to Development, talking them through each stage if necessary.
The answer is (d) – it might be our environment or it could have been fixed by some other fault fix in the new version.
9 :: You have two sets of tests to run on the new version of the software?
Scenario:
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?
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.
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?
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.
10 :: Describe the stages of testing and what the objectives are at each stage?
Component Testing
Lowest level of testing, detail, finding faults, performed by the developers
Component Integration
Combining components, testing interfaces, performed by developers, various types of integration (top-down, functional, bottom up and big bang). Business scenarios and non-functional aspects if possible.
System Testing (functional and non-function)
Testing the system as a whole. Testing requirements and business processes. Also testing non-functional aspects such as Performance, usability etc.
System Integration
Testing the system with other systems and networks
Acceptance Testing Testing by users/customers to gain confidence that the system is going to support the business as well as meet their requirements.
Lowest level of testing, detail, finding faults, performed by the developers
Component Integration
Combining components, testing interfaces, performed by developers, various types of integration (top-down, functional, bottom up and big bang). Business scenarios and non-functional aspects if possible.
System Testing (functional and non-function)
Testing the system as a whole. Testing requirements and business processes. Also testing non-functional aspects such as Performance, usability etc.
System Integration
Testing the system with other systems and networks
Acceptance Testing Testing by users/customers to gain confidence that the system is going to support the business as well as meet their requirements.