The philosopher Seneca said, “Luck is what happens when preparation meets opportunity.” And I think that’s what happened when I founded XBOSoft in 2006 in China. I have a habit of questioning how things are done, and love coming up with solutions. And I seek out software testers with a similar mindset.
The Chinese cultural bias toward copying the ways of the master rather than striking out on one's own can make recruiting employees in China difficult for companies that are seeking creative thinkers.
I have been working as a software tester for a while now, and I still have a very clear memory of the moment I decided to throw myself into this field. I majored in computer science and technology with hopes of becoming a software developer. The only problem was that I wasn’t very good at coding. So, instead of subjecting myself to the grueling task of studying coding languages, I decided to focus my energy into becoming a great software tester. When I first started, there was a lot of training on how to do the work, but not necessarily how to handle the work. While there will continue to be lots of learning to do on my part, I’m very passionate about what I do. I always wished that someone would have given me advice about entering the testing field, so here are three tips for all of you new software and QA testers that are getting started in software testing to help you adapt to your new work environment and grow faster.
I had the pleasure of attending the keynote talk of my colleague and friend, Michael Mah, at the recent PSQT conference in San Diego in August. Michael, as usual, was very entertaining and passionate about his ideas and research. In his talk, he discussed a case study in which one of his clients has achieved and continues to achieve great results in implementing XP. He also drew an analogy of their Agile team characteristics as compared to other high performing teams. No, he wasn't talking about the Golden State Warriors. Michael's passion is saving the oceans, so he was sharing his experience in working with the Sea Shepherds. The Sea Shepherds work together with passion and purpose and Michael's story could motivate anyone to stop going to SeaWorld and join the fight in saving the oceans and the life within them.
A few short weeks ago at the PSQT conference, I had the fortune of sitting in on Tom Cagley's session, titled Impact of Risk Management on Software Quality. One of the components that Tom mentioned as part of the Agile Risk Taxonomy is Agile Organizational Risk or People Risk. He describes it as the "impact of an environment populated by people." Some may think that this is the most nebulous risk, when compared to business or technical risk. I think it's probably one of the most important but, unfortunately, it's often swept under the rug.
In sports, everyone plays different positions and makes different salaries based on their position and skills. A quarterback generally makes more than a linebacker. Likewise, Tom Brady makes more money than Michael Vick. Everyone knows it and they accept it. His numbers are better and his team wins. His teammates also know he makes more money than they do. However, for some reason, when it comes to evaluating Agile teams, I tend to hear only about measuring the team's overall success. Well, how do you put together a good team without knowing the true value of highly performing individuals like Tom Brady?
I've been to many sessions on software testing metrics where the instructor will discuss the software testing Hawthorne Effect. Often cited are lighting experiments done in the 30's where the light in a manufacturing facility was increased and decreased and its positive effect on factory workers' productivity. When applying the results of these experiments to software testing, most will then discuss testing metrics such as test cases written or defects found, and the unexpected consequences or changes in behavior that can result from using such metrics. But I think we are missing the importance and significance of the Hawthorne Effect. First, the Hawthorne Effect was based on several experiments not only in lighting but also, in many other factors such as break times, food, and payment schemes. Secondly, the interpretations of the Hawthorne experiments vary, and many researchers have derived different conclusions. Some of their conclusions, I hereby summarize as the Hawthorne Lessons:
Agile software development follows an iterative method with the goal of providing working software to stakeholders at the end of each iteration. By providing a view of the software at the end of each iteration, I think each team member gets to see what the others have done and if the team has moved forward towards its final goal of delivering the software. I think that this process helps to build what I call Agile Trust. That is, confidence is provided throughout the process, not only for the stakeholders that the product is moving in the right direction, but also for the development team that they have understood the requirements well.
As a QA on an Agile team, providing confidence to stakeholders on a product in development requires consistent performance throughout the lifecycle.
When recruiting Agile testers for scrum teams, everyone wants to have all senior testers. However, this is not usually the case, and many times you need to recruit the newbies. When I run through my list of considerations, testing skills are, surprisingly, the last thing I look at.
From our webinar last December with Greg Burns and Ron Ben Yosef from BlackLine Systems on agile challenges that they’ve faced and how they got through them, there were several questions from the audience that we had no time to answer. We sat down with Ron and Greg and discussed the classic question of the recommended Developer-to-Tester Ratio.
Managing agile teams is often tied to metrics and measurements. I was in a recent talk on metrics and many were discussing agile metrics. One of the key points repeatedly raised was that you should never have individual metrics, only team metrics. So as I sit here writing evaluations, how should I be evaluating my team members if I have no individual metrics?
Is ISTQB certification useful? Yes, for certain roles on your team. But is is not for all, and does not necessarily make you a good tester. We recently had one of our European clients mention that they thought all testers that are on their team need to have the knowledge equivalent to the ISTQB foundation level. They haven't specifically said that all team members must have ISTQB certification, but this is scary. We certainly understand the need for basic knowledge of testing to work on a project and we would not even dare put a newbie on a project without hands on training, but we think ISTQB is a little bit over the top. Some of our guys have gone to ISTQB training and been certified, but we have found no direct correlation between those that are certified and those that make good testers. What assurance is there that a person with an ISTQB certification can find good defects? Can they recite the components that should go into writing up a defect? Yes. But can the find a good defect, and then can they actually document it in a way that a developer can understand and then rapidly fix the defect.
A while back when we first started our company, we had a very typical hierarchical structure in a management sense. We had me, as the CEO, and project managers beneath me. You could say we managed our business using waterfall. Decisions coming from the top, analyzing requirements, and then developing the plan, executing it, etc. I was determined to work myself out of a job, so that I was not needed. What happened if I got run over by a beer truck?