Welcome to my software testing thoughts portal .The opinions/thoughts expressed on this blog are my own personal opinions/thoughts and do not represent my employer's view in any way. Come On ! Let us share to learn together.

Monday, November 29, 2010

Vedic Literature & Waterfall Model Literature




"As the food,so the mind;as the mind, so the thought;as the thought so the act" -Vedic Literature

"As the requirements,so the design;as the design,so the coding;as the coding so the testing" -Waterfall Model Literature





Sunday, November 21, 2010

MUST? or SHOULD? or COULD?



We recently got a requirements document from a new customer where the requirements priority ratings were mentioned as follows



S.No Req Tag Req Description Req Priority Rating
1 R1 AA…AA.AA.AA.AAAA 9
2 R2 BB..BBB.BBB.BBBBB.. 7
3 R3 CC.CCCCCC..CCCC 3
4 R4 DDD…DDDD…DDDDD 3
5 R5 EEEE…..EEEE….EEEEEEE. 7
6 R6 FFF.F…FFFF..FFFFFFF..FF 9



The legend for requirement priority ratings was given as follows
9 :( MUST)A requirement/feature that is fundamental to the project or product
7 :( SHOULD)A requirement/feature that is strongly recommended for the product but is not critical
3 :( COULD)A requirement/feature that is nice to have in the project or product.

R1 and R6 are MUST class requirements/features; R2 and R5 are SHOULD class requirements/features and R3 and R4 are COULD class requirements/features.

We have derived a work plan and schedule and communicated the customers that R1, R6 will be delivered on so and so date first and then R2 and R5 features and then R3 and R4 features. Next day we had received a reply from customer that we want R2 and R5 first and then R1 and R6 for their planning purposes so as to get the things delivered to a third party organization to do some work on their side.

Now we are confused with the question that what is the meaning of requirements priority rating as mentioned in the above table? Then we have decided to reframe as Requirements criticality rating instead of requirements priority rating. This was communicated to the customer and then the above table got modified from the customers as follows with the explanation of the requirements release priority rating as follows
9: Release 1
7: Release 2
3: Release 3

S.No Req Tag Req Description Req criticality Rating Req Release Priority Rating
1 R1 AA…AA.AA.AA.AAAA 9 7
2 R2 BB..BBB.BBB.BBBBB.. 7 9
3 R3 CC.CCCCCC..CCCC 3 3
4 R4 DDD…DDDD…DDDDD 3 3
5 R5 EEEE…..EEEE….EEEEEEE. 7 9
6 R6 FFF.F…FFFF..FFFFFFF..FF 9 7


Lessons Learnt are:
1.Look for the words MUST, SHOULD and COULD
2.Don’t get confused with critical and Priority requirements.

Saturday, November 20, 2010

Three Wise Monkeys (wise enough for testing?)


All we are well aware of three wise monkeys concept which tells the world the following principle: Hear No Evil... See No Evil... Speak No Evil. The monkey covering his ears hears no evil; the monkey covering his eyes sees no evil; the monkey covering his mouth speaks no evil.

Recently in my city there were some advertisement posters (as shown above) pasted in all public transport vehicles with a quote like LISTEN, LOOK and CALL. That advertisement is from a flat promoter organization seeking public to book the flats.

That poster reminds me
Andy Glover‘s Whats-best-testing-tool-ever blog post where he listed out all human organs as the best testing tools.

If testers exhibits these behaviors of not hearing (listening skills), not seeing (being more observant) and not speaking (talking to the stakeholders and talking about the defects), are those are eligible for testing assignments? It’s absolutely no.