Management Consulting
Project Jump Start
Management Coaching
Workshops AYE Conference
Project Management
Management
Hiring
Requirements
Consulting
Process Improvement and Quality
Managing Product Development
Hiring Technical People
Manage It! Your Guide to Modern, Project Management
Behind Closed Doors: Secrets of Great Management
Hiring the Best Knowledge Workers, Techies & Nerds
Corrective Action for the Software Industry
Amplifying Your Effectivess
Speaking Calendar
Testimonials
Resume
Contact
Questions and Answers from Johanna's Radview webinar:
Becoming a Great Tester: Assessing Tester Expertise
Listen to the January 2003 webinar.
Questions and Answers:
Kirk Dameron Asked: I play many roles. I am a Sw Development Mgr(6 folks), and a Test Mgr (2 folks, hiring a 3rd), and also a Tester!)
JR: Thank you for the information. I have no idea how you would have answered my original question!
Jeff Switzer Asked: The information here appears to focus on functional testers. Do you have specific traits, qualtities, preferences for testers that do Load, Stress and Performance testing?
JR: Load, Stress, and Performance testing require in-depth knowledge of the product (level 2 domain knowledge). If you're talking about people who need to write and read code, their personal qualities, preferences, and non-technical skills look a lot like developers: ability to generate multiple designs and choose one, not just choose the first design; the knowledge they are human and will make mistakes (and look for those mistakes), focus on completing the task at hand. The functional skills include debugging as well as design.
Barbara Burkhardt Asked: Please define difference between black/white box testing
JR: black box testing is when you test the code from the outside. You have the requirements or a spec or some other knowledge of the product, and test without looking to the inside of the product. White box testing is when you look at the code, and see how to test the product from the code.
Varsha Shah Asked: What techniques do you use for Architecture based testing?
JR: First, look at the architecture. Do you see potential problems? Do you see processing or data manipulation that could change depending on how the product is implemented? Could the product work different for different people? Are there any timing issues, especially timing that's data dependent? Look for risks from how the product is organized.
jon hagar Asked: How do you handle companies where they require "ranking" and putting "numbers" against people as this cause problems in staff?
JR: I'm writing an article and developing an assessment about this now, because this practice is so prevalent and so bad. Companies should define what they need from employees, in much more than the 7 or 8 dimensions they look at now. However, the assessment should be for each person, against themselves, not against the other people. If we were all plug and play, it would be ok to rank people against each other. However, we each come with our own set of skills and abilities, which differentiate us from each other. The problem is that we have nothing to use instead of the ranking now, which is why the assessment tool is necessary.
Janis Hall Asked: What were the books that Johanna mentioned in her presentation?
JR: I believe I mentioned "Lessons Learned in Software Testing" by Kaner, Bach, and Pettichord. I probably also mentioned my upcoming book, "Hiring Technical People."
David Rabinek Asked: can you suggest interviewing techniques to assess these skills?
JR: Yes, use a combination of closed questions to establish the facts, behavior-description questions to uncover the story of how the person works, meta-questions to see if there are other questions to ask, and auditions to see how a person works. My upcoming article in STQE has brief descriptions about these techniques.
Ajeet Dyondi Asked: can we read the questions and the answers presented somewhere after the session?
JR: Here they are!
Kevin Guy Asked: how do you deal with unrealistic timelines, releasing a product before you believe you should and dealing with the fallout when bugs are discovered in production?
JR: Common problem. Sigh. I do a few things: 1. Define release criteria with everyone at the beginning of the project. Then, if we have to release before we meet the release criteria, everyone agrees about the risk of release. 2. Track the cost to fix a defect during the release and post-release. Your cost to fix a defect isn't the straight 1:10:100:1000, but something different. When your management sees the cost, they can make a management decision about whether to release. 3. Start tracking and use DeMarco's Estimation Quality Factor to understand how good your estimates are. Sometimes the timelines are unrealistic, sometimes the estimates are way off. Make sure you know which one (or which combination) is occurring.
Kirk Dameron Changes Question To: Can you offer any short term help in obtaining more info on "auditions" as part of tester interviews. I have a current opening for a test engineer (in Colorado!)
JR: Call me.
Erick Rozelle Asked: Please describe your definition of people based testing.
JR: People-based testing is testing based on who performs the testing. So, alpha testing is a form of testing, where you release the product to internal people. Beta testing is a form of people-based testing where you release the product to external people. If you ever use tech support people -- because they find things other people can't, you're using a form of people-based testing. "Lessons Learned in Software Testing" covers this well.
An Asked: What is the guerilla testing?
JR: Guerilla testing is a time-limited attack on part (or all) of the product. You use guerilla testing when you want to know if you should spend more time testing a particular area. If the testing does not uncover problems, the risk of not testing that area is lower than the rest of the product, and you can choose whether to continue testing there, or spend time on the rest of the product.
Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.