Friday, June 19, 2009

Motivation - are we all the same?

Motivation is one of most appealing management tools. Motivated employees can produce more of the product and with better quality. Many companies work on their employees’ motivation to get the best outcome. Introducing bonuses, providing cars, better working environment, and social benefits - all aimed at keeping workers, clerks, and managers motivated.

But what is the motivation itself? Is it the same for a person, who likes washing windows so much that he can't wait until tomorrow to go to work, and a person who wants to organize things so, as to sit back and see things moving round in a well-organized way? Are these two kinds of people thinking the same categories? No. They even have opposite motivational goals.

Today I have read an interesting work on motivation. Author was speaking of three kinds of motivation:

- Rational (I love my job and I have a natural desire to do more, to do better)
- Irrational (I don't like working, I better make things turn around themselves)
- Egocentric (I can stand anything if I get promoted)

People of rational type of motivation enjoy the work itself. They have a natural desire to work more, to work better than yesterday. They find motivation in what they do.

Second type is completely different. They do not like working. They are motivated by... laziness. No. This is not a joke. And such people are not losers. Most of innovations come from this type of motivation. The many of this sort have their own business, which they started having perspective goal to sit back and watch things move on their own.

Third type finds motivation in esteem of peers and management. They are clearly of extravert type. They do care what other say about them and how they see them from the outside. You can keep the salary of such person relatively low. Having a good career perspective, such a person will work the best.

Each of three groups of motivation requires different actions to keep it warm. Instead of looking inwards companies prefer to stick to one type of motivation that, in their opinion, can target all the types of individuals. So, we should not be surprised with the results.

Identifying the right motivation for your employees is vital for your business. It's hardly possible to keep "sheep safe and wolves full". There are different types of personalities working for you. Learn them and find the best way to manage their intentions and to use it for the success of your business.

Thanks to author of that original article for insiping me on writing this.

Thursday, June 18, 2009

The outsoucing thorns

When I first came to the outsourcing company I was perplexed and confused at the same time. The entire set of values I brought with me from a company that worked on domestic product was hardly applicable and required significant adjustment.

First thing that made me nervous was the absence of a defined development model. Each project was a small company per se with its own game rules. The set of rules depends on the qualities and experience of a leader (PM) and customer will. This is not arbitrary that I placed leader in the first place. PM is more influential figure in the project than it may seem to be. Few customers come to the outsourcing company having enough experience in software development, so they know how to organize the process. Most of clients are new to the domain and have vague idea about peculiarities and risks related to software development. A strong project leader can correct customer's vision of the problem to a decent extent.

Another difficulty was the dictate of the rules by customers. There were problems selling off testing services, especially in the difficult recession times. Testing is being seen as an additional cost. Testing does not create the direct value so it was perceived as a good candidate for cost cutting. Some customers even insisted that they will do testing on their own. I am not sure they realized what it would cost them. I am sure they would find a better use to their precious time. This looks even stranger if we think of a pitiful experience in testing they usually have.

The third problem is also related to the company being split into small reins with their own small kings. Introducing changes is a much more painful process. If it can be done only with enthusiasm in the "domestic" company, this is absolutely impossible in the outsourcing without a constant support from the top management. You simply find yourself bogged down in communication maze with all the parties interested, each of whom have their own vision of the problem, and each of whom used to adapt different kind of processes.

This is, in general, the core difference between testing and QAing in "domestic" and outsourcing companies. Having experience in both worlds I would suggest you to select the former if you want to learn building quality processes. I would suggest the later to those of you who value challenging environment, don't fear changes of rules during the game, and who is a good negotiator.

Wednesday, June 17, 2009

Should we care about certification?

Ceritification is one of things that cause a lot of flame. Some people say this is critical to have a proof that your knowledge and it helps to find the job. Others insist that managers learned to be suspicious about certification value because theoretic knowledge it provides is of little help to day-to-day work.

I myself is rather of the second type of managers. I ground my conclusion on the fact that the best testers I worked with were not certified. On another hand, I know average professionals having tens certificates.

Of course, when comparing two idetical candidates (which is a very rare case), I would pick one with a certificate. So, the certificate wins but with a very small (insignificant) lead. This means that you need to think twice before investing into certification.

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 :)

Friday, June 12, 2009

Unit testing is what you need


"Whatever you do today will get you one step closer or one step further from the intended goals."

How can this statement be reflected on the idea of Unit testing? Unit testing is usually seen by people as the additional cost related to development. If you do not write additional lines of code we save time. We could spend this time writing production code, for example.

Well this is only partially true. In many cases we [mistakenly] assume that writing a line of unit the same as writing a line of production code. This leads us to incorrect understanding of unit testing benefits.

Testing code is as simple as it takes 10 to 100 times less time than writing a piece of production code of the same size. So, do not even listen to voices of people who claim that development with unit testing takes 1.5 to 2 times more time based on code line calculation.

Unit tests are trivial, as simple as code below. Just think of how many such tests you can write in the course of an hour...

public void testAddNegative () {
assertEqual(MyClass.Add(2,-1) , 1);

Supporting unit tests after change is as trivial as writing them. You can even afford rewriting them from scratch with easy.

Why to unit test?

If you can write code without error you would probably not need to test it. If you cannot write code without error them how do you check that it does what it should do? Using debugging is a tiresome tedious manual activity, not in the way how developers are meant to do it. Not to say this is hardly possible to run all required tests in debugger after changes. I know no developer who would do this stupid thing.

So, having produced a piece of code with undefined quality developer simple gives the responsibility for testing it away to someone else down the line. Let's see if there are right people to do it. Hm...

Integration engineers are supposed to see your modules as black boxes. So, they do not care about your inner functionality. All they work with is external interfaces, input and outputs of your module. If there is a branch in the code that was never tested it's very probably remain such after Integration testing.

The next possible candidates to catch your defects are system testers (or QA as they called sometimes). These guys care about code structure even less than integration and deployment engineers. Testers focus on business logic. Their job is to make sure the ideas you have implemented is exactly what customers wanted. Testers care about neither code structure nor architecture. If they catch your intrinsic code error it is only by chance.

The next in the food chain is the end user. Unfortunately those guys are extremely lucky at finding the issues. If you leave defects in the release system be sure they will stumble upon it %)

There is no one down the line who can catch and correct your code errors. Only you, as a developer, can check if all branches through the code are examined carefully. Only you are responsible for quality of code that you check into the code base. So, find time to test.

How do you know you are done?

How developers get to know that code piece is done? If they have automated unit tests then this is not a problem to run them and see the results. But what is there are no tests? Do such developers have habit to provide to someone code of unknown quality? Just imagine what if cars were made using the same attitude.

Having your code run under debugger with 1 typical data set is not enough. There are boundary conditions, zero and incorrect input, big volumes of data, stressful conditions that also can lead to failures. Who of developers do such testing under debugger? I guess no one.

So, there is no other way to make sure you finished the code but Unit testing. If you know a reasonable alternative to Unit testing just drop me a line and I'll fix this statement and will eat my hat ;)

The most effective unit testing

Unit testing has proved itself as a powerful tool against software regressions (issues that appear after changes or defect fixes). So, the more changes you do to the project keeping tests untouched the more return of investment you have.

Who does unit testing?

To me the answer is simple - developers should do it because:

* They know the code and there is no need to explain it to someone else.
* They think of testing during code design.
* They need something to demonstrate that the code is finished.

The crude world

If unit testing was so easy it would not be so difficult to start. Yes, there are problem. But there is none that was not faced and overcame by someone else. If you faced a problem just look around, ask your peers, search Internet but don't give up! You need unit testing anyway.

While talking about unit testing with developers I was often asked for recommendations on testing:

* Databases
* JavaScript
* UI

No problem. Just try Google for any of these to see how many possible solution you have at hand.

Wrap up

All you need to do unit testing is to start it. And do not lay it off until tomorrow, start today. As the final reason I will tell you that developers who do unit testing prove to be more successful than those who test under debugger. If you do not start today you waste critical experience and fall behind your peers. Do not be surprised if someone of them will suddenly appear one step higher in the company hierarchy ;)

Thursday, June 11, 2009

The silver bullet of test automation

Note: This topic is about system test automation only. Developers (unit) testing is out of scope of this article.

I have purposely chosen such a sound name for this topic. I myself am a big believer in system test automation. But, as any other kind of tool, automation likes those who know what to do with it.

This is way too easy to be misguided by marketing stuff promising you to become more effective using their new generation super-duper automation tool. Beware, 90% of what advertisement says is a lie. The solution how it is presented may work on a very limited number of projects. What vendors don't say may hit you hard or even kill your test automation endeavor. Read on in order to get ready to concealed challenges.

Test automation is development

First thing to remember is that test automation is creating a program that tests another program. As any other kind of code it is governed by same lows. Unnecessary complexity, unclearness, duplicates, high coupling, hard-coding strings and constants have the same bad effect for test code as they do for production code. So, make sure that you know how to write code efficiently before jumping into automation boat.

Record&playback does not work

Do not believe anyone who tells you that test automation is as easy as record&playback. This is a pure lie. Following this model is undermining the biggest automation benefit - having reliable regression suite that requires little changes after changes in application. Tests generated by action recording tools are non-maintainable and you will need to re-record them afterwards. Test execution in this case will be more expensive than running those tests manually. Now think of how often you make changes to your system and try calculating whether you are going to have benefit from automation with record&playback.

Test automation is the investment

Be ready to invest. Automation is not a tool that starts working right away. There is always some leading cost involved. Yet the benefit you get down the line worth it all.

Implementation of a good automated test suite requires skilled staff, resources and time. Our suite took 4 engineers for 4 years. But the result was outstanding. It worked so well that we almost stopped testing for regressions manually. It helped us finding the issues we could never find any other way. So, our investment into automation stared paying back after about 2 years since the project start.

I concluded that automation starts working when you have at least all critical tests automation but it shines when the number of automated tests is over about 40% of your test backlog.

Automated test is strict

Automated test is a program and it can help you finding only those issues for which it is programmed. Manual testers look around, note different strange things that automation tests just pass by, on his mission to click this and read that.

Make sure you have a human being tested the feature before it is handed over to test automation.

Automation tools are as easy

I would never start automation project having no skilled professionals involved. Experience is the key. Else you are in position to pay for automation as much as 300% of its actual cost. Rephrasing famous Russian advertisement: Have too much money? So, we are going after you ;)

Tests have to be selected carefully

Ideally, you need to think of testing as a whole in the very beginning of the project. You have to get a clear picture of which tests you will have automated and which are better to be left manual. Test design should be oriented at contributing test automation using data-driven testing technique. Due test design may make your automation efforts 10 times more effective.

In the real world, we sometime face the situation when tests are already designed. Even in that case, if you have the possibility, look at test design from automation perspective. Change it the way as to get most benefit of your automation tool. Sometimes it makes sense to add tests in places where we had to compromise coverage for execution cost.

As far as implementing automated tests is an additional cost it can only be saved by execution. The best candidates for automation are those, which are executed often. Also there can be tests that are easy to automate. Doing them manually may be not reasonable.

Automated testing economics

I mentioned that automated tests pay for their creation during execution. There is a simple math example that demonstrates this postulate:
• 10 manual tests require 2 hours for execution.
• Implementation of these 10 tests would take 16 man hours.
• Execution of 10 automated tests takes 0 (zero) man hours.
• So in order to get the benefit we have to execute tests at least 16/2=8 times.
Follow this principle in assessing automation feasibility and you will have positive return on investment (ROI) at your test automation projects.

Note: Sometimes we fool ourselves wrongly assuming "perceived" frequency of test usage for the real one. The problem is that once we have tests implemented it's very easy to run them. So we run even those tests, which we would never execute manually. If you want to know the real benefit of the automation, try to get rid of desire to calculate this "perceived" frequency. However, reporting the “perceived” benefit can be good for you career ;)


Automation is a silver bullet but only in case when it is done by experiences professionals, on a lengthy projects (2 years and more), following strict best development practices and disciplines.

To test or not to test?

Having some experience in software development outsourcing company, I faced the problem with how our customers think of testing. Some of customers believe that testing is an added cost that can simply be cut. They believe that testing is simple and they can do it on their own. Others just keep insisting that developers write code without defects, so testers won't be needed.

Let's start from the first problem. Customers who come to us asking for development only and testing product themselves soon find themselves drowned in the information regarding quality. Not to say they rarely know what to test in the system because they simply do not know what boundary conditions or security testing means. Such projects usually result in mutual frustration. Customer is frustrated with quality of development work and quality of the resulting product (under-tested). Developers are frustrated with the project failure.

In order to avoid such problem, we have to warn customer of possible bad scenarios that may be caused by decision to buy only development services and to cut testing off.

The second bad scenario is when customer believes that testing is not needed, that developers can produce software without defects. Yes, they can. Developers can check they produced correct code but they have trouble making sure they implemented right thing. Developers are too biased toward inner code structure and design, so they have trouble seeing a big picture. Independent testers play role of end user advocate. They pretend they are users during the testing. I doubt developers can do it effectively because they have to think of inner design all the time.

So, having independent system testing is crucial for project success. The question in the title of this post has the meaning similar to the famous question posed by Shakespear. And it has the same crucial importance to the project as it was for Hamlet.

Wednesday, June 10, 2009

Quality Vampires

Before writing materials on technical aspects of testing, QA and management I decided to provide my vision of what can make any quality initiative bound to fail.

Vampire 1: Quality costs.

First of vampires is the notion that quality costs. Yes it does, but not in the way you may think. Just look at the best examples of the contemporary automobile industry. There are players on the market who provide a very different level of quality for the same money. Those who produce cars of better quality feel themselves more secure on the market. They also show better result financially, having sold more cars and having fewer warranty cases. Now ask yourself whether or not quality costs and in which way?

Right! This is not the quality that may cost you reputation, lost sales, and frustrated customers. This is the lack of quality solution that may make your business sinking.

So, before even thinking of saving a coin today by skipping important quality practices like design, review, unit testing, and the like, ask yourself whether or not it may result in heavier losses down the production line.

I tell you from my own experience. All the compromises we make today will hit us tomorrow. Insignificant time we won cutting design or test review may cost complete module redesign or missed defects.

In the famous quality/resources/feature triangle quality is the most important! You may change the other two as you need to fit your business goals.

Vampire 2: This is not possible to produce software without defects.

The phrase itself makes sense. The problem is how people tend to be using it. Some developers use it for the excuse and take making defects in code too lightly. I am a human, I make mistake. So, who cares? This is a bad-bad habit in the software industry that is easy to accommodate but hard to get rid of.

Developers like any other kind of workers make mistakes. This is true - It’s ok until they learn from those mistakes. We learn it from the childhood that making mistakes is bad. Those of us who make more mistakes than other are valued less. They have fewer career opportunities and earn less money than those who produce high quality results. But both are humans. The difference is how they feel about making mistakes.

One may say that it's ok, because I am a human. Another will ask himself: “what can I do differently in order to avoid making these types of mistake in the future?” This is a completely different story, thinking that way.

So, the phrase itself is true, however do not let it misguide you. Always analyze your mistakes and learn from them.

Vampire 3: Everyone can do testing; it's easy.

This is the strangest misconception I ever met! Who decides? Usually I hear it from people who never practiced software testing. So, they cannot provide arguments if asked a simple question: why?

Testing is a big knowledge area. It takes several years to grow into software testing professional. Being professional in testing and development is beyond human possibilities. Testers are not looser-developers. Just look around. These people have chosen testing deliberately because they like it. Of many testers with whom I worked, only few were wannabe developers.

So, let's stop talking flame about who is more important for the success and get back to job!


At last... After so many years of pondering this idea away, I decided to start my own blog. I feel like I have enough to say and to share. I hope that experience I gained for 11 years in software testing and quality assurance area and the ideas that I have will help others being more successful in such a challenging, tricky and enjoyable bsuiness like quality engineering!

I also have a decent knowledge in management and some thoughts that you may find interesting.