Tester
|
Acceptance Criteria Checker
|
Requirements
|
|
A tester knows that
even if the product meets the requirement to the T, the product could
totally suck. So, they do not rely too much on the requirement to measure product quality.
|
A checker is
heavily reliant on showing the acceptance criteria is met. They won’t go into
testing without a document.
|
Test Cases
|
|
A tester writes
product based test cases. They ensure test case longevity with data set up and tear down info for fast execution
|
A checker checks the acceptance criteria. They do
not know they need to plan for the future, they focus on the bare minimum.
|
BUGS
|
|
A tester works to
find issues that wont show on the surface
|
A checker works to
find issues inside and within the acceptance criteria.
|
Purpose
|
|
A tester explores
the product and understands what it does and how is does it.
|
A checker checks
the surface and within the boundaries of the requirements.
|
Focus
|
|
A tester
contributes to making a product better
|
A checker tries to
find where the product is broken
|
Product vs Project
|
|
A testers job never
ends. A tester feels responsible to support the product through its life
|
A checkers job ends
with the project
|
Test Data
|
|
A tester works to
create, edit and maintain the data required for testing
|
A checker is
dependent on the developer or the business to provide the data
|
Ex – Sign Off
|
|
A tester relies on
product and architecture knowledge to understand the state and stability of
the product and little on the regression tests
|
A checker relied on
the PASS and FAIL test results.
|
Ex – Superman vs Clark Kent
|
|
A tester will go
deep into what superman is all about, who are his parents, what is his real
identify and all that jazz.
They understand
that Clark Kent and superman are the same person so focusing on clothes is
literally scratching the surface.
|
A checker will only
observe that obvious differences of the superman costume.
Clark Kent – wears his
underwear inside
Super man – wears his
underwear outside
|
Ex – Menus or drop-down lists options
|
|
A Tester will
explore where this data is stored (in the database or hard coded into UI)
|
A checker will make
sure the list of items shows up as listed in the requirements.
|
Ex - Authentication of the user
|
|
A Tester will find
out where the registered user information is saved and make sure the
passwords are salted too.
A tester will also find out how the user session is authenticated and terminated in the browser
|
A checker will make
sure the registered user is authenticated with valid credentials.
|
Wednesday, August 9, 2017
Tester vs Acceptance Criteria Checker
Sunday, August 6, 2017
Can SCRUM save Shark projects
I just watched a movie
called Shark Exorcist (It is a real movie, someone wrote a story and spent
money on making it - http://www.imdb.com/title/tt3120314/).
I was thinking about what could have made the movie better since a team of people worked on it, they must have had hopes for it. I mean when we make
dinner, we want it to be really tasty! When we put on makeup, we want to look
pretty! So, what could have been done to make this movie better?
Answer: Obviously, Not make the movie at all.
I got to thinking - if the makers used the waterfall methodology to make this movie they may not have had a chance to look at the whole product till the very end, so they may not have known about the lameness of the movie. If
they had used SCRUM methodology in the movie making, they might have realized they
were just wasting money and might have scraped the project in its initial
stages and my 5 minutes would have been used on another terrible shark movie. (watched in Fast Forward)
I have personally never worked on a SCRUM team where a project was scraped off
because the vision was so terrible (although SCRUM implies that you can catch issues early on). Because let’s face it, if the team actively
acknowledged the vision was poor suggested
to scrape the project, their jobs would be at stake. We will have less job
security.
So, we silently groom, point, develop, code review, test, release and do tasks
without challenging the vision.
I have worked on SCRUM projects where all my team mates and I trusted each other (that takes time and bad ass
people to self align themselves), and pushed back features and changed features drastically to make the
product better or less defective. But that did not happen just by calling a methodology SCRUM. We were really a team and we were focused on the product not just what the business wanted.
For a project to be noteworthy
or successful the vision is the most important thing. So, do not get hung up on methodology or its certification (I too spent money on the certification). Because the methodology does not make a project successful on its own. It is the people and their insight into the project that makes a great product and successful project.
Wednesday, July 19, 2017
Diapers and User Stories
diapers. They added convenience for
unplanned outings and emergencies. But when they were understood as the norm
and taken for granted, the result was more landfills occupied with junk that
takes more than 500 years to decompose.
Once upon a time user stories were suggested in agile
methodology for unplanned needs about which much was unclear but there was a
need, an unplanned need, but a valid need. This enabled anyone to be able to
write requirements and put them through the backlog. But when they were
understood by the upper management as norm and taken for granted, the result is
lots of user stories (most of them poorly written) that look the same and take
longer to understand and implement and result in half-baked products that
constantly break other logic.
Advantage – anyone could take care of the child and people
were not tied to the child.
Disadvantage – babies who used to be potty-trained by 18
months take 36 + months now.

Advantage - the business teams can pile up on wants with
user stories in bits and pieces.
Disadvantages – Art of writing fully vetted technical requirements
is forgotten leaving a lot to be improvised by the developer on the fly.
Diapers and User stories were meant for good purposes, but
misuse and overuse made kids and IT inefficient. They both deal with a lot of Shit!!
Subscribe to:
Comments (Atom)
Why you should not delete Tickets
I am old school. Back in the day, logging a ticket was not everybody’s job. Prioritizing and removing tickets from the queue was also handle...
-
Vanilla Ice Cream that puzzled General motors’!!!! An Interesting Story Never underestimate your Clients' Complaint, no matter...
-
“Working so hard” “There is a lot of work to do” “Such a big application” “So many bugs” "Too much work load" ...
-
The old school philosophy of testing is "Break the software". I used to think this way and be driven this way. Then I realized so...