Testy Testy

Taking Sides Regarding Slides

Testy Redhead — Fri, 13 Apr 2012 06:02:12 GMT

The Slides are NOT the Talk

If the slides are any good, and the speaker is any good, the slides aren't your notes. They aren't the talk. All they are is a small visual reminder to support the story that the speaker is telling you. Getting them in advance and hoarding them is as silly as when we'd obsess about requirements and refuse to test until they were carved in stone as if those were the holy unchangeable truth. Those aren't even a basic outline! They simply do not matter when compared to the REAL THING. Stop hoarding the slides. They are one small supporting factor, unless, of course, your speaker is boring, or inexperienced. In that case, skip the talk and read the slides.

The Slides are NOT to be taken out of context

If you didn't hear the talk, don't take one word from the slide and fill in your own assumptions. That can be amusing, like a madlib, but I didn't SAY that. Sometimes a person will tweet what I said, and although I did say that very phrase and mean it, in the context of a talk, when it doesn't have the story I shared, it may take on a different meaning. Please ask the speaker if you don't understand.

The Slides SHOULD be confusing without the Audio

If the slides are fully beautiful prose, why bother listening to the speaker? You don't get my talk without getting the talk. Show UP! Participate. Decide to come hear me speak, or don't. The slides and the talk are a matched pair. One is a visual support. The other is an audio story. The rest is interactive, where there are questions and answers.

Networking-Connections, NOT Contacts

When you go to a conference, look for the speaker, the attendee, the writer, or even the person you see testing or chattering in the hallway that you have a strong connection with. Who gets you excited about your profession? Who do you see that is "your people" or "Who you'd love to work with one day"? Have a meaningful connection with that person. It doesn't matter how many cards you have. It matters how many stories you remember, and how you made other people feel. It matters what ideas, spirits, and minds connected in a memorable way.

One thing I do when I get your card at a conference, is I use it for a bookmark. Then that day I think about what we talked about. I try to remember specific things. It sounds weird, but I like to do that. Sometimes if it's been 2 years and we haven't talked, I just can't remember, but I do really want to get to know people in testing. That's why I bother. That's why I keep working on this stuff instead of surfing cat videos during my evening. Don't hesitate to tweet or email me if you want to follow up.

It's about the Content

I mean, if you say, "Hey, I'm Bob. We met before." I may not know you. Say, "We met at dinner over Ribs when we were in Las Vegas for STPCon in 2010! yeah. Remember? I was learning .net and we were both talking about struggling with Metrics? What did we talk about in common? Tell me what matters to you. Tell me what impacts you, and I'll trust you and help you however I can. Don't collect my card in a stack. Leave it unless I resonate with you. I'm not for everyone. I'm available for those who are my people. Those who love the part of testing I do.

How to Learn to Make Slides
This is my best advice, and it explains my path.
1. See speakers every month. The talks you like the most--what do the slides have in common?
2. Watch speakers you don't admire. What do their slides have in common?
3. Inspect, Adapt, Improve.
4. Get feedback.
5. IGNORE the scathing and the overly flattering top 1%.
6. Inspect and adapt without the raves and rants.
7. Keep what is uniquely you, but restate it a few ways if it isn't clear.
8. Don't be afraid to improvise and change up your slide deck. The story matters, the slides matter less.
9. I can present without the slides, but they help me stay organized, and the pictures are fun.
10. What purpose do your slides have? If it IS to tell the story, you are doing it wrong. If it is to visually support the story you are already telling? That's great.
11. By the time you start the slides, the presentation should be completed in your mind. Otherwise, you don't have your story yet. Try an outline first, slides later. It might make your slides better.

My Style of Slides
1. Make Draft 1 with Notes.
2. Take out half the words, add in pictures.
3. Take out half the notes, add in pictures.
4. Shuffle the slides around.
5. Add more pictures.
6. Find new fonts.
7. Get more pictures.
8. Consider my examples. If not gender neutral, try again.
9. Consider my examples. If outside of my country, do they make sense?
10. Practice on an audience and ask for feedback.

What's The Purpose?

When I'm at a conference to present, and I have anywhere between 40 minutes to 1 hour and 15 minutes, my goal is to share information. At best, I hope you leave knowing a few things, and that you can contact me for more info if you need to learn it further or want to use the idea. Unfortunately, in that time frame, usually you can't teach someone a whole skill or something very complicated in enough depth that they are ready to go back to work the next day and start using that with no followup. Although I know that without practice, you can't DO that thing yet, I want to leave you with some useful information to consider, think about, form your own opinion on, and follow up with, including how you can learn more if it interests you. Thus, when you go to an industry conference, consider it a smorgasbord and not a cooking class or even a full meal. This is a place for you, the diner, to taste a maximum variety of things that interest you, and follow up on that information in the future.

What's Next?
I am, at this very point, still very engaged with 2012 conferences, but now that many of my 1 hour talks are in the past, or NEXT WEEK (Yay!), I'm going to be moving my focus on to interactive teaching! Half day sessions, and eventually, I have a goal to do a full day session. I want to go beyond offering an appetizer and teach hands on skills that people can get in depth with, and learn enough to perform the task on their own, explain it to others, and put their new skill into practice. The more I learn about how the human mind works, the more I'm convinced that most test conferences and presenters have their slides totally wrong. It isn't the fault of the presenters, as our examples are often poor, and attendees try to collect slides as if they can somehow consume all of that information via PowerPoint slideshow. I know that is a poor way to present, and a worse way to attend a conference. I'm hoping that this post explains why, as well as how and why I've changed my slides and how I attend presentations as a result.

Selenium Meetup West Coast Style

Testy Redhead — Wed, 01 Feb 2012 03:28:04 GMT

Last week I was in Mountain View and very much looking forward to SFSE! I'm happy to report that it was packed, and if you missed it, before reading my take on it, you may want to check it out yourself without my biased point of view interfering at http://saucelabs.com/blog/index.php/2012/01/sfse-meetup-video-keeping-selenium-tests-100-blue/

I'm interested in learning more about selenium, well, to be specific, I'm interested in using Web Driver with Python and Ruby to automate tests where it makes sense and basically expand my capabilities in web testing. I believe automated testing is very important, and automated checks should be created, maintained, and relied upon as one aspect of quality by the development team. The whole team. I mean that when you ask who is responsible for quality the whole team says, "We are." When asked, "Who fixes the automated tests when they break?" I also want a clear, "We do and we don't develop new features until they are fixed." Anything less means your automation really isn't working to the level that your team can depend on it, so it doesn't have a bright future at this point, or should be rated "needs improvement" by the team. I've seen great test automation only twice. Both times the team owned it, relied on it, and would literally fix it right then. No shutting off tests. If it isn't sacrilege to turn off broken tests that used to work, the automation just isn't reliable enough to be counted on by your team.

So, with all of this in mind, let me share first the happy. So many things to love about San Fran and Mozilla. The patio over there is WOW. Mozilla's got some bucks. That's all I'm saying! I almost felt bad about drinking their soda for a minute, but I think maybe they can afford even my Diet Coke for a night.

Also, a kind fellow took this shot for me! Volunteered even. That makes for a happy tourista. No, my hair hasn't turned black, it's was just a bit dark outside at this point.

Lest you think I was cranky, I had a blast that day. I've been waiting for a huge merge, and my devs did testing together! Yes! They fixed bugs and swarmed for the first time. This team had NO testers, and now they are testing their own code and I feel so proud of them I could burst because they are showing just what a team can accomplish together, and they care about testing their own work. Then I spent the day finding issues, and I even handed off a feature I coded, so I'm learning and teaching on the job which basically means that my self-esteem is at an all time high. I'm seeing a great friend who I enjoy, the sun is shining. I had a new type of food, even red wine the night before. I've basically been drinking free cool Diet Cokes between lovely sun breaks, and despite being pale I'm not sunburned at all since the sun is so mild in the Bay Area this time of year. I'm expecting to learn more automation and even see some developer testing, which I believe is essential for delivering quality software.

During setup, the meetup hosts had some problems, and I was able to suggest ways to use the seating already there so everyone could see. I felt helpful, competent, happy, and above all, like a part of this group excited to see what new things companies are doing with Selenium. It doesn't matter to me where the testing is happening. I am a fan of all testing. I believe that different companies and contexts can tolerate different amounts of risk, so I don't assume that every single company has a use for a test team.

Now the Sad Part

When the talk started, I had an open mind. I am learning more about presenting for developers and mixed tester/developer crowds. Personally, I felt that the slides weren't attractive and that they looked a bit "retro" like a 1995 slide-deck, but I said that before I was upset at all. Honestly, it's a great point that the content is all that really matters. The speaking was good and the story did flow. People were extremely engaged. At least you can tell from this blog, that despite the lack of beautiful fonts or lovely photography in the slides, that the presentation did invoke some emotion in me.

Large crowd had about 100 people. All polite and friendly.

By the time the speaker was done, I felt totally deflated. The presenter said things to me that felt derogatory to testers and dismissive to testing. I felt this way specifically because of the following statements, which lI'll try to be careful to quote and please verify via the recording to get the tone used.
1. We run 90 minutes of tests so we KNOW that everything is safe.
2. We do not have a QA team and we never want one.
3. It is ALWAYS best to automate every test. (this was said despite admitting vast difficulty with automating some tests)

It isn't only that the speaker said these things, but that many others in the room were nodding with such sycophantic vigor that their heads nearly fell off. As I looked around I envisioned the sinister large framed hipster glasses hiding evil eyes identifying me as a tester, and I felt like I wasn't welcome. The inexperience reeked to me, and I felt as if I was the only person who noticed that the demos AREN'T on a real website.

Then--want to know the secret? How they keep the tests all BLUE? It's this secret we've called resetting the baseline in testing for the past 15 years. They aren't even testing the actual THING. They are just notifying themselves of what has changed. It isn't new. If they had testers they might have found that solution sooner. It's a great way to resolve the false positives that are always a part of the normal complexity when doing automated checks. It is sad to me that developers who are inexperienced at testing are so certain that they have all of the answers that they don't even attempt to get any training in testing from those of us who have been doing testing for many years.

I find these slides retro, and note that code review is for people who don't like each other, pairing is for folks who do, but as a tester, especially as a tester who shines in the areas of integration, collaboration, usability, and finding requirements gaps, my opinion was irrelevant in this case. Perhaps a title change from Test Lead to Overlord of Automated Checks (90 minutes to total perfection code confidence) is in order. Maybe some provisos can be added such as "So long as they happen in Chrome, we thought to validate them, they weren't an issue that needed human judgement, and they were in the subset of important tests that we picked, but other than that we are 100% confident."

I feel pretty awful as a public speaker saying anything negative about any person, and especially a fellow member of the tiny group of females in technology who speak, and I want to be clear that this isn't personal. Not only were the speaking skills very good, but her enthusiasm for automation was infectious in a good way. If I've misunderstood, or misquoted, I apologize in advance and will make edits. I do believe that this is a common view in the Bay area, and just a team approach that was being candidly shared for the benefit of other people. I do appreciate hearing the plain truth of the work that is done by the doers and I know that having a good set of automated tests is hard work that takes technical skill and persistence. It isn't just what was said, but the feeling of such enthusiastic agreement and unquestioning that really emotionally resonated with me. The speaker was an experienced Automated Test Creator also speaking on team philosophy. While she's not likely up for Testing Advocate of the Year award(if such a thing existed), but she may be nominated with a few others for "Most Divisive Talk 2012". I've got many more talks and conferences to attend, so this may not even make the top 5 before the year is out, but I sure hope the "Let's trash all testing done by humans for any reason" trend can make the rounds in the Bay area and the rest of the country can keep doing good teamwork, like the agile teams have been lately. I'm seeing progress in developers and testers working together. I'm seeing good classes in mobile testing. From what I understand, this dismissal of the value of all human testing isn't what is happening in Europe. I think this is common in the start-up community and also in the web space specifically where there is venture capitol. It's less prevalent elsewhere from what I can tell so far.

It isn't that they don't have or want testers that bothers me. Why do you hate testing? Without understanding what you are dismissing why don't developers even ASK for our help to learn testing? I promise, we want you to test. Our numbers are shrinking. I never want to visually compare data again. Nearly all of the testing I do is tool assisted. There is lots of testing going on outside of the bay area. If you look, even in the space of the web, the secret shame of even the large companies is the human testing is STILL being done because it is finding critical issues that the automation still isn't finding. Even the boatloads of cash Google and Microsoft have thrown at automating all testing hasn't solved the issue.

When you aren't writing all new code, what then? When you ship your first catastrophic error and find that the dashboards you have aren't really as good as you thought, will that 90 minutes seem like it was enough? Or, when you simply want a human to test for usability, error handling, or the code you forgot to write or put in which even the best code coverage can't check for, the few of us who still put up with the emotional battering it takes to actually give two craps about testing in this hostile environment will be here to help you. How would you feel if a manager took a look at a code generation tool and because it gave an impressive demo felt it wrote better code than you do because it was more consistent? It couldn't replace your talent and experience. What if despite evidence to the contrary, they insisted it was true, and the room full of people clapped? Why are you still sending it to uTest? Because you've only checked it. If no humans have used it, you really have no idea what you are shipping to the public. That may be an appropriate risk in your business. Unlike you, I'm not one to tell people in other professions what is and is not true in their business.

I'm just thankful that there are places where developers and testers still work together. I'll be found in those places. It was difficult to write this. I'm glad I did, because I'm not sure I could give an overview without getting teary at our Seattle meetup tomorrow.

Oh San Francisco Selenium Meetup, you've got yourselves some major fans. On the way there in the traffic Marlena and I joked that the California state motto is, "Keep up or Get Out!" Well, I'm out. I also feel thankful that I work for a client who's been in business with NO testing team for 20 years. I'm the first tester. We now have a team! I'm working full time and another tester is working part time, and even our developers are learning to test. I'm also coding some features, shockingly enough.

It makes me very happy that now the person who hired me says, "I get it! You don't have to explain testing any more to me. I'm seeing it!" Yes. He can survive without testing, but we can all deliver features that have value to the customer faster and more reliably when we all care about and do testing. We don't have all of the automation we would like, and yes, I'd like more of a balance. I care too much for my profession to wish for anything other than forward progress for the industry. I love using software, not just earning a living. That is a big part of why I love testing. Each person I prevent from having a bad experience with software is a point of pride for me. That is true if I do the testing, or even if I teach one developer of a test he might run himself. If I teach a tester one idea they may not have tested before, I'm as happy as if I'd prevented the bug with my own code or my own test (I use both manual tool assisted tests and automated checks).

It isn't the unintentional innocence that upsets me. It's the willful ignorance combined with marginalizing an entire profession. I have more than one skill. I'm not terrified that testing will die, because if it does, there are many other possibilities. I fear for the users of this software, because I am a heavy user of software. I also worry about who you are going to hire to do this totally boring work that no one wants to do. This repetitive droning work that so many companies keep trying to staff. You don't get it. You don't get why you suck at hiring testers. You don't understand why your SDETS are all moving to be full coders now? No one wants to be treated like an idiot and to be your code monkey boy. Stop treating people like they are less than human and then wondering why it's so hard to hire and retain the test coders with your laundry list. Then again, that's for another blog. I'm just thankful that the trip didn't end on this note, or I may have started to drink shots on the plane ride home to soothe my sore feelings rather than working on my testing ideas. There is a reason I'm working so hard to talk beyond just testing. A story of how easy it is to feel "100% safe" after running 90 minutes of automated tests is seductive. There is nothing that can be said to that. You can't warn. You just let it run it's course. Either there will be pain or there won't. I'm certainly at my limit when it comes to fighting a gorilla with a toothpick. I'm here for those who want to work with me, not to convince those who've got the answers already.

The bridge was still beautiful later. The structure wasn't as visible, but it was still there holding up the cars. The lights were far more shiny when the sun was down. It didn't make the supports less useful. I hope when they were last tested, it wasn't just in the emulator.

So, for me, the Selenium SF meetup was the most depressing night of January. I'm happy I met some nice people, and I don't let the opinion of a few folks lead me to assume that everyone shares the same opinion. I have hope for the future, and I am really optimistic to have a happier report for you about the Seattle meetup, which I'm going to be participating in. I'm still planning to take a class to improve my understanding of testing using Selenium, hopefully from Adam Goucher. By the way, if you think testing isn't important, please ask Sauce Labs what they think of the importance of testing and if they have any QA team or testers. I believe they have an agile team, which includes testing in many forms, including developer testing and other agile testing, including some thoughtful human exploratory tests.

Now, on to February and BEYOND! I hope the happy post from earlier was enough to sustain you through this long and pretty sad post.

Agilistry Meetup

Testy Redhead — Tue, 31 Jan 2012 19:21:19 GMT

I've been enjoying time in Mountain View this week! I'm happy to say I've been visiting my dear friend Marlena Compton, fellow test blogger and currently a Mozilla tester, along with her hubby Chris who has spoiled us rotten with great cooking and even tolerating figure skating on television. This enabled me to go to my first Selenium Meetup, which Mozilla SanFrancisco was hosting, as well as a meetup at Agilistry.

The start of the Selenium meetup was amazing. I got these picture of the bridge that just blew me away! The space was amazing, and it was fun to see Matt Brandt who I know from the Writing about Testing conference. There were no chairs, which worried some folks, but there were actually plenty of seats, so as a team, once we scavenged chairs I helped explain to my Mozilla friends how we could arrange them by height, and also have some out of the room so we wouldn't break the fire code. I can't talk much more about the Selenium meetup until after next Wednesday when we do the first Selenium Meetup in 2012 in Seattle, and then I'll share it all! Hope to see some of you at the Seattle meetup, but to get in you MUST sign up to get to the floor we are on, so http://www.meetup.com/Selenium-Seattle/ is the link. I left feeling quite discouraged from the San Fran meetup, but the next day was exactly what I needed.

Agilistry has a meetup where smart, amazing testers, developers, and product owners work together. I realized what I love about software is working with smart, good-hearted people on things that I'm proud to be a part of. Some people want to be wealthy. Some want to be part of the in crowd. Others want to be famous. Some even aspire to make a scientific contribution or to change the world. I simply want to do good work with people I'm proud to work with on software I'm proud to work on. I believe I met some like minded people at Agilistry. People who are interested in agile methods because continous improvement can lead many teams to a better place, and they feel happy with the small victories, the quiet accomplishments, and the humble willingness to change. Something keeps coming up repeatedly, and that is that the practice of mindfulness.

Kirk Hendrickson was the presenter. The topic was Customer Empathy Maps.
Kirk explains what Customer Empathy Mapping is to the group.

Empathy Map Categories and Starting Considerations

Group all added in what we were hearing, thinking, doing, seeing, saying, feeling and what is our pain, what is our gain. When we added in real things it was more relevant than adding in assumptions or our ideas of what a person "like that would be ________". Lesson was learned that it becomes less useful if we make a caricature than if we get deeper with one real person.

I would use this technique for understanding more about a customer on a visit. I would do an interview and ask them some questions like, "What are some specific things you did yesterday?" Maybe even, "What was the highest point of your week last week in terms of x task? What was the most frustrating part of the week doing Y?" Maybe even taking what they say and listening in terms of what they are thinking, hearing, feeling might help me come up with a new solution, or even a new test. Does X meet a requirement, but miss the mark in terms of giving a rewarding feeling? These are things that could help a whole team considering quality, but I fear mostly is limited to the PO or "requirement creation" portion of a team.

I learned one unexpected thing, and that is that generally the developers I enjoy and want to spend my time with are not young, cool, new graduates out to change the world with their lean startup in the bay area. I like developers who've got some experience under their belt. Perhaps some grey in their beard. They tend to know more about testing, including how they test their own code. Most often, they have a broad view of quality, and for that reason are questioning easy answers. They may be the person who sees that the demo isn't on a live website, when Skippy the New Graduate is nodding so fast he looks like a bobblehead at the new tool demo. Skippy is totally convinced when he hears a presenter say, "It's ALWAYS better to automate a test, no matter how hard or expensive it is to get there." The grey bearded developer is thinking, "How can I incorporate this new tool as one part of a solution, and how many years until it isn't such a hot mess it makes me miss an important client delivery?" Anyhow, It isn't that I like Agile so much. It's just that generally the people are better for me to work with. If there are smart, open, team oriented people who are using any development methodologies and care about whole team ownership of quality, I'm interested in seeing what they are doing as well.

Thank you to Agilistry for hosting this meetup, and to Kirk for sharing his knowledge on Customer Empathy Mapping.

Build Keeper not Grim Reaper

Testy Redhead — Mon, 16 Jan 2012 21:44:11 GMT

Keeping Builds
December 7th was the first day of continuous integration. When the day started, we had three locations: A Dev server, a QA server, and a Prototype (Client Demo) server. As a tester, I can see the builds created, and push them to production. Then the stories that are waiting for me automagically move to Accept or Reject for me. This is pretty swift use of Hudson if I do say so myself. Now, I'm not the person who set this up. Instead, I'm the tester who can now pull myself a nice build, test some acceptance level basics, run through a couple of important fixes, and make a decision about when to push this build to the client (Prototype) folder. The build selection isn't final though, as I have full power to roll back to an earlier build should the need arise.

After several weeks, I've loved having the power to get new testing builds. The developer who made this happen is someone I consider very test enlightened. He not only gave me ideas of how to automate what I'm currently doing manually, but understands why it is bad for the team if testing is blocked.

Speaking Out
I had a great time presenting at QASIG in Seattle last Wednesday on Pairing Programmers with Non-Programmers and/or Testers Part 2. The recording is available and also the slides. You can't see the slides in the recording, so it's a bit odd to just watch as you sort of need both the slides and the talk for an approximation of being there.

Drama Causing Topics
I touched on three topics that I've nicely avoided getting into here. One I think I will broach. That is how the intent of the Agile Manifesto has been turned into a way to justify blaming others for "imperfect requirements" rather than using collaboration and critical thinking to improve the requirements. It isn't a lack of tools causing requirements gaps. It's a lack of responsibility and commitment. It's the new "us and them" a new silo. This isn't what was intended, but it makes sense that when a team perceives others as "outside" that this sort of intentional improved focus by cutting out important items is just another example of inattention blindness.

Another little hidden secret is my distain for the mandate that "All Testers Should Code." Generally this means to those who say it, "I will hire only those who code in my language and speak my language because everything important is obviously in my language, which is the best." I prefer not to work with ego-centric folks who are too lazy to understand anything that isn't easy for them. Imagine if they decided anyone with an accent was too hard to understand? That wouldn't even be legal. However, their elitism is totally legal if they apply it just to the code. It doesn't make it a good way to categorize, pick, or eliminate employees, but there is one advantage. They do self-select. When companies do this, some types of testers will simply never apply. I work for clients whom I like and respect. If the becomes untrue, I spend some time without work until it can become true again. I'm not saying that I have the same beliefs as all of my clients, because I don't. Only that I don't consider any of them willfully ignorant. When I know of companies who believe all testers should code no matter what they do, I imagine willful toddlers. Spoiled, intentionally immature, elitist people who are unwilling to understand another skill set. I do mourn the loss of what that does to a potentially rich and diverse learning culture. Mandates and absolutes are so ugly. They are a true limit to learning. What I mean by a true limit to learning, is that time and money aren't the only enemy. By insisting on hiring one TYPE of skill sets you eliminate entire categories of people. If you insist on coding on a whiteboard as a hiring criteria, you automatically define you will get no better than 2nd tier testers. The aspiring developer who doesn't always have passion for testing. I'm really enjoying seeing small companies, charities, and startups reap the rewards of the cast off pile that large companies missed out on. Adam Goucher told me, "I'm not a good employee anymore." Basically, I get it. He's super talented. He doesn't need his skills to be wasted by people who don't even bother to understand what he does.

Then we have Marlena C and Matt over at Mozilla. Really unique perspectives. Testers I'd totally dig working with. Apparently in terms of leadership at least, Ebay gets it. They snagged Jon Bach. I'm also talking about Lisa Crispin, Dawn Code, Johnathan Kohl, Selena Delesie, and Fiona Charles. Not all of these folks would certainly be independent and/or working for small companies if testing were amazing and full of learning, freedom, and opportunities at big companies. I still cringe at the useless "SMART" goals that link up into "Initiatives" having nothing to do with real useful value delivered to clients. The endless side projects and political one-upmanship that kills team momentum. However, we start to also see small teams inside of big companies bursting free of the overall culture as well as these small indy companies and those working for small companies! Nordstrom Innovation Lab, FINALLY seeing Ben Simo happy on a team.

So, to summarize, when I hear large companies lamenting that smart people, especially CEOs, aren't interested in the testing that they are doing, and assume as a result, that all testing must be dead, I'm not at all shocked. First off, when were executives ever interested in testing? I don't think they ever have understood what we can do in the first place. Those of us in the industry haven't been interested in the things you call testing at large software companies for awhile. I mean, the things you talk about, I go investigate, and most of the time find out that isn't what's largely happening on the teams anyhow. Sadly, most companies have no idea what they are actually DOING for testing on the team. The message gets confused on the way up the command chain. It's been so severe you've created an entire subset of free-floating people who it takes more than money to hire, and many of whom aren't threatened or impressed by whatever you have to say, because they no longer believe you are in touch with reality in a meaningful way. An entire new type of tester. You've been screwing around for so long that most of testing no longer is looking to the large companies for innovation or even useful ways to test. Many of the ways you test don't transfer. Even when they do transfer, there are cases where they aren't affordable or viable, let alone practical. If I could draw right now, I'd have for you a cartoon with a brick & mortar urn store with a person behind the counter saying, "Death is DEAD! It must be the Zombie Apocalypse!" and on the other side, a website UrnsDirect with sales up 666% in analytics.

TestyRedhead's Final Thoughts (Hopefully w Less Chair Throwing than Jerry Springer's)
Survival isn't something scary. Evolution favors those who improvise, read change in the weather, and prepare appropriately. We are right at the start of the change still. What you know now is of little relevance. What are you able to learn quickly? What isn't being done that needs doing? Is that defined as testing right now? I get some flack because I do non-testing tasks. I don't really care much about that. If it needs doing, and it adds value, I'm open to learning it. Why? Because that's what it is to be working at a small business. I am a small business. It means I do needed tasks, not that I adhere to a defined role at all times. This is a skill that the testers I talked about above have had for years and years. They aren't concerned with representing just testing. They are concerned about doing good work, being ethical, and delivering value. If you are concerned with that too, you won't allow yourself to be wasted for long. You won't work for people who you don't think are smart, ethical, and deserving of respect, even if that means you may for a time earn less. Through faith comes strength. We are just starting to see what testing can become. This is simply the first time testing itself, as a profession has been severely tested. I believe what will come out of it will be stronger, refined, and better for having faced adversity.

Catch Me Presenting and skills S-T-R-E-T-C-H

Testy Redhead — Mon, 05 Dec 2011 03:58:07 GMT

See Lanette Present in Spring 2012

STPCon 2012 March 26-29, 2012 New Orleans, LA
StarEast April 15-20, 2012 Orlando, Florida
BetterSoftware/ADP2012 June 5-10 Las Vegas

Possible Exciting Things (or I'm hoping to attend or speak at)

Agile and Beyond March 10 Dearborn, MI
Agile 2012 August 13–17, 2012 Dallas Fort Worth
There is a small chance of me coming to Europe this year. *gulp* That is expensive & difficult due to the travel time, lost of sleep, and lodging expenses.

By this time in 2011 I'd been hoping to be writing only in my new, fancy, less spam generating blog. I'm realizing that part of being an independent consultant is to better accept the state of things now while planning for the future. Thus, my blogging sabbatical is officially at an end! I've missed it, and to give up the present things that sustain your energy and focus it ALL on the future just isn't sustainable, especially when the future vision is taking longer than expected to arrive.

Since the fall, I've been working hard on a client project. It has given me quite a chance to stretch my skills beyond what I've typically done in the past. Some of that stretching is clearly into a more technical type of testing, by using SoapUI to test Web Services before they were completed! That led to me learning that more test coverage on web services are of very little value in my context. I found one unimportant bug. The time I spend creating and running checks for web services helped me learn a new skills, but in retrospect, I wished I knew before starting what I know now. I would have spend all of that time instead finding a way to speed up testing on the areas that are more risky. I will use SoapUI again, but only because it is lovely to have checks in place that I can hand off to a client that is simple to understand, fast to run, and easy to add to.

I've also written my first code that turned out good enough that it has been put in production (after review and integration). It's very exciting! I'm learning some JavaScript when I get the chance to work on my coding skills.

I hope that testing is treating you well! I'm excited to see many of my fellow cohorts in testing out at conferences this spring.

CAST 2011

Testy Redhead — Mon, 22 Aug 2011 20:20:38 GMT

I had such a great time at CAST 2011 that I just now have had time to process all that went down. First, I gained a new skill, thanks to the risk taking courage of Adam Yuret. I have now presented without slides! I felt great about that since I had planned a slow and careful strategy of steps toward building that skill, starting by ramping down my overall number of slides last year, all the way to planning to present with a few images only. I finished with just 16 seconds left in my time, having hit all of my main points in why I tested (some) anyways when told not to test. Adam did a great job with his perspective on why he didn't test when asked not to test. The deciding factor for us both way our perspective about which was the ethical thing to do, for the company, for the users, for everyone involved. Our situations were different, our background is different, but we both decided based on some common tester concerns. Who are the stakeholders? What options do we have here? I would also clarify that I did not use any deception with my team about my testing strategy, nor did Adam, and we both feel good about our choices and stand behind them.

Biggest regret: Missing seeing Harry Robinson present. I was co-presenting, helping out, doing a guest costumed appearance, or whatever else you want to call my CAST antics at that time. I'm hoping to catch a demo of his exploratory testing automation soon. I've heard about it. I've seen some of the early bits, but it just made me interested in learning more.

A Testing Competition is Not a Bug Finding Competition
When I signed up last minute, happy to be upright, for the testing competition, I just knew a few basics about it. There were money prizes, but mostly I was excited that the testers I worked with before were out at CAST! I thought it would be great to test with them again. I expected some sort of browser based product. I've never been in a live testing competition before.

You see, there are different testing games. Sometimes, for example, in services like UTest, the first person to file the bug report, regardless of the quality of such report, gets credit for it. Criteria may or may not be outlined in advance.

What I learned in my partial participation was that this was about testing. Finding out about the stakeholders, criteria for winning, and fulfilling the stakeholder needs. I think that is a good lesson about testing in general. Testing is more about asking the right questions based on what is important than it is about finding bugs quickly and reporting them accurately. Not sure that will help you on uTest, but at CAST, it was a good reminder.

We participated a tiny bit, until we realized how late it ended. We all logged out, finished our wine, and headed off to bed. Alas, it was still good to be at CAST this year. I think it went amazingly well, and I feel lucky to have been a part of it.

So, You Want to be a Conference Presenter?

Testy Redhead — Tue, 16 Aug 2011 01:53:17 GMT

Here is my fantastical fiction guide on how to become a Rockstar Presenter

"It worked for Lanette. I thought I could just wear a cool costume."-Puposaurus Rex

So, how do I get on the internet in a head to toe cat suit complete with insane tail singing with Geordie Keitt and doing improve with Michael Bolton? Serendipity and cool hair, man.

Super Seekrit 3 Step Instruction Manual:

Read a few books, but certainly not ALL of them, for crying out loud who has time on earth to join the Weinborgian Revolution amid all of these new things we must be learning?
Get pissed off and cause a big scene on Twitter &/or Facebook whenever you are rejected for any conference. Claim foul play and bias.
Make sure what you have to say is factual because people remember facts. Maximum charts and references + metrics=WIN

Now you are on your way to fortune & fame in the wonderful world of Presenting for Software Geeks! Surely a matter of time before TED comes calling.

Real Story of How I Became a Presenter

From 1999-2007-Work quietly building experience in the industry. Learn as much as you can by moving around test areas to build product expertise. (or alternately, you can try different jobs to gain experience as well). If you don't have much experience in the industry, you may want to start with sharing what you are learning, and how you are applying what you are learning.
Attend Conferences-Before I ever presented, I was going to at least 2 conferences a year. Every chance I got, I'd try to attend. Every conference I got to attend, I'd try to attend a session for.
Serendipity-James Bach offered a session at CAST 2007 in Bellevue, WA on Community Leadership. To summarize, it hadn't occurred to me that I was hiding all of my ideas, thoughts, and comments in a small envelope of my mind, and deciding not to share any of them as they weren't important, but pretty much, I was.
Have a Point-If you don't have something to say, please don't blog? And for the love of all that is holy, don't present! You need to have a point and be able to express it to be worth the listener's time. These things take practice. I'd suggest starting to practice in your own blog. Continue to practice there. Practice in your own team. Your own company, and then slowly, as you improve, test out the scale you are at. Get feedback. Improve. Practice and record yourself.
Fail-One of my most important presentations of all time was Testing Beyond the Code. I presented this at Better Software 2010. I was so excited about this presentation. I'd practiced it repeatedly. It had better facts that many of my other presentations. I freaking LOVED this presentation. The audience who came to see it DID NOT so much love it. I felt crushed. This was my Mona Lisa. To me, this was The Best Presentation I Can Do™ and Those Creatins® didn't appreciate it. I had to go eat worms. In dramatic flourish, promise myself to quit! Tantrums were planned. So, what went wrong?I went wrong. When you present, it isn't FOR you. It is FOR the audience. Silly artist--soapboxes are boring.
Listen/Grow/Adapt-I put the Code Coverage Isn't Enough (so open your d@mn eyes man and stop chasing the green bar!) speech and the coordinating soapbox on the shelf firmly in the storage unit. I labeled "Do not touch. Contents may be dull, early, and self-absorbed." I promptly moved myself to Reality Town in the district Cafe Getting Over Herself to work on presenting again. I wrote about what I was doing in the last 2 months only. I got back to explaining what I was learning currently. Not pontificating on my great learnings. Not sharing with "those people", who may not know what I know, but instead, just talking to my people. I prepared less. There were fewer facts. There were more humans and more pictures. It had the best feedback I've gotten so far, and I had more fun working on it.
Repeat step 6 and keep remembering that even the most famous dude in all of software is less well known than Snooki-None of the people you see presenting get rich doing this. Maybe if they sell enough book copies or contracts or get a better job due to their network, but I promise you that my total earnings on presenting are now at least a net LOSS of at least ~$6,000 or more, and worth every penny for my future education. I am thankful for every person who has ever given me feedback. For every person who has rejected my papers or asked for a revision, or explained what I could do to better serve those who care enough about software to invest time in hearing a presenter, or better yet, in engaging with them in some sort of debate.

So, How did you end up at CAST in a Cat Costume?
When I got the chance to appear with Geordie, it was because I write and knew him from before. It was because I said yes. It was because I like to improvise and last moment doesn't scare me. It's because he knows it was my life's goal and one of the best parts of 2010 that I got to sing with a live band. It's because we've talked before. You have to be there and participate. You have to be up for it and say yes when other people say no or make polite excuses. You have to want it more and work harder. It's not just free.

You think you are so great? What now?
So, to summarize, I'm still a beginning presenter. I don't even have a 10 step plan yet. If you don't have a point you can't blog. If you have a point and can communicate it, you can write an article. If you can write an article and explain it well to your team, you can practice on that until you can present at a local special interest group. You can take feedback from that, and go learn how to engage well with others at a conference and go listen to learn how to be a great conference presenter. As you are learning, you can submit at a place that helps new speakers. As you are at those conferences you will meet great people who may hear a lightening talk you can do on the side. Then you can get feedback and submit to another conference. It builds from there.

Before long, you'll be yourself in public without much trouble. Be it a silly person like me, who thinks a cat costume is hilarious, or a serious person wearing a tie at a casual convention. Whatever style you have, as you get more comfortable, you will be more of it when presenting. Don't be afraid to get a mentor. Don't be so self-absorbed that you forget who has helped you and is STILL helping you. I don't have just one mentor. It took a team of awesome people for me to get up and try the first time, and even more amazing people for me to get past the fail step.

If you haven’t been rejected yet, you clearly aren’t trying hard enough. -Unknown

Performance Testing Opportunity-CloudTestLite

Testy Redhead — Sun, 24 Jul 2011 19:21:31 GMT

I may be the least patient person. Performance issues BOTHER me. I take them personally! I enjoy reporting performance problems, but so far my tools have been pretty limited until just recently.

Past:
I've ended up setting up meetings with "Everyone log on NOW--getting a total count and assigning people to do work and email me with the results." This is the manual version of load testing, but it doesn't scale so well. I've set that up across locations, servers, and also in one lab. It can be useful, and pretty simple. The trouble is, if you find a bug, how do you easily retest?

I do my own multi-user scenarios sometimes, trying to overwrite and test permissions. I think most testers end up doing the reboot shuffle and trying to access locked files sometimes in order to test different user setups.

I've also written a document about the DOS switch to limit your own RAM to run in a limited memory state. There are a few ways to mimic manually low resources.

On top of that, I'm the queen of fake file land. I know how to make files of any size in order to test boundaries and stress copy systems.

I also wrote a script to kick off multiple processes at once in order to test for race conditions and to figure out the order in which requests in a queue are handled.

All of these techniques mean that I don't have much performance testing experience at all compared with testers who specialize in it. I haven't bothered to go further because my small clients haven't had a need for it, and the one who did had a separate team using LoadRunner.

Until this week, it hasn't been easy or practical to learn modern performance testing because the tools were limited and expensive!

I waited awhile to say anything, because I'm basically the LEAST experienced person in performance testing tools, but I think that makes me perfect to give you the real deal on how you can learn a tool totally risk and money free. I believe this is a game changer for consultants! Seriously! I'm working to learn more. I think in time this tool will allow testers to test up to 100 users (not sure if it is simultaneous, concurrent, or either/or so long as it is <=100) for free!

What you need without any drama or marketing:
1. A machine bought in the last 2-3 years. Pick a good machine that isn't old & moldy.
2. Either a Virtual Machine (like VMWare Fusion, or VMWare), or you download the free VMplayer.
3. The ability to STOP THINKING and just learn and mess around for awhile. If you overthink this like I did you are going to get in your own way. Don't think about what you need. Don't think about how you are going to test YOUR software or what you need to test, just set aside a little time to mess around instead and think about learning a new skill, not exactly what you are going to do. You can't figure it all out if you never try it, and if you need to understand it all before you try it, it isn't likely to happen. Anyhow, stop asking questions and start doing stuff, and then you can learn.
4. Ignore anything "cloud" related. The cloud stuff doesn't really matter to learn the tool, especially the free part. Just one performance tool to learn how to use in isolation first.
5. http://www.soasta.com/cloudtest/lite/ has the client and all links to get the VMPlayers.
6. Once the VMWare player and CloudTestLite VM are on your machine, you just double click that VM and let it run. Don't overthink. You don't need a remote desktop app or to start thinking about cloud stuff yet.
7. Log in to the CloudTest account you have and start the learning. www.soasta.com/info-center/press-releases/cloudtest-lite-edition-announcement/ has the overview links and so forth.

Let me know how it goes. I hope over time to update when I know enough to do some free testing for a client, and then later when I start to find & isolate some bugs.

I'm thankful for ANY company who allows testers to learn for free. Thank you.

Testing for the User Experience Whitepaper

Testy Redhead — Thu, 16 Jun 2011 20:27:15 GMT

My old links fail to work. I wrote this paper in 2008 and presented it at PNSQC as my first ever presentation in public.

IMPORTANT: The video is posted now at vimeo.com/25106672 (talk starts at 1:46)

Slides don't tell you too much, but are here: http://slidesha.re/lxcgIv

TestingfortheUserExperience

Note: I know my buzzwords post is a hot mess from the summary page because of the tables. I'm taking it down until it can behave.

Collaboration Elaboration-in Mountain View

Testy Redhead — Tue, 07 Jun 2011 23:38:26 GMT

I'm so excited to report that I'm headed to California next week. I'll be speaking at Mozilla, and they have kindly invited others to join, both in person or online!

Details at http://quality.mozilla.org/events/2011/06/07/join-us-for-a-testing-talk-with-lanette-creamer-on-june-14/

June 14th at High Noon Pacific Time there will be live streaming at air.mozilla.com!

The first time I presented this topic it was based on an overview of Testing for the User Experience white paper which won best paper at PNSQC 2008. Since then I've also written an article, 10 tips to encourage collaborative testing, and shared a lightening talk to StarEast 2009 on cat collaboration. Well, you may think you've heard what I had to say on Collaboration before, but alas, you'd be mistaken! This is the super fast overview along with the sequel (not to be confused with the SQL). What in the world has happened with my collaboration efforts since? What about collaboration when the developers weren't even at the same company? What about when our testing "team" was a team of 1? Did I collaborate with myself? Let's just say that I had to alter my ideas on collaboration in order to get any testing done. Even if you've heard me present on collaboration before, you'll get some new ideas, hear some updates, and there will be cats.

Stardust says, "You'd be silly to miss it! I'm out of the shelter and spoiled rotten due to cat collaboration."

Testing Buzzwords Decoded

Testy Redhead — Sat, 04 Jun 2011 19:23:00 GMT

If you work at a larger corporation, you are in danger of attending a "Directional Strategy Meeting" where you might hear some buzzwords used. This handy guide can help you translate!

Phrase	Possible Meaning
World Class Quality	We have no idea what quality is
Standardize	We are even willing to lower quality, as long as it is cheap and we can outsource it or simplify it
Modern tools	Try to automate our way out of this mess we created using magic
Best practices	Copy other companies
Global economy/global concerns	Outsourcing will save us money and give us tax shelters
Measurable progress	More Micromanagement will make us feel like we are making progress.
Increased Efficiency	Mandated Unpaid Overtime where we break the law, but pretend we don't
Measurable Goals	Limit ourselves to what we can easily measure

So, should you find yourself in a situation where you are being assaulted by buzzwords, here are some ways to help yourself take these in without despair. Often, you’ll find that a well-intended person who simply isn’t experienced in quality has been slightly tricked. They’ve been convinced either by success with engineering groups, or by reading books that leading a quality group is exactly the same as leading a group of programmers. That simply isn’t the case.

I’ve found I really enjoy working for teams where those in charge of quality leadership have not only done excellent testing, but have successfully led testing for projects before, and importantly, were well liked and recommended by those doing the work as well as the managers they were reporting to. Too often, managing up well is prioritized over managing your direct reports, and their direct reports. If you can skip several levels and interview both levels up and levels down in an organization and get a consistent picture of the performance and it is good? That person is a true excellent leader. If the person in charge is polarizing, and either everyone above or below doesn’t believe in the competence of the leader, that is a huge risk.

I hope that this translation guide can help you along with how I answer the question: "Should I stay or should I go now?" Are you protected enough from the larger corporate problems to perform your day to day work to the best of your ability? If you are, you may want to stay. Every company has issues, and every job has pros and cons. The question in software isn’t, “Can’t I do this for the rest of my life?” The better question is, “For the next 6 months, what are my plans?” Things change pretty fast. Even 6 months may be too long to wait to evaluate. If you are in a buzzword heavy situation, try this translation chart, and see if it helps you write your own.

Corporate Phrase	Edited Meaning
World Class Quality	Our team needs to define what meaningful quality is before someone does it for us!
Standardize	Even if we need a limited set of "supported tools", we'd better protect the future and make sure each team can use the tools that work and we aren't limited so much that we can't use new tools are they are available.
Modern tools	Money to use for sustainable, well designed, helpful automation that applies in our context. Protect this money so it isn't wasted.
Global economy/global concerns	We understand the needs of our global customers and have our testing scaled to support all regions that apply now and in the future.
Measurable progress	We must decide what progress we really need, find a way to measure it, and make sure it’s agreed upon by our management or they could do this for us.
Increased Efficiency	Iterative improvement as measured by meeting team goals.
Measurable Goals	Agree on goals that matter, understand how they will be measured, make sure that the data isn’t abused or unfairly manipulated.

If there are other buzzwords, terms, or worse yet “Mandates”, try to think about what you can do to make them positive for your team and protect what is working to get the job done.You may think I'm picking on one particular company or client, but I assure you, if these seem familiar, it is only because I've seen them in no less than 3 places, and they are commonly used in anything from "quality improvements", "testing plans", "long term goals", and "engineering excellence" as well as "corporate initiatives". It isn't enough to point out the lack of details or flaws within them, as that will just target you as being a "trouble maker". Unfortunately, the majority of the people willing to use this corporate speak will not understand that you questioning them is meant to make them better, or is helpful feedback. If they truly understood testing, they would know to choose better words than these. Words with meaning. Better yet, words that don't alienate testers. This isn't the sort of fight best won with bluntness and confrontation. It is likely that you'll be seen as disloyal to your company if you approach these buzzwords with disdain.

Instead, do your best to reinterpret these goals and make them useful. Assume that they just don't know better, and the intent really is to improve quality, and help them improve quality, even if they can't express a good plan for doing so. If it isn't possible to help influence the buzzword party for good, at least protect what is good about your teams to help you best cope and limit the harm they can do. Test through it, just keep testing, keep learning, and long after the nonsense goals have passed, you'll have useful testing experience to share. Also, keep in mind that it isn't always like this. There are small unstable start-ups where even the executives, all the way up to the CEO are doers. They are the people writing the code. They often don't do much testing or hire many testers, but there is far less time for writing buzzword heavy documents at some small companies. There are also some amazing large companies being led by amazingly smart and capable testers (nod to Jon Bach from Ebay as a prime example), so there is even more hope on the horizon for better understanding of what makes testing good, and what good testing looks like. Whatever happens, don't spread these nonsense words yourself. When you refuse to leverage the synergy, and instead put it into simple terms that make sense, we all win.

Each time you leverage the intrinsic skills driving passionate innovation in the instant mobile world of the web 2.0 social media strategy, embracing world class quality at a company known for class leading technology, a kitten dies. Save the kittens. Down with buzzwords.

Testing Coach, Consulting Tester Update

Testy Redhead — Tue, 03 May 2011 17:10:00 GMT

Best Things
I have a new perspective on what is possible with automating acceptance tests for Agile stories because I've seen it working better than I believed teams could achieve! I'm inspired.

Seeing some very good testers finding some new bugs and becoming even better at working with their developers is the most rewarding part of coaching so far.

One bug was found that went undetected for a decade because of a tester learning new exploratory testing techniques! It's talent she had all along, but now it is set free!

Got to work with a developer that I admire to troubleshoot an issue that was important to a client, and made a major breakthrough on it in just a few hours.

I had no idea how friendly, open, and kind people were in the middle of the country. It sounds odd to say, but in Seattle, people don't often invite me over, or offer to have lunch, or greet a new person and go out of their way to show them around. The fact that it isn't just one or two people, but most of the people I've had the honor of working with makes me want to do my best work for them even more than I already did.

Worst Things
Working in an open space, I've learned that I need to be a bit more careful. I'm loud, enthusiastic, and I have distracted people on accident, slowing their progress at times. Enthusiasm can be good, but breaking someone elses flow or distracting them unintentionally isn't.

There is an unfounded fear that some testers are dealing with that I'd like to see wiped away. Code should not be used to confuse, belittle, or intimidate anyone. I assume (sometimes wrongly), that testers have understanding of programming concepts, when in reality, our experience and comfort level varies. I'm proud to say that I'm working on material for a quick class on Object Oriented Programming Basics for Testers. One of the testers on my team is going to collaborate with me make it stronger and present it with me for any testers who want to come learn or review.

I've learned that I'm limited. I tend to get excited and think that because I want to do something, that I can go on forever without free time, sleep, or time to care for myself. As a result, I've been in worse health the last month. I've literally fell asleep onto my laptop twice. I'm growing, but I know it is possible to learn and grow without self-abuse. I just haven't found that balance yet. I suppose I had to test myself to know what the limit was.

Boundary Testing

Testy Redhead — Sat, 30 Apr 2011 23:45:00 GMT

I believe that boundary testing is in the calculator exercise in Testing Computer Software, which is also known as "The Bible" among software testers. Despite the fact that most professional testers know that we should be testing for boundaries, I'm finding that often, these tests aren't well performed, and even when we do perform the tests, the bugs aren't fixed! Here is a true story about several different bugs found in one day, just by testing ONE boundary.

A bug was found that when a certain number or more characters were entered, truncation did not happen. This error was handled, and an error dialog was brought up, alerting the user. Unfortunately, this application is expected to be run without a person watching (without a UI, or also known as headless in some circles). This meant that for all practical purposes, the application was frozen. A fix was put in place, but I was curious to test all of the boundaries. The team created an exploratory testing charter.

When the charter was run, we found MANY diverse behaviors depending on where we exceeded the expected characters.

1. In some cases, the application would crash. We wrote a bug on this straightforward issue with ease.
2. In other places, truncation happened, leaving unusable and incorrect email addresses and ages. These are easy to report, but difficult to know what is "expected" or what would be desirable in that case.
3. The most interesting issue we found was a silent failure. The entire entry would be skipped, and the log would report for example--Success! 10 entries imported. 9 Correct 0 Skipped 0 Errors. Subtle silent failure is the riskiest issue we found in my opinion, because if you are dealing with many enterprise solutions, you might have millions of imported pieces of data per day, and nothing to check that any are ignored, truncated, or missed.

A few things to think about in terms of boundaries. It isn't just how many characters, or what characters, or is "replace with nothing" or "null" allowed, or can you delete nothing that concerns me. The better question is, on what scale are these issues fixed? Will the headless system ever be fixed so that NO error dialogs will put it into a useless state again? It is easy to test for the error conditions that we handle. It is the error conditions that we don't handle and don't expect that we need to test for. This is why unless we have tested the boundaries and error handling ourselves, we should not assume that because it is basic that it is covered, or that because in one part of the application it is handled, that it is handled everywhere.

New Article Published-Why Participate?

Testy Redhead — Tue, 19 Apr 2011 12:31:00 GMT

If you haven't checked it out, I am proud to be in such great company with the other authors in the April edition of Teatime for Testers.

Read online at http://issuu.com/teatimewithtesters/docs/tea-time_with_testers_april_2011__year_1__issue_ii

Or download the PDF at www.teatimewithtesters.com/#!downloads and click on the icon of the April issue. I recommend getting all of the issues if you haven't. They are fantastic reading.

Yes, the boring part is required too

Testy Redhead — Mon, 18 Apr 2011 23:34:00 GMT

I got into an interesting chat on twitter about "Happy Path Testing". You see, in the experience of one guy, exploratory testers just don't have the patience to test requirements. They get bored and stop seeing problems when they become familiar with a UI. Well, it seems to me he is blaming several different issues on "Exploratory testers", when really they are issues with some people, and all humans. Let me break it down for you.

Issue 1: Functional Testing is part of the job.

By this, I mean testing the requirements and verifying correct behavior (I.e. "The Happy Path") is part of every testers job. There is NO exception for Exploratory testers. The difference is, with Exploratory testers this is where you start (your acceptance criteria), not where you finish. In many modern software testing groups, there is some automation in place to make sure that the happy path stays happy. This may be in FitNesse, Selenium, Unit tests, TDD, and it may be created and/or maintained by Developers, and/or testers. Usually the basic happy path is best covered by developers, and more complex combinations are covered by testers using some sort of scripts or tools, but the point isn't to automate all testing. It is simply to automate the boring testing so that humans can do what they are better at rather than running the same test the same way time after time. Also, just because the test is automated doesn't mean you never need to test it manually. It is good to test the user experience from time to time. Automation has a narrow validation scope in most cases. A human can generally detect more variance than automation can.

Today I spent several hours validating 117 XML files and out of those I had a list of 2 separate issues. It turns out there was a valid explanation of both problems. So. Did I waste my time? Am I doing a poor job? I say no. No, because this was new functionality that needed thorough testing. Even a slight problem would be quite expensive in this area, and this data change involves some math. I had to validate beyond the smallest scope to make sure that the changes didn't impact more than intended. The FitNesse tests and unit tests not only passed, but were reviewed by another developer, and a tester. Also, this was a new area for me, so I learned more by going through these files difference by difference to understand why. However, why did I stop short of validating all 580 of the files? For a great reason. After testing over 20% of the files, I didn't find even one unexpected difference, yet, I'd validated every expected change over 100 times total. It is possible that I missed a bug, however, the likelihood was low. I conferred with my fellow testers. We all found the same results with different tests. The fixes were good. Did we feel bummed out by learning this? No. We felt proud of our developers because more and more they are delivering solid code. Many times the bugs found are requirements gaps we didn't consider rather than something functionally missing or a code error. This doesn't mean that our testing skills are slipping or that we no longer have to do functional testing. It simply means our team of developers has evolved beyond the "throw it over the wall" phase.

I've worked on teams with another culture in the past. The culture where, "We don't have time to make Unit tests!" That is confusing. If you don't have time to test it, you surely don't have time for the customer to reject it, to fix it, not test it, and get it sent back again. If your excuse is that you don't have enough time, realize that you are dumping boring work, and part of your responsibility ON your exploratory testers. Don't be shocked if the best testers don't want to work with your team. Just as I'm sure you don't want to work with testers who are so limited that they can't start testing without "complete documentation", or expect hand holding, the best testers want to work with developers who have pride in the code they create. There is no joy in finding bugs that any monkey could find. The joy is in discovering a bug important enough that it SHOULD be fixed, but not because it is a developer mistake, but because it saves many users from frustration and makes the product better that it was found and fixed before it harmed any customer.

The second issue is caused by something all humans can fall victim to, not JUST exploratory testers, and not just testers, but all humans! It's congnitive bias, which there is a nice list linked to here. Anyhooo,..not specific at all to testers, but something we professional testers, along with all scientists must work to avoid.

To summarize,..the boring part IS your job as a tester. Any kind of tester. However, it is also your job to try to automate the boring part, for the simple fact that humans aren't especially good at repetitive tasks, and brain engaged testing is the best sort of testing. It may not be possible to eliminate tedious checks, but try to reduce them where you can. Also, as a developer? The boring UNIT TESTS and the discipline of doing some checks yourself before releasing code is YOUR job. It isn't to be pushed off onto the testers. We share in common that the more we automate the happy path, the more time we can spend writing interesting code, and finding interesting bugs rather than rehashing the old stuff, or finding and fixing the same bugs over and over again.

None of this is Real!

Testy Redhead — Fri, 01 Apr 2011 14:39:00 GMT

When in a small web company, Agile releases are real. By real, I mean they SHIP, and then you get feedback. In situations where you don't actually release the software at iteration end, done means different things, but until it is released and people are USING it, it isn't done. Even then, it isn't truly "done", but that isn't my point. My point is, we set up these arbitrary iterations to help us meet our goals, yet it is just a structure if we aren't actually releasing at the end of a sprint. There are many business reasons why it isn't always possible to release that often, as well as testing considerations! It isn't always best for the customer to get the latest code every few weeks even if we like the short feedback cycle. My point is, when you aren't really releasing, there is an awareness that the iterations are a fake framework slapped on top of a real release schedule. This has some pros and cons. Also, I've learned in the last month that business size has little correlation to agility. I'm working with a very agile team at a large company, and a team which isn't following any process I've experienced before at a very tiny company. Overall, I'm glad to be experiencing both!

Pros
-Ability to work in testing that spans features. There is a huge gap in the general "Agile Testing" strategy used right now. That is the basic fact that many teams using Agile aren't on the first release anymore. There is a huge debt swamp of regression, building changes, and outside risk to be slogged through, sifted, and planned for. If we prioritize these, they can be great to automate, manually test, as exploratory charters, or even as end to end collaborative test exercises.

-Flexibility in validating bug fixes. We aren't REALLY releasing. This means even if others try to impose an emergency, we testers can be wise and stay calm. Emotions can be useful in testing, but they are deadly and dangerous to making good decisions. We can keep things in perspective.

-Partial stories don't have to make sense to the user. We just have to demonstrate them internally.

-Retrospective, burndown, & backlog all regularly get done, so we can incrementally improve.

Cons
-No feedback from users!

-Not really getting the full advantages including actual practice of a full release every iteration.

-Testing is still going to be different before a real release than it is for iteration end.

-Little to no incremental insight into how to adjust our testing to improve it.

Personal Life Stuff
Much of my daily life has changed! Long time no post, and mostly that is because of all that has been happening behind the scenes. First, I've gone independent! Yep. I am now the sole owner of Spark Quality, LLC. In a few months a business website with all sorts of info should be ready. For now I'm focused on my work. My main work is happening in South Bend, Indiana where I'm working as a testing coach and consulting tester. The team I'm working with is amazing! They are not only the most "agile" team I've worked with, but they have the most functional and best FitNesse automation that I've seen in practice. The testers pair with the developers and each other. They are warm, welcoming, friendly, and just a killer team to work with.

I'm also working as a test practitioner at starting a test team from scratch. We've gone from no testing, to one fulltime tester, one part time lead (me), and one intern I'm coaching to become a tester, which is a huge challenge to do on a remote part time basis. In fact, it may be the very biggest challenge I'm facing, and I'm facing many.

So, overall, I LOVE IT! I mean it. I have never been happier as a tester and human with my career. Not every part of it. I HATE doing the bills. I HATE being away from Craig so much. The time zones are difficult. The worst thing so far is the increased pain & loneliness of not having my support system, and also the food in Indiana is yucky to me. Pretty flavorless. When I think of Seattle I think of fresh seafood, variety, produce, & spices from around the globe. I think about Indiana and it's fried stuff, bland grey beef, and more french fries. Kind of makes it easier to not overeat, except for the few exceptions. There's an Italian Bakery--WOW. I could eat all meals there. Heh. The best things about Indiana are the people I work with. They are true good people. Just all heart, humor, and hard work. They are the kind of team to welcome you in and help you overcome all obstacles in order to be productive. Then there is Matt, who is the only reason I was able to work out a way to try this job! Thank you so much to Matt Barcomb, who is an inspiring agile coach. The opportunity to work with him is a true blessing. I feel like I won the lottery here with this job.

Video Blog-What now?

Testy Redhead — Sat, 05 Mar 2011 21:05:00 GMT

Sorry I'm so tired and congested in this video. You can tell I'm not feeling 100%. I did want to remember to come back to talking about this idea of improving speed & accuracy though. Please share if you have your own ideas on making exploratory testing faster & better. Also, how do you judge what is most important? Faster? Is there ever a point at which we are happy? Can we ever say that our testing is "fast enough" or "good enough" for now? Will we always be shaving off any second we can in order to be faster than the next team?

Funeral Dirge of Regression Automation Myths

Testy Redhead — Fri, 04 Mar 2011 21:12:00 GMT

The Joy of Failure

Testy Redhead — Wed, 02 Feb 2011 15:14:00 GMT

One of the important testing questions that I don't see asked often enough are performance related design questions.

1. How long do we keep trying for?
2. What do we do while we are trying?
3. When we fail, how long does that take?
4. How do we define fail?
5. How many ways can we fail?
6. What if we fail in another way?
7. Can we clearly and correctly define success and failure?
8. How does failure impact the user?

I have an example here of what I love to see and one that really bothers me, and the difference is really subtle.

Happy Case:
In free Hotmail, which is supported by ads, when faced with a connection issue, I'm shown my email and an ad error. Good choice, Microsoft! The ads will give up and live to fight another day. They will accept failure to the ad server this once, still give me my email, and the next time I click, they get another chance.

Also, while I'm pretty happy with this fail, it could be better. How else could it fail? When should they require success to show me my email?

Sad Case:
I've had to stop using Google Chat for awhile. I often have many browsers and windows open at once. The combination of reading gmail with a google chat window open, active, and searching for new updates is a performance battle to the death. I urge you to try this.

Setup: Either Firefox or Safari for the Mac or IE on Windows
1. Read and respond to multiple gmails in one browser tab or window.
2. At the same time have a Google Chat with 5-10 minute lags between responses keeping the window minimized and bringing it up again periodically.
3. See how long you can tolerate it for.

I was ready to kill within 20 minutes. How does this happen? This is called team silos, and way too little human scenario testing across applications. How can products known for speed be SO painfully slow used together? It's subtle failure to let go, persistence to avoid failure. Perfectionism hurts perfomance in some cases. Look for it. Think about when failure is the better option.

I'll take "What is the question?" for $1000, Alex!

Testy Redhead — Sat, 29 Jan 2011 03:01:00 GMT

What is the important part of a test?

Why do so many companies track them step by step? Is it the charts? Business people LOVE the chart, the number, show me how you saved money/earned money. What is the bottom line? Why do I pay for this? They want to know.

Here is my ranking system in the last 10 project I've worked on:
1. The Question the Test Idea is Trying to Answer
10. The Test Idea
15. The Test Data
100. The Topic
1001. The Title
1002. The Expected Result
Either 2 or 2002 depending on how you are using it. The Actual Result (at that time)

When judging the priority of a test, how important is the question that the test will answer? This helps me prioritize better.

Define cheap. You gave me $0.02 & told me to buy lunch with it.

Testy Redhead — Wed, 19 Jan 2011 01:28:00 GMT

Today I tested a feature which supposedly allows a user to upload a training video. I reported a bug that I was unable to load any of our small files, even the smallest video we had. I got an appropriate error which informed me of the upload failure due to exceeding the file size. The maximum file size?

2,000,000 bytes

Well, that doesn't look so bad, does it? If you gave me that many dollars, I'd be pretty rich! So, that leaves me trying to explain a few things.

1. People don't speak in bytes. I mean, not since the early 1990's. Not anyone I like to talk to, unless they are talking about converting FROM bytes to something more useful in the UI or using byte comparison to detect changes for automated checks, but I digress here. The point is, bytes do amazing things, but video takes more than that. If we are attaching a .txt file, I'm happy with this limit.

2. Before they followed gmail in offering ever growing free space, I believe Hotmail allowed 20GB space for users for free! Don't quote me on that one, because it's been so long since I had to much about with deleting my photos and excel spreadsheets that I've forgotten. The client I'm testing for is paying money. YouTube lets any video jockey who wants to upload a cute kitten riding a roomba have bandwidth at 5GB a pop and that's while compressing the daylights out of it for you so it will fit in the 5GB beach bucket. We aren't talking cinema quality here. Yet we can't allow these paid users upload more than .001 GB of video? Feel free to point me to .001GB worth of video to show me what kind of video training I can upload. I'm sure it will be very informative. Rated G or PG only please. I keep content to PG13 or below. It's me, so I have to allow for an occasional "d" or "s" word, but I try to avoid dropping any "f" bombs on my kindly readership.

3. Why? Why bother to support a format without supporting the ability to upload files IN that format? It's like the gift of the Magi, but less sweet. However, I had fun giggling about this defect. The funniest thing about this defect? It isn't considered a bug.

What? How can this not be a bug? We're talking about 0.001GB allocation. Several years ago, before they moved to mostly unlimited, free Hotmail allowed users 20GB. YouTube is giving us 5GB per video. Has been for ages. Cloud space is going for $.03 per hour (after a setup free, some contracts that said something about rumplestilskin, and a few cloudy things). By calling this NOT A BUG do you realize what you've done? You've made me do it. Yes, I researched the average hourly wage of EACH user by area and job title in the US who we intend to use this system, and conservatively, based on public data, that is an average of $26.43 PER user.

So, for each user who spends time trying to upload something and fails, we lose not just the support cost, but .44 seconds per MINUTE over just allowing them to do what the system intends to do, which is upload the blessed training video.

Now, for the love of Kaner, do not make the tester go crazy again, or Bachs help me I WILL calculate the likelihood that the user will go view a cat riding on a roomba rather than watch the software training that could help them do their job.

So, why is it important to USE software rather than just use automated checks without any complimentary professional human testing? Because this meets the requirements for each portion of the system. This unusable combination of this, which when considered by any person makes no sense, is exactly what would be delivered to users.

Let's test together. By that I mean, let's test our products working with other products. Let's test our features working with other features. Let's test our data in other browsers. Let's test all of the integration with all of the interactions all happening at once. Because that is what life is like. Life is not one little isolated morsel by itself. It is the full beautiful messy symphony of noise. We may like different types of music, but I'm trying to find out, can you dance to it? Is there any rhythm here? When I talk about testing the workflow, about testing for the user experience, it is this exact thing I'm talking about. Not about converting Bytes to GB, but about having some point to your testing. It isn't about being right. It's about being useful. And sometimes, it's about shaking your groove thing to a really great application.

Testing the Boundaries of Testing

Testy Redhead — Mon, 17 Jan 2011 16:42:00 GMT

My current project is quite busy right now for me. I'm on my forth week of overtime, and despite being prepared for the crunch, I'm becoming a bit weary. Therefore, I'm taking a break to share with you a few things I've learned recently about testing as a consultant. I've heard many testers explain what is and is not in the scope of their "job" as a tester. Strict statements, such as "It is my job to provide information, but I don't assure quality." or "I make recommendations, not decisions." One of my favorites, heard recently, was "You are a consultant. You provide suggestions. It could harm your longevity with the client if you forget that!" Wow. There are some strong feelings out there about what boundaries we testers must stay within. Being a tester, exploring boundaries is quite natural for me. In fact, if I never check them, I could be guilty of self-limiting behavior, which is worse than testing boundaries to me.

I see my role as a consultant to provide what is needed for the project to succeed. Sometimes that is testing information. It certainly includes a solid testing strategy that adapts as the context changes, and it does include testing that is improving over time. On this project, I've created a new section to test plans that my boss plans to use for future test plans, I've started creating draft read-mes and delivering those along with some documents to help users to the tech support team which supports our product (along with dozens of other products), I'm doing the planning and documentation for UAT, and have done research to inform the deployment plan for the project. None of these things are traditionally testing tasks. I feel fantastic about this! Teams are smaller. The teams I want to be on should hire a flexible person who will grow over time. I want to keep learning skills. I also want to work with Developers who do what is needed. You need a diagram on how X works with Y? They will draw one on the white board to use for now, and possibly revise it later, but they don't wait for the planets all to align and a new analyst to be trained just to stay within their job description. This is part of the freedom of being a team member, and not just a role or list of skills. While not all of the tasks we do fit into "testing" strictly, I'm a consultant. That frees me up to do what is needed, which is not always testing.

Waterfolly la, la la la la

Testy Redhead — Thu, 16 Dec 2010 14:52:00 GMT

Deck the halls with specifications
Water folly lolly la, la la la la
Wad up the changed versions for decorations
Water folly la, la la la la

Don we now our passing deadlines
Waterfall folly la, la la la
Tripping bugs like aging landmines
Wateryfolly la, la la la la

Ok, I kid. In all seriousness, I've learned some great things going from Agile to Waterfall that I'd like to share. Scrum has a few problems that I'd like to see addressed. One is that the PO job is too hard! On the project I'm working on, we have a great team of Business and Functional Analysts. They are working with end users to design something that works overall WITH agreement and flexibility for change in the future. Because they demo the creation in Proof of Concept, and because there is User Acceptance Testing, there is more customer interaction than the Agile team I worked on. Also, instead of the product owner being the one who understands, we are all responsible for understanding and building/testing/designing what suits the business need. The part where someone communicates well with the users is deemphasized in the way Agile is often implemented, especially with Scrum.

So far the best part of working on this team is my stress level. I'm not working every weekend and until 1am. I don't feel on the verge of tears or like I'm working with an axe over my head. I have a reasonable amount of time to do things. The schedule is MORE agile than my agile project was. I do not miss the daily Scrum meetings at all. I meet up with the analysts when I have questions, and in this way communication is better than it was on my agile team.

If I could change one thing, it would be the specs. Rather than endless pages of documentation, we'd do quick presentations, diagrams, and demos. The recordings in video would be the working spec. It is getting the walk through and agreement that matters, not the format. I also notice that business people read even less than we do. No one making business decisions want to read a 150 page technical spec. I like the agile approach better.

I've realized I want to work on a team with great communication, a flatish org structure, and to have trust. I'd prefer a place who doesn't do "initiatives" and instead is focused on building great software (what works over what the process is). I don't think scrum or waterfall are good answers. In fact, I think scrum as practiced has little to do with the agile manifesto.

9 Tips To Encourage Collaboration Webinar

Testy Redhead — Wed, 15 Dec 2010 15:39:00 GMT

Thanks to Frank and Saurabh from pushtotest.com for hosting a webinar! It is a bit more than an hour long. There are many webinars which are more technical and developer oriented at the site as well to check out!

http://www.pushtotest.com/lanette-creamer

Video Blog Chatter-5 Testy Minutes

Testy Redhead — Sat, 27 Nov 2010 06:25:00 GMT

Firstly, I must now approve all comments as spam has run rampant. This is an attempt to manage it. Once I approve you to comment, you can always comment, so please be patient as I try to make my comments worth reading in this blog. Rather than posting this on Wednesday as I'd hoped, I found and reported a bug to GoDaddy.com. Using a workaround, I now present to you the video blog I'd planned to share 2 days ago.

In case you don't have 5 minutes, let me summarize.
I did a webinar today on 9 Tips to Encourage Collaboration hosted by Frank Cohen from PushToTest.com. I'll share the link once it is posted next week! Everyone can watch it for free and send me comments/questions/throw rotten tomatoes! Today's webinar was the first time I presented with a cat on my lap the entire time. It was quite calming, although I blame her for me going over time as I normally leave 10 minutes at least for discussion and stories. Kind of weak to give a talk on collaboration and then not take any input? Yeah--Well, give me some input. Blog about what you thought if you like and I'll comment back to you.

I'm reading Weinberg on Writing right now. I like it, but as I lazily skimmed the exercises I've decided to go back and do them all instead of being that "instructions are for wussies" arrogant girl that I can be sometimes. Rules? What rules? I break them or make them, don't abide by them.

Also, THANK YOU. To the people who read my blog. To the many people who've helped me get started and grow as a speaker and writer this year. To the people who believed in me when I got laid off. To those who recommended me and showed up! Happy Thanksgiving.

The Future of Testing is Wide Open

Testy Redhead — Thu, 18 Nov 2010 22:30:00 GMT

There has been plenty to read lately about the Future of Testing. Some of it from testers who I greatly respect, and up until now I've held my tongue and instead rambled on about topics I know more about, such as the real experience of using a schedule to keep me sane on my current project. Paying attention to the context of my assignment and changing my test strategy to be more waterfall (gasp) because that is what the client is asking for. So, considering that my current testing for the most part in much like testing I did in 2003, who am I to talk about the future of testing? I'm Lanette. Also known as Testy Redhead by some. I'm not here to predict the future of testing. I'm here to ask what people are smoking that makes them think that because they are great testers or that because Agile is really popular right now that they suddenly are psychic friends and can accurately predict the future. I must call some shenanigans on method used to predict the future here. I do so with all respect for the TESTING expertise of people involved, as they are talented at testing and have great ideas. Predicting the future didn't make the cut for me in terms of their great ideas though.

First, what I'm talking about is this summary blog from Sauce Labs which isn't the main culprit, but merely the straw of pseudo science that broke the camel's back. A few weeks ago, Elisabeth Hendrickson ASKED (note: She did not state a proven fact, she wrote a question) in her blog if Agile development had changed the skills employers hiring testers are asking for. She did some investigation, and found that among employers running want ads for testers, a certain percentage were asking for coding skills. She speculated that this meant that in the future testing will look like this set of skills employers are asking for now.

Chris McMahon took this a different direction in his blog, but then again, he doesn't talk about what it means or does not mean when some employers who post ads ask for certain things. Furthermore, he goes on to talk about "New Frontiers". Agile is the mainstream way to develop and test now. It isn't a bleeding edge anymore. It IS the mainstream. Doing automation isn't new. Asking for programmers isn't new. Microsoft laid off everyone who wasn't years and years ago. Has it already been 5 years? Yes I believe we are coming up on it. Testing the emotional response of Badgers with various mobile ringtones to determine human response would be new and possible blazing quite a frontier of testing. Not sure if Chris would listen to me speak on it, but it would be new. When I think of frontiers in software, I think of people with the guts to work for free. Open source. Startups. I don't think about trying a mainstream testing tool as being a huge risk. When all of the big players are already in the cloud, that isn't a frontier anymore. It's at least a freaking colony by now. I'm here with my covered wagon to tell the Young Guns that they're going to need to find a new wild West, as this West ain't so wild anymore.

Why am I the first person to ask what it means when jobs posted in want ads ask for something? How does it relate to the skills the testers who get hired actually have? What about the large number of jobs which are filled before they are ever posted publicly? What about the jobs that are so enjoyable the tester who has them stays in them, and for that reason the job wasn't open?

Here is a normal discussion in our household. Craig: Guess what this job posting wants from a QA? Me: They want a Masters in Computer Science, a bag of chips, and a pony? Craig: Nope. They would like a build engineer, a full developer, and an entire test department for the price of an intern!

Many a job ad is more of a wish list than official requirements.Candidates will claim all sorts of skills that they have very little applicable ability in, let alone talent and experience in a professional environment. When I think of the few instances I know of where hiring managers preferred seeing candidates coding on a white board over successful testing experience combined with brilliant creative ideas, I cringe. I don't think that the popularity of agile caused that either.

Just as there will always be a long list of unrealistic lonely older guys seeking a female companion aged 18-25 with long blonde hair, blue eyes, and 125lbs or less, so will there always be companies seeking the perfect blend of programming skills with testing skills. There will be those who insist the skills are the same. That still doesn't mean it is the norm, or it reflects most of reality.

I believe companies WANT to move towards more automation that works, but they are still failing far more often than they are succeeding. They want to be agile, just so long as they don't have to risk anything to get there. They want programming skills, but they still don't know what to do with them in many cases. I went to Better Software/Agile Development Practices just this Spring. I didn't notice much difference. There is still a HUGE range of skills and abilities in software testing. We have people who don't code at all, and people who do amazing things with code.

If I had to guess about the future of testing, I would guess it will be a huge range of things just like it is now. No number of badger testers or yak shaving specialists desired in want ads will change the variety of needs and thus the diversity of the skill set of the tester of the present. Since we can't even agree on what testing is now, I'll have to opt out of predicting the future.

Consultant Learnings-Simple Tools Kicking It Old School

Testy Redhead — Wed, 10 Nov 2010 01:59:00 GMT

You Want it When?

Doing test planning for my current project phase has been a challenge because we have so many things to complete in a short period of time. I was totally overwhelmed looking at the total number of things we had to test with two people. It seemed impossible for awhile even though I know it is possible to deliver helpful test data in ANY context being from the context driven school of testing. There is one simple thing that was a huge breakthrough and it is totally simple.

We have a testing schedule for the rest of the project. A what? Yes. A simple list of what happens when so I know if we are behind or not. This isn't for the project. It is just for us. Because if we do things to plan we WILL deliver great testing. A simple weekly schedule for us to follow is the simplest thing in the world. So why? As an agilist what in the living daylights am I thinking?

1. This isn't an agile project.
2. It isn't in my control.
3. This isn't one project. We have about 8 mini-projects to manage instead.
4. A test plan ain't gonna cover this situation unless it helps us DO the testing.

Break it Down
What buckets of testing do we need to complete? I don't mean test cases, I mean huge buckets/topics of testing. This is just the headlines.
What is due when?
What can we start?
What do we need first?
When do we have to start what we need first to be finished with that when we can start?

Line it Up
For us, lining up what to start each week helped. Could be different in other situations.

One Day, One Tester, One Deliverable, One Completion at a Time
No longer stressed. If (and this is a BIG if) we get what we need to start on time, I am CONFIDENT we will rock this project on the testing side. This is well within our capability. It can be 20% messy and we'll still pull it out. Haven't figured out how to express that risk in the plan other than show days slippage on dependencies. Examples are welcome.

STPCon Slides

Testy Redhead — Fri, 29 Oct 2010 14:50:00 GMT

Collaboration

9 tipstoencouragecollaborativetestingstp con

View more presentations from lanettecream.

Agile Testing Ninjas

Agile testingninjasst pcon

View more presentations from lanettecream.

Pairing with Developers

Pairing w developers_stpconpics

View more presentations from lanettecream.