At the STP Fall 2012 conference in Miami, I gave a keynote on “The Discipline Aspect of Software Testing.”
I created tweets for my presentation in advance (and had those tweets posting while I was presenting) so I included those tweets as part of my slides. Discipline & Software Testing slide deck
My presentation kicked off with a video showing the marshmallow test, a well-known test – the video speaks for itself. You can find the video on YouTube here.
This past week I taught a class on mobile testing at CAST 2012. We brainstormed a list of factors to consider when reporting a mobile defect. Not all of these items will be a factor in the defect but it is a list to think about.
• Hardware Specific: Try another device, try a device that is close in “class”
• Note the OS, manufacturer, version of device, and the version of software
• Device orientation
• Battery status
• Applications running in background
• Connectivity. Network – wifi – if there was any carrier switching taking place
• Device Settings
• Drivers, LED notifications, Bluetooth
• SIM Cards
• SD Cards
• Integration with other software
• Language Settings
• Varying Bandwidth
• Input speed and mechanism
• Navigation Path
Thanks to attendees: Kelli Cruz, Nicole Thompson, Cathy Clary, Cherri Shang, Rajiv Bhati, Saraswathy Ramadas, Chris Anders, Sakina Crocker, Jon Hagar, Gary Norris, Anand Ramdeo, and Jean Ann Harrison. And to Eric Proegler who facilitated.
Software testers have assorted job titles such as Quality Assurance Analyst, Software Test Engineer, QTP Specialist, Lead Quality Assurance Engineer to list a few. Some people care deeply about their job title feeling their title is part of their identity professionally both at the office and within the greater software testing community. Other people don’t particularly care what their title is.
At the Belgium Testing Days conference, I’ll be giving a keynote called: “Why it matters what I’m called: Quality Analyst or Software Tester.”
I’m conducting a survey on job titles in our field. It would be great if you could help me. Here’s what I need: your name, country, job title and if you’d like to add your company name and any comments – comments relating to how you feel about your job title, that would be great.
I’ll probably out the data together in Excel so if you could send this information like this:
Karen Johnson, USA, Software Test Consultant
And comments like this would be helpful:
I care deeply about my title. I feel my title sends a message to my team mates about what I do and what my role is.
I don’t care about my title. I just want meaningful work. My team mates know what I bring to the group and the company.
Leave a reply. Email me (if you don’t want to share this information publicly). Or reply in Twitter @karennjohnson
I gave a presentation called Building Alliances. It was a non-technical talk focused on working with people. The talk focused on positive alliances we can build at work as well as some of the realities – the good, the bad and the ugly of office politics. The talk was recorded at the Pacific Northwest Software Quality Conference (PNSQC) 2009. The recording includes the audio, the video shows the slides from the talk. The recording can be downloaded and played through iTunes.
At PNSQC 2009, I’ll be talking about “Building Alliances.” For a long while, I have avoided discussing assorted topics especially at conferences that might be viewed as “soft” topics. As a software tester without a developer’s background and being raised in small development companies, I didn’t feel I could take the risk of being viewed as “fluffy.” But now some years later, I want to talk about some of the topics that aren’t technical but are just as essential in getting the job done. I want to share ideas about how to build solid working relationships.
I want to talk about ideas on how to build working relationships and ways to collaborate with other people and other teams. I’m fortunate to have had experiences working with some really great people and teams over the years. But people dynamics aren’t always happy path just like software isn’t always functional in the early build stages, so I also want to talk about adversarial relationships and share some stories and ideas on how to re-route and realign relationships. People issues, politics and team dynamics are factors in how well or even whether some products evolve, not to mention how fulfilling or frustrating work time can be.
One of the principles from the context-driven school of testing states: “People, working together, are the most important part of any project’s context.” I want to share ideas for how to make that happen.
The STANZ conference begins on Monday in Wellington New Zealand and continues through the week ending in Sydney Australia on Friday.
I’ll be talking about my use of storytelling with my work in software testing. I’ll also be teaching classes in both Wellington and Sydney as part of the conference.
I’ll be in Malmo Sweden this coming week teaching and presenting at the Oredev conference. You can read more here.
If you’ll be attending the conference or if you’re located nearby and want to meet up, send me an email. It’s interesting to meet other testers. I feel most fortunate to have the opportunity to be at the conference. It will also be my first time to Sweden, yahoo!
The week after Oredev, I’ll be presenting at the ExpoQA conference in Madrid Spain. You can read more here.
I’m surprised I haven’t blogged more about both conferences (Oredev and ExpoQA) but have been busy working. And now I need to pack …
I’m teaching a workshop on how to build a test strategy at GLSEC in Michigan. The workshop focuses as much on creative thinking and strategic thinking as drafting a test strategy document.
Over the years, I’ve often focused on deepening and continuing my technology knowledge with less focus on business and strategic thinking. I’m sure this has to do with my background and comfort zone; I’m used to learning new technologies all the time but less used to thinking about business strategy. In recent time, I’m schooling myself in strategy as much as technology. Without a business background, it’s a less familiar learning path. And as a tester (in my experience), I often didn’t have to (or ignored) thinking much about strategy – at least strategy from a team or product point of view. My strategic thinking was more immediately-centered on breaking whatever application I was working with. But from the perspective of leading a team, there is more and other things to think through.
As a test lead, test manager and now as an independent consultant, I’m often more focused on strategy and less frequently working as a test executor. Strategy has become what I’m working on nearly every week if not daily, by either coaching tactical approaches or in writing a test strategy or updating an approach based on new knowledge or a change or fresh obstacle that needs to be addressed.
The writing aspect of crafting a test strategy isn’t a challenge for me. I can write without difficulty (although I have some annoying habits like switching from present to past tense that challenges both my co-writer and different editors). But it is the actual writing that is difficult for some people and I realize this. Write like you’re talking would be my primary advice. Write what you think. And don’t write what you don’t believe you or your team can execute. I think of a test strategy as a statement of work, every aspect of the strategy should be a tangible or should provide insight into the thinking behind the tactical real work to come. Skip the fluff.
One of my teaching objectives is to help people get past the anxiety of writing. Another objective is to show how strategic thinking is reflected in how we execute throughout a project.
I’m at the PNSQC conference in Portland Oregon. Yesterday I taught my SQL for Testers class. Today I’m giving a presentation on building a test strategy and tomorrow I’ll be sharing ideas on storytelling. If you’re at the conference or in the area, email me (firstname.lastname@example.org). And if you’re headed to Powell’s let me know …