Showing posts with label Requirments. Show all posts
Showing posts with label Requirments. Show all posts

Thursday, November 17, 2011

When you Feel Rejected…

It is common to see a bug rejected as “Not a requirement”. It sometimes hurts as it pushes aside your valuable feedback with a process related excuse.
Common examples are
·         When a requirement includes implementation details and the devil (our bug) is in those details – the bug is actually in the requirements.
·         When an issue is detected by using an oracle other than the official requirement (for example one of the HICCUPPS heuristics).
Some less logical examples that I’ve actually seen:
·         When the fix involves someone who is not committed to the effort yet – for example when a Platform bug requires a Software workaround, especially if the effort is big. “Not a requirement” here actually means “Not my responsibility”.
·         When a bug is the result of a design limitation. “Not a requirement” here is actually “It’s not my fault, it’s the Designers fault” and many times the “Bug fix is too expensive”.
Choose the playing field according to the context.
There’s a big field of product value that includes a smaller field of the requirements scope. I play in both. When in order to find this disputable bug, we kicked the ball to the big field, when someone moved its status to “Not a requirement”, he kicked the ball to a smaller field.

Now it’s your turn to select your move according to the context:
1)      Accept the bug rejection
Sometimes the other side of the coins’ argument has validity.
2)      Kick the ball within the requirements field
While the “requirements – yes or no?” argument limits the discussion, if you are able to win it, it will be easier to lead the bug to fix, as the bug handling process is usually more efficient and faster than the requirements definition and approval process. Beware of being too persuasive and winning the argument without a proper reviewer.
3)      Kick the ball to the big field of value again
When the rejection is correct process-wise but not product value wise, it’s time to play in the big field with the big boys. Advocate your bug to stakeholders and decision makers, learn more from customer support and architects or submit a requirement change request. Running in this field is long distance, scoring a goal is much rarer, but this is where you will meet the professional players and improve your own skills.
While the requirements discussion can be more or less relevant, playing beyond it might bring the best rewards.

Tuesday, November 3, 2009

Read the requirements (again)!

This week I helped my 7 years old Son, Harel, in a school project – building a model of Noah’s Ark. Since I liked it to be educational and to teach him a bit about approaching a project, I asked him to list all the Ark's requirements directly from the source. We opened the Bible and read (I am quoting here the original Hebrew text and the American standard version, Genesis 6,13):

עֲשֵׂה לְךָ תֵּבַת עֲצֵי-גֹפֶר, קִנִּים תַּעֲשֶׂה אֶת-הַתֵּבָה; וְכָפַרְתָּ אֹתָהּ מִבַּיִת וּמִחוּץ, בַּכֹּפֶר. טו וְזֶה, אֲשֶׁר תַּעֲשֶׂה אֹתָהּ: שְׁלֹשׁ מֵאוֹת אַמָּה, אֹרֶךְ הַתֵּבָה, חֲמִשִּׁים אַמָּה רָחְבָּהּ, וּשְׁלֹשִׁים אַמָּה קוֹמָתָהּ. טז צֹהַר תַּעֲשֶׂה לַתֵּבָה, וְאֶל-אַמָּה תְּכַלֶּנָּה מִלְמַעְלָה, וּפֶתַח הַתֵּבָה, בְּצִדָּהּ תָּשִׂים; תַּחְתִּיִּם שְׁנִיִּם וּשְׁלִשִׁים, תַּעֲשֶׂהָ. יז וַאֲנִי, הִנְנִי מֵבִיא אֶת-הַמַּבּוּל מַיִם עַל-הָאָרֶץ, לְשַׁחֵת כָּל-בָּשָׂר אֲשֶׁר-בּוֹ רוּחַ חַיִּים, מִתַּחַת הַשָּׁמָיִם: כֹּל אֲשֶׁר-בָּאָרֶץ, יִגְוָע. יח וַהֲקִמֹתִי אֶת-בְּרִיתִי, אִתָּךְ; וּבָאתָ, אֶל-הַתֵּבָה--אַתָּה, וּבָנֶיךָ וְאִשְׁתְּךָ וּנְשֵׁי-בָנֶיךָ אִתָּךְ. יט וּמִכָּל-הָחַי מִכָּל-בָּשָׂר שְׁנַיִם מִכֹּל, תָּבִיא אֶל-הַתֵּבָה--לְהַחֲיֹת אִתָּךְ: זָכָר וּנְקֵבָה, יִהְיוּ. כ מֵהָעוֹף לְמִינֵהוּ, וּמִן-הַבְּהֵמָה לְמִינָהּ, מִכֹּל רֶמֶשׂ הָאֲדָמָה, לְמִינֵהוּ--שְׁנַיִם מִכֹּל יָבֹאוּ אֵלֶיךָ, לְהַחֲיוֹת. כא וְאַתָּה קַח-לְךָ, מִכָּל-מַאֲכָל אֲשֶׁר יֵאָכֵל, וְאָסַפְתָּ, אֵלֶיךָ; וְהָיָה לְךָ וְלָהֶם, לְאָכְלָה. כב וַיַּעַשׂ, נֹחַ: כְּכֹל אֲשֶׁר צִוָּה אֹתוֹ, אֱלֹהִים--כֵּן עָשָׂה. וַיֹּאמֶר יְהוָה לְנֹחַ, בֹּא-אַתָּה וְכָל-בֵּיתְךָ אֶל-הַתֵּבָה: כִּי-אֹתְךָ רָאִיתִי צַדִּיק לְפָנַי, בַּדּוֹר הַזֶּה. ב מִכֹּל הַבְּהֵמָה הַטְּהוֹרָה, תִּקַּח-לְךָ שִׁבְעָה שִׁבְעָה--אִישׁ וְאִשְׁתּוֹ; וּמִן-הַבְּהֵמָה אֲשֶׁר לֹא טְהֹרָה הִוא, שְׁנַיִם--אִישׁ וְאִשְׁתּוֹ. ג גַּם מֵעוֹף הַשָּׁמַיִם שִׁבְעָה שִׁבְעָה, זָכָר וּנְקֵבָה, לְחַיּוֹת זֶרַע, עַל-פְּנֵי כָל-הָאָרֶץ
Make thee an ark of gopher wood; rooms shalt thou make in the ark, and shalt pitch it within and without with pitch. And this is how thou shalt make it: the length of the ark three hundred cubits, the breadth of it fifty cubits, and the height of it thirty cubits. light shalt thou make to the ark, and to a cubit shalt thou finish it upward; and the door of the ark shalt thou set in the side thereof; with lower, second, and third stories shalt thou make it. And I, behold, I do bring the flood of waters upon this earth, to destroy all flesh, wherein is the breath of life, from under heaven; everything that is in the earth shall die. But I will establish my covenant with thee; and thou shalt come into the ark, thou, and thy sons, and thy wife, and thy sons wives with thee. And of every living thing of all flesh, two of every sort shalt thou bring into the ark, to keep them alive with thee; they shall be male and female. Of the birds after their kind, and of the cattle after their kind, of every creeping thing of the ground after its kind, two of every sort shall come unto thee, to keep them alive. And take thou unto thee of all food that is eaten, and gather it to thee; and it shall be for food for thee, and for them. Thus did Noah; according to all that God commanded him, so did he. And Jehovah said unto Noah, Come thou and all thy house into the ark; for thee have I seen righteous before me in this generation. Of every clean beast thou shalt take to thee seven and seven, the male and his female; and of the beasts that are not clean two, the male and his female."

So Harel took a pencil and listed the requirements of his model in his own words:

1. It should be made pales from a certain wood type
2. The ark should be sealed (with pitch)
3. Size in cubits will be 300(Length) X 50(width) X 30(height)
4. A window should be on the upper floor in size of one cubit
5. A door should be on the side of the Ark
6. The Ark should have 3 floors
7. In addition: The Ark will hold Noah’s family and the beasts: a pair of each kind, but seven of each “clean” kind.

When he was done listing, we noticed a few things which are not usually shown in the typical drawings or models of this favorite subject: I never saw anyone painting the Ark in black, however, it’s very likely that after Noah pitched the Ark from outside and inside he didn’t paint it brown and draw wood parts on it, like is shown in most pictures. No one also painted seven sheep or giraffes although these animals are from the “clean” type according to the tradition and Noah might have brought seven of them. We also noticed that the triangle roof and the ramp are optional components. Then we went to work – fulfilling the requirements without the bias we had from other sources, and learned a lesson about getting the requirements from the original source.


Harel demonstrates great requirements reading skills. I am not sure what is the chance that my son will be a tester in his future (currently he wants to have a career as a gaming SW tester, which in his eyes is the perfect profession), but for me this experience is an additional reminder of the danger of executing a test from a test plan without reading again the requirements.
The traditional test execution process (unlike ET), is built as a linear line of of turning the requirments and SW design into test cases and then executing them, but our mind is not linear. The ideas and understanding of the product evolve with time and experience, and our original perspective changes - for better, since it's more mature with time, and for worse, since it's likly to disconnect from the original sources of knowledge. Returning to the requirements at each stage of the execution will reconnect us to our mission definition and will give us an opportunity to relearn the material when our mind is more ready.
My recommendation to everyone who opens a bug or executes a test is always: Read the requirements (again)!





The Ark model.
We didn’t paint it black (we thought brown is nicer). We placed two
sheep and not seven (resources limitation), but we did it consciously.