There are a lot of great leaders within the testing community. Most everyone could produce a list of whom they consider a leader and the qualities that they admire about them. However, I do have a concern that the “leadership” label can actually prevent testers from recognizing their own potential. Too many testers believe if they do not have the “right” title they cannot be leaders. Some testers will have “leader” in their job title such as a “team leader”. They may lead a team of testers to meet a testing deadline by providing direction and oversight. Others will have “leadership” implied in the job function. A senior software tester may provide leadership through decision-making and solving complicated testing problems to provide guidance to more junior testers. The Testing Manager may provide leadership through sharing vision and strategic direction. I would like to dedicate a few postings to talk more about developing your leadership potential and opportunities – regardless of your job title.
How do you define “leadership”? Depending upon whom you ask, they may provide a slightly different definition. Below are definitions from popular leadership experts and from the online business dictionary.
Dr. Stephen R Covey teacher, organizational consultant, and author:
“Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves.”
Dr. John Kotter, Harvard Business School and the Chief Innovation Officer at Kotter International. From HBR Blog network January 9, 2013:
“It is associated with taking an organization into the future, finding opportunities that are coming at it faster and faster and successfully exploiting those opportunities. Leadership is about vision, about people buying in, about empowerment and, most of all, about producing useful change. Leadership is not about attributes, it’s about behavior. And in an ever-faster-moving world, leadership is increasingly needed from more and more people, no matter where they are in a hierarchy.”
From the online Business Dictionary:
The activity of leading a group of people or an organization or the ability to do this. Leadership involves:
- establishing a clear vision,
- sharing that vision with others so that they will follow willingly,
- providing the information, knowledge and methods to realize that vision,
- coordinating and balancing the conflicting interests of all members and stakeholders.
A leader steps up in times of crisis, and is able to think and act creatively in difficult situations. Unlike management, leadership cannot be taught, although it may be learned and enhanced through coaching or mentoring.
Whose Leadership Do you Admire?
Create a list of testers who inspire you and whose leadership you admire. What makes them a good leader? Did they receive a promotion and suddenly people started to follow them? Or did they build a reputation over time where earned respect resulted in people seeking them out and following their direction? How many of them had “leadership” in their title or job function?
There are many testers I admire for their leadership skills – often I do not know their job title or job responsibilities. I respect the ability to identify and progress a vision that is adopted by other testers. The creation and evolution of weekend testing is a perfect example. There were the initial testers who led the initiative and then testers around the world stepped into leadership roles to create and evolve their chapters. I admire those who become a champion for different approaches such as documenting test ideas and strategies. A great example is the teaching and sharing of practical examples on how to use a tool like mind maps. The leadership I have witnessed by several testers has influenced many testers throughout the world to adopt mind maps as a testing tool.
Throughout the years, I have witnessed leadership within companies I am employed by testers stepping into this role when their title and job function does not indicate “leadership”. Some have taken the lead when a project is in trouble. Other testers have taken the initiative to learn complex functionality to lead those testing efforts. While other testers excelled in their communication ability to present new ideas for acceptance by other testers.
When testers believe that they need to be in the right job before they can become leaders, they can actually limit their career progression. Typically people are promoted once they demonstrate the ability to perform higher-level position responsibilities. This should not be interpreted that you should only work on your leadership skills when there is a promotion opportunity. Developing these opportunities can make your current position more rewarding. Becoming a leader is not like turning a light bulb on and off. I receive a promotion and now I can be a leader. This is flawed thinking that I have witnessed in the testing community. Leadership presence is not a title instead it requires influence and respect that is earned through your actions. For example, it is making eye contact, personal connections, building trust and respect, and acknowledging other people’s skills and abilities. Leaders initiate communication and relationships with other people – they do not wait for people to seek them out.
So you might be wondering how to develop your leadership potential. Leaders identify opportunities and take calculated risks. We have seen that with the examples I discussed in this article. However, do not be concerned that you need to start off with something big. Find small opportunities to develop your leadership skills, reputation, and consider developing your own learning plan.
What have you done to develop your leadership potential? What could you be doing now to be a better leader?
One aspect of management that I have always enjoyed is sponsoring an internship program. I have sponsored these programs for software testers, business analysts, and other technical professionals. I love working with college students to help them discover a new field or expand their knowledge in a discipline they have chosen.
One comment I hear is how difficult it is to find good testers. Those of us who live in the “rust belt” region understand the challenges. Recently I watched Erik Davis “CAST Live” discussion on this problem. Click here to hear what Erik has to say about the problem. One option to this problem is to start an internship program that may allow you to fill open positions and help educate people what testing is really about. In this posting I am sharing some guidelines that helped me start a program.
Things to Consider
Before starting an internship program consider the following points in relation to the length of the internship program:
If you do not have time to properly train or work with the intern then perhaps sponsoring a program is not a good idea.
Job Posting and Local Colleges
Write a brief job posting of what you are hoping to achieve from the internship and any basic requirements. Contact your local colleges to understand what departments may have students that meet your objectives. Many times they want a job posting to send out to their students. I have found that some colleges are great sources for filling a short-term internship whereas others are better at fulfilling internships with students who are interested in future employment.
Paid Versus Not-Paid
Sometimes the student will receive college credit for the internship. Companies may offer an hourly rate to encourage students to apply. I recommend that you pay your interns. Often the college student needs the money for tuition, books, and living expenses. Plus if you define your internship correctly as to expectations and find the right interns, you should receive testing beyond checking exercises.
When interviewing the students, remember they may not have a lot of experience to discuss so your approach needs to be different. Scale back the intensity of the questions you ask. Spend time talking about the testing field and the role they will fulfill in your company. Most likely they will not know anything about testing. And many people think of testers as checkers. Try to tap into something they enjoy (ie., playing video games, Facebook) and relate it to the testing field. I often start interns with regression testing and easy bug fixes. I let them know their role can be expanded based upon how quickly they learn and their desire to take on more responsibility.
I usually look for students with good work ethics and show an interest in learning more about our product. If you have any younger testers who may relate to the students, consider pairing them with a more experience tester during the interview. This provides the younger tester with interviewing experience. Plus he may relate to the student talking about his initial experience entering the work place as a tester.
Review your current testing onboarding program. Identify important areas that the intern will need to successfully complete his assignments. Try to narrow it down to what he really needs to not overwhelm him. You can always provide him with additional training material throughout the program. If you had a younger tester part of the interview process, talk to him about his initial job experiences. What helped him? What would have helped him? The great part of going through this exercsie for an intern is you can expand this approach when you hire testers straight out of college!
It is helpful to identify a mentor for the intern to ask questions. If you are the manager or team leader you may not always be available to assist him. Having a dedicated contact is beneficial to the learning process.
Look for testing assignments that are contained in scope and are easier to learn. If your department test reports, identify an easier report to train him. Provide a demo on the report’s functionality and then identify small testing assignments ensuring you provide sufficient guidance. Do not provide too much structure to your training program so you can adjust it based upon how quickly the intern learns. I have found that some interns have a natural appitude for testing and transition into a software testing job. While others may enjoy the internship but will pursue a different career path.
Have you worked with any interns? How did it go?
This week I read about Microsoft abandoning its “Stack Ranking of Employees” and then I read that Yahoo just adopted a similar approach to appraising employees. These review systems require managers to rank a certain percentage of employees as poor performers with the intent of removing them. Those supporting these performance systems claim that your company is stronger by removing your poor performers. The problem I have is managers are often forced to reduce ratings in order to meet the “bell curve” ensuring a percentage of their employees are below standards. What happens if you have a really good team where there are no poor performers? That really is not an unreasonable expectation. I believe these systems lead to a competitive, cutthroat environment that is not healthy. Employees are always worried for their jobs if every quarter there is a review and if you get a couple of reviews with low ratings, you are fired. If employees have distrust with these systems that the ratings are not fair, then fear is introduced. I do believe in healthy competition and higher rewards for those who take on more risks. When I read these articles, I am glad to work for a small, private owned company.
I also dislike self-evaluation performance reviews where the employee rates himself and the manager completes the same performance ratings. Then at review time, the employee and manager compare their rankings to foster a conversation on the difference in scores. For example if the skill is “team player” and the rating scale is 1 to 7 with 7 being outstanding. The employee rates himself as a “6” and the manager rates him as a “4”. In theory this difference in score should open a healthy dialog on why they have a different opinion. In reality the employee is thinking the manager does not appreciate him and his contribution. Any further conversation is all about defending the score instead of discussing accomplishments and future potential.
One of my best performance review was when a manager said to me, lets put the paperwork aside and talk. Since that wonderful experience, I have changed my approach. I typically like to provide the formal paperwork to the employee ahead of time to read. During the performance review meeting it is a conversation about what they accomplished the past year and where their career is headed. The performance review document is used as a roadmap to ensure pertinent areas are covered instead of reviewing it line by line. Below are a few questions that employees can think about before meeting with their manager.
- What were my important accomplishments over the past year?
- What were the challenges I had to overcome this past year?
- What do I hope to accomplish next year?
- What training or skills do I need to further develop over the upcoming year?
A performance review should be a conversation and not about defending numbers. Personally, I do not want to be defined by a “number” or a “rating”. I want to be known for my accomplishments. What are your thoughts on performance reviews and forced-rank systems?
Many people do not think about Software Testing as a career. In fact many do not even know the field exists nor how rewarding and challenging it is to be a Software Tester. There is not a degree in Software Testing so many people applying for the job are not really sure what we do. It does make me contemplate how I learned to test. In my earlier days I was trained as a Cobol programmer. As part of my training I learned how to create flowcharts; test my own code (negative, positive, boundary testing); validate the records returned at each data set; and review the raw data to ensure it was processed correctly at each step. The assignments were difficult and our documentation was expected to be perfect. If you made one mistake in your flowchart you lost a grade level. At the time it seemed very harsh to me, but I now understand the discipline was necessary to help us work through a problem. In those days we worked through the assignment by creating a flowchart. From there I worked as a programmer in different capacities that included finance, human resources, and securities. Sometimes we received written requirements, but most times we needed to work with the requestor to understand what s/he needed. Other times we wrote code for production systems or consolidated programs for efficiency that often required reading in a dozen or more files. We needed to understand the file layouts, the data, and how to merge the files to ensure we did not duplicate records. Basically we gathered our requirements, wrote the code, and tested it. We did not have a testing department – sometimes you could get another programmer or a business user to help with the testing.
I was often the liaison with the Information Technology department on the behalf of the business community. I could speak both languages. This afforded me opportunities to test the output of the IT department projects such as an employee change form that automatically filled in data based upon pre-defined information. While working in Human Resources we implemented an application tracking system to handle the large amount of resumes received for opened positions. This afforded opportunities to help define the requirements and “test” the commercial-off-the-shelf products to determine if they met our needs. As object-oriented programming became more popular or perhaps better known, we were hearing more about Java, Oracle, and data warehousing. During that time I started a new job to start a software development department and we did it all. We wrote requirements, developed the code, and tested it. Over time I moved into a role to start a Software Testing department. And we performed a lot of different roles including business analysis, software testing, training, and implementation.
I will always value my days as a programmer because it helped shaped my career. Plus when I talk to the developers I have an appreciation for their struggles and can visualize what they are trying to achieve. I find myself translating what they say to how I would code the solution. Through all this, I realized I was a born tester as I view my world through my testing eyes. It can be difficult to explain to those who are not passionate about testing. As an example, when something does not work in our house I automatically think about the business requirements, how it might have been developed, and tested. Immediately I want to study and test the problem to find any patterns to the failures. When there is an upgrade to our DVD, I start to “test” the new features. What happens if I try this, or try that? What is the logical flow and how can I take what I know about software standards to learn more about the upgrade. I tend to not read manuals – I jump in and start with exploratory testing. I start with learning at a high-level or the surface. How does it work? Then I will go deeper to understand the functionality. I tend to be a button-pusher; what happens when I click this button. As an example, when we moved into our house, we got a new stove. It had an electronic clock. While the delivery guy was still in the house, I went to the stove and started to push buttons to figure out how to set the time. The delivery guy was stunned. He asked how I knew that because they have customers calling them to find out how to set the time. Honestly, I do not know how I knew – I just did. And that is how it is with software testing. Some of us are born testers and some may not know – yet. There are just times when we know what to do when others are scratching their heads asking, “how did you know to do that?”
So what is your story on how you became a Software Tester? I would love to hear it.
I will never forget the time when a release went to production and a business user thought he found a serious problem. He proceeded to tell everyone about the bug which made the developers and testers look bad that we missed something so serious. Long story short… the business user made a mistake and there was not a bug. But the damage was done. Of course no one went around telling everyone there was not a serious bug. Since that time I became rather sensitive about using the word “bug”. I prefer to say that we have a problem that needs to be researched. It may or may not be a bug.
I originally wrote an article “Guidelines on a Meaningful Problem Report” in the November 2011 edition of Testing Circus. Click here to read the original publication. I have revised this article to include the perspective “Is it really a bug?”
Providing the correct information to the development team on a problem discovered during testing is an important role of the tester. To gain an understanding of the functionality’s expected behavior the tester may talk to a business user or a business analyst. Through researching a problem we may discover it is a bug; we did not understand the expected behavior and it is intended functionality; or it might be an enhancement.
General Guidelines to Research a Problem
Below are guidelines in researching and writing a problem report. I do value communication with the development team over sending them problem reports. But sometimes they are busy and cannot stop what they are coding to review a problem. In those cases and when submitting to a bug tracking system it is important to write a concise, accurate report.
When writing a problem report or in your verbal discussions with a developer it is important to provide the correct steps to reproduce the problem. It is best to submit a report once the problem is verified with the expected behavior. False or incorrect problem reports can harm a tester’s reputation and relationship with developers. Make sure you can reproduce the problem. For example, it is important to reproduce the problem to determine if:
• you can reproduce it upon demand;
• the failure is related to specific test paths;
• the failure is associated with specific data;
• certain environments cause the problem (ie., client, browsers).
If you encounter a sporadic problem, work with the developer to determine what information will help him find the solution. I would document as much information as I can capture. Depending upon the type of problem, I might add what other programs are running at the same time. Providing a percentage of the failure can be helpful, such as: I ran test “x” 10 times and it failed 60% of the time and here is how it failed. Sporadic problems can be difficult to fix; therefore, it is important to provide as much information that you can gather. Sometimes I like to review the information I am gathering with a developer before I complete my tests in case he can identify additional details that will be helpful.
When appropriate, have another tester reproduce the problem to help identify additional details. If the problem cannot be reproduced on a different machine, document any differences between the two computers.
Reproducing a problem can also identify tester error and it is best to catch those prior to submitting a problem that does not exist.
Some problems will produce an error log with additional information that is valuable to the developer. Understand what additional technical information is valuable and be sure to capture that information.
I only provide screen shots if the problem is difficult to describe. In those situations, I would prefer to discuss the problem with the developer. If that is not possible or more documentation is needed, I will consider adding screen shots. However, I will crop them to show only the important details as to reduce the noise in the report. I use them as supplemental information as my written report will contain all the information without needing to review the screen shots.
Document the Steps
Remember that someone else needs to reproduce this problem on his machine and sometimes problems are fixed months after they are submitted. Therefore, take time in documenting the steps and review them by re-testing to ensure all critical steps are captured. Identifying at what point the problem occurs is important. For example, if the problem occurs when clicking on a create button or when clicking on the save button is valuable information to the developer.
Is it a Known Problem?
Before submitting a new problem, review the bug tracking system to ensure it has not been logged. If a problem has been logged, add any additional details if the information provide new insight. If a similar problem has been entered, work with the employee who can make help determine if a new problem should be submitted. You do not want to add too much noise to a bug tracking system. I have seen the results of a bug tracking system where everyone adds new issues without consideration of what was previously entered. It becomes difficult to find information because there are duplicate bugs and issues are entered that are not bugs. I always believe it is a good idea to first check your bug tracking system before you get too far in writing a problem report.
Discussions with the Developer
If there is an opportunity, review the problem with the developer to gather more information to add to the report. For example, a developer may ask for additional tests to be performed and those results can be part of the report. This conversation may help the tester understand if the problem has been logged or if there is a difference in opinion on how the functionality should perform. Any differences should be resolved with the business user before submitting the problem.
Discussions with the Business User
If the tester is unsure if it is a problem, or does not understand the intended behavior, review those questions with the business user. I prefer that the tester first review questions with a tester who may understand the business functionality. That way we are tapping into the business community to seek out new information for the department instead of continual training on the same areas. I use the same process with the development team. Before submitting the report, make sure it is a problem and that the correct expected behavior is defined.
How Much Information to Document
How much information should you document in the test report? The details can depend upon:
• the company’s standards;
• how difficult it is to reproduce;
• the complexity of the problem;
• how much information the development and testing team requires.
Writing the Report
When writing the report, I prefer to keep the sentences concise providing critical information at the beginning of the report. Additional information that may or may not be helpful to the developer should be placed at the end of the document with a descriptive heading. This ensures the developer does not have to read through the document to find the important details. Re-read your report to ensure steps are not missing, sentences are clear, unnecessary information and words are not included, and follows any company’s standards.
Submitting the Report
The tester will submit his report based upon the bug tracking system adopted by the company. Sometimes a developer may question a tester’s report especially when a developer is closely attached to the feature. It is best to handle these conversations with the facts, reproduce the problem with the developer if that is helpful, and do not get into an emotional discussion. If an agreement is not reached, then be sure to involve the business user who is responsible for the functionality for the final decision. It is best to minimize these situations by gathering sufficient upfront information and having conversations with the developer and business user (or Test Lead, Test Manager) prior to submitting the problem. Submitting a false or incorrect problem report can hurt the tester’s reputation and relationship between developers and testers. Refer to my posting on Crucial Conversations for a communication model that can help with bridging conversation gaps.
Picture Credit: Amazon
It is important to develop your communication skills to better handle conflict and different types of conversations. There are a lot of people I admire because they can handle a conversation that has the potential of becoming hostile or provide bad news in a non-confrontational manner. Or someone who can gain buy-in on a new approach from his or her peers and management. As testers it is important we develop our communication skills, as we need to provide information to developers, business analysts, and other stakeholders. Sometimes we need to provide information that no one really wants to hear when a release is close to going to production and we uncovered a serious problem. How can we communicate the risks in a manner that our voice is heard?
I found a wonderful book that provides a solid communication model “Crucial Conversations: Tools for Talking When Stakes Are High” by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler. I find their dialog model helpful when preparing for conversations or when you suddenly find yourself in a difficult situation. Imagine you are having a conversation with a developer that is not going well. You need to find a win-win solution – here is a model that can help you.
Below is a brief overview of the model; but you will need to either read the book or attend one of their training programs to fully understand the model and application. Their website provides many wonderful free tools and they have a free newsletter providing feedback to reader’s questions on how to address different types of conversations. You can purchase their book through Amazon.
Start with Heart:
What do you really want to happen?
Example: I want to come to agreement with the developer on the importance of this bug.
Learn to Look:
Look for safety problems in the conversation.
Example: the developer thinks I am attacking his code, I need to find a way to make this conversation safe for him.
Make it Safe:
Look for mutual purpose or mutual respect.
Example: both the developer and tester wants minimize any important bugs from going to production.
Master My Stories:
Stay with the facts and understand the purpose of this conversation.
Example: attacking a developers coding abilities is not going to help the situation. Stay with the facts on what we are witnessing in testing in regards to the bug.
STATE My Path:
Share your facts
Tell your story
Ask for others’ paths
Example: The tester should not be doing all of the talking. Listen to what the developer has to say for a meaningful dialog.
Explore Others’ Path:
Understand their path.
Example: if the developer does not think this is a critical bug, listen to why he feels that way. What are his facts? Repeat them back to him to see if you understand.
Move to Action:
Determine who does what and by when.
Example: if the conclusion is the tester and developer disagrees on the bug’s severity, agree to whom to escalate the problem.
Your Communication Skills Action Plan
What communication skills do you need to address? How well do you handle conflict or interacting with people who have different opinions? If you are not sure, go to Crucial Conversations website. Under Resource Center, Tools + Assessment, complete the free assessment. I found this assessment useful to improving my communication approach. Plus there are different checklists to help you get started. Once this is completed, what is your plan to improve those skills?
If you decide to read this book, let me know how it helped you. Plus if you sign-up for their free newsletter you will have the opportunity to see how others use it to work through problems. I am often asked by testers for books they should read. Crucial Conversations is part of my top 3 books. It is important we can communicate what we witness during testing whether it is to clarify expectations or raise a red flag. I will always encourage testers to work on their skills such as testing techniques and problem-solving. But do not forget to further your communication skills.