Lately we had a quote from a client who was seeking for a help in writing software requirements. He was looking for someone to translate a unstructured input into a set of solid, high quality requirements. That was a wise step because requirements is where the quality of a product starts.
More and more people come up with ideas of a software product but the numbers of people who can transform an idea into a full spectrum of professional requirements remain too low. I will try to explain some of the ideas behind writing good requirements, so one could do this on a high level without a help.
Let's start with definition. Software requirements are a set of statements that define software behavior. Under behavior I mean the functionality available for the user or the characteristics of the software that directly affect its business success.
Aside from the qualities of requirements a big role is played by the process. The way you work with requirements defines their effectiveness in the development cycle. During the lifecycle requirements go through several stages:
- Creation or gathering
- Review
- Modification or update
As you see this is not enough to just create requirements. You have to have means to update it later, when changes come up. No matter how good at gathering requirements you are or how good you know what you want to have in the product, you will face change requests. They can come up out of review, development, testing, beta program and field usage. So, you must have a process how to deal about changes, so as to have the lowest possible cost of the update, making sure everyone interested is notified.
All above impose the following demands on the requirements:
- Correctness
- Completeness
- Consistency
- Non-ambiguity
- Testability
- Traceability
- Maintainability or changeability
- Sense of priority
Correctness means that your requirements shall speak the truth. This is not enough to simply state the truth once. You need to make sure that requirements are being updated timely.
Completeness implies the all the required information is provided. You need to remember who the customers of the document are. They span from developers through testers and deployment engineers toward technical writers and support engineers. In some cases, the customer also is a consumer. So, interests of all those people shall be taken into account.
Non-ambiguity means that there is only one understanding of what requirements say. Two different people reading requirements must have the same idea of what they speak of. There three possible failure scenario for this quality:
- Boundary shift ("up to 100" instead of "100 or less")
- Synonyms use (use the same term consistently throughout the document)
- Negative sentences (use positive sentences instead)
Testability is as simple as its name. You should be able to check if a requirement is met. And you should be able do this in a reasonable time and with reasonable resources. Testers are best people to judge upon it.
Traceability is a key to connecting different entities in your process into logical chains. Change in requirements may need according changes in design or test documents. To track those changes and update all connected entities correspondingly, we need to give a requirement an identifier. This is usually an unique number, that defines one and only one atomic statement.
Maintainability is how easily you can update it. The structure of the document defines how much efforts you may need to make a change. Duplicate information doubles the efforts, so use references instead.
Sense of priority gives the possibility to easily say which requirement is a must and which is nice to have. This is especially important when it comes to selecting tests for regression testing or shaking up the functional scope with hope to find 1-2 man months you are lacking in the development plan.
If you manage to write requirements that meet the above qualities then you are most likely to succeed. I would also recommend keeping it short. As one wise man said "conciseness is talent's sister".
Additionally I would recommend finding articles related to wording to be used in requirements definition. Following simple rules may help making requirement easier to read. All the more, the language is ambiguous per se. You may find in there which construction of language to avoid making it less ambiguous.
Good luck!
Monday, November 23, 2009
Monday, November 16, 2009
Change your environment!
I am back from a short vacation that I have spent with my family. It was good but too short :) Anyway I felt much better getting back to work after a week I spent outside the usual routine. The most important about my comeback is how I feel about things that seemed common and normal before I have taken a fresh look at them. Once I am back I felt myself full of ideas and desire to change things for better.
If we only could change the way things are being done on a daily basis it would open a whole new thinking perspective to us. Instead of banging at the wall with our foreheads we would oversight the problems from above and find a solution we never though as to be existing before.
Every time I come back from vacation things looks a bit differently. It helps me to see in them what I have overlooked before. Hopefully you have the same feeling coming back from a lengthy vacation. Let's trust our fresh look and change things for better!
Happy innovating! :)
If we only could change the way things are being done on a daily basis it would open a whole new thinking perspective to us. Instead of banging at the wall with our foreheads we would oversight the problems from above and find a solution we never though as to be existing before.
Every time I come back from vacation things looks a bit differently. It helps me to see in them what I have overlooked before. Hopefully you have the same feeling coming back from a lengthy vacation. Let's trust our fresh look and change things for better!
Happy innovating! :)
Tuesday, October 20, 2009
Getting complacent is a killer
One of biggest problem of mature companies is becoming complacent. They used to make money, so they believe this is the time to gain. There is no more need to strive for the success. They are already there. Things do the way they used to be, etc...
Wrong! This is so wrong because those who do not think this way will be soon ahead of you. They will eat you for the breakfast if you do not compete, if you do not try becomming better, doing more and achieving things greatest than those you already have achieved.
So, wake up and find out what you can do today to be one step ahead of your competitors tomorrow! :^)
P.S. You may also research for "destructive management" to get more insights on how to manage a company that have signs of becoming complacent.
Wrong! This is so wrong because those who do not think this way will be soon ahead of you. They will eat you for the breakfast if you do not compete, if you do not try becomming better, doing more and achieving things greatest than those you already have achieved.
So, wake up and find out what you can do today to be one step ahead of your competitors tomorrow! :^)
P.S. You may also research for "destructive management" to get more insights on how to manage a company that have signs of becoming complacent.
Wednesday, October 14, 2009
Who whants to test forever...
Today I heard from a coleague of mine that she is going to head off to development. She went to studying Flex technology and had showed not a bad result on the exam. So, most likely I will be in need to find a replacement shortly.
I never liked hiring testers who are about to become developers one day, who approach testing as starting point for the future career in development. On my personal experience, it didn't work too well. Despite I knew some brilliant minds who were equaly successful in testing and in development afetrwards, such things are rather exceptions. (Though there is a chance that a good tester make a good developer too. In contrary, I never saw a bad developer to become a good tester. I appologize if I hurt anyone by last statement though)
Testing and development are adjucent knowledge areas. But they are different. The skills needed for being a good tester are different from those, needed for a developer. If testers think in categories how to break things, developers mostly focus on getting them work. Satisfaction that we get in result come from very different sources. Few of us can feel well both ways. The majority are restricted to just one way of getting satisfied.
Aside from the different qualitties and knowledge needed for testing and development, a person who choses testing as the starting point most probably looses her time, getting wrong experience. Days in testing will be a plus in development, no doubt. It will surely help writing code with fewer defects. But it's the waste of time that could be spent on gaining purely development experience to fill in the resume. So, those who start from testing with aim to move to development do not waste your time! Just go right to development. No compromises!
Not to say what a waste of time of people who invested in teaching wannabe developer it is. It is a huge additional cost for the company. The company usually gets less than it pays for bringing such a developer up.
Anyway, now I am in the situation when I can only react. There is no possibility to change the circumstances because I cannot make that person think that her goal and inner desire are false. Partially because I know that she is sincere in her intentions.
I never liked hiring testers who are about to become developers one day, who approach testing as starting point for the future career in development. On my personal experience, it didn't work too well. Despite I knew some brilliant minds who were equaly successful in testing and in development afetrwards, such things are rather exceptions. (Though there is a chance that a good tester make a good developer too. In contrary, I never saw a bad developer to become a good tester. I appologize if I hurt anyone by last statement though)
Testing and development are adjucent knowledge areas. But they are different. The skills needed for being a good tester are different from those, needed for a developer. If testers think in categories how to break things, developers mostly focus on getting them work. Satisfaction that we get in result come from very different sources. Few of us can feel well both ways. The majority are restricted to just one way of getting satisfied.
Aside from the different qualitties and knowledge needed for testing and development, a person who choses testing as the starting point most probably looses her time, getting wrong experience. Days in testing will be a plus in development, no doubt. It will surely help writing code with fewer defects. But it's the waste of time that could be spent on gaining purely development experience to fill in the resume. So, those who start from testing with aim to move to development do not waste your time! Just go right to development. No compromises!
Not to say what a waste of time of people who invested in teaching wannabe developer it is. It is a huge additional cost for the company. The company usually gets less than it pays for bringing such a developer up.
Anyway, now I am in the situation when I can only react. There is no possibility to change the circumstances because I cannot make that person think that her goal and inner desire are false. Partially because I know that she is sincere in her intentions.
Friday, September 18, 2009
Making the testing better
Despite unit testing has formal metrics that can prove at least minimal level of thoroughness; many organizations struggle to uncover measurement that can help telling how much of unit testing is enough. The minimal level of testing can be measured in terms of code coverage. Code coverage can be as weak as statement to as strong as du-paths. But this is not my goal to explain each of those. My goal is to help those who try finding an alternative measure of unit testing quality.
One of ideas is measuring it post-factum. Well it may be too late to know the truth. Nonetheless this knowledge can be used in the following project to reduce number of defects of a specific sort. I mean the feedback that you receive from testing.
Software is being developed in several stages. Even in Agile, there are stages; but they are shorter and tightly intertwined. Defects injected at a given stage can be found at that stage or at the following ones. Depending on how many defects injected at the stage escaped quality control, we can draw our conclusion about testing quality.
For example, we have created a unit and performed unit tests. In result of testing we have found and fixed 16 issues. But later when a unit comes to Integration and System testing, we discover additional 4 issues attributed to unit. This means that defect removal efficiency of unit testing for that module was:
DRE = (1-4/(16+4))*100%=80%
To enable this measurement you need to analyze issues found at later stages of development. If you have a defect tracking system (and I hope you do) then you can simply introduce the field that will denote to what of development stages a defect can be attributed. The biggest problem here is having defects found at unit testing stage filed somehow. Many developers see it as an additional unneeded paperwork. So, if you are going to implement this metric be prepared to the resistance. You may decrease the pain by claiming only brief information on unit testing defects to be filed (summary only). There are tools that can be integrated into development IDE to soothe this pain for developers.
Other testing stages' effectiveness can be measured the same way. All you need is to collect this information continuously. Two or three projects later you will have plenty of interesting information to think of:
- Why is this module's unit testing is lower in effectiveness than others?
- Why developer A usually produces higher effectiveness than others? Can the latter share the experience to the team?
- Who is responsible for most of the issues down the road? What can you do about it?
Hope this helps! :)
One of ideas is measuring it post-factum. Well it may be too late to know the truth. Nonetheless this knowledge can be used in the following project to reduce number of defects of a specific sort. I mean the feedback that you receive from testing.
Software is being developed in several stages. Even in Agile, there are stages; but they are shorter and tightly intertwined. Defects injected at a given stage can be found at that stage or at the following ones. Depending on how many defects injected at the stage escaped quality control, we can draw our conclusion about testing quality.
For example, we have created a unit and performed unit tests. In result of testing we have found and fixed 16 issues. But later when a unit comes to Integration and System testing, we discover additional 4 issues attributed to unit. This means that defect removal efficiency of unit testing for that module was:
DRE = (1-4/(16+4))*100%=80%
To enable this measurement you need to analyze issues found at later stages of development. If you have a defect tracking system (and I hope you do) then you can simply introduce the field that will denote to what of development stages a defect can be attributed. The biggest problem here is having defects found at unit testing stage filed somehow. Many developers see it as an additional unneeded paperwork. So, if you are going to implement this metric be prepared to the resistance. You may decrease the pain by claiming only brief information on unit testing defects to be filed (summary only). There are tools that can be integrated into development IDE to soothe this pain for developers.
Other testing stages' effectiveness can be measured the same way. All you need is to collect this information continuously. Two or three projects later you will have plenty of interesting information to think of:
- Why is this module's unit testing is lower in effectiveness than others?
- Why developer A usually produces higher effectiveness than others? Can the latter share the experience to the team?
- Who is responsible for most of the issues down the road? What can you do about it?
Hope this helps! :)
Wednesday, September 9, 2009
Management means no friendship?
Not so long ago I partook in a long discussion related to whether or not a manager can have friends among his subordinates. As I remember, the vast majority people in management role believe there is no problem having friendly relationships with your teammates.
But I remember another very successful manager (a top manager) who kept saying "you should not be a friend to your people", "you should not go to lunch with them". Since then I keep replaying this through my mind and all the time it responds with "It is wrong", so I cannot adopt this thinking.
To me, building unnatural barriers is counterproductive. Open communication is a key to effective professional relationships. People are smart enough to pick up the signs of too artificial behavior. They will mind a reason behind it and will start doing the same. So they will never be open with you.
The same top manager once told me "why you cannot speak to me frankly?" How could I if I did not trust him because of his ways of managing people?! That was kind of paradox that we could not solve. I guess he had same problems with others. I heard it many times that people preferred to talk to him what he wanted to hear, not what they thought. No need to say that he was not able to manage the team effectively. So, despite of his experience I would say that he was wrong. Friendly open relationships help managers doing the job. It does not free people up of the responsibility; it rather imposes the responsibility on them. Subordinates tend to feel badly when they did not do things right, when they couldn't keep the promises not only to a manager, but to a friend as well.
Of course, this way of management works not for all of people you will encounter in your managerial career. As I always liked to say "In management there are always several ways to do the same. The way that you like is not the only one. So, keep learning."
It may also depend on the culture. If you have anything to say on this matter I would gladly hear that.
What do you all think? Long to seeing your comments…
But I remember another very successful manager (a top manager) who kept saying "you should not be a friend to your people", "you should not go to lunch with them". Since then I keep replaying this through my mind and all the time it responds with "It is wrong", so I cannot adopt this thinking.
To me, building unnatural barriers is counterproductive. Open communication is a key to effective professional relationships. People are smart enough to pick up the signs of too artificial behavior. They will mind a reason behind it and will start doing the same. So they will never be open with you.
The same top manager once told me "why you cannot speak to me frankly?" How could I if I did not trust him because of his ways of managing people?! That was kind of paradox that we could not solve. I guess he had same problems with others. I heard it many times that people preferred to talk to him what he wanted to hear, not what they thought. No need to say that he was not able to manage the team effectively. So, despite of his experience I would say that he was wrong. Friendly open relationships help managers doing the job. It does not free people up of the responsibility; it rather imposes the responsibility on them. Subordinates tend to feel badly when they did not do things right, when they couldn't keep the promises not only to a manager, but to a friend as well.
Of course, this way of management works not for all of people you will encounter in your managerial career. As I always liked to say "In management there are always several ways to do the same. The way that you like is not the only one. So, keep learning."
It may also depend on the culture. If you have anything to say on this matter I would gladly hear that.
What do you all think? Long to seeing your comments…
Wednesday, September 2, 2009
What makes a Good tester?
Everyone can easily say a good tester from a not as good one. A good tester finds more quality defects. But what makes one to be good tester? What is the difference that helps identifying important sound bugs faster?
First is technique. A good tester knows what the weak points about the application are. If it accepts a text for the input and produces a tagged text as the output, then most likely the issues will start popping up if you feed it a large volume of text. If it ate it successfully then change the text to something developer would not expect for the input. This is a sort of destructive thinking that helped my son breaking seemingly unbreakable toys when he was from 3 to 5. Thinking in categories "what else people usually omit?" helps finding more defects faster.
Second difference is the feeling of urgency. A good tester will explore entire functionality of the application rather than focusing on a small part of it. In result, the number of defects and the severity of defects is usually higher than quantity and quality of defects produced by testers bogged down into details of a specific dialogue. Likewise, a tester who focused on functionality will produce more quality issues than a person who is too deep into UI testing. Small issues reported early in the testing when application is full or crashes may make developers and project manager go mad. You are very likely to hear: "What are you thinking about?" So, better start from beginning and focus on how system works. Of course they may be exceptions. For example, it may be not reasonable to test a part of functionality and get back to it later. Anyway, if it does not cost too much I would rather recommend focusing on what matters now.
Third difference is level of expertise. A good tester can quickly imagine in which way a new functionality can affect the existing one. Knowledge about system functional and structural dependencies can help finding integration issues. Such issues usually have heavy consequence, so they are rated as critical.
Forth difference is seeing it all as a whole. A good tester always finds out how the functionality is supposed to be used and tries it on realistic tasks. There is no need to remind what use case or end-to-end testing is. This is all natural for a highly skilled testing professional to think of what real user is supposed to do with a system. It also helps finding usability issues. Recommendations on how to make system better are always welcome!
I wish all testers around would be good ones. Hopefully this article will help some of the readers to become one :)
First is technique. A good tester knows what the weak points about the application are. If it accepts a text for the input and produces a tagged text as the output, then most likely the issues will start popping up if you feed it a large volume of text. If it ate it successfully then change the text to something developer would not expect for the input. This is a sort of destructive thinking that helped my son breaking seemingly unbreakable toys when he was from 3 to 5. Thinking in categories "what else people usually omit?" helps finding more defects faster.
Second difference is the feeling of urgency. A good tester will explore entire functionality of the application rather than focusing on a small part of it. In result, the number of defects and the severity of defects is usually higher than quantity and quality of defects produced by testers bogged down into details of a specific dialogue. Likewise, a tester who focused on functionality will produce more quality issues than a person who is too deep into UI testing. Small issues reported early in the testing when application is full or crashes may make developers and project manager go mad. You are very likely to hear: "What are you thinking about?" So, better start from beginning and focus on how system works. Of course they may be exceptions. For example, it may be not reasonable to test a part of functionality and get back to it later. Anyway, if it does not cost too much I would rather recommend focusing on what matters now.
Third difference is level of expertise. A good tester can quickly imagine in which way a new functionality can affect the existing one. Knowledge about system functional and structural dependencies can help finding integration issues. Such issues usually have heavy consequence, so they are rated as critical.
Forth difference is seeing it all as a whole. A good tester always finds out how the functionality is supposed to be used and tries it on realistic tasks. There is no need to remind what use case or end-to-end testing is. This is all natural for a highly skilled testing professional to think of what real user is supposed to do with a system. It also helps finding usability issues. Recommendations on how to make system better are always welcome!
I wish all testers around would be good ones. Hopefully this article will help some of the readers to become one :)
Subscribe to:
Posts (Atom)