Breaking in a New Meetup - Browserstack San Francisco (Live Blog)

Hello and welcome back to the TESTHEAD live blog. It's been a few weeks, primarily because I went into overdrive in late March and April around 30 Days of Testability and STP Con. Still, I was invited to come out to see Browserstack's first meetup in San Francisco. I was intrigued, specifically because we use Browserstack at my company (and then didn't but now do again, a post will be on that later).

We've kicked off the night listening to Browserstack CEO Ritesh Arora, who has been sharing the timeline of the growth and evolution of Browserstack. Again, I'm not necessarily here to talk about Browserstack as a product (I certainly can in future posts if interested) but I do appreciate the fact that they have developed one of the most responsive device farms anywhere. The mobile offering they have is pretty extensive but most important it is quick as far as spinning up multiple devices in the cloud goes. Their overall vision is that they want to develop the de-facto testing infrastructure of the Internet. That's a pretty sweet goal if I do say so myself. As a remote engineer, the challenges of gathering enough devices together to do meaningful testing is large. Using a tool like Browserstack, that helps me extend out and test a variety of products I don't actually have.

Dang it, I said I wasn't going to make this all about Browserstack. Oh well. For those curious, yeah, it's a tool I enjoy using. It's not perfect but it definitely made clear how much I liked it when I had to do without it for several months because of a change in focus and perspectives shifted us to different products. Suffice it to say, we are back and I'm happy about that.

OK, enough marketing spiel. Lanette Creamer flew down from Seattle to talk at this event, which, hey, that's pretty cool. Lanette and I have traded war stories for a few years now (the better part of a decade, really, but who's counting ;) ). Lanette is here to talk about "Small Projects" and how they can actually be more difficult than larger projects. The common challenge is that smaller projects will go faster, or at least that is the belief. However, there are times where smaller projects don't really end up being faster. In many cases, there are challenges that will cause users to not be able to really do what they hope to do. That small project can blow up very quickly and become a much bigger challenge than was expected.

When people talk about projects that are small, what they are actually aiming for is "something simple that we can do quickly". However, the problem often arises that scope rises in the allotted time frame. Thus, the trick is to make sure that the systems are in place to be able to keep everything in place. Small projects are risky projects, so it's vital that we trust our team members. We also have to realize that there is no way we will be able to do everything we would like to do. Perhaps swap real-time paring with your developers over having to write bug reports and waiting for a response. Get away from the time killers and project killers; avoid politics, get away from micromanaging and try to not be so beholden to perpetual status updates. Be aware that there is a freedom that can be had with the right attitude. You may not be able to do everything but it's better than doing nothing. Start there :).

---

The next talk was presented by Priyanka Halder. She currently heads the Quality Engineering team in GoodRx. Priyanka's talk is "Taming the dragon: Going from no QA to a fully integrated QA". I can relate to this from a variety of situations in my testing career, where I've either had no QA or we have had to retool the testing that was done previously. I've struggled in a few of these environments and have at times had to make new initiatives just to make headway. Some times I've had lots of automation but it had limited focus or it worked for part of the product and other areas needed coverage but it didn't exist yet. Very often, we had experiences where what worked in one part of the product didn't work in another area. As for the premise of Priyanka's talk, I also know what it feels like to be the first tester in a team that didn't have one previously. That's a special challenge but a real one and it requires a certain kind of finesse. It's not just that we have to test, we also have to make a case as to why we are worthwhile to have on the team.

Very often, the problem that we have to deal with up-front is the issue of testability. If we are coming into a new QA environment with a lot of manual testing, if the goal is to automate (and even if it isn't) placing an emphasis on testability early can reap large dividends.

---

The last talk for the night is being delivered by Brian Lucas of Optimizely. He is responsible for Build, Test, and Release engineering processes. His talk is about "Avoiding Continuous Disintegration at Optimizely". One of the keys to being successful in developing software are certain common traits: speed, engagement, and iterative development can help keep quality high. However, as the product becomes more complex, if the time and effort are not put in to be able to keep that process rolling, things can fall apart quickly. One of the approaches Brian suggests is the idea of releasing faster and shipping quicker comes down to working in smaller increments, shipping more frequently and working through experiments. Components usually work well in isolation but they struggle when they have to work with each other.  If your team is playing Dev and QA ping pong, stop it! BY working more openly with QA and doing testing earlier, it is possible to get more coverage even in smaller increments of time. In short, your testers are not going to be able to do all of it and groups that don't prioritize for this will lose that opportunity.

Optimizely crowdsources their QA to their entire engineering team so that all of the testing efforts don't just fall on the heads of the testers. More to the point, rather than to have one person testing a hundred commits, having the developers test their own commits speeds up the process and lessens the load on the testers so that they can focus on more pressing areas.

Continuous Integration, Continuous Delivery, and Continuous Deployment are areas that will take time and care to set up but by taking the time to do it it makes it easier down the line. Ultimately the goal is to improve the feedback cycles and build out the infrastructure in a way that allows for repeatability, testability, and implement-ability in many places.

---

On the whole, a nice first outing Browserstack. Thanks for having us. Also, thanks for the shirt and water bottle. I should get a few laughs at tomorrow's standup when I wear it (hey wait, isn't that... yes, yes, it is ;) ).

What's That Smell? Angie Jones Talks at #BAST (LiveBlog)

Tonight is proving to be an exciting evening for the Bay Area Software Testers Meetup.

Angie Jones has come out to talk to us about "Code Smells", where we have code that "works", but may have some unusual issues that don't necessarily jump out at us.

More than just talk about the issue, Angie is actually walking us through and showing a real project that has some definite issues. The first example she uses is classes that are too long, where there is a lot of stuff put into a single class and it doesn't have a specific purpose. Oftentimes classes grow over time because there's no other logical place to put something. Think of writing a test where you put a lot of browser interaction into a class so that it's readily available. One one hand, it makes sense, but on the other hand, if it is overloaded or the items added to a class can be grouped somewhere else, take the time to put it there.

Another common smell is "Duplicate Code", where if you have an issue where something is repeated in multiple places, you end up having to do what Angie calls "Shotgun Surgery" (I just love that term :) ). Anything being duplicated more than twice is probably a really good indication that a separate class with that information probably makes a lot of sense.

Next up is the 'Flaky Locator Strategy". Oh, do I know this one! Angie is exhorting, loudly, to not trust the Copy XPath option that comes with Dev Tools, and I wholeheartedly agree. This is also something I wrote about in my "Less Brittle Automation" posts, part one and part two. Happy to see that something I found frustrating is also something Angie pointed out :).

Angie calls out the "Indecent Exposure" smell. If you are showing too much of your data, you may allow for people to get to your data and information in ways you may not want to. This is fixed by narrowing the scope of your classes, making certain methods private when they should be and only keeping public methods that actually need to be public that distinction.

Something that I'm all too familiar with is the issue of explicit waits. Yes, I do this. No, I'm not proud of this. Yes, I can do better. Angie encourages us to Wait Intelligently, by either polling for an element or to make sure that the test doesn't move forward until there's a confirmation that an item is present.

Frameworks are supposed to drive the logic of the browser and to create a state condition. Frameworks don't actually test anything, so putting assertion codes into the framework is a problem. Instead, we want to create state conditions that e can evaluate elsewhere. Otherwise, we may find ourselves painted in a corner unintentionally.

This was a really great discussion, and it was made the more effective by seeing the actual code being modified. I'm super happy to have had Angie come out to speak with us at BAST tonight and she has an open invitation to come out and talk any time she wants to :). For everyone else, thanks for indulging me this evening as I got to geek out a bit. 'Til next time!

Does the Agile Testing Process Work? - A #BAST Lean Beer Summary (1/5)

On Thursday, December 10, 2015, the Bay Area Software Testers Meetup Group got together and held its quarterly Lean Beer event. Lean Beer is the "evening equivalent" of Lean Coffee, where individuals come together and discuss topics of interest in a loose format. Topics are proposed, the participants vote on the topic that most interest them, and the topics are ranked based on the votes they receive.

Each topic gets a set time to be discussed and at the end of the time, a vote is made to see if the discussion should be continued. if majority votes to continue, more time is added to the clock and the discussion continues. If the votes indicate energy has been depleted for that topic, we close it off and move on to the next one.

We covered five topics at our most recent event, and based on the feedback, and as a point of reference for the members of the BAST Meetup that couldn't attend, these are summaries of what was discussed.

The top vote recipient, and therefore the first topic we discussed, was the "Agile Testing Process", or more to the point, "is there such a thing"? For several of the attendees, it seemed that the Agile Development process worked, but that testing was still treated as an after the fact activity. Isn't the point of Agile software development supposed to be that information about the product is discovered quickly, feedback received, and the ability to deliver software faster is primarily to make better quality software available?

Included in these questions is also the changes that many have witnessed at their respective companies as to not just how software development has changed, but how software testing at those companies has changed as well. For some companies, there is not a dedicated test team any longer, at least not one with a separate reporting structure. The idea of a separate test team and test manager has given way to having an integrated team of programmers and testers working together as much as possible, or to having test be an activity rather than a separate role.

Regardless of the team structure, testing is meant to happen, but how that testing is performed or who does it is open to debate. For those of us who work as testers in our given organizations, our efforts are often spread among various initiatives. Some of us focus most of our efforts on exploration, some of us are primarily working on automation. Some of us have the ability to get into the story writing process early, via the Three Amigos approach, and can apply our testing efforts early on during the requirements stage. Here, we are able to provoke requirements and provide thoughtful analysis and add value by helping see what aspects we need to consider up front before development even starts.

One of the comments that most of us agreed with is that having a dedicated (as in, involved) product owner made a considerable difference. Unit tests and Test Driven Development can be a big help towards designing a product that meets the requirements set forth by the stories. Having a system in place that allows for the software to be built and deployed in a timely manner can be a tremendous help to the process. Automation is important here, but more so to eliminating busywork and pushing things around than actually providing core testing. There is still a need for meaningful testing and applying testing skills to these stories, and part of that involvement is having the discipline to focus on just those stories that can be done in a particular sprint.

Local Stuff in Testheadland (for SF Bay Area Software Testers)

As I have come back from CAST, and I have taken some time to settle back into daily life and breathe a little easier, it strikes me that there's some stuff happening in my local reality that I'd like to encourage others to get involved with.

If you are outside of the San Francisco Bay Area, this may not be all that interesting to you. If you call the Bay Area home, and specifically, if the cities of Palo Alto or San Francisco are easy for you to get to, then these two items may be of interest to you :).

Socialtext is looking for a Senior Quality Engineer

Socialtext was acquired a few years ago and folded into another company called PeopleFluent. While we do have a site and a brand that is advertised as Socialtext, all of our hiring is being done through PeopleFluent. After being alerted to the fact that that was causing some confusion, I figured a quick explanation would help matters.

If you go to the Socialtext web site and look at the Senior Quality Engineer position, and then click on "Apply Now", you will be directed to a job listing with PeopleClick. That is by design and exactly what you should see. Also, while I cannot guarantee it will fast track you in the system, you have the option of including a note that says you are an employee referral. If you'd like to contact me directly and have any questions, I'll be happy to answer them as best I can. After that, if you add that you are an employee referral, and say that Michael Larsen referred you, we'll both be telling the truth ;).


BAST is going to be holding a Quarterly Lean Beer

I'm taking this from the BAST Meetup page, but since I feel it gets the point across, I'm going to add it mostly verbatim:

Bay Area Software Testers was originally created with 1 rule: it won't always be Curtis, Michael, or Josh speaking. Unfortunately, for the most part we've violated that rule. It's time for that to change.

Join us for the first of our quarterly "Lean Beer" BAST events. What is Lean Beer you ask? Well, it's identical to Lean Coffee, but we used beer (or water) and it happens in the evening instead of the mornings! 

Okay, smart ass answer aside, here is an excerpt from the leancoffee.org website:

"Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated."

The basic idea is we talk about what the majority of the people present want to talk about. There is no central speaker and no central topic. Come prepared to talk about what matters to you!

We are also planning on using these events to help get an idea of what people are interested in, and trying to find experts to come and speak on those topics. So come, discuss, and have fun.

My goal coming back from CAST was to get more involved in the things happening locally, and emphasizing my commitment to software testing in the Bay Area. Consider this a first step towards that :).

BAST in the Saddle Again: New Talk for January, 2015

As many of you saw last month, we had some dramatic happenings in the Bay Area Software Testers Meetup group. We want to usher in 2015 with a bang, and to that end, I am please to say I will be giving a talk on Thursday, January 8, 2015 and I want you all to come.

Now, granted, this is probably going to work best for people who will happen to be in the San Francisco Bay Area on Thursday, January 8, 2015, but hey, why be exclusive ;). Seriously, though, if you can make it, here's the details about the event and what we will be covering:


All for Web, and Web for All: Designing and Testing for Accessibility - Michael Larsen

As the web, mobile, and other devices we have yet to fully comprehend proliferate around us, we want to do our best to cater to the customers that best represent the users of our products. However, there is a population that is frequently left with little to work with, and that is those who have to deal with physical disabilities. Issues with sight, sound, motor movements, comprehension and other disabilities puts many sites and apps out of reach for those who would most like to use them.

Making products that are accessible is more than just implementing a few tags so a screen reader can spell out the terms, it involves designing a product from the top down to be navigated easily and seamlessly.

In this talk, I will present some challenges those with disabilities face, ways that we can design products to better work for those with various physical disabilities, and that testing for accessibility can be a fun, interesting and important part of your organizations product offerings.

To RSVP, please see the formal invitation and event details HERE.

Don't Know What You've Got Until Someone Tries to Take It

The past three days have been, shall we say, emotional, frustrating,  and wonderful, all at the same time. Most of all it has shown me that a group of vocal people can make a difference, but more on that in a bit.

First, some perspective. Last year, Curtis Stuehrenberg and I, along with Josh Meier, decided it was high time there was a software testing Meetup group in San Francisco. May not sound all that revolutionary, and wait, weren't their plenty of software testing groups already? Well, yes, if your main focus was on a specific tool. The Selenium Meetup group has been a de-facto testing group for years, and it's where a lot of software testers go to participate and share in testing topics from time to time, but what we noticed was missing was a focus on the "ilities" of software testing, as well as the areas that go beyond the programming aspects of software (or "paradev" aspects, to borrow from Alister Scott). Thus, we decided to inaugurate the Bay Area Software Testers group, or BAST, as we colloquially refer to it, with the following goals in mind:

The Bay Area Software Test Association originally formed as an impromptu attempt to provide software testers and quality engineers from San Francisco and the East Bay a place to meet and network without having to brave the Silicon Valley traffic snarl. Currently we meet on a monthly basis, providing a chance to hear people talk about general topics and socialize/network/schmooze some of the more interesting people on any software development team .... the testers!

We enjoyed several months of great talks, great conversations, and great activities, and then the summer and fall time frame saw less activity, due to scheduling challenges all of us were dealing with, and just a general challenge to get everyone on the same page. Sometime in this time frame, my Meetup account had been hacked, and I stopped receiving updates. Sad thing is, so much else was going on that I didn't get a feeling for what was happening until just a few days ago. A post to Twitter, though, definitely got my attention:

My first reaction was confusion, then bewilderment, then anger. How could someone hijack our group? Well, we discovered how quickly enough. In the interim as we were looking to transition out of the previous payment and registration (which Curtis had held) and to our new payment model (which Josh and SalesForce had offered to help us with) a member of the group jumped in and made the payment for the next year. In the process, they set themselves up as the organizer, effectively blocking us from being able to administer our own group. What followed was a conversation between Curtis, the person who shall remain nameless, and the folks at Meetup. We were, of course, frustrated that this new entity took over the group from us. We were doubly frustrated when they wouldn't give it back, and we were triply frustrated, and then enraged, when the group started to get spammed with commercial training dates posing as Meetup events. 

To add to the frustration, Meetup gave us the standard policy line of "sorry, it's not up to us, you need to work this out with the new organizer, as they have paid for the group". It was at this point that Curtis, Josh and I, as well as many other people, went on the offensive and started to look for other options. Would we abandon BAST? Make a new group? Drop Meetup altogether and go to another service (Eventbrite perhaps?). Several people took to the interwebs and started calling out the individual who had hijacked the group, and Eventbrite responded to us publicly and said that, if Meetup couldn't help us, they'd be happy to help us establish a new home.

This story, I am happy to say, has a happy ending. Due to the pressure and the vocal comments from several members of our broader community (many of which aren't even in San Francisco), Eventbrite willing to help us make a new home, and our own members posting to the BAST forum that they would not stand for their group being hijacked, and would therefore leave (myself being one who posted a similar comment), Meetup came back to us, allowed us to reinstate Curtis, Josh and myself as organizers, and we were able to deal with the person who hijacked the group and ban them from further participation.

Several lessons came out of this experience, but none more poignant than the fact that we realized we had a great thing, and that it could be take away from us far easier than we ever imagined. Second to that was the fact that we have a great community that cares about what we have created and were wiling to fight on our behalf, not just to say how sorry they were that this was happening, but actually step in and help us resolve it. Third is that people vote with their feet, and if you abuse their trust, you can lose their support very quickly. Fourth, it showed me that we can't take this group for granted. It needs to be cared for and it needs to be nurtured. To that end, for those who left BAST because of this recent mutiny, and for those who were unhappy with the change of events and chose to abandon ship, we want to let you know that everything is back to normal (perhaps even better than normal) and that Josh, Curtis and I are looking forward to making 2015 an active and involved year of discussion and get togethers. Perhaps we let time and momentum take over, but this recent upheaval showed us all how much this group mattered to us, and we are not going to let such a thing happen again. If you left us, please come back. If you want to help us develop events for 2015, we'd love to hear from you. Most of all, we look forward to getting together to socialize/network/schmooze with some of the more interesting people on any software development team .... the testers ;)!

From Mid-Town Manhattan, it's #TestRetreatNYC

In the offices of LiquidNet, a group of intrepid, ambitious testers met and decided to discuss what aspects of testing mattered to us. Test Retreat is an Open Space conference, where the sessions begin when the participants want to have it begin (and end), the people who are there are the people who need to be there, and the law of two feet rules. We took some time to discuss topics, pull together similar topics and threads, and then head into our places to talk about the stuff that is burning us up inside.

---

The first session I attended was based around developing a testing community within a city or region. As many of us were part of different communities around the world, there were a variety of experiences, ranging from very small markets with perhaps a hundred testers total, to large regions with hundreds of thousands of testers, but little in the way of community engagement. 

Rich Robinson led the discussion and shared his own experiences with growing and scaling the community in Sydney, Australia. Rich shared that there were three areas that were consistently asked for and looked at as the goals of the attendees: looking for work, finding out the latest trends, and honing and sharpening skills. Rather than try to be all things to all people, they developed a committee and separate initiatives, with committee members focusing on the initiatives that mattered to them. For the group that wanted to get work, they made an initiative called “opportunity seekers”, and focused energy on those who had that as their biggest objective. For those who want to focus on latest trends, they have an avenue for that as well. 

Different regions have unique challenges. In the Bay Area, we have an overabundance of meetups for technical topics, of which a handful of them relate to software testing. As a founder of Bay Area Software Testers (BAST), Curtis Stuehrenberger, Josh Meier and I have chosen to try to focus on areas that are not as often discussed (we tend to steer clear of automation tools and techniques, since there are dozens of other meetup groups that cover those topics). Another challenge is frequency. In some cases, regular and frequent meetings are key. In others, having them less frequently works, but the key is that they meet regularly (monthly, every six weeks, or quarterly seem to be the most common models).

Rich also shared that their initiatives branch away from the formal meetup sessions, and have other opportunities that they initiate that occur outside of the formal meetup times. By having each initiative have people committed to it and resources to help drive those initiatives, buzz gets generated and more people get involved. One of the key things that Rich emphasized was getting people involved and engaged for these initiatives. The Sydney tester group has a committee of ten members that helps make sure that these initiatives are staffed and supported.

Another challenge is the local regions. Some cities have sprawl, others are difficult to get to in a timely manner due to traffic and population density. For example, the San Francisco Bay Area has four general regions: San Francisco (and the upper San Francisco Peninsula, Silicon Valley (and the lower San Francisco Peninsula), the East Bay, and the North Bay. With a few exceptions, people who participate in one generally do not regularly participate in the others. To reach out to a broader community in these sub-regions, it may require using technology and remote-access options for people to participate. 

Ultimately, growing a community takes time, it takes dedicated people, it takes a range of topics that matter to the attendees (including making sure that food and drink is there ;) ). To get those people you want to be involved, it helps to be very specific about what is needed. Saying “I need help with this” is less effective than saying “I need this specific thing to be done at this time for this purpose”. Specificity helps a lot when recruiting helpers.

—

The next session was “Sleep No More”, presented by Claire Moss, and focused on the model of the performance/play called Sleep No More (which is, in some ways, described as “an immersive performance of Macbeth”). It’s a darkened environment, all participants wear masks, no photography, no talking, just experience as the person sees it. Exploratory Testing, in many ways, has similarities to this particular experience. Claire used a number of cards to help display the ideas, and one of the first ideas she shared was “fortune favors the bold”. Curiosity and a willingness to go in without fear and deal with a substantial amount of “vague” is a huge plus. If you already have that, you have a strong advantage. If this is not natural for you, it can be developed.

Each room in the Sleep No More experience was part of the performance, and at any time, rooms could be empty or have people filter in during the performance. There are “minders” in the event that help to make sure that people don’t completely lose track of where they are. At times, there are very personal experiences that take place based on your tracks and where you go. Claire described a very intense experience of the performance based on where she went and what she observed and chose to follow up on. She also said that, up to this point, no one that she knew had anything like the experience she had.

The experience of Sleep No More was bizarre, creepy, full of strange triggers, and the potential to go into wildly unexpected direction. Software testing in many ways mirrors this experience. While there may be familiar areas and ideas, very often, our choices and angles may take us into very unexpected places. To give an example of the scope of the space, this was in a six story building, in an area that used to be a hotel (and whole areas of the building were gutted, in some spaces multiple floors were open to the air and visible). 

Claire described a feeling of “amazement fatigue”, where the level of stimulus is so high that there is no way to take it all in. The participants have to make conscious choices as to where they will go, and many of the participants will have wildly different experiences. Sometimes, they would follow a character, only to watch them go through a door and close and lock it, so that they couldn’t be followed any longer. This reminds me of following threads of a feature, and being brought to a dead end. People will observe different things, and they will also observe what other people do, and what they focus on. This can give us clues as to areas we want to explore next. 

This experience sounds amazing, and I am definitely interested in going and doing it myself, if time and commitments permit me to do so. Looks like I will be attending the August 10 performance :).

—

The next session was based on “Leadership”, and Natalie Bennett led the session with the idea that she wanted to see where individuals felt their experiences or needs for leadership were, as opposed to her telling us what she felt about Leadership and how to do it. Questions that Natalie wanted to discuss were:

- What is the purpose of a test team lead?
- What is it for?
What makes it different than being a test manager?

The discussion shifted from there into ways that test team leads and test managers were similar and where they differed. Some of the participants talked about how they led by example, and that they divvied up the work among the group based on the people involved and what they were expected to do. Team leads in general do not have hiring/firing authority, and they typically do not write reviews or have salary decision input. In other environments, the team manager and team lead are one in the same. There are some who are cynical about the effectiveness of this arrangement, while some feel that it is possible to be both a team lead and a team manager.   One attendee who is a Director of Q.A. for her company said that she was “the face of Q.A.” to the organization, and as such, she was setting the direction and expectations for the organization, as well as for her own direct reports.

Team leads are expected to teach and coach the members of their group, as well as be the point of contact for the group. It’s seen as important that they be able to focus on and develop their own role and make it responsive to their own environment. The team lead stands up for the group, and defends them from encroachment of issues and initiatives that are counter-productive to their success. Responsibility and authority tends to be on a sliding scale. Different companies allow for a different level of authority for the leads. Some give a level of authority that is just short of being an actual manager. In others, the leads is considered a “first contact” among equals.

One of the bigger challenges is to deal effectively when team members are failing. Failing in and of itself is not bad. It’s important to learn, and failing is how you learn, but when the failing is chronic or insurmountable, there needs to be a different level of interaction. Lean Coffee, direct mentoring, or even a serious re-consideration of experiences and goals can be hugely beneficial, both for the individual and the team as a whole.

—

Matt Heusser led a session about “Teaching Testing”, and some of the challenges that we face when we teach software testing to others. When we have an engaged and focused person, this usually isn’t a problem. When the person in question isn’t engaged, or is just going through the motions, then it’s a little more difficult.  The question we focused on at first was “what methods of teaching have worked for you?” Testing is a tactile experience, rather than looking at an abstract questions. We are familiar with questions like “how do you test a stapler?” or “how can you test a Rubik’s Cube?”. The presentation of this challenge may be the most important aspect. For some, they might look at “how do you test a stapler?” as demeaning. They are professionals, what is this going to teach me?

In my experience, one of the things I found to be helpful is to actually spell out how challenging the exercise could be. Rather than ask “How do you test a stapler?”, I might instead say “Tell me the 120 ways that you can test a stapler to confirm it’s fit for use?” This sets a very different expectation. Instead of saying “oh, this is trivial”, by seeding a high number, they may want to try to see how they might be able to meet or exceed that number. They become engaged.

To borrow a bit from Seth Godin, there are two primary goals for everyone. It’s the important aspects that we need to learn, regardless of the discipline. The first is to focus on authentic problems. The second is to be able to lead. Domain knowledge is a huge factor in helping to identify authentic problems. It’s not the only means, but getting to really know the domain can help inform the testing ability. Another important aspect is to understand how people learn, Everyone goes about learning a bit differently. Helping each person learn how they learn can be a huge step in helping to teach them. Sometimes the most ripe area of learning is to wade into an area where people disagree, or where there might be a number of people or groups where there might be dysfunction, where team members don’t talk to each other, or there’s simmering hostility between people. If there’s hostility between two programmers, and they write software that interacts with each other, it’s a good bet that there might be a goldmine of issues between their interaction points (I think this is a very interesting idea, btw :) ) .

Key to teaching testing is the ability to reflect and confirm what has been taught and learned, and for me, I think that Weekend Testing does this very well. The benefit of Weekend Testing, beyond just doing the exercise, is that we can see lightbulbs turning on, and there’s a record of it that others can see and learn from. Creating HowTo’s can also be a helpful mechanism for this. 

—

This section is the talk that Smita Mishra and I gave about “Hiring Testers and Keeping them Engaged Once We’ve Hired Them”. I recorded this session, and I will transcribe it later ;).

—

Claire Moss led a session on “Communicating to Management” and we went through and considered a list of questions that are important to frame the conversation(s):

What does quality like to our organization?

Why spend money on testing?

What does testing do?

What value are we getting out of testing?

I read this about QA, and it says we should do this… why aren’t we doing this?” 

These are all questions that we need to be prepared to answer. The question is, how do we do that?

There are several methods we can use, but first and foremost, we need to determine what we need to speak with management about, and if possible, use the opportunities to help educate them about what it is we can do, and at the same time, get a clear understanding about what their view of the world is.

Looking to standards and practices that are helpful can give us guidance, but it doesn’t always represent our reality. Information needs to be specific to explaining where we stand at the given time. Testing is primarily focused on giving quality information to the executives so that they can make qualified decisions. That is first and foremost our mission. Information that we can effectively provide is: 

- Framing of the ecosystem on a global scale (browser standards, trends, data usage histories)

- Impact on customers (client feedback, analytics data)

- Clarify issues and questions (heading off the executive freakout)

- Managing expectations (especially when dealing with something new)

- Explaining how likely issues brought to their attention really are problems worth investing in

- Explaining risk factors and methods to mitigate those risks

—-

At the end of the day we had a lot of new idea, feedback for some new initiatives, an emphasis on better communication, more focused due diligence, and the fact that so many participants had a lot they felt they could contribute. This was a fun and active day, and a lot of learning and connecting. One of the key things I am always impressed about when it comes to these events is that we really have a lot of solid people in the testing community, but we need even more.

I encourage every tester that admires craftsmanship, skill, and thinking make it a point to come to these now annual events (this is the third of these, so I think it’s safe to say that it’s a thing now ;) ). Once again, thanks Matt (Heusser) and Matt (Barcomb) for organizing what has becoming my favorite Open Space event. May there be many more.

Listening to a Cowboy: Live at Climate Corp, It's BAST!!!

Hello everyone, and sorry for the delay in posting. There's a lot of reasons for that, and really, I'll explain in a lengthy (or small series) of posts exactly why that has been the case. However, tonight, I am emerging from my self imposed exile to come out and give support for Curtis Stuehrenberg and hist tall about "ACCellerating Your Test Planning".

From the BAST meetup post:

"One of the most pervasive questions we're asked by people testing within an agile environment is how to perform test planning when you've only got two weeks for a sprint - and you're usually asked to start before specifications and other work is solidified. This evening we plan on exploring one of the most effective tools your speaker has used to get a test team started working at the beginning of a sprint and perhaps even earlier. We'll be conducting a working session using the ACC method first proposed by James Whittaker and developed over actual practice in mobile, web, and "big data" application development."

For those not familiar with Curtis (and if you aren't, well, where have you been ;)? ):

Curtis is currently leading mobile application testing at the Climate Corporation located in San Francisco, Seattle, and Kansas City. When not trying to help famers and growers deal with weather and changing climate conditions he devotes what little free time he can muster to using his 15 years of practical experience to promote agile software testing and contextual quality assurance at conferences like SFAgile, STPCon, ALM-Forum, and CAST as well as publications like Tea Time for Testers and Better Software magazine.

This is an extension of Curtis' talk from the ALM Forum in April. One of the core ideas is to ask "can you write your test plan in ten minutes? If not, why not?"

Curtis displayed some examples of his own product (including downloading the Climate Corp mobile app by each of us), and brought us into an example testing scenario and requirements gathering session. Again, rather than trying to make an exhaustive document, we had to be very quick and nimble in regards to what we could cover and in how much time we had to cover it. In this case, we had the talk duration to define the areas of the product, the components that were relevant, and the attributes that mattered to our testing.

Session Based Test Management fits really well in this environment, and helps to really focus attention for a given session. By using a very focused mission, and a small time box (30 minutes or so), each test session allows the tester the ability to look at the attributes and components that make sense in that specific session. By writing down and reporting what they see, they are able to document their test cases as they are being run, and in addition, show a variety of areas where they may have totally new testing ideas based on the testing session they just went through, and these in turn inform other testing sessions. In some ways, this method of exploring and reporting simultaneously allows for a development of a matrix that is more dense and more complete than one that may be generated first before actively testing.

the dynamic this time around was more personal and more focused. Since it was not a formal conference presentation, the questions were more common, and we were able to address questions immediately rather than waiting until the talk was finished. Jon Bah's idea of threads was presented and described, and how it can help capture interesting data, but help us consciously stay "on task", yet capture interesting areas to explore later (OK, I piped in on that, but hey, it deserved to be said :) ).

It's been a few months since we were able to get everyone together, and my thanks to Curtis for taking the lead and getting us together this month. we are looking forward to next month's Meetup, and as soon as we know what it is (and who is presenting it ;) ).

Django 1.7 and… ME (yet another Live Blog)

So this might seem an odd spot, but this has become something of a mission on my part for 2014. I’ve decided that I want to try to become multi-lingual when it comes to web frameworks. We have all sots of interesting frameworks to play with to make web apps and web sites,and Django is the Python centric web framework, and therefore one I want to know more about and get more experience with. Seems a great reason to come into San Francisco and see what the Pythonistas are doing and how they are doing it with Django.

Yes, this is going to be live blogged, and as usual, it may be messy at first. Forgive the stream of consciousness, I promise I’ll clean it up later :).


A bit about our topic this evening (courtesy of Meetup):

Django 1.7 is one of the biggest releases in recent years for Django; several major new features, innumerable smaller improvements, and some big changes to parts of Django that have lain unchanged since before version 1.0. Come and learn about new app loading, system checks, customized select_related, custom lookups, and, of course, migrations. We'll cover both the advantages these new features bring as well as the issues you might have when upgrading from 1.6 or below.


A bit about our presenter this evening (also from Meetup):

Andrew Godwin is a Django core developer, the author of South and the new django.db.migrations framework, and currently works for Eventbrite as a Senior Software Engineer, working on system architecture. He's been using Django since 2007, and has worked on far too many Django websites at this point. In his spare time, he also enjoys flying planes, archery, and cheese.


Lightning Talks 

#1 Randall Degges - Django & Bcrypt

Randall kicked things off right away with a talk about how Django does password hashing and securing of passwords, with the estimated cost o what it takes to crack a password (hint, it's not that hard). If you want to be more security alert, Randall is recommending that we consider using BCrypt. It's been around awhile, and it allows for transparent password upgrading (users update their hash the first time they log in. No muss no fuss :). Sounds kinda cool, to tell the truth, I'm looking forward to playing with it for a bit.

#2 Venkata - Django Rest Framework w/ in-line resource expanding

The second talk discussed a bit on the Django REST framework. Some of the cool methods to handle drop down, pop open and other events were very quickly covered, and some quick details as to what each item can do. A quick discussion with fast flashes of code. I caught some of the details, but I'll be the first to admit, a lot of this flew right past me (gives me a better idea as to areas I need to get a little more familiar with). Granted, this is a lightning talk, so that should be expected, but hey, I pride myself on being able to keep up ;).

#3 Django Meetup Recap

The third lightning talk basically covered a recap of what the Django group has been covering and some quick recaps of what has been discussed in the previous meetups (Ansible, Office Entrance Theme Music, Integrating Django & NoSQL, etc.). Takeaway, if we want resources after the meetups are over, we have a place to go (and I thank you for that :) ).

---

Andrew Godwin's Talk

This seems like a great time to say that I'm relatively new to Django, so a lot of what's being discussed is kind of exciting because it makes me fgeel like I'll be able to get into what's being offered without having to worry about unlearning a lot of things to feel comfortable with the new details. Part of the new code is an update to South (which, as is mentioned above, is something Andrew is intimately involved in).

Details as to how apps are loaded and how to check for and warn programmers about what may happen with an upgrade. Having suffered through a few updates where things worked, then didn't and not having any clue as to why, this is very appealing.

Another new aspect is an adjustable and tunable prefetch option, so that instead of all or nothing, there's a spectrum of choices that can be looked up and help based on context.

A rather ominous slide has flashed across saying "Important Upgrade Notes", and a new detail is that all field classes need to have a deconstruct() option. It's now a required method for all fields. Additionally, initial_data is dead. It's important to have modules use data migration instead. In short, don't automatically assume that older modules that use initial_data will cleanly work. I will take Andrew's word on that ;).

So what's coming up in Django 1.8? Definitely improvements in interactions with PostGreSQL, as well as migrations for contributing apps. But that's getting a bit ahead of the race at the moment. Expect Django 1.7 to hit the scene around May 15th, give or take a few days. Again, I will take Andrew's word on that ;).

---

There's no question, I feel a little bit like a fish out of water, and frankly, that's great! This reminds me well that there is so much I need to learn, especially if my goal of becoming a technical tester is going to advance farther than just wishful thinking or following pre-written recipes. It's not enough to just "know a framework" or "know my framework".

As was aptly demonstrated to me a year and a half ago, I spent a lot of time in the Rails stack, and then I went to work with a company that didn't user Rails at all. Did that mean all that time and learning was wasted? Of course not. It did give me a way to look at how frameworks are constructed and how they interact. I'm thinking of it like learning Spanish when I was younger. Don't get me wrong, I'm not great shakes when it comes to Spanish, but I understand a fair amount, and can follow along in many conversations. What's really cool is that that gives me an add on benefit that I can follow a little bit in both French and Italian as well, since they are closely related. that's how I feel about learning a variety of web frameworks. The more of them I learn, the easier it will be to move between them, and to understand the challenge that they all face.

In any event, this was an interesting and whirlwind tour of some new stuff happening in Django, and I plan to come back and learn more, with an eye to understanding more next time than I did today. Frankly, that shouldn't be too hard to accomplish ;).


Thanks for hanging out with me. Have a good rest of the evening, wherever you are.

Selenium SF Live: An Evening With Dave Haeffner

It’s been about three years since I first met Dave. He was, at the time I met him, working with the Motley Fool, and was one of the people I connected with and recorded some fun (albeit rather noisy) audio for what I had hoped would be a podcast from the Selenium Conference in 2011. Alas, the audio wasn’t as usable as I had hoped for a releaseable podcast, but I remembered well the conversation, specifically Dave’s goal to see if he could, at some point, find a way to make Selenium less cryptic and more sturdy that what had been presented before.

Three years later, Dave stands as the author of “The Selenium Guidebook” and tonight a couple of different Meet-up groups (San Francisco Selenium Users Group and the San Francisco Automated Testers)  are sharing the opportunity to bring Dave in to speak. I’ve been a subscriber to Dave’s Elemental Selenium newsletter for the past couple of years, and I’ve enjoyed seeing how he can break down the issues and discuss them in a way that is not too overbearingly technical, and give the reader a new idea and approach they might not have considered before. I’m looking forward to seeing where Dave's head is at now on these topics.

Here's some details about Dave for those of you who are not familiar with him:

Dave Haeffner is is the author of Elemental Selenium (a free, once weekly Selenium tip newsletter that is read by hundreds of testing professionals) as well as a new book, The Selenium Guidebook. He is also the creator and maintainer of ChemistryKit (an open-source Selenium framework). He has helped numerous companies successfully implement automated acceptance testing; including The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of the Selenium Hangout and has spoken at numerous conferences and meetups about acceptance testing.

This will be a live blog of Dave’s talk, so as always, I ask your indulgence with what gets posted between the time I start this and the time I finish, and then allow me a little time to clean up and organize the thoughts after a little time and space. If you like your information raw and unfiltered, well, you’ll be in luck. If not, I suggest waiting until tomorrow ;).

---

The ultimate goal, according to Dave, is to try to make tests that are business valuable, and then do what you can to package those tests in an automated framework that allows you to package up these business valuable tests. This then frees the tester to look for more business valuable tests with their own eyes and senses. Rinse, lather, repeat.

The first and most important thing to focus on is to define a proper testing strategy, and after that's been defined, consider the programming language that it will be written in. It may or may not make sense to use the same language as the app, but who will own the tests? Who will own the framework? If it's the programmers, sure, use the same language. If the testers will own it, then it may make sense to pick a language the test team is comfortable with, even if it isn't the same as the programming team's choice.

Writing tests is important, but even more important is writing tests well. Atomic, autonomous tests are much better than long, meandering tests that cross states and boundaries (they have their uses, but generally, they are harder to maintain). Make your tests descriptive, and make your tests in small batches. If you're not using source control, start NOW!!!

Selenium fundamentals help with a number of things. One of the best is that it mimics user actions, and does so with just a few common actions. Using locators, it can find the items that it needs and confirm their presence, or determine what to do next based on their existence/non-existence. Class and ID are the most long term helpful locators. CSS and X-Path may be needed from time to time, but if it's more "rule" than exception, perhaps a chat with the programming team is in order ;). Dave also makes the case that, at least as of today, the CSS vs. XPath debate has effectively evened out. Which approach you used depends more on what the page is set up and laid out to be rather than one approach over the other.

Get in the habit of using tools like FirePath or FireFinder to help you visualize where your locators are, as well as to look at the ways you can interact with the locators on the page (click, clear, send_keys, etc.). Additionally, we'd want to create our tests in a manner that will perform the steps we care about, and just those steps, where possible. If we want to test a login script, rather than make a big monolithic test that looks at a bunch of login attempts, make atomic and unique tests for each potential test case. Make the test fail in one of its steps, as well as make sure it passes. Using a Page Object approach can help minimize the maintenance needed when pages are changed. Instead of having to change multiple tests, focus on taking the most critical pieces needed, and minimize where those items are repeated.

Page Object models allow the user to tie selenium commands to the page objects, but even there, there's a number of placed where Selenium can cause issues (going from Selenium RC and Selenium WebDriver made some fundamental changes in how they handled their interactions). By defining a "base page object" hierarchy, we allow for a layer of abstraction so that changes to the Selenium driver minimizes the need to change multiple page object files.

Explicit waits help time-bound problems with page loading or network latency. Defining a "wait for" option is more helpful, as well as efficient. Instead of hard coding a 10 second delay, the wait for allows a max length time limit, but moves on when the actual item needed appears.

If you want to build your own framework, remember the following to help make your framework less brittle and more robust:

• Central setup and teardown
• Central folder structure
• well defined config files
• Tagging (test packs, subsets of tests (wip, critical, component name, slow tests, story groupings)
• create a reporting mechanism (or borrow one that works for you, have it be human readable and summable, as well as "robot ready" so that it can be crunched and aggregated/analyzed)
• wrap it all up so that it can be plugged into a CI server.

Scaling our efforts should be a long term goal, and there are a variety of ways that we can do that. Cloud execution has become a very popular method. It's great for parallelization of tests and running large test runs in a short period of time if that is a primary goal. One definitely valuable recommendation: enforce random execution of tests. By doing do, we can weed out hidden dependencies. find errors early, and often :).

Another idea is "code promotion". Commit code, check to see if integration passes. If so, deploy to an automation server. If that works, deploy to where people can actually interact with the code. At each stage, if it breaks down, fix there and test again before allowing to move forward (Jenkins does this quite well, I might add ;) ). Additionally, have a "systems check" in place, so that we can minimize false positives (as well as near misses).

Great talk, glad to see you again, Dave. Well worth the trip. Look up Dave on Twitter at @TourDeDave and get into the loop for his newsletter, his book, and any of the other areas that Dave calls home. 

Fix You Estimating Bad Habits: An Evening with Ted M Young and #BAST

Tonight in San Francisco, BAST (Bay Area Software Testers) will be hosting our first Meetup for 2014. For those who will be there, I'll be excited to see you there. For those who aren't able to make it, please follow this post in the coming hours, as I will be live blogging what I hear and do.

BAST (Bay Area Software Testers) has made the commitment to try to bring in topics that go beyond or outside of the common or typical tester MeetUp topics. To that end, we are hosting Ted Young (Twitter: @jitterted) who will be talking about  how to "Fix Your Estimating Bad Habits".

For those planning on attending, here's the details:

Date: Wednesday, February 12, 2014
Time: 6:15 p.m. to 8:30 p.m.
Location: Salesforce.com
Address: 50 Fremont St, 28th Floor, San Francisco, CA (map)

From our Meetup site description:

Ted is a self-styled Renaissance Coder who has been coding since 1979 and sold his first commercial program at the age of 14.  Ted is currently the chief practitioner and evangelist of lean and systems thinking for GuideWire software.  He works nicely with our mission statement to present you with outstanding thinkers and practitioners from all across the spectrum of software development and business.

I hope you'll be able to join us at the facilities of our gracious host, SalesForce. Food (pizza) and beer will be provided! Also, we will be giving away two books by O'Reilly Media, who has graciously started supporting us and is giving us books that we can give away. Tonight's titles are "Vagrant: Up and Running" and "LEAN UX". Must be present to win :)!

For the rest, you're just going to have to wait until I get there.
---

Ted started off the talk tonight describing some of the environments where he has worked and some of the challenges he's faced. He's asked up to use the slides as a token for conversation, and not to treat this as a "presentation' per se. This is meant to be a conversation, not Ted talking, which means this is likely to be even more fun than normal.

Think about the things you want to do, what are some options you'd like to try? Ted mentioned that he'd love to do TDD in his organization, but it's not practical with their environment as it currently exists. There are trade-offs in all things, and one of the tradeoff's he's had to deal with is that the nature of their tests. The real world is full of constraints, and we often have to deal with those constraints.

Ted through out a provocative question... what is an estimate? It took awhile for people to reply to this. A best guess based on information that we have (aka "bull---t"). SWAG, or "silly wild ass guess". A combination everything you need to do, paired with everything you've already done and know, and figuring out how to harmonize the two. Any wonder why we (collectively) are so bad at this;)?

How about bugs? Have you ever estimated how long a bug will take to fix? Of course, it depends on the bug. A mis-label of an element might take five minutes. A (seemingly) random performance drop under load might take days to figure out, maybe more, not even counting the time it might take to actually fix it. Some bugs seem obvious after the fact, but getting to "obvious" might pas our programmer and tester through days of hair pulling and mega frustration.

Ted refers to bugs, infrastructure, and other such items as "overhead", and while it's important to know how long it takes to take care of these things, trying to score points is counter productive. Ted isn't saying "don't rack the time it takes to do tasks" Those items are important, they take up time to do real feature coding (and feature testing, too).

Another bad habit is to "ignore all previous or other projects". Why do we save all of our spreadsheets, story point data, and other details if we have no intention of learning from it? The reason is that history proves that time and energy just seek a status quo. We record everything because we once intended to learn from what we found, but over time, we just end up recording everything because we've always recorded everything. Mining the data to make some projections of future work may not be entirely relevant, but it's not worthless either. Has anyone ever really delivered a project early with all scheduled features? Typically, projects come in over time, over budget and with jettisoned features. Examining previous projects to see trends allow us to counteract biases, if we are willing to pay attention. This approach is called Reference Cast Forecasting, and while it may not be very glamorous, it can give amazing guidance. Sadly, companies that are good at doing Reference Cast Forecasting are rare.

Another challenge we face is that we try to sample data without a clear reference of what we are sampling or even why we are sampling it. Think of audio. The lower the sample rate, the lower quality toe audio. The higher the sample rate, the better fidelity the audio you capture is. Sampling of data and history (think velocity of projects) could be very high fidelity or very low fidelity. Most of the time, we just don't know what we are really measuring. We are also terrible at statistics, on the whole. We tend to focus on perceived catastrophic instances, where the likelihood of that event happening was so incredibly low, winning the PowerBall lottery was more likely. Meanwhile, real and genuine dancers, much more prevalent, were not given the attention they deserved, especially considering their likelihood of occurring was significantly higher.

Another mistake we make is to believe that velocity (or defect rate, scope creep, expertise, skill, etc.) is linear. It's not. there comes a time where technical debt or other issues will slow down the process, or speed up one area to the mis-balance and detriment of another.

Ted talked a bit about the flaw of averages, and the danger of always taking the mean and adding it up. Granted, the mean may be correct 68% of the time, but that also means that 32% of the time we are wrong, or off the mark, or potentially *way* off the mark. That 32% chance is one in three. That's a lot of potential for getting it wrong, and all it takes is one unknown variable to totally throw us off. An unknown could, potentially, help us move unexpectedly faster, but generally speaking, unknowns tend to work negatively to our expectations. The mean may be a "3", but one out of three times, it will be a six, or an eight.

Another big danger is "attribute substitution". We don't know the answer to A< but we know B very well, and we kind of thing B is a lot like A, so we'll provide B as support for why A will take as long as it will. It's a dangerous substitution, and people do it all the time, most of the time not realizing it. It's the analogy stretched too far. Analogies can be helpful but analogies are never perfect fits. There's a real danger on relying on them too much. Measuring everything the same way is also problematic. Epics, themes, stories, tasks. Measuring them all the same way, there be dragons!

 Another danger we face is that we spend a lot of time on things that have little value. Why? Because it's much easier. Ted mentioned the idea of the cost of delay, where if I don't have a capability as a certain point in time, there is a cost, and I might be able to calculate that cost. Very often the hard stuff gets pushed back, and it's the hard stuff that's most at danger of becoming the victim to the cost of delay.

Ted suggests that we tend to underestimate our own completion time, but we are much better at estimating other people's efforts. Is it wishful thinking on our part, or are we just better observers of others and their capabilities over time? Perhaps taking our over estimation of another and added to our underestimation of ourselves might bring us to the sweet spot to how long something will really take. It's an interesting idea.

How many of us tent to only estimate our actual "touch time", meaning our in the zone, fully focus on what we are doing time? We tend to think way too much of how we allocate our time and attention. we forget all of the things that we may need to do, or just plain want to do. Do we ned to talk with other stakeholders? Do we need to coordinate with other members of the team? Those external dependencies can have a major impact on how much time and attention we can actually apply to an issue.

Another danger we face is that we tend to associate points and sizes to time in isolation. We completely neglect the actual complexity of the effort. we don't want to think of just the idea that a point equals a perfect engineering day. the whole idea of points was that we would abstract away the time factor, and that a difficult task or simple tasks would still have point value, but the points would be variable. Unfortunately, we've pegged points to time, so changing that attitude may be a lost cause. Additionally using things like Fibonacci numbers or planning poker, aspects that point to larger numbers, tends to increase the odds of under-estimation. The big numbers scare people. It's more comfortable to go with the values in the mean, an effect referred to as Anchoring Bias. We tend to anchor to what other people say, because they are close together. we don't want to be the outlier, even if we have a deep suspicion our pessimism may be well warranted. Our attempts to remove anchoring bias instead puts social anxiety into the mix. In short, we go with what feels safe. Remember, safe has a one in three chance to be wrong.

Another real danger is premature estimation. Have you explored the options before you commit? This can happen when someone tells us what to implement, rather than describing the problem and looking for the WHY of the problem. Exploring the WHY lets us see other potential avenues, whereas committing to a WHAT may mean committing to a course of action that is overkill for what is really needed to solve the actual problem. Sometimes we just have to experiment. We may not be able to come to an obvious course of action. There may be two competing ideas and both may look great on the surface. Sometimes we may just have to set up a few experiments to see what might be the best approach.

This was a deep talk, and there were some interesting aspects I hadn't considered. Some of these items are really familiar, and some are subconscious; there, but under the radar. Lots of food for thought to say the least :).

Our thanks to Salesforce for providing the venue for tonight, our thanks to Ted Young for speaking, and thanks to O'Reilly Media for providing free books for our Meetup. We would of course love to have more to give away, if you feel so inclined ;).

By the way, just want to point out, as the picture indicates, the spelling of "Fix You Estimate Bad Habits" was originally a typo, but became part of the title because it underlined the whole point of the topic :).

Live from Climate Corp, it's BAST!!!

Another day, another Meetup, and this time, I don't have to present, so I can do what I usually do at these events, which is stream whatever flows into my brain and capture on bits to share with the rest of you.

Again, as in all of these events, this will be raw, dis-jointed and potentially confusing, but the benefit is you get to hear it here and now as I hear it (well, for the most part). If you want fully coherent, wait a while ;).

So for those curious, here's where we are at tonight, and what we are covering:

"Productivity Sucks, How About Being Effective" an evening with Jim Benson

Wednesday, December 4, 2013

6:00 PM - 8:30 PM

The Climate Corporation

201 3rd Street #1100, San Francisco, CA

Jim Benson, the co-author of "Personal Kanban", and a contributing author of "Beyond Agile: Tales of Continuous Improvement", is here to talk about  about the myths surrounding our work and how we think of it, specifically around how we determine what is productive, and isn't. Tonianne DeMaria Barry, the co-author of "Personal Kanban" (and his partner at Modus Cooperandi) will also be sharing some of her experiences from a variety of successful "kaizen" camps that have been held around the world.

What we are hoping to do with tonight's talk (and several more in the future) is to expand the range of topics that get covered in a typical software testing Meetup. Our goal is to help develop a  broad cross section of skills for testers, not just those in the nuts and bolts of direct and specific testing skills, or programming/toolsmith topics (nothing wrong with those, of course, we have them, too).

At the moment, though, we are eating food, drinking beer, wine and soft drinks, and conversing. Thus, I feel it vital to schmooze and welcome our guests, but I will be back shortly ;).

---

Jim stated our talk tonight about how he was able to set up a variety of opportunities selling Agile Methodologies to organizations (businesses, government, etc.), and realizing that many of the Agile Methodologies were, well, problematic. While working through some of the issues, they opted to try to apply Lean principles and, in the process, developed a variety of methods around a "kanban" system ("kanban" being a Japanese term that means "ticket" or "the card that moves"). Anyway, that's Jim, and that's what he said he wanted to get out of the way right now.

What he really wants to talk about is the fact that, if you work for a team or company that prides itself or markets itself as a "highly productive team", it's very likely that you are working in the worst environment possible. Wait, what?! Why would that be the worst possible things?


Part of the reason is that with that "high productivity" comes a lot of gamesmanship. It's also incredibly subjective; productive according to whom? Do they mean the team as a whole,? Do they mean the development methodology? Do they mean how much they push out? Who is defining or describing the "productivity"? We love to believe that everyone is all on the same page at the same time, and everyone is working in tandem.

Anyone who is in testing knows that this is rarely the case, unless you are fortunate to have the opportunity to pair with the developers as they code and you are riding along as a testing navigator (and yes, I do that from time to time, but not always, and not nearly as often as I would like to).  More times than not, we get our stories dropped in a group at the end of the coding time, and testing then spins up and frantically tries to get the testing done.


Jim makes the point that we are seeing an increase of productivity in some aspects, but we are seeing a proportional decrease in actual effectiveness, because much is getting done, but little is being accomplished (or it's overloading the downstream parts of the process, i.e. those of us in testing or ops).

So how can we solve this? First is recognize that productivity silos exist, and that they are evil. The more functionality that is sandwiched into one role, regardless of how productive they are, they are not going to be able to increase the entire teams ability to produce, release, or deploy because while one group is hyper-optimized, other groups are woefully under-prepared and over-burdened, because they do not have a complementary option. think of trying to fit a 12 foot diameter water pipe and its flow through a connecting pipe that is only three feet in diameter. Doesn't matter how much you put into the 12 foot pipe, the three foot pipe is going to be a bottleneck.

Think DevOps... and before anyone thinks "DevOps" as a team, it's not. It's a mindset and an approach. The goal, though, is that all of the teams need to be able to get the optimization that the programming group has. For the effectiveness of such a team to get better, all of the connection points need to be addressed, and all of the players need to be on the same page. That could mean many things. Sometimes it means that some of the programmers are going to be up in the middle of the night when something goes wrong ;). Silos are easy to talk about, but very hard to optimize and balance in reality.

"Productivity is just doing lots of stuff". Actually, James used a more colorful metaphor, but you get the point ;). Bad productivity is a reality. Lots of stuff is getting done, but it is really worthwhile? Is the chase for the almighty "velocity" really a worthwhile goal? Are we actually adding to the value of what we are creating? Or are we creating technical, intellectual, and expectational debt?

One of the goals behind Personal Kanban is to make it a pull system, where we grab what we can work on as soon as it's available. There are a variety of impulses that drive this, Demand pull, of course, is that the market is telling us "hey, we want this, please make it for us". Internal pull is when our internal voices of our companies are saying "we need this and fast" without any correlation to what our customers want. Aim for the former, but let's do all we can to resist the latter.

One of the real challenges of what we produce in a software centric world is that our "product" is extremely ephemeral. What we produce is difficult to visualize. Because of that, we have to be mindful of exactly what we are making, how that stream is created, and what has to happen from start to finish. The tricky part is that, more times than not, the initial value stream starts from the end and works its way backwards. What results, very often, is that we are missing stuff, and we don't know what we are missing, or why. If we are focused on productivity, we do not have any incentive to seek out the holes that exist. To be effective, we need to be aware, as much as possible, where the deep holes might actually be, and find them. Quickly is best :).

One of the concepts that we bring with Kanban, and that comes from the world of manufacturing, is the idea of "inventory". The goal is to have the right amount of materials on hand, but to not have too much inventory. Think of an auto manufacturer that produces tens of thousands of cars, only to discover that the market has no use for their cars, and therefore, they have produced tens of thousands of cars that no one wants. We'd see that as suicidal. Well, that works with code, too. When we write code that is bloated, filled with features that no one really wants, we are doing the same thing. We don't want to write a lot of code, we want to write the right code, an make sure that the right code WORKS!!! Note: this is not an Agile thing, or a Lean thing, or a Waterfall thing. It's a human thing, and we all feel its effects.

OK, so we have your attention. Productivity bad, effective good. That's great, but how can we use this in our testing? How can we recalibrate ourselves to a mindset of effectiveness? The most difficult thing is that, when we find that we have a back log of done things, rather than pushing those downstream to work harder and process more, we need to actually stop doing things and examine issues that might be "done" and see if "indeed" it really is (think of a story delivered two weeks ago, but that testing just got to today, and in the process, they found a bug. What does a programmer do? Well, very likely, they have to go back two weeks in memory to think about what they actually did, and that context switch is expensive. Compare that to programming happening and testing happening in a tight feedback loop. Which approach do you think will be more effective? Why?

Chances are, because if we can address something shortly after we worked on it, we would be fresh and remember where we were, what we were doing, and how we might be able to address it. Delays make that process much harder. Therefore, anything that creates a delay between Done in one sphere and Done in another will cause, surprise, more delays! the best thing we can do is build a narrative of our work that is shared and that is coordinated. If we realize that we have ten stories in backlog, the best thing we could do is stop adding to the back log.

Jim brought up the Buddhist concept of "mindfulness", and the ability to be mindful of the shared story comes to the fore when we are not overloaded and focused on production at the expense of everything else. Avoid becoming task focused, aim to be situationally aware. Specifically look for opportunities to collaborate. That doesn't necessarily mean "pair programming" (that might be a better be described as "teaming"), but it does mean try to find ways that we can leverage what each other is doing, not just to get stuff done, but to more likely ensure that we are doing the right things at the right time, in the most effective way.


One very special aspect that needs to be addressed... there are things that are just plain "hard". Very often, the way we deal with hard problems is we move over to easier things to work on, and when we get them done, we feel accomplished. It's human nature, but it doesn't address the fact that the hard stuff is not getting dealt with. the dancer is that, at the end of the sprint/iteration/cycle/etc. all that's left is the hard stuff, and now we have a danger of not being able to deliver because we didn't address the hard stuff until we reached a point of no return. when we get to things that are complex, it doesn't necessarily mean that we have failed. It may just mean that we need more than one person to accomplish the task, or that we need to have a more thorough understanding of what the actual goal is (it may be vital, or it may not even be necessary, but we will not know until we dig into it, and the longer we wait to make that dig, the less likely we will get a clear view of where on the spectrum that "hard problem" lies.

Back to testers in this environment. How can we help move towards effectiveness? Put simply, get us involved earlier, and have us test as soon as humanly possible. We don't have to test on finished code. we can test on requirements, on story points, on initial builds to check proof of concept. Sure, it's not finished, it's not elegant, but we don't really care. We don't want to polish, we want to check for structural integrity. Better to do that as early as humanly possible. We can focus on polish later, but if we can help discover structural integrity issues early, we can fix those before they become much mode difficult (and time sensitive) later.

---

My thanks to Jim and Tonianne for coming out tonight to speak with us, and thanks for helping us cover something a bit different than normal. I enjoyed this session a great deal, and I hope we can continue to deliver unique and interesting presentations at BAST Meetups. My thanks also to Curtis and Climate Corporation for the space and all the leg work for making this happen. Most of all, thanks to everyone who came out to hear tonight's talk. You are making the case for us that there is definitely a need for this type of information and interaction. Here's wishing everyone a Happy Hanukkah, Wonderful Winter Solstice, Merry Christmas, Happy New Year an any other holiday I might be overlooking, but we wish you the best for the rest of this crazy active month. We look forward to seeing you all again sometime in mid January, topic to be determined ;).