A book titled “Managing the Test People: A guide to Practical Technical Management”

• One of the big mistakes: You’ve brought a problem to your manager without proposing a solution


• When you are looking at old performance review you don’t know who wrote it, so take it as input but not as the authoritative word


• Don’t exclude good candidates who might have similar experience but not direct experience with your product


• The test engineer position is not an analyst or test position. Engineers are expected to architect and write code.


• A person who doesn’t proofread their cover letter and resume isn’t going to proofread bug reports or test plans or test reports


• Job classification -->bit of information necessary to classify the job such as job title, job grade/number/salary range/experience. Job description-->this explains the roles and responsibilities and qualifications


• A lead is a person who has project and personnel responsibility. In some organizations leads never have personnel management roles, they have only project responsibility


• It’s not fair to add management responsibilities on top of someone’s technical duties without offloading some of their work.


• You can learn a lot from a bad manager about what you should not do!


• Time spent in meetings means time spent away from your “real” work.


• Everyone interprets information in terms of how it affects them


• Don’t take ownership of a problem that isn’t yours.


• Tester’s job is to provide factual information to the decision makers.


• Create an open and strong working relationship with your development peers: They can be your strongest allies or your worst enemies.


• Don’t break your own rules


• Keep meetings to an hour or less and surely not more than that


• Ten minutes should be enough time spent on a daily/weekly status report


• A natural leader will already be leading before the title change


• You are responsible for your people and their actions


• Project problems are the easiest to fix-personnel problem are the hardest


• Quitting and leaving a department you have built is one of the most difficult things you’ll do in your career
  

The list continues…..

The above points (a valuable lesson is the right word I can say) were taken from the book “Managing the Test People: Judy McKay: A guide to Practical Technical Management”.

In my 7.5 years of software testing experience I had learnt only a few of them mentioned above but so many of them were new since everyone’s career is an ongoing learning. Judy explained a lot of them with her 20 years of technical and practical expertise. Once started reading these points I got happy that I had learnt so many things with the expense of just 40 USD (Cost of the book) and a few weeks of time taken to read this book.

Thanks a lot Judy McKay

This is not only a guide to practical technical management. This is a guide to practical technical as well as people management. This is a very good book I can recommend to each and every tester, test lead and test manager in the industry.

Best Practices - Dialogue between Test Analyst (TA) and Quality Analyst (QA)

Here goes the conversation happened today between a test analyst and quality analyst regarding “Best Practices”

TA: Hi, Good Morning and I have news for you and it’s that I have identified a best Practice for our testing project we are currently working on.

QA: Had you started implementing that practice or just identified.

TA: Just identified and we are planning to implement.

QA: Oh No! Then you cannot call/claim it as a best practice.

TA: Why is it so?

QA: You had just identified a practice that was not yet implemented in a project and you had not experienced its good results of following it and hence you cannot call it as a Best practice.
Also is that practice you are going to implement a step or part of our organization’s QMS definitions/processes/steps/practices mentioned.

TA: No I had checked and it’s a new one.

QA: That’s nice. Should not have been already mentioned in our organization QMS.

TA: OK.Is there any other constraints?

QA: Yes. A new practice that is applicable only to a specific project team and could not be applied across the organization, is not a best practice

TA: Okay and Thanks for your nice explanation. I will come back to you after implementing this practice in my project with the evidences of its good results. Thank you and bye for now.

After few hours of this conversation I had asked myself what the lessons are learnt by me from this discussion and the answers are

1. Some organizations have best practices (can we say best practices or conditions/guidelines?) to claim some practices as best or not.
2. Without implementing and having the results, a practice merely cannot be claimed as a best practice. This is obviously true.
3. The best practices of a specific project do not work out for other projects within the organization since the context of projects differ. Then how this QA is claiming “A new practice that is applicable only to a specific project team and could not be applied across the organization, is not a best practice”. I really disagree with this point.

Best practices to claim practices as best—a good research topic for any IT guy to research further?