Recently I have convinced in it myself yet another time. The task looked as simple as generating load on a site accepting several files for parameters. As usual it was easy to record and parametrize scripts, debug and plan the first load.
The difficulties appear during the testing. Every time when I approach load testing the results kind of amaze me. They are not what I would expect. This time was no different. I was amazed and did at least 5 times more test execution than planned originally.
Thanks to my managerial experience I have lend myself some time for contingencies. So it worked well and I met the deadline :)
Every time you plan for load testing keep in mind that this is investigation rather than determined work in sense that we put in it when we approach planning.
Showing posts with label management. Show all posts
Showing posts with label management. Show all posts
Friday, September 10, 2010
Tuesday, August 31, 2010
What a developer wants?
After so many years of driving testing and QA processes I have some possibilities to realize and rights to publish here some of ideas on how things are working from the inside. One of such things is what developers ask of a QA manager.
My top 5 are following:
1. Change defect tracking system
2. Stop reporting duplicates and non-defects
3. Do no find defects too late
4. Stop reporting minor/cosmetic defects in such a number
5. Test design is not review-able
Now back to the details =)
Change the defects tracking system I am always happy when people come to me with their ideas which they think will help them doing their work better. However, I don't like when it stems from the "I don't know what is wrong but I feel that something needs to be changed" intention.
In the past, developers came to me complaining that it takes too much time to work with defects. The only solution they saw was to change the tracking system. I asked in respond what exactly does take time when they work with it. As it turned out the reason of their complaints is not in the system per se but in the time they had to spend understanding the defect and trying to reproduce it. No defect tracking system can change that, so they went out in peace with the idea to leave the old system. Others developers came after... period =)
Stop reporting duplicates and non-defects Yes, this is a problem. But let's see how big it is. On my memory we reported not more than 1% of bad defects. Is that so huge to be whining about at each managers meeting? Nope. Then what was it?... I'll tell you. This is an excuse for not doing own job right. Kind of "hey! they also have problems". It makes them look better in they eyes. What a shame! =)
Do no find defects too late Another problem for testers. We have to find serious problems as soon as they appear in the code. There is no excuse... Wait a minute! What issue are speaking about? That one that developers introduced in the same build? How do you think testers could find it earlier?... We hear such acquisitions too many times. Make sure you take the blame for your own mistakes.
Stop reporting minor/cosmetic defects in such a number The answer is "stop reading them". It's easy =)
Test design is not review-able In majority of cases they just don't care to put some efforts in this. This is merely a laziness that cannot be an excuse :) However, providing a summary of your tests design is always helpful. Remember, those who read your design help you making it better, so it's in your interest to make it easier to them.
My top 5 are following:
1. Change defect tracking system
2. Stop reporting duplicates and non-defects
3. Do no find defects too late
4. Stop reporting minor/cosmetic defects in such a number
5. Test design is not review-able
Now back to the details =)
Change the defects tracking system I am always happy when people come to me with their ideas which they think will help them doing their work better. However, I don't like when it stems from the "I don't know what is wrong but I feel that something needs to be changed" intention.
In the past, developers came to me complaining that it takes too much time to work with defects. The only solution they saw was to change the tracking system. I asked in respond what exactly does take time when they work with it. As it turned out the reason of their complaints is not in the system per se but in the time they had to spend understanding the defect and trying to reproduce it. No defect tracking system can change that, so they went out in peace with the idea to leave the old system. Others developers came after... period =)
Stop reporting duplicates and non-defects Yes, this is a problem. But let's see how big it is. On my memory we reported not more than 1% of bad defects. Is that so huge to be whining about at each managers meeting? Nope. Then what was it?... I'll tell you. This is an excuse for not doing own job right. Kind of "hey! they also have problems". It makes them look better in they eyes. What a shame! =)
Do no find defects too late Another problem for testers. We have to find serious problems as soon as they appear in the code. There is no excuse... Wait a minute! What issue are speaking about? That one that developers introduced in the same build? How do you think testers could find it earlier?... We hear such acquisitions too many times. Make sure you take the blame for your own mistakes.
Stop reporting minor/cosmetic defects in such a number The answer is "stop reading them". It's easy =)
Test design is not review-able In majority of cases they just don't care to put some efforts in this. This is merely a laziness that cannot be an excuse :) However, providing a summary of your tests design is always helpful. Remember, those who read your design help you making it better, so it's in your interest to make it easier to them.
Wednesday, April 28, 2010
"Look into the roots"
One of my colleagues who wanted to leave has claimed that the company has done something wrong to him, so he could not stand being in it any more. After 30 minutes of talking to him I could not make an idea what the reason of his complaints is as well as the complaints themselves remained the mystery to me.
He named such things like advertising that we are looking for a senior specialist and did not bother to suggest that position to him. That's was unfortunate because we considered him on very that position several months and he did not manage to impress the customer well enough. I asked "why didn't you come to me to discuss it?" He responded that "Anyways, this is not as big a problem as..."
The next reason he called out was the lack of work in the crisis times. Well I accepted that was the case and many people were sitting on the bench whereas the company tried to find the work for them. They were underpaid but this was done to keep the team. Those who could not stand such conditions have found another job. But that colleague of mine didn’t. I asked him why and didn't get the response either. He used the same tactics and jumped to the next complain which was about his personal attitude to work. He insisted that it was not exciting enough. So this might be a case. Nonetheless this is not the type of a problem one could not decide with a manager. But he never came to me with this.
In the end I decided that he complains not about the conditions but about his own behaviors in those conditions. I quickly figured that I can do nothing about it and let him go to find himself in another place (I purposely did not use word "better" here).
What the wisdom we could elicit from this short story? Obviously, if we cannot stand something or don't like something about our works or in more general sense about our lives them go an change it. Do not wait until the boomerang to hit you in the back.
And never fake the reason why you leave the company. Aside from not giving a chance for the company to fix the problem you make a bad impression of yourslef, so no one will miss you after all.
He named such things like advertising that we are looking for a senior specialist and did not bother to suggest that position to him. That's was unfortunate because we considered him on very that position several months and he did not manage to impress the customer well enough. I asked "why didn't you come to me to discuss it?" He responded that "Anyways, this is not as big a problem as..."
The next reason he called out was the lack of work in the crisis times. Well I accepted that was the case and many people were sitting on the bench whereas the company tried to find the work for them. They were underpaid but this was done to keep the team. Those who could not stand such conditions have found another job. But that colleague of mine didn’t. I asked him why and didn't get the response either. He used the same tactics and jumped to the next complain which was about his personal attitude to work. He insisted that it was not exciting enough. So this might be a case. Nonetheless this is not the type of a problem one could not decide with a manager. But he never came to me with this.
In the end I decided that he complains not about the conditions but about his own behaviors in those conditions. I quickly figured that I can do nothing about it and let him go to find himself in another place (I purposely did not use word "better" here).
What the wisdom we could elicit from this short story? Obviously, if we cannot stand something or don't like something about our works or in more general sense about our lives them go an change it. Do not wait until the boomerang to hit you in the back.
And never fake the reason why you leave the company. Aside from not giving a chance for the company to fix the problem you make a bad impression of yourslef, so no one will miss you after all.
Friday, March 26, 2010
Who decides if the product ready?
In my career I have often been in the situation when I was asked whether or not the product is ready to be shipped. After so many times I was through it I still hesitate when I am asked this question. The reason why I couldn't answer it for sure is that I do not have all the required information to draw a decision.
Being a quality manager all I can judge upon is the quality. But the quality is not the mere criteria to take into consideration when trying to figure if you are ready to release. There are also business demands and limitations, promises made to customers, market situation, corporate strategy, and so on. All those questions are beyond the authority of a quality manager.
So, what to do if you are asked this question yet. Below is how I would behave at different positions.
Quality manager
Above I mentioned that the only criteria you can asses is the quality. You have to start answering this question since the very start of the project. You have to build this answer with all the activities on testing and QA throughout the project timeline. Start building it up from the very beginning - test strategy and keep it in sight all the time. Assess and mitigate quality risks. as you learn new information about the product do the corrections of testing course.
When it's time to answer this question, use all the information you have collected. Just compare metrics against previous similar releases (or against you previous experience with similar systems) and state things as they are, without too much of optimism. If the product is a crap say so. Don't be afraid. You will not be punished for the truth in case you kept saying so all the time when you were asked. Saying that everything is fine during the project and demanding that it's a crap in the end looks unprofessional.
Providing your answer make sure that everyone understands that you are talking of QUALITY CRITERIA ONLY. So that no one can bear an incorrect opinion that you are taking the responsibility for a BUSINESS DECISION.
The best way to say it IMO:
- All the testing we have planned is completed. No issues that are considered critical for the release are open. Latest cycles of testing did not reveal many regression issues. The changes in the latest builds were scarce and undergo all a strict process of risk assessment and regression testing. Fixes which were too risky to do have been moved on to the next version. I can say that we are in good shape from the quality perspective.
In case it's not as good you may also add:
- However, we have experienced significant problems with testing the system under high load. The tools that we have used did not allow us generating required load capacity. So, we do not know how system reacts to peak load. It is a risk for the system operation. After discussion with management we decided that this risk can be accepted.
In the case when it's not good at all:
- Every time we start testing the system it brings many new issues. Defect arrival rate is at almost the same rate all the time. It stays as high as X defects per day till the very end of testing cycle. I would strongly recommend analyzing the reason why we introduce so many defects, improve the process and do another cycle of development and testing to create a product of acceptable quality.
Project manager
As a project manager you have to be sure that your quality manager is confident with the quality of the release. If it is not the case then try to find out the nature of the risks. Assess those risks against project goals and made a decision. It can be a hard one nonetheless you are in better position to make it than anyone else on the project team.
Software tester
I knew several top managers who liked asking it to software testers. They believed that they can get to know the information from first hands, thus testing the correctness of information provided by middle level managers. I don't think this is a good idea. Anyway, as a tester, you need to be prepared. Before giving the answer, make it clear that you can answer only based on YOUR experience with the system. Your experience may be limited to some module or type of testing. If it went good then say that only that system's feature is OK. Do not pretend you possess all the information to say so about the whole product. This may be a killer. I also was in the situation when I was asked "why do you say that everything goes smooth if your guy told me that his module is full of bugs and he sees no end to it?" or opposite "why do you keep telling me that things go so badly when your guys report the system is fine?". Do not put your manager in the situation like this.
Top manager
Well you have someone to report to (board of directors or something) you also need to weight your words. The most dangerous but exciting about your position is that this decision is completely yours. So, don't show a weakness and don't expect that someone else will step up and do it for you. All the responsibility as well as all the fame is yours.
Before making a decision, ask your managers (quality and production). But don't be pushy. Do not force them saying what you want to hear. Be as objective as you can.
It's all for now. Sorry for a mess in thoughts I wrote it real fast. Hope this helps you avoid embarrassing situation when you are asked if the product is ready to be released.
Being a quality manager all I can judge upon is the quality. But the quality is not the mere criteria to take into consideration when trying to figure if you are ready to release. There are also business demands and limitations, promises made to customers, market situation, corporate strategy, and so on. All those questions are beyond the authority of a quality manager.
So, what to do if you are asked this question yet. Below is how I would behave at different positions.
Quality manager
Above I mentioned that the only criteria you can asses is the quality. You have to start answering this question since the very start of the project. You have to build this answer with all the activities on testing and QA throughout the project timeline. Start building it up from the very beginning - test strategy and keep it in sight all the time. Assess and mitigate quality risks. as you learn new information about the product do the corrections of testing course.
When it's time to answer this question, use all the information you have collected. Just compare metrics against previous similar releases (or against you previous experience with similar systems) and state things as they are, without too much of optimism. If the product is a crap say so. Don't be afraid. You will not be punished for the truth in case you kept saying so all the time when you were asked. Saying that everything is fine during the project and demanding that it's a crap in the end looks unprofessional.
Providing your answer make sure that everyone understands that you are talking of QUALITY CRITERIA ONLY. So that no one can bear an incorrect opinion that you are taking the responsibility for a BUSINESS DECISION.
The best way to say it IMO:
- All the testing we have planned is completed. No issues that are considered critical for the release are open. Latest cycles of testing did not reveal many regression issues. The changes in the latest builds were scarce and undergo all a strict process of risk assessment and regression testing. Fixes which were too risky to do have been moved on to the next version. I can say that we are in good shape from the quality perspective.
In case it's not as good you may also add:
- However, we have experienced significant problems with testing the system under high load. The tools that we have used did not allow us generating required load capacity. So, we do not know how system reacts to peak load. It is a risk for the system operation. After discussion with management we decided that this risk can be accepted.
In the case when it's not good at all:
- Every time we start testing the system it brings many new issues. Defect arrival rate is at almost the same rate all the time. It stays as high as X defects per day till the very end of testing cycle. I would strongly recommend analyzing the reason why we introduce so many defects, improve the process and do another cycle of development and testing to create a product of acceptable quality.
Project manager
As a project manager you have to be sure that your quality manager is confident with the quality of the release. If it is not the case then try to find out the nature of the risks. Assess those risks against project goals and made a decision. It can be a hard one nonetheless you are in better position to make it than anyone else on the project team.
Software tester
I knew several top managers who liked asking it to software testers. They believed that they can get to know the information from first hands, thus testing the correctness of information provided by middle level managers. I don't think this is a good idea. Anyway, as a tester, you need to be prepared. Before giving the answer, make it clear that you can answer only based on YOUR experience with the system. Your experience may be limited to some module or type of testing. If it went good then say that only that system's feature is OK. Do not pretend you possess all the information to say so about the whole product. This may be a killer. I also was in the situation when I was asked "why do you say that everything goes smooth if your guy told me that his module is full of bugs and he sees no end to it?" or opposite "why do you keep telling me that things go so badly when your guys report the system is fine?". Do not put your manager in the situation like this.
Top manager
Well you have someone to report to (board of directors or something) you also need to weight your words. The most dangerous but exciting about your position is that this decision is completely yours. So, don't show a weakness and don't expect that someone else will step up and do it for you. All the responsibility as well as all the fame is yours.
Before making a decision, ask your managers (quality and production). But don't be pushy. Do not force them saying what you want to hear. Be as objective as you can.
It's all for now. Sorry for a mess in thoughts I wrote it real fast. Hope this helps you avoid embarrassing situation when you are asked if the product is ready to be released.
Saturday, January 16, 2010
A silly question: why testing takes long?
Recently I came across an amusing post on one of professional forums dedicated to testing. The post was an elaborated description of how to convince management that testing needs so much time to complete. The author worked his way beautifully introducing parameters and formulas, ezplaining assumptions and proving theories with examples. Great job - no doubt! But... it's all useless :)
No manager will care to read it through and through. None!
The mere fact that the management needs to be convinced in things that SHALL BE OBVIOUS is a problem per se. With that multi-pages work author only supposed to solve the symptoms instead of targeting the disease root-cause.
What could be the root cause for the managers to doubt that testing team work efficiently? What managers need from testing to be in order to feel comfortable about its performance? I am sure you guessed right :) All they expect from your team is VISIBILITY. Just let them see what it takes to define strategy, make required environmental preparations, procure and learn tools, create tests, combine suites, execute tests, submit defects, work with fixed and rejected defects, and so on. I you manage to build a transparent process that everyone can watch in the motion you will never ever be asked to prove that you spend your resource cycles effectively.
Another important issue is getting management involved in taking all important decisions. Make them not just supervisors but active contributors. Share with managers all the important decisions, discuss and argue your position. Let them help you with their experience as well as let them see your professional level by providing them technical assistance. Once a decision is not just your but theirs as well they start feeling much better :)
In short, this is all you need to make sure that you are never asked that silly question - "Why does testing take so long?!"
No manager will care to read it through and through. None!
The mere fact that the management needs to be convinced in things that SHALL BE OBVIOUS is a problem per se. With that multi-pages work author only supposed to solve the symptoms instead of targeting the disease root-cause.
What could be the root cause for the managers to doubt that testing team work efficiently? What managers need from testing to be in order to feel comfortable about its performance? I am sure you guessed right :) All they expect from your team is VISIBILITY. Just let them see what it takes to define strategy, make required environmental preparations, procure and learn tools, create tests, combine suites, execute tests, submit defects, work with fixed and rejected defects, and so on. I you manage to build a transparent process that everyone can watch in the motion you will never ever be asked to prove that you spend your resource cycles effectively.
Another important issue is getting management involved in taking all important decisions. Make them not just supervisors but active contributors. Share with managers all the important decisions, discuss and argue your position. Let them help you with their experience as well as let them see your professional level by providing them technical assistance. Once a decision is not just your but theirs as well they start feeling much better :)
In short, this is all you need to make sure that you are never asked that silly question - "Why does testing take so long?!"
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.
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…
Friday, August 28, 2009
Test design: do it right the first time!
If you are in software testing field you probably noted how difficult it is to grasp the idea behind the test cases when all you see is a collection of steps presented for review. This is too easy to get bogged down into step details. You may have even got this impression "Wait a minute! I wanted to review what is supposed to be tested instead of reading individual steps trying to compile them into logical test sequences!" If you did – then read on. Some advises may prove to be useful for you. If you never experienced such issue read on anyway. The fact you never noted the problem does not mean it cannot not hit you ;) Remember, this is not what you know will kill you.
The solution to the problem is of the same sort as we used to apply in other types of activities - early validation. So, you need the means to early identify problems with your design, until it gets "hardcoded" into written form, with steps and test data. The question remains – how to present testing ideas in a short and convenient for review form? There are a couple of ideas. Both proved to be quite successful in my experience.
The first idea is to generate a list of test conditions or test requirements before starting to generate test cases. The list can be presented in form of a tree:
- file types:
---- doc
---- txt
---- pdf
---- xml
- file content:
---- text
---- pictures
---- text + pictures
- file size:
---- large
---- empty
The time needed to generate such a list is negligible. You don't even need to bother about test data at this point. The whole idea you put behind the testing may be wrong, so time spent for creating complex test files will be a total waste.
Tree forms allows for easy review. It helps providing your thoughts in a structured way and keeps reader's attention at one context at a time, thus improving the quality of analysis. Seeing such a list one may easily find out that there are no tests for specific conditions (text in UT8 format for example). The only problem with this approach is that you do not tell how you are going to validate those conditions.
Another way is providing an overview along with your test design. It works as well to better review process, but it does not help against rework. If you have chosen wrong way in your design, you will need to re-develop your test cases.
Overview is written for the reviewer. It shall answer the following questions:
- What is supposed to be tested?
- How is it supposed to be tested?
- What conditions are to be tried out?
- How the results are going to verified?
- Whether or not automated testing will be used?
- Risks and limitations of selected testing strategy.
Having the answers on these questions will allow a reviewer to easily grasp the ideas behind the testing and to validate them.
Test design review is a hard task because there is a lot of a detail. The main goal of review is not to make sure details are correct. We are much more interested to see if testing design is adequate to get confidence that, once it pass, we have a quality product. There is no need to provide obscuring details to review. The early you present your work to review and the easiest it will be to understand it - the best quality and productivity you can achieve.
The solution to the problem is of the same sort as we used to apply in other types of activities - early validation. So, you need the means to early identify problems with your design, until it gets "hardcoded" into written form, with steps and test data. The question remains – how to present testing ideas in a short and convenient for review form? There are a couple of ideas. Both proved to be quite successful in my experience.
The first idea is to generate a list of test conditions or test requirements before starting to generate test cases. The list can be presented in form of a tree:
- file types:
---- doc
---- txt
---- xml
- file content:
---- text
---- pictures
---- text + pictures
- file size:
---- large
---- empty
The time needed to generate such a list is negligible. You don't even need to bother about test data at this point. The whole idea you put behind the testing may be wrong, so time spent for creating complex test files will be a total waste.
Tree forms allows for easy review. It helps providing your thoughts in a structured way and keeps reader's attention at one context at a time, thus improving the quality of analysis. Seeing such a list one may easily find out that there are no tests for specific conditions (text in UT8 format for example). The only problem with this approach is that you do not tell how you are going to validate those conditions.
Another way is providing an overview along with your test design. It works as well to better review process, but it does not help against rework. If you have chosen wrong way in your design, you will need to re-develop your test cases.
Overview is written for the reviewer. It shall answer the following questions:
- What is supposed to be tested?
- How is it supposed to be tested?
- What conditions are to be tried out?
- How the results are going to verified?
- Whether or not automated testing will be used?
- Risks and limitations of selected testing strategy.
Having the answers on these questions will allow a reviewer to easily grasp the ideas behind the testing and to validate them.
Test design review is a hard task because there is a lot of a detail. The main goal of review is not to make sure details are correct. We are much more interested to see if testing design is adequate to get confidence that, once it pass, we have a quality product. There is no need to provide obscuring details to review. The early you present your work to review and the easiest it will be to understand it - the best quality and productivity you can achieve.
Tuesday, August 11, 2009
Interviewing candidates
I have done it many times. A lot of lessons were learned. However, even now, from the heights of experience, I realize that I still can fail. The reason is that people are very creative if it comes to making impression. The more intelligent a person who sits against you in the interview, the more difficult it is to probe the true qualities of that person. Being smart is just one of qualities that you look in candidates. It defines aptitude to some degree. However, this is far not all that you may need to find out.
If a person is smart enough he or she may tell you rather what you want to hear, not what he or she is thinking. So, in result, you may get a wrong image of a candidate. Such a hire, if made, may prove to be wrong not only for you, but for a hired person as well. So, it makes sense to put it clear right before interview that this is not only the examination of person's qualities but also a test if a person fits the position. The later will be evident in a while. So, you both better not to waste time and to be honest. A candidate must be honest about achievements and experience as well as you must be honest in your responses (overtime work, salary increases, etc.). Lie leads to another lie. Don't start your relationships in the wrong way.
Now back to the interview… I used to think of candidates in terms of three A (Attitude, Aptitude, and Achievements). Fist two “A” are most important for newbie candidates. The last one is extremely important for a senior position.
Attitude is how a person sees his or her future in your company. This is a measure of desire to work in your team, the level of loyalty. And this is what candidates are dishonest about most of the time. So, do not believe just words. Look at the reaction of a person to specific questions. If there is lie you should guess it from the looks and gestures with easy.
Aptitude is how candidate's skills cover requirements of a position. Some things can be caught up at easy. Some can't. The difference is crucial. If there is anything in a candidate that makes you believe he or she will not be 100% efficient in a new role and if you are not sure you can fix that - never hire such a candidate.
Achievement is demonstration of the skills at the tasks similar to one you want a candidate to perform in the future. If the tasks are different and he or she will have to do incomparably different things then you better consider him or her to be a newbie.
Hiring newbie is more complicated because you simply do not know what to ask. Usually we ask people to describe what they did in the past and drive their talking with questions. A newbie do not have achievements to talk about, so you need to use standard cliché questions like "why you have chosen this domain?", "what have you read on this?", "what do you want to achieve in 5 years from now?", "what are you ambitions?" and so on. But those questions will reveal just a bit of a candidate. To learn more, I used to give them short tests, which allow me judge upon professional qualities. I use these tests for more than 10 years and have never regret about it.
What a test may be? Well, for a software tester this is a quick test to produce as many as possible tests for a simple function of a well known and broadly used software product. Calculator or Notepad will do just perfect. The answer not only indicates candidate’s natural ability to create test cases, it also provides you some feedback on how good a person is at using the software at all. You may guess it by the depth of the testing a candidate is generating. One may come up with tests for Undo operation, another may have it omitted.
Such tests can be developed for any position. For a developer it can be a test task to design a simple system using OOP, or to write a piece of code on a paper. For a technical writer it may be a quick description of some software function. System architect shall be able to come up with a solution to the architectural problem that you faced in the past. Or it may be just a sketchy design of a system described right at the meeting (chat machine of online magazine, for example).
Yes, such tests will require your time and time of a candidate. But you will hardly be able to gauge person’s abilities without it. Only practical task show how good candidate is at work that you want him or her to do in the future.
Of course, aside of above, there are still a lot of things to look at. How a person will be able to meet deadlines? Is the level of responsibility is high enough? Can this person learn new things quickly? Is there any problem with communication? And so on.
Sorry for this a bit clumsy but hopefully useful piece of information. I will get to it back when I have time to polish it.
If a person is smart enough he or she may tell you rather what you want to hear, not what he or she is thinking. So, in result, you may get a wrong image of a candidate. Such a hire, if made, may prove to be wrong not only for you, but for a hired person as well. So, it makes sense to put it clear right before interview that this is not only the examination of person's qualities but also a test if a person fits the position. The later will be evident in a while. So, you both better not to waste time and to be honest. A candidate must be honest about achievements and experience as well as you must be honest in your responses (overtime work, salary increases, etc.). Lie leads to another lie. Don't start your relationships in the wrong way.
Now back to the interview… I used to think of candidates in terms of three A (Attitude, Aptitude, and Achievements). Fist two “A” are most important for newbie candidates. The last one is extremely important for a senior position.
Attitude is how a person sees his or her future in your company. This is a measure of desire to work in your team, the level of loyalty. And this is what candidates are dishonest about most of the time. So, do not believe just words. Look at the reaction of a person to specific questions. If there is lie you should guess it from the looks and gestures with easy.
Aptitude is how candidate's skills cover requirements of a position. Some things can be caught up at easy. Some can't. The difference is crucial. If there is anything in a candidate that makes you believe he or she will not be 100% efficient in a new role and if you are not sure you can fix that - never hire such a candidate.
Achievement is demonstration of the skills at the tasks similar to one you want a candidate to perform in the future. If the tasks are different and he or she will have to do incomparably different things then you better consider him or her to be a newbie.
Hiring newbie is more complicated because you simply do not know what to ask. Usually we ask people to describe what they did in the past and drive their talking with questions. A newbie do not have achievements to talk about, so you need to use standard cliché questions like "why you have chosen this domain?", "what have you read on this?", "what do you want to achieve in 5 years from now?", "what are you ambitions?" and so on. But those questions will reveal just a bit of a candidate. To learn more, I used to give them short tests, which allow me judge upon professional qualities. I use these tests for more than 10 years and have never regret about it.
What a test may be? Well, for a software tester this is a quick test to produce as many as possible tests for a simple function of a well known and broadly used software product. Calculator or Notepad will do just perfect. The answer not only indicates candidate’s natural ability to create test cases, it also provides you some feedback on how good a person is at using the software at all. You may guess it by the depth of the testing a candidate is generating. One may come up with tests for Undo operation, another may have it omitted.
Such tests can be developed for any position. For a developer it can be a test task to design a simple system using OOP, or to write a piece of code on a paper. For a technical writer it may be a quick description of some software function. System architect shall be able to come up with a solution to the architectural problem that you faced in the past. Or it may be just a sketchy design of a system described right at the meeting (chat machine of online magazine, for example).
Yes, such tests will require your time and time of a candidate. But you will hardly be able to gauge person’s abilities without it. Only practical task show how good candidate is at work that you want him or her to do in the future.
Of course, aside of above, there are still a lot of things to look at. How a person will be able to meet deadlines? Is the level of responsibility is high enough? Can this person learn new things quickly? Is there any problem with communication? And so on.
Sorry for this a bit clumsy but hopefully useful piece of information. I will get to it back when I have time to polish it.
Walking problem
What if one of your team members appears to be a problem? He or she may not fit into the team and having such a person among the others may prove to be too risky. People are getting infected with examples of bad behavior way too fast. (I wish they did as well mimicking something good, *sigh*)
The first advice is not to lay it off for too long. Yes. This is harsh business but it has to be done. Otherwise what kind of a manager you are? I usually start fro, talking to a person explaining him or her: what is wrong with the behavior and how it affects the team. Once a person is aware of the problem he or she can do something about it. In this respect, this is a service to a person that you do.
It may not be as easy though. Some people take critics personally. It may make your efforts all in vain. It helps to explain that the reason you are talking to your team mate now is not to "put in place" but to help, help to grow, help to get better.
Mostly, things are looking too good from the inside. We all fool ourselves that we work as well as it can only be. The reality is a little bit different. The extent in which it differs depends on our inner qualities. Some assess their achievements with due criticism. Some think that they do much better than others having no real reason to think so.
Your goal is to provide objective feedback on the achievements. Do not forget to mention good ones. It will make your team mate more open to discussion. And it's always better to start meeting from talking about positive achievements. Remember, you goal is a constructive discussion. Having someone in bad resistive mood will make things much more complicated.
Once you delivered your viewpoint explain the consequences. I usually make it clear if I am going to let a person go in case there is no progress on the improvement plan. This is tough but fair. Do not try to make corners flat. Just put it clear.
Then sit together and define strategy of how to make it all better for a person and for the team. Once you have a plan, define deadlines and metrics that will help making sure you have achieved the goals.
Following these simple recommendations may save you a lot of time and nerves.
The first advice is not to lay it off for too long. Yes. This is harsh business but it has to be done. Otherwise what kind of a manager you are? I usually start fro, talking to a person explaining him or her: what is wrong with the behavior and how it affects the team. Once a person is aware of the problem he or she can do something about it. In this respect, this is a service to a person that you do.
It may not be as easy though. Some people take critics personally. It may make your efforts all in vain. It helps to explain that the reason you are talking to your team mate now is not to "put in place" but to help, help to grow, help to get better.
Mostly, things are looking too good from the inside. We all fool ourselves that we work as well as it can only be. The reality is a little bit different. The extent in which it differs depends on our inner qualities. Some assess their achievements with due criticism. Some think that they do much better than others having no real reason to think so.
Your goal is to provide objective feedback on the achievements. Do not forget to mention good ones. It will make your team mate more open to discussion. And it's always better to start meeting from talking about positive achievements. Remember, you goal is a constructive discussion. Having someone in bad resistive mood will make things much more complicated.
Once you delivered your viewpoint explain the consequences. I usually make it clear if I am going to let a person go in case there is no progress on the improvement plan. This is tough but fair. Do not try to make corners flat. Just put it clear.
Then sit together and define strategy of how to make it all better for a person and for the team. Once you have a plan, define deadlines and metrics that will help making sure you have achieved the goals.
Following these simple recommendations may save you a lot of time and nerves.
Wednesday, July 29, 2009
Why do many performance appraisal initiatives fail?
The key to company success is people. Performers is what build tomorrow of every organization. The way they spend their working time today directly affects the company's outcome tomorrow. Many companies do not just rely on people themselves to drive personal performance. Not everyone has that nagging second self inside which does not allow staying complacent.
Almost all companies want to drive personal performance. Many companies think that they do. And just a few actually do it. Despite the idea is quite simple, implementation is what makes the difference.
There are almost infinite numbers of ways, in which a good endeavor can fail. Personal performance management is not an exception. Below are recommendations, failure scenarios and things to avoid while establishing a reliable performance management program. I have derived it from my own experience. It comes from the real world cases.
Process tips:
- Do it regularly, but at least once a year.
- Do it consistent throughout the organization.
- Gather information for the appraisal from more than one source (the more, the
better).
- Provide improvement plan within the appraisal.
- Track improvement plan execution.
- Meet in person to discuss the appraisal.
Failure scenarios:
- Lack of initiative on management side. Managers clearly do not understand why they need it. As the main driving force is down, the whole process collapses. In order to avoid, one needs to sell off the idea to managers, so they agree spending time for working on appraisals. Create a plan and demand following it strictly.
- Lack of credibility to what is stated in the appraisal on the side of the employee. In order to eliminate this factor, let employee know how many people participated in providing information for the appraisal.
- Attempting to create a Magic formula. Quantitative metrics (how many lines of code, defects, tests, etc.) are good source of information on performance. But those metrics need additional analysis. How complex a problem solved was? How big was the responsibility and time pressure? What was the quality? - Do not try adding more parameters to cover all those deviations! You’re either find yourself in the middle of near infinite number of scenarios or you will fool yourself with some compromise variant (one of many). Better stick to qualitative parameters (excellent, good, mediocre, bad) to assess the appraised features.
Things to avoid:
- Subjectivity is the killer. Gather information from as many sources as possible.
- Disagreement can severely undermine the efficiency. Make sure all disagreements between you and employee are settled.
- Taking it too lightly can let any good initiative die silently. Keep re-stating how important it is for the company and the goal the process is pursuing.
Following the tips above, having in mind failure scenarios, and avoiding traps will help you define the process that actually works. Good luck!
Almost all companies want to drive personal performance. Many companies think that they do. And just a few actually do it. Despite the idea is quite simple, implementation is what makes the difference.
There are almost infinite numbers of ways, in which a good endeavor can fail. Personal performance management is not an exception. Below are recommendations, failure scenarios and things to avoid while establishing a reliable performance management program. I have derived it from my own experience. It comes from the real world cases.
Process tips:
- Do it regularly, but at least once a year.
- Do it consistent throughout the organization.
- Gather information for the appraisal from more than one source (the more, the
better).
- Provide improvement plan within the appraisal.
- Track improvement plan execution.
- Meet in person to discuss the appraisal.
Failure scenarios:
- Lack of initiative on management side. Managers clearly do not understand why they need it. As the main driving force is down, the whole process collapses. In order to avoid, one needs to sell off the idea to managers, so they agree spending time for working on appraisals. Create a plan and demand following it strictly.
- Lack of credibility to what is stated in the appraisal on the side of the employee. In order to eliminate this factor, let employee know how many people participated in providing information for the appraisal.
- Attempting to create a Magic formula. Quantitative metrics (how many lines of code, defects, tests, etc.) are good source of information on performance. But those metrics need additional analysis. How complex a problem solved was? How big was the responsibility and time pressure? What was the quality? - Do not try adding more parameters to cover all those deviations! You’re either find yourself in the middle of near infinite number of scenarios or you will fool yourself with some compromise variant (one of many). Better stick to qualitative parameters (excellent, good, mediocre, bad) to assess the appraised features.
Things to avoid:
- Subjectivity is the killer. Gather information from as many sources as possible.
- Disagreement can severely undermine the efficiency. Make sure all disagreements between you and employee are settled.
- Taking it too lightly can let any good initiative die silently. Keep re-stating how important it is for the company and the goal the process is pursuing.
Following the tips above, having in mind failure scenarios, and avoiding traps will help you define the process that actually works. Good luck!
Monday, July 20, 2009
Automated tests: the sooner the better!
This is the most impressive experience I gained in my entire professional career. Read on and you will probably find it worth of trying.
Several years ago we faced the need to dramatically increase test automation coverage. Let the reasons be aside for now and let's focus on the problem per se. We had complex UI-driven software, full of custom controls and volatile UI elements changed from release to release. Our experience in test automation was refrained to the collection of several hundred tests that we occasionally used for smoke and regression testing. In order to get where we needed to be we had to automate ten thousand tests in a very short period of time, 1-2 years.
At the first glance the problem had no solution. It was really hard to be in that situation, when you see no way out. But we started the project having no idea if it's going to be successful. We started from optimizing of what we already can do, divided team in two sub-teams (one team focused on test design and manual execution, another took responsibility for test automation). We also introduced all the best practices that helped us to keep test production and maintenance cost low.
But this was not enough. Automation team was always behind testing process because they needed time to implement and debug test code on a working system. With insignificant exceptions, so, we could not use automated tests for functional test execution during the production cycle. We could only use it for regression testing of future versions. Tests still needed to be executed manually at least once. It had severe impact on testing schedule and drug us back because manual team was always on a critical path.
Then we’ve got an idea. It was as easy as it could only be. As far as implementation phase is what makes automation team fall behind we have to shorten it somehow. Adding resources is not an option. We already had several people working on this project and adding more people could severely increase overhead cost of communication. We went anther way.
Instead of adding resources we decided to move a part of test automation preparation task back in time, to do them in advance. We decided to do design of automated tests long before a working version is made available. Design means that we created fish bones of tests. Those tests used virtual functions that, when implemented, allow manipulating application features. Functions remained not implemented until we have a working version of a product in our hands. So, the tests could not be debugged until that time. But the most of design work is already done. And our experience indicated that this part is very significant.
When a new version of application comes to testing, automation engineers started implementation phase. They simply added code to the helper functions to make the test work. After that they run and debugged tests.
I will demonstrate how it worked in example:
1. We need to test a web search system that allows users to run the search, browse results and bookmark interesting findings.
2. Automation engineers select tests for automation. For example they have selected the following tests:
a. Different types of queries ("", "my search", "very-very-very long string").
b. Browse results (pages 1 through 10).
3. Automation team has steps of tests and test data defined in the test description created by manual team. So, thy create test architecture design like this:
test 1 - Different types of queries
test01_Search (String query, Integer expected) {
login();
doSearch(query);
assertEqual(getResults().totalCount, expected);
}
Used functions login(), doSearch(), and getResults() are not implemented so far! We have only figured out which functions we will need to enable our tests work.
Note: In order to do it safely it is recommended to insert a string of code that will fail your tests until function is not implemented, like this:
function doSearch(String query) {
fail('Not implemented');
}
Test that go through pages of results could be looking like follows:
test02_Paging (String query, Integer expected) {
String[] pageTokens = {"page1", ..."page 10"};
login();
doSearch(query);
for (int i=1; i<=10; i++) {
goToPage(i);
assertEqual(getPageToken(), pageTokens[i]);
}
}
Same way we can Design all tests that we selected for automation in advance. Thus we are saving this time from implementation and shorten the duration of automation. As practice had shown we can save up to 50% of time allocated for test automation. Roughly assessing, design phase is accounted for a half time allocated for the automation. So we shorten the second phase in a half, allowing automated tests to be ready sooner in the testing cycle.
Using this technology we have achieved the ratio of tests executed manually and automatically 1:1. This means that only a half of tests were executed manually each new release. Another half of tests were executed as automated right away. This had greatly increased automation ROI because we had no need to execute them manually at all and saved up to 40% of manual testing resources each release. Additionally, automated tests could be used for in-project regression testing much earlier. It also helped to get much of benefit from the idea.
In general, this approach had completely changed the role automated testing played in our project, making it at least as important and effective as manual testing.
Hope this helps making your test automation effort more fun! :) Feel free to comment should you have questions on details of implementation or should you have risks that may prevent you from having it work for you.
Several years ago we faced the need to dramatically increase test automation coverage. Let the reasons be aside for now and let's focus on the problem per se. We had complex UI-driven software, full of custom controls and volatile UI elements changed from release to release. Our experience in test automation was refrained to the collection of several hundred tests that we occasionally used for smoke and regression testing. In order to get where we needed to be we had to automate ten thousand tests in a very short period of time, 1-2 years.
At the first glance the problem had no solution. It was really hard to be in that situation, when you see no way out. But we started the project having no idea if it's going to be successful. We started from optimizing of what we already can do, divided team in two sub-teams (one team focused on test design and manual execution, another took responsibility for test automation). We also introduced all the best practices that helped us to keep test production and maintenance cost low.
But this was not enough. Automation team was always behind testing process because they needed time to implement and debug test code on a working system. With insignificant exceptions, so, we could not use automated tests for functional test execution during the production cycle. We could only use it for regression testing of future versions. Tests still needed to be executed manually at least once. It had severe impact on testing schedule and drug us back because manual team was always on a critical path.
Then we’ve got an idea. It was as easy as it could only be. As far as implementation phase is what makes automation team fall behind we have to shorten it somehow. Adding resources is not an option. We already had several people working on this project and adding more people could severely increase overhead cost of communication. We went anther way.
Instead of adding resources we decided to move a part of test automation preparation task back in time, to do them in advance. We decided to do design of automated tests long before a working version is made available. Design means that we created fish bones of tests. Those tests used virtual functions that, when implemented, allow manipulating application features. Functions remained not implemented until we have a working version of a product in our hands. So, the tests could not be debugged until that time. But the most of design work is already done. And our experience indicated that this part is very significant.
When a new version of application comes to testing, automation engineers started implementation phase. They simply added code to the helper functions to make the test work. After that they run and debugged tests.
I will demonstrate how it worked in example:
1. We need to test a web search system that allows users to run the search, browse results and bookmark interesting findings.
2. Automation engineers select tests for automation. For example they have selected the following tests:
a. Different types of queries ("", "my search", "very-very-very long string").
b. Browse results (pages 1 through 10).
3. Automation team has steps of tests and test data defined in the test description created by manual team. So, thy create test architecture design like this:
test 1 - Different types of queries
test01_Search (String query, Integer expected) {
login();
doSearch(query);
assertEqual(getResults().totalCount, expected);
}
Used functions login(), doSearch(), and getResults() are not implemented so far! We have only figured out which functions we will need to enable our tests work.
Note: In order to do it safely it is recommended to insert a string of code that will fail your tests until function is not implemented, like this:
function doSearch(String query) {
fail('Not implemented');
}
Test that go through pages of results could be looking like follows:
test02_Paging (String query, Integer expected) {
String[] pageTokens = {"page1", ..."page 10"};
login();
doSearch(query);
for (int i=1; i<=10; i++) {
goToPage(i);
assertEqual(getPageToken(), pageTokens[i]);
}
}
Same way we can Design all tests that we selected for automation in advance. Thus we are saving this time from implementation and shorten the duration of automation. As practice had shown we can save up to 50% of time allocated for test automation. Roughly assessing, design phase is accounted for a half time allocated for the automation. So we shorten the second phase in a half, allowing automated tests to be ready sooner in the testing cycle.
Using this technology we have achieved the ratio of tests executed manually and automatically 1:1. This means that only a half of tests were executed manually each new release. Another half of tests were executed as automated right away. This had greatly increased automation ROI because we had no need to execute them manually at all and saved up to 40% of manual testing resources each release. Additionally, automated tests could be used for in-project regression testing much earlier. It also helped to get much of benefit from the idea.
In general, this approach had completely changed the role automated testing played in our project, making it at least as important and effective as manual testing.
Hope this helps making your test automation effort more fun! :) Feel free to comment should you have questions on details of implementation or should you have risks that may prevent you from having it work for you.
Tuesday, June 16, 2009
Management style: directing vs. controlling
Today I am in the mood to talk on a high matter - management.
I was managing a team of software testers for about 10 years and learned management from both ends: as a manager and as a subordinate. My manager side has learned that we are not as perfect as we may seem to be, so there is always things to learn from our more successful colleagues. My subordinate part observed a lot of mismanagement errors on the side of my bosses. Both kinds of experience allow me becoming a better manager myself.
Analyzing my own mistakes helps me avoiding them in the future. Watching mistakes of higher managers is a little bit thougher experience as it requires to get detached from theunpleasant emotions they cause and to observe the picture as if from the outside.
Management is not a science. This is rather an art. There are styles. Which style to follow depends on the situation on the managed project as well as on personal qualities of a manager. Methods that work best for one manager may be totally unacceptable for another. For example, strong egocentric leaders tend to adopt commanding style, while technical managers mostly use supporting style of management. The worst of mistakes is jumping from one style to another or having no style at all. It will look as if you act inconsistently and your people will have no idea what to expect of you, so they will be cautious andself- protective.
Part 1: Lessons of a manager
Below are some lessons I learned while being a manager.
Lesson 1: Be in touch with your team
In order to lead a team of people you have to feel them. You need to keep in touch with each team mate, to stay aware of what happens to the motivation level and what problems may prevent your people from feeling all right.
Managerial attention flatters people. They start feeling important and recognized. So, do not hesitate to stop by and ask not only about the status of ongoing tasks, but also about how they feel, what they did on weekend. Let them know that you care. I hope you do. Otherwise, you are on a wrong career path.
Lesson 2: Be informed and proactive
There is no excuse for a manager who does not know what happens on his project. Collect information regularly, summarize, analyze it and make correction to faulty actions timely. It will help fixing issues until it's too late.
Be proative and predict different kinds of situations, risks and contingencies. Have a plan for the cases when things go not as you wanted them to.
Lesson 3: Don't kill the initiative
Your primary goal is to provide the best outcome your team can produce. Some managers tend to achieve it by doing 200% themselves. Some managers control every action of subordinates strictly. Both ways are killers to personal initiative and responsibility. The people that are working for you are smart enough to take on decisions on their own (If they aren't then think if you have right people on the team).
It's ok that they make mistakes until they learn from it. Micromanagement is the cycle that never ends. People start thinking that their own thoughts are not needed and will wait for your command to take on every simple actions. Allow some freedom in decision making. After several (probably painful) mistakes you will get the team that can solve complex problems on their own.
Lesson 4: Don't push too hard
Pushing too hard is even worse than not pushing at all. Remember Newton third law and think twice before applying extra-pushing on people. All you may achieve is getting proportional resistance. Instead, try talking them into being your ally. Share the goal with them, make the goal their own.
Lesson 5: Trust but verify
Sometimes people lie. Have the means to check what you are told is actually the truth. In a while you learn who can lie and who is out of suspicion. After being caught on lie the former soon transform to the latter.
Lesson 6: Never commit to what you cannot deliver
This is the hardest part of management to me. I am a very optimistic person and I believe that there is no limits to possibilities for a team of professional. Probably, if the entire team was of such people, who simply forget about the other entire world when they see an interesting challenging goal it can do.
The reality is a bit different. Every team has capacity, throughput that cannot be exceeded. Committing to the task that is out of possibilities of your team is damaging to your image and career. I know that sometimes you are pushed to commit to the goal you don't believe in. Well you always have a choice...
Lesson 7: Foster a good friendly climate in your team
Healthy atmosphere boosts productivity. There is unnecessary friction. Peers willingly help each other to be successful. Communication is open and honest. Problems are made visible early, so you have time to react. Everyone is interested in self-development. There is a healthy level of competition within the team.
Part 2: Lessons of a subordinate
Now let's talk about what I learned to be the worst mistakes of my managers.
Harsh lesson 1: Inconsistent management
If you change your mind to often without justifiable reason people stop believing what you are saying. When they do, you cannot effectivelly manage them anymore.
I was told many different things by my managers, which I learned to be a lie. I was so frustrated that I stopped listening to what they say and started finding self-motivation in what I do. Not evryone can do this. Other people may simply allow their motivation to sink below the productive level.
Harsh lesson 2: Emotional management
Emotions indicate that you have lost control of yourself. Losing control is not the best thing because you hardly know what you are doing in such conditions. You may easily abuse someone and switch them into resistant attitude. In any case it will only make your management task harder.
I had a manager whose behavior was very dependent on the mood. He could shout loud at a person in the presence of others. This was simply devastating to the team attitude. Mostly it happened on Monday what made me believe that he had troubles at home. Anyway, your personal troubles shall be left off the doors of an office.
Another one liked to make harsh faces and to talk seriously". This was ridiculous. He looked like an idiot. Always remember that people sitting against you are smart enough to "read you".
Harsh lesson 3: Whishfull thinking
Wise men say "In order to learn how to speak you have to learn how to listen". Do not simply discard what you see for the reaction on the goals you set. Even if you want that deadline more than anything in the world, do not let this feeling to react on how you treat people who are going to work on it. Probably, you simply do not get the complete difficulty related to the task. Do not push because sonner or later people may agree with you being personally not sure that it's possible.
If you cannot suggest the way around the problems you have been reported do not simply put the responsibility and blame on your subordinates. Do not let them feel guilty because they cannot invent something completely new to achieve the goals you set before them. Instead, try to motivate them, give them your support, and recognize their achievements. They simply cannot provide more than they can! If you think they do then you are that kind of managers they mention in the anecdotes.
Harsh lesson 4: I am boss - you are fool
Do not pretend you are smarter than people who work for you just because you’re a boss. Most probably they are even technically more experiences than you because they do that kind of things every day. So, do not let only your voice speak. A good manager makes people saying.
I had a manager who _loved_ to speak. He was so enthusiastic about it that could never imagine how boring it was. It was a complete waste of time for those who listened.
Harsh lesson 5: This is them!
If something goes wrong have a nerve to take the responsibility. Report that you under-managed the process so it failed and take the blame. The worst kind of managers are those who start looking for the reason of failure in subordinates and finger-point to their own people, whom they hired and for whose performance they were responsible. This is so shortsighted. Believe me; this is obvious to your managers that you are trying to get out of responsibility. And they will not tolerate a manager who cannot bear responsibility. Think about that.
Harsh lesson 6: Having no idea what it's going on, yet make on decision
This is another though experience of mine. One day a big boss came to me and asked why we did not achieve our goals in test automation. I told him the difficulties we face on the way and how we decided to deal about them as well as presented my projections on which goals I can admit as reasonable. He was not happy and asked me if a problem was in a lead person. I was simply stunned because that guy worked as hell. He was the heart and the nerve of the project. I was so amased that I could hardly find the right words. Then I simply said my strict "no".
I was amased by how detached my boss was from what's actually going on on the project. However, he feels so sure of himself that tried to take on such a critical decision having lack of information. I would not call it smart.
Harsh lesson 7: The truth is out there...
One of the top managers I knew one day came to me and said exactly this "Vladimir, you are a good guy, however I do not see so much energy in what you do any more, so we decided to let you go." In that very moment I figured out why I did not trust that person before, why I hesitated speaking frankly to him. He did not tell me the truth that time. I figured it out later and it was not easy. The story was completely different from how he explained it to me. Why did he so? Because he did not care! He simply went the easiest way. He had no nerve, no courage to say the thing as they are.
Be honest. Say the truth. No matter what it takes of you to say it. Even if it reveals your own managerial mistakes, have the courage to admit them and to learn from them. Even if you are a big-big boss you still have things to learn. If you don't think so, you will never climb higher than you are now.
"A single lie destroys a whole reputation for integrity." - Baltasar Gracian
This is enough for today. I have to get back to work. I will write more on management later, when I have time and inspiration :)
I was managing a team of software testers for about 10 years and learned management from both ends: as a manager and as a subordinate. My manager side has learned that we are not as perfect as we may seem to be, so there is always things to learn from our more successful colleagues. My subordinate part observed a lot of mismanagement errors on the side of my bosses. Both kinds of experience allow me becoming a better manager myself.
Analyzing my own mistakes helps me avoiding them in the future. Watching mistakes of higher managers is a little bit thougher experience as it requires to get detached from theunpleasant emotions they cause and to observe the picture as if from the outside.
Management is not a science. This is rather an art. There are styles. Which style to follow depends on the situation on the managed project as well as on personal qualities of a manager. Methods that work best for one manager may be totally unacceptable for another. For example, strong egocentric leaders tend to adopt commanding style, while technical managers mostly use supporting style of management. The worst of mistakes is jumping from one style to another or having no style at all. It will look as if you act inconsistently and your people will have no idea what to expect of you, so they will be cautious andself- protective.
Part 1: Lessons of a manager
Below are some lessons I learned while being a manager.
Lesson 1: Be in touch with your team
In order to lead a team of people you have to feel them. You need to keep in touch with each team mate, to stay aware of what happens to the motivation level and what problems may prevent your people from feeling all right.
Managerial attention flatters people. They start feeling important and recognized. So, do not hesitate to stop by and ask not only about the status of ongoing tasks, but also about how they feel, what they did on weekend. Let them know that you care. I hope you do. Otherwise, you are on a wrong career path.
Lesson 2: Be informed and proactive
There is no excuse for a manager who does not know what happens on his project. Collect information regularly, summarize, analyze it and make correction to faulty actions timely. It will help fixing issues until it's too late.
Be proative and predict different kinds of situations, risks and contingencies. Have a plan for the cases when things go not as you wanted them to.
Lesson 3: Don't kill the initiative
Your primary goal is to provide the best outcome your team can produce. Some managers tend to achieve it by doing 200% themselves. Some managers control every action of subordinates strictly. Both ways are killers to personal initiative and responsibility. The people that are working for you are smart enough to take on decisions on their own (If they aren't then think if you have right people on the team).
It's ok that they make mistakes until they learn from it. Micromanagement is the cycle that never ends. People start thinking that their own thoughts are not needed and will wait for your command to take on every simple actions. Allow some freedom in decision making. After several (probably painful) mistakes you will get the team that can solve complex problems on their own.
Lesson 4: Don't push too hard
Pushing too hard is even worse than not pushing at all. Remember Newton third law and think twice before applying extra-pushing on people. All you may achieve is getting proportional resistance. Instead, try talking them into being your ally. Share the goal with them, make the goal their own.
Lesson 5: Trust but verify
Sometimes people lie. Have the means to check what you are told is actually the truth. In a while you learn who can lie and who is out of suspicion. After being caught on lie the former soon transform to the latter.
Lesson 6: Never commit to what you cannot deliver
This is the hardest part of management to me. I am a very optimistic person and I believe that there is no limits to possibilities for a team of professional. Probably, if the entire team was of such people, who simply forget about the other entire world when they see an interesting challenging goal it can do.
The reality is a bit different. Every team has capacity, throughput that cannot be exceeded. Committing to the task that is out of possibilities of your team is damaging to your image and career. I know that sometimes you are pushed to commit to the goal you don't believe in. Well you always have a choice...
Lesson 7: Foster a good friendly climate in your team
Healthy atmosphere boosts productivity. There is unnecessary friction. Peers willingly help each other to be successful. Communication is open and honest. Problems are made visible early, so you have time to react. Everyone is interested in self-development. There is a healthy level of competition within the team.
Part 2: Lessons of a subordinate
Now let's talk about what I learned to be the worst mistakes of my managers.
Harsh lesson 1: Inconsistent management
If you change your mind to often without justifiable reason people stop believing what you are saying. When they do, you cannot effectivelly manage them anymore.
I was told many different things by my managers, which I learned to be a lie. I was so frustrated that I stopped listening to what they say and started finding self-motivation in what I do. Not evryone can do this. Other people may simply allow their motivation to sink below the productive level.
Harsh lesson 2: Emotional management
Emotions indicate that you have lost control of yourself. Losing control is not the best thing because you hardly know what you are doing in such conditions. You may easily abuse someone and switch them into resistant attitude. In any case it will only make your management task harder.
I had a manager whose behavior was very dependent on the mood. He could shout loud at a person in the presence of others. This was simply devastating to the team attitude. Mostly it happened on Monday what made me believe that he had troubles at home. Anyway, your personal troubles shall be left off the doors of an office.
Another one liked to make harsh faces and to talk seriously". This was ridiculous. He looked like an idiot. Always remember that people sitting against you are smart enough to "read you".
Harsh lesson 3: Whishfull thinking
Wise men say "In order to learn how to speak you have to learn how to listen". Do not simply discard what you see for the reaction on the goals you set. Even if you want that deadline more than anything in the world, do not let this feeling to react on how you treat people who are going to work on it. Probably, you simply do not get the complete difficulty related to the task. Do not push because sonner or later people may agree with you being personally not sure that it's possible.
If you cannot suggest the way around the problems you have been reported do not simply put the responsibility and blame on your subordinates. Do not let them feel guilty because they cannot invent something completely new to achieve the goals you set before them. Instead, try to motivate them, give them your support, and recognize their achievements. They simply cannot provide more than they can! If you think they do then you are that kind of managers they mention in the anecdotes.
Harsh lesson 4: I am boss - you are fool
Do not pretend you are smarter than people who work for you just because you’re a boss. Most probably they are even technically more experiences than you because they do that kind of things every day. So, do not let only your voice speak. A good manager makes people saying.
I had a manager who _loved_ to speak. He was so enthusiastic about it that could never imagine how boring it was. It was a complete waste of time for those who listened.
Harsh lesson 5: This is them!
If something goes wrong have a nerve to take the responsibility. Report that you under-managed the process so it failed and take the blame. The worst kind of managers are those who start looking for the reason of failure in subordinates and finger-point to their own people, whom they hired and for whose performance they were responsible. This is so shortsighted. Believe me; this is obvious to your managers that you are trying to get out of responsibility. And they will not tolerate a manager who cannot bear responsibility. Think about that.
Harsh lesson 6: Having no idea what it's going on, yet make on decision
This is another though experience of mine. One day a big boss came to me and asked why we did not achieve our goals in test automation. I told him the difficulties we face on the way and how we decided to deal about them as well as presented my projections on which goals I can admit as reasonable. He was not happy and asked me if a problem was in a lead person. I was simply stunned because that guy worked as hell. He was the heart and the nerve of the project. I was so amased that I could hardly find the right words. Then I simply said my strict "no".
I was amased by how detached my boss was from what's actually going on on the project. However, he feels so sure of himself that tried to take on such a critical decision having lack of information. I would not call it smart.
Harsh lesson 7: The truth is out there...
One of the top managers I knew one day came to me and said exactly this "Vladimir, you are a good guy, however I do not see so much energy in what you do any more, so we decided to let you go." In that very moment I figured out why I did not trust that person before, why I hesitated speaking frankly to him. He did not tell me the truth that time. I figured it out later and it was not easy. The story was completely different from how he explained it to me. Why did he so? Because he did not care! He simply went the easiest way. He had no nerve, no courage to say the thing as they are.
Be honest. Say the truth. No matter what it takes of you to say it. Even if it reveals your own managerial mistakes, have the courage to admit them and to learn from them. Even if you are a big-big boss you still have things to learn. If you don't think so, you will never climb higher than you are now.
"A single lie destroys a whole reputation for integrity." - Baltasar Gracian
This is enough for today. I have to get back to work. I will write more on management later, when I have time and inspiration :)
Subscribe to:
Posts (Atom)