When
I became a lead, one of the first real changes I noticed was the
necessity of trusting those who worked for me. When you are no longer
doing all of the work directly, you have to report what others tell
you. This is very different from reporting on work you’ve done
yourself. This can feel really strange and can lead to a desire to
double check everything. Resist that temptation.
When you are
an individual contributor, you *know* the truth of everything you say.
If someone asks you whether a feature works or not, you know the
answer. You are the one who ran the tests. You have first-hand
knowledge of its state. Similarly, if someone asks you how far along
programming for the new widget is, you know. You are the one doing the
programming.
This
all changes when you become a lead. If your manager asks you the state
of a feature, you can only repeat what you were told. If the person
telling you didn’t do things right, you’ll be passing on false
information. This takes some time to come to grips with. It is a
strange thing the first time you have to do this. Up until now, you’ve
always known for certain the truth of your statements. Now, you do not
and really cannot know.
How
then should a new lead deal with this? You have to just trust people.
Until they prove that they are not trustworthy, you need to just
believe them. If they tell you that FeatureX is working, you have to
report that. You don’t have the time to check up on everything, nor
should you if you did. You have someone reporting to you whose job it
is to do this work. You must assume competence. If you do not, you’ll
harm your relationship with that employee and you’ll run yourself
ragged. Whoever hired these people verified that they were competent.
Unless something changed, they still are. Feel free to spend some time
with your employees trying to understand what they are doing and how
they are approaching the problems. Do this to educate yourself, not to
question their work. With time, you will learn the abilities of those
reporting to you and become much more comfortable with their reports.
http://blogs.msdn.com/b/steverowe/archive/2006/03/09/547373.aspx
jueves, octubre 4
Casos de prueba para Pruebas Unitarias
¿Cuáles casos de prueba se deben realizar para las pruebas unitarias?
Estos son los casos de prueba obligatorios a realizar cuándo se están realizando Pruebas Unitarias
- Casos de prueba positivos.
Entradas correctas, salidas correctas. - Casos de prueba negativos.
Datos incompletos o faltantes, manejo adecuado. - Casos de prueba de excepción.
Excepciones que son lanzadas y atrapadas apropiadamente.
Fuente: http://ssoftwaretesting.blogspot.mx/2010/07/what-are-three-test-cases-you-should-go.html
lunes, octubre 1
Becoming a Lead, Pt. 1
At Microsoft, there are two classifications of people: Individual Contributors and Managers/Leads. Individual contributors are those who spend most of their time doing the work that makes software spring into existence. These are the programmers, testers, and program managers that create the products. Managers and Leads are those who spend a large part of their time making sure everyone else has time to do real work. Leads
are usually those who have a few people reporting to them and Managers
are those who have leads or other managers reporting to them. Those
of us who are managers pay attention to schedules, product roadmaps,
bug trends, people development, and—most importantly—making sure that
our people are not blocked.
There comes a time in many careers where a person makes the transition from an individual contributor to a lead. There are some big differences and not all of them are obvious. This series of posts will cover many of those aspects. The things I talk about will be specific to the software industry but should be applicable in any occupation. Before I start, however, let me give some thoughts on the prerequisites for becoming a good lead.
Great leaders are grown, not born. No one comes out of school ready to be a great lead. It takes a solid foundation before you can effectively lead. If you try to lead without that foundation, you’ll end up being more Pointy Haired Boss than Great Leader. To get a solid foundation, spend some time (several years at least) doing whatever it is you expect to be leading people at. As
this blog is about the software industry, spend several years
programming or testing (or both) before trying to lead testers or
developers. Once you become a lead, you will have less direct exposure to the technology. You’ll need a solid background to understand everything those reporting to you are working on.
Not everyone is cut out to be a lead. I’ve seen too many times when a great developer is forced to become a manager. What results is often the loss of a good programmer and the creation of a bad manager. I’m very much with the author of First, Break All the Rules. One
of his basic premises is that people have certain talents and if you
don’t have the right talent for a particular job, the best you can be is
mediocre. For instance, I’m not artistically inclined. I could go to art school and get lots of training, but I’m never going to be a great artist. Likewise, if you are not naturally a leader, you’ll never make a great one. With the right talent, and the right training, a person can become a great leader. Without both, they never will.
How do I tell if someone is a natural leader? I have a thought experiment I like to apply. If
I put together 3 people on a project and tell them what the goal is but
don’t assign any of them roles, by the end of the project one of them
will be contributing more to the overall direction than the others. Someone will be the person designating who works on what. This is not the bossiest person. Without a talent for leadership, the person will be seen as pushy and their leadership will be rejected. The good leader will lead without having to claim the mantle of leadership. Instead, it will be given to him/her by the others on the team. It may not be verbalized, but there will be one person the others look to for help making decisions. That’s the natural leader.
I once had a report who claimed he wanted to be a leader. I gave him responsibility for an area and another person to help him do the work. A few months later, the helper was doing his own thing. He was being given no direction. Needless to say, when this person came to me and asked why I didn’t make him a lead, I just had to point to that incident. When given the chance to lead, he didn’t take on the role. Leadership is a behavior, it is not a title. If you think you want to become a manager, do so because you enjoy leading, not because you want the title or the prestige.
http://blogs.msdn.com/b/steverowe/archive/2006/03/08/546210.aspx
Suscribirse a:
Entradas (Atom)