Thursday, June 19, 2014

I Failed The ISTQB Practice Exam - Part V

Series: Part IPart IIPart III & IVPart VPart VI and Final Thoughts

I was on 15/28...

Part V - Test Management

29. Which of the following best describes the task partition between test manager and tester?

a) The test manager plans testing activities and chooses the standards to be followed, while the tester chooses the tools and controls to be used. 
b) The test manager plans, organizes and controls the testing activities, while the tester specifies, automates and executes tests. 
c) The test manager plans, monitors and controls the testing activities, while the tester designs tests. 
d) The test manager plans and organizes the testing and specifies the test cases, while the tester prioritizes and executes the tests. 

My Answer: None / it depends

It depends on the company. In A sometimes testers choose tools to be used, in D sometimes the tester specifies test cases and the manager prioritizes testing.
What's really interesting go me is the answer in B (also in C) that the manager controls the testing activities. Only if you hire dead testers and tie strings to them like a macabre puppeteer. Hey testers, do you have any control over your test activities? That is to say when you're doing the things you do to test do you have any control over the things you do to test? Does your manager have any direct control over this at all?

Well you're wrong because it's B.

Score: 15/29

30. Which of the following can be categorized as product risks?

a) Low quality of requirements, design, code and tests.
b) Political problems and delays in especially complex areas in the product.
c) Error-prone areas, potential harm to the user, poor product characteristics.
d) Problems in defining the right requirements, potential failure areas in the software or system.

My Answer: C

A is project, B is project, D is project, C is product. Me good test now.

Score: 16/30

31. Which of the following are typical test exit criteria?
a) Thoroughness measures, reliability measures, test cost, schedule, state of defect correction and residual risks.
b) Thoroughness measures, reliability measures, degree of tester independence and product completeness. 
c) Thoroughness measures, reliability measures, test cost, time to market and product completeness, availability of testable code.
d) Time to market, residual defects, tester qualification, degree of tester independence, thoroughness measures and test cost.

My Answer: A

What are "test exit criteria"?  For me that's things like "end of the session" or "I'm bored now" or "Not much more I can do here" or "time for a break". Things like that. How do we measure thoroughness? Seriously, measure my thoroughness, I dare you. Then measure my reliability. I like to use a tricorder. State of defect correction is a test exit criterion?
This doesn't make any sense. I'm so confused. Oh, the answer was a guess.

Score: 17/31

32. As a Test Manager you have the following requirements to be tested: 
Requirements to test: 
R1 - Process Anomalies – High Complexity 
R2 - Remote Services – Medium Complexity 
R3 – Synchronization – Medium Complexity 
R4 – Confirmation – Medium Complexity 
R5 - Process closures – Low Complexity 
R6 – Issues – Low Complexity 
R7 - Financial Data – Low Complexity 
R8 - Diagram Data – Low Complexity 
R9 - Changes on user profile – Medium Complexity 

Requirements logical dependencies (A -> B means that B is dependent on A): 
How would you structure the test execution schedule according to the requirement dependencies? 

a) R4 > R5 > R1 > R2 > R3 > R7 > R8 > R6 > R9.
b) R1 > R2 > R3 > R4 > R5 > R7 > R8 > R6 > R9.
c) R1 > R2 > R4 > R5 > R3 > R7 > R8 > R6 > R9.
d) R1 > R2 > R3 > R7 > R8 > R4 > R5 > R6 > R9.

My Answer: I wouldn't.

Who in the name of buttery buttocks structures a test execution schedule ahead of time? If you've worked on a serious product and had a test execution schedule (a schedule for executing tests) that actually says when what tests are executed and stuck to it I'll give you 20 quid. Why are we assuming that this document is accurate? Who wrote it and why? Are these really the dependencies? According to whom? What about changes to the project? What about parallel activities or early availability of functionality or documentation? Can we express the logical relationship between explicit requirements with an arrow? Can we do it with implicit/tacit requirements at all? Hint: no. There's an infinite number of places where this schedule can fail. Is it important to schedule by dependency in whatever this example would be in real life? These are the interesting questions.
So no, I would not just write a test execution schedule, I'd sketch a plan based on things like availability, testability, deadlines, deliverables, and not just complexity but RISK.
I'd like to do an experiment. Change the question to just show the diagram, the answers, and a big question mark and see if the pass rate for this question remains the same.

Score: 17/32

33. What is the benefit of independent testing?

a) More work gets done because testers do not disturb the developers all the time.
b) Independent testers tend to be unbiased and find different defects than the developers.
c) Independent testers do not need extra education and training.
d) Independent testers reduce the bottleneck in the incident management process.

My Answer: D?

What is independent testing? Independent of what? Freedom of thought? I could recommend some books and scientific papers indicating that independent testers have a raft of biases. And what evidence is there that they find "different" defects? Different how? Do they necessarily and all the time find only different defects?This question is so infuriating.

Score: 17/33

34. Which of the following would be categorized as project risks?

a) Skill and staff shortages.
b) Poor software characteristics.
c) Failure-prone software delivered.
d) Possible reliability defect (bug).

My Answer: All of them, obviously

Okay, if you have a skill/staff shortage that could run a risk to your project, depending on what the skill and staff shortages are. I mean, we have a huge skill shortage when it comes to arc welding, architecture and railway maintenance but it's never seemed to come up.
If the software has "poor characteristics" then that could be a project risk. For example if the product has the poor characteristic of "not very testable" then testers may not be able to provide fast useful feedback to test clients which means that people are making uninformed decisions which is a project risk.
Delivering failure-prone software is a project risk. It's a risk to the success of the project. Delivering a failure-prone product is definitely a risk to the success of the project. I don't know how else to put this.
A "possible reliability defect" is a risk (as it's only a possible bug) and it threatens the success of the project so it's a project risk.

Am I just being dense? Anyway, the correct answer is A.

Score: 17/34

35. As a test manager you are asked for a test summary report. Concerning test activities and according to IEEE 829 Standard, what should you consider in your report? 

a) The number of test cases using Black Box techniques.
b) A summary of the major testing activities, events and its status in respect of meeting goals.
c) Overall evaluation of each development work item.
d) Training taken by members of the test team to support the test effort.

My Answer: B

I don't know the IEEE 829 standard. That didn't help as I wasn't allowed to look it up. I've never needed to. I've never worked in an IEEE 829 standard environment. And if I did the company would ensure I knew IEEE 829 well enough. So why is there a question on it here? Do they teach IEEE 829 for the exam? But hey, if there's anything that says "efficiency" is standardisation of test documentation, right? How about "report what's needed to the right person in the right way at the right time"? I like that as a standard. I'll call it Common Sense 829.
I guessed the answer they wanted. The actual answer is: you'd consider them all if you felt it was necessary to summarise your testing. Say you needed to train your test team to use a helpful tool in order to better test the product? I'd include that in my report to a manager who wants to know what I've been doing with my time and why more testing wasn't done.

Score: 18/35

36. You are a tester in a safety-critical software development project. During execution of a test, you find out that one of your expected results was not achieved. You write an incident report about it. What do you consider to be the most important information to include according to the IEEE Std. 829? 

a) Impact, incident description, date and time, your name.
b) Unique id for the report, special requirements needed.
c) Transmitted items, your name and you’re feeling about the defect source.
d) Incident description, environment, expected results.

My Answer: A?

Again, I don't know the standard. A is the only one that contained both description and impact. D was another candidate as it contained environment and expectation (oracle information). What  the gibbering testicle are "transmitted items" anyway? I don't know "you're" feeling on the matter.*

* Remember, this is the practice exam directly downloaded from the ISTQB's own website, provided by them as a workable example.

Score: 19/36

Next time, the thrilling conclusion and my final thoughts! See you then!

1 comment:

  1. Great analysis! Remember that we measure What is easy to measure, not What is important!