Chapter 7 Acceptance
Testing
Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.
Chapter 8 Testing
Strategies
I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.
No comments:
Post a Comment