Under the Rocks and Stones

I've deliberately taken some time to step away from blogging and post less the last few weeks. Part of that was because I had completed a large multi part series (more about that in a bit), and part of that was a conscientious decision to spend some more time with my family during the holidays, but I can't let the year end without my "the year that was" post, and see if I can find another line from the Talking Heads "Once in a Lifetime" to keep the string going. For the fourth year, I'm still able to do that :).

This year was definitely one of digging into my mind and my experiences, and taking advantage of the fact that what I can learn, and what I struggle with, has a value to others as well. I focused the first part of the year on running through the Practicum approach and Selenium 2, specifically David Burns book. I found this process to be enjoyable, enlightening, and yes, it required me to be willing to dig further than the printed material. Plain and simple, even with the best guide, the best materials, and the most specific examples, the natural drift of software and software revisions means that we need to be alert to the fact that we have to do some digging of our own. Sometimes, we get frustrated in our efforts, but if we continue to dig, and ask questions while we dig, we can do more and get better at what we are doing.

SummerQAmp was an important focus for me and others this year, and we expanded on the modules that were offered. We made inroads on what we covered, but also discovered that the materials and the model we were using was less effective as we tried to branch out and try different ideas. The biggest challenge? How to make the material engaging with self directed readers and interactions. Much of the best software testing training that is out there that focuses on skills-based testing is best learned with a group of people discussing and debating the ideas and approaches. Taking that approach and making it work for a single individual that needs to learn the material is a challenge we are still working on, and I am hopeful we will make good on improving this process in 2014.

Weekend Testing in the Americas has had a great run, and it has been blessed with additional facilitators who are helping to take the weight off of my shoulders and bring in ideas and approaches that are different from mine (which is great :) ). Justin Rohrman and JeanAnn Harrison have been regular contributors and facilitators, and to both of them I owe a huge debt of gratitude. There's definitely more opportunities to dig for more and better ideas when there are additional facilitators helping to look for and pitch ideas.

If there was one concept or test idea/approach that became foremost in my thoughts this year, it would have to be "accessibility" or how to interact with systems and information for those with physical disabilities. Much of my work this year was associated with learning about and working with stories that focused on exactly how we can make our interactions better for those who cannot see or interact with systems in ways that most of us take for granted. I worked primarily with an intern to help make this a better focus for our product, and to learn how to continually ask questions and consider ways that we can better focus on what we do to deliver a usable and worthwhile experience to all of our users.

I participated in three conferences this year, two of them here in the United States, and one in Sweden. STP-CON in April (held in San Diego, CA) was a chance for me to talk about Agile testing and how I adapted to being a Lone Contributor on a team (a situation that I am no longer specifically doing, as I am now part of a larger testing organization, but still small enough that many of the lessons still apply). August 2012 saw me presenting in Madison, Wisconsin at CAST 2013 and Test Retreat and Test Leadership Camp (a continuous week long event of learning, interacting, and developing ideas that I would present in other talks and places). Finally, I was invited to speak on two topics (balancing automated and exploratory testing, and how to "stop faking it" in our work lives) at the Øredev 2013 conference in Malmö, Sweden.

In addition to formal conferences, I participated in numerous Meetup events in and around the San Francisco Bay Area, and what's more, with Curtis Stuerenberg, helped to launch the Bay Area Software Testers Meetup group. This is a general interest software testing group, with the goal of expanding into topics that, we hope, go beyond just testing and into aspects that can help software testers get a better feel and understanding for more areas of the software development business.

An interesting challenge came my way in 2013. I've been blessed with additional outlets to write and present my ideas beyond this blog. Smartbear, Zephyr, Atlassian, Testing Circus, Tea Time With Testers, and StickyMinds have all been outlets where I have been able to present ideas and write to a broader audience, and my thanks to the many readers of this blog who have seen those articles, shared them with others, and helped make it possible for me to keep writing for these sites. I appreciate the vote of confidence and the comments and shares of my work with others, and if you will keep sharing, I will keep writing :).

The project that, for some, will be the most recognizable for 2013 was, in many ways, just another bold boast that I figured would be some basic ideas that I would write on each day. Instead, my expansion and developing workshops on the "99 Ways to Become a Better Software Tester" e-book offered by the Ministry of Testing in the UK became a multi-month process, and one in which I had to do some significant digging to bring to completion. While the series is now finished, the ideas and the processes I learned are still having ripple effects. I think there is more where this came from, and I want to explore even more how I can expand on the ideas I wrote about, and make them better.

Through the process of being on the Board of Directors for the Association for Software Testing and working as the chair for the Education Special interest Group, I learned a lot about how to better deliver software testing training, and to help expand on the mission of AST and how we deliver training and the people involved in that training. I took a step back this year to let others teach and become leaders, and I am grateful for the level of participation and focus given by so many people to step up and help teach others. It cements my belief and testimony that software testers in our broad and worldwide community contain some of the most giving and helpful people I've ever met.

This year saw me interacting with two additional initiatives, one I've been involved with for a few years now, and one that is very new to me. Miagi-Do had a banner year, in which we started a blog, developed more challenges and sought to get more involved as a group in the broader software testing discussion. We brought on board many additional testers, many of which are doing so much to put into practice ways to help share and grow the skills of the broader testing community (many of the current facilitators for Weekend Testing around the world are also Miagi-do students and instructors). Additionally, I was invited to participate in a mentoring program through PerScholas, and have interacted with a number of their STeP program graduates (many of whom have also come through and been participants in Weekend Testing as well).

All in all, this has been a year of digging, a year of discovery, a year of new efforts and making new friends. It's been a year of transition, of picking up, and letting go. A year of seeing changes, and adapting to them. It's been a year of learning from others, and teaching what I can to those interested in learning from me in whatever capacity I can teach. Most importantly, it has shown me that there are many areas in testing I can learn more about, perform better, and get more involved than I already am. What will 2014 bring? My guess is that it will be a year of new challenges, new ideas, and more chances to interact with my peers in ways I may not have considered. Once thing's for sure, it will not be "Same as it ever was" ;).

Sharing Some December Cheer With the #Packt$5 #ebookbonanza

For those of you who read my blog regularly, you know that I do not sell advertising here, and I do not typically "shill" for other companies, for products, or any of that.

However, from time to time, a company that is helpful to me, and gives me items to help me learn and share on my blog, has something they do that I think is worth talking about and sharing with others. Packt Publishing has been the source of many of my book reviews, and they frequently give me the eBook versions that I review, which I appreciate. In that spirit, they asked if I would highlight a special December program they are running, and I said, "sure, I'd be glad to".

Packt has, from Deember 19, 2013 through January 3, 2014, priced all of their eBooks and videos at $5 each. That's roughly 1700 titles, all told, and you can buy as many as you want at that price. – more information is available at http://bit.ly/1jdCr2W



If you would like to take advantage of this, then go to the link above and make your selections. I know I will be (I have some titles related to node, nginx, and some open source graphical applications already picked out, and yes, they will likewise be reviewed soon :) ).

On Surroundings, Clutter and Getting Out of My Own Way

One of the things that I have found over the past several years, and it seems I am destined to ever relearn this, is that I can always find a way to get in my own way. I am a fan of classification, organization, attempts to streamline and de-clutter, yet I always seem to have too much stuff surrounding me. Note, this is not a complaint, but an observation. I love the home I live in. It's not opulent, not hugely spacious, but it serves the needs of a family of five quite nicely. The one drawback, at least for me, is that there has to be someplace where chaos can exist so that order can take place elsewhere. Ironically, those places seem to be my garage and my office (i.e. my two "creative domains").

There is a joke among "organizistas" that allows for the "ten percent rule". No space is ever completely organized. There is always some place where there is chaos and disorganization. Every immaculate kitchen has a junk drawer. There is one closet that is not perfectly organized, and one room tends to be a jumble of things. Often, it is because the activity or purpose of those areas is perpetually labeled "miscellaneous". It's where all of the odds and ends tend to end up. My office gets this designation.

Understand, my office is the most "unlovable" room in our house. For various reasons, the previous owners of our home, when they chose to build an upstairs addition over the garage, decided to route out a section of the garage to put the staircase. They made a large main room, a half bath, and a "bedroom". Well, some room had to go over the staircase, and to be creative about it, the "bedroom" was the spot chosen to be over the stairwell.

Were the room to be a perfect rectangle, it would be nine feet nine inches wide by thirteen feet six inches long, with five and a half feet by two feet taken up by closet space. But this isn't that room. Instead, there is "the bump", four feet six inches by four feet four inches, that goes over the stairs. This unfortunately placed bump makes the room a bit, shall we say, less than ideally shaped. To the previous owners credit, they did make some interesting use of the space and made an additional closet out of it, albeit a closet with a floor that rises above the floor of the main room.

There were a few owners that owned this house before we did, and everyone who owned the house before us used this room for the same purpose. It was "the office" or "the spare room", because it did not fit any pre-conceived plan to be used as a regular bedroom. Feng Shui was not taken into account when this room was made ;). Thus, I tended to do the same, and for fifteen years, this room has undergone several transformations, purges, redesigns, clutter abatements, organizations, reorganizations, and somehow, I still manage to get work done in here.

The room has to serve several purposes, mainly because there's no place else to practically have me do these things. Not only is my office my work and testing space, my writing haven, my exercise room, my craft room, and my recording studio, in a pinch, or a late night or early morning call or work assignment space needed, it doubles as a meeting room, a lounge, a reading area, and occasionally, a guest bedroom (and likewise, on occasion, "my" bedroom, when I find it late and I just need to get a couple hours rest before I get up and go to it again).

The biggest challenge with a multi-purpose room is the need to switch tasks, and have a system where I can do so effectively. "A place for everything and everything in its place" is great in theory, but very often, I find myself having to contend with two or three projects needing the same space. thus, what often happens is there is a bundling up of stuff, stuffing wherever I can make room, and then getting back to it when I can. It's a room that invites fiddling, tweaking and moving stuff around to find that "best spot" to put everything. In short, it's a place where, very often, I find that I get in my own way; my best laid plans for one project/process cause me to be horribly inefficient for another.

In an ideal world, I would just say "OK, well, I will set up another room to do that other thing", but that's not really an option. To keep a happy home, this room is my domain for whatever project I need to be working on, and as such, it has to work, odd and ends and all.

I liken this to my testing career. Too often, people on the outside look at testing as though it's a neat little atomic and simple process. You look at something, you expect a behavior, you confirm the behavior, it passes. If it doesn't confirm the behavior, it fails. It limit testing to a very simple yes or no system that is efficient, elegant, and easy to organize. Hate to be the bearer of bad news, but testing is none of those things. It's wildly cross-discipline, it takes from many places, it needs many unique resources, some of which are really hard to categorize.


Testers don't just have a small set of tools at their disposal. In fact, they literally have the entire world of knowledge to work with to help define their tests, their strategy and their approach. When you picture a heavily cluttered and wildly akimbo lab of a mad scientist, that is the essence of a tester, and the way a tester often works.

Does this mean that we cannot be organized, that we cannot be efficient? Of course not, but it does mean that we run the risk of getting in our own way. We are often enticed by some new tool, app or device that will make things simpler, more elegant, less crowded, more organized and methodical. Unfortunately, I tend to look at testers (not all, mind you) as those people that fall under the "ten percent chaos rule". We have needs for more than the "nicely organized" environment that fits one purpose very well. We shift, we switch, we weave and bob through ideas and applications, and sometimes, that requires a tolerance for "stuff and clutter" that goes beyond what many think is comfortable.


As of now, I have some semblance of control over my domain, but alas, this is a good day. Some days are more chaotic than others. In my world, the best thing I have discovered is that "nothing stays the same, and nothing ever changes unless there's some pain involved". That doesn't mean that I don't keep trying to organize and get everything where I want it to be. It means that I do my best to rid myself of distractions until I actually need them, and then know where those distractions have gone. Once I know where they are, I try my mightiest to forget they are there, at least for the time being. Ultimately, I have to be aware of the fact that, most of the time, the person that gets in the way of my progressing on something, ultimately, is me. Thus, it is best to do whatever it takes to get me out of my own way whenever possible :).

Let's Stop Faking It: My "Other" Talk from Øredev 2013

I realized this morning, as I went back to the Øredev 2013 site, that my video for my 2nd talk had been posted. My talk about Balancing ATDD, GUI Automation and Exploratory Testing has been getting most of the press, as well as repeat performances for the Bay Area Software Testers and Silicon Valley Software Quality Association meetups. Still, I want to talk about this one, as it really draws on a lot of things I've been thinking about, as well as a moment of embarrassment and realization during the Q&A.

This talk was all about expertise, and how we all deal with it and represent ourselves around it. I draw a lot on my own experiences and how I like to deal with ways to get beyond faking what I know and moving forward into real knowledge and skill. For those who want to see the actual Prezi presentation up close and personal, it's here.

The embarrassing moment? In the Q&A, I was asked how I felt about "Impostor Syndrome". I totally botch the definition, and I give an answer that is 100% opposite as to what Impostor Syndome actually is. Maybe it was a combination of lack of sleep or adrenaline rushing through me, but I worked through the answer, moved on to other participants, but as I would look back at the person who asked about Impostor Syndrome, I could tell by the look on their face that I didn't answer their question. 

Fortunately, one of the participants clarified for me what I had messed up. Impostor Syndrome is where you are competent but believe you are not. I felt tremendously relieved to hear this, as it gave me a chance to re-consider, re-frame and add to my understanding. Of course, some are going to ask "How could you give a talk about faking it and not have had a good grasp of "Impostor Syndrome"? It's a fair question. I didn't prepare my talk from a perspective of psychological reasons why people fake it, I approached it from my own memories and working with other people I directly knew. "Impostor Syndrome" was a term that, until that very moment, I'd never actually heard. I mentally walked through what I figured it would be, and answered. Were I perhaps better rested and less amped at that immediate moment, I might have said "what do you consider good examples of Impostor Syndrome?" so I could see their context, and then get an understanding for what they mean by the term. It's what I should have done, but didn't.

So why was that great? It gave me a very public opportunity to come clean, to not be evasive, to actually address head on something I didn't know, but "pretended" to (ironic considering the topic, huh ;) ?). It let me live my creed, and allowed that to be the lingering memory, rather than having no one call me on it, but then have several people walking around afterwards saying "wow, what a hypocrite, he just totally faked his way through that answer!"

It was a terrific reminder, and one I won't soon forget.

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 ;).

A Survey on “The State of Testing”

So let me set the stage here….


Joel Montvelisky (http://qablog.practitest.com) wanted to write a post about the advances that have taken place in the tester-verse in the last 5-10 years. While he was trying to put this post together, he came to the conclusion that there really isn’t a centralized set of information or trends as to what is happening in the testing world.

What does a tester do when they can’t find that information? They take it upon themselves to make their own. Trust me, I understand this logic completely ;).

Thus, Joel reach out to Lalit Bhamare (who edits Tea Time with Testers) to create and conduct a "State of Testing" survey. The purpose? To provide a “ snapshot” each year of what the “ reality” of the testing world is, and see if we can follow various trends as they shift year by year.

Of course, for a survey like this to be effective, a lot of people need to participate. To get a lot of people, exposure is necessary. To get that exposure, it would help if other testers would participate and spread the word.


Therefore, I feel it my duty and privilege to be part of drawing attention to this initiative, and I’m going to ask all of my tester friends out there to do likewise and take part in this survey.

Great, dude, I’m in… what survey?

THIS ONE!

Joel is planning on posting the survey (you can be added to the email notification list via the link above) by Thursday or Friday, December 4th or 5th. It will be up for about ten days.

So what am I asking?

1. Go to the link and subscribe so that they can contact you when the survey goes live.
2. Participate in the survey and give you honest feedback.
3. Make a point to tell as many testers as you can to likewise participate in the survey.

Tired of others telling you what testing is like and what the issues surrounding it are? Would you like to contribute in this endeavor and make your voice heard? Then by all means, please do, and tell other testers about it and get them to participate. Knowledge is power, after all :).

Another BAST Event: Productivity Sucks, How About Being Effective?

First, I want to say thank you to everyone who came out a little over a week ago to help us usher in our first formal talk at the Bay Area Software Testers (BAST) Meetup group. I was officially the first speaker with a prepared talk, and it was a repeat of my talk that I gave in Sweden a couple weeks back about "Balancing ATDD, GUI Automation and Exploratory Testing". Overall, it was a fun time, a great group, lots of great question, and our thanks to SalesForce for letting us use their offices at One Market in San Francisco.

To keep the momentum going, we (that is, BAST) are hosting another Meetup on Wednesday, December 4th, 2013. As part of our mission, we are striving to invite speakers and perspectives that break from the traditional "software testing" talks and focus on additional areas and a broader range of topics. To that end, this month we are pleased to welcome Jim Benson, the author of "Personal Kanban" and a contributing author of "Beyond Agile: Tales of Continuous Improvement".


As seen above, the topic is "Productivity Sucks, How About Being Effective?" Jim will speak to us about the myths surrounding our work and how we think of it when determining what is and is not productive.


Again, our goal is to arrange to have speakers that talk to and about testing, but also to hear from people outside the narrow confines of what we traditionally hear at software testing talks. We think this would be a good talk for anyone, not just software testers, so we are hoping that some programmer, project manager and management types may find this interesting.

Date/Time: December 4th, 2013, from 6:00 p.m. to 8:30 p.m.

Location: The Climate Corporation, 201 3rd Street #1100, San Francisco, CA

The Meetup announcement is here. Please help us spread the word :).

Adventures In Failure: Benign Neglect vs Over-Reacting

This is a blog post I hoped I would never have to write. To my tester friends, this has only peripheral relation to my testing career, but it's something I've been dealing with for the past several days, and it's taught me a few things, and reminded me once again of several things I thought I already knew. Normally, I take a somewhat self-deprecating tone with posts like this, but I'm really and seriously bummed about this, so I'm just going to tell it straight without any jokes or color commentary.

Yesterday, my 70 gallon fish tank became a ghost town.

This tank has been up and running, in some way, shape and form, continuously, with one major exception (for a swap-out back in 2007 due to a ruptured seam) for 19 years. In that 19 year period, many fish have come and gone, for a variety of reasons (personal taste and interest, changes in water chemistry moving from soft, acidic San Francisco to hard, alkaline San Bruno, etc.). Generations of fish have been born, grown, given away, and repopulated to other tanks. It was a vibrant community of predominantly cichlids, though it has housed other fish over the years as well. To put it simply, it's run pretty much flawlessly, and without much in the way of tweaking and meddling on my part, for years. That all changed Monday the 11th of November.

Wait, let me step back another few days, to Saturday, November 2, 2013. That day, I did something momentous, and potentially provided the catalyst that started this whole thing. On that day, I made a decision to end a decade long experiment. I'd kept a breeding colony of Convict Cichlids (Archocentrus nigrofasciatus) running in that tank for that time, and it was successful. In fact, it was too successful. I had run out of tanks to house them, and shops willing to take them (even for free; I was flooding the local market with Convicts). With no more room to put them, I decided it was time to make a change. I kept the largest and longest lived males, separated out all of the females and juveniles, and with a final "special delivery" to my favorite fish store, I brought the breeding colony to an end by bringing those females and juveniles to the shop. Yes, we're talking dozens of fish.

In the process, I noticed that they had some new arrivals, in particular several Green Terrors (Aequidens rivulatus). Contrary to popular folklore, the name is a bit of a misnomer. They are cichlids, so yes, when they are in "breeding mode", they can be as aggressive as any other cichlid species, but no more so. As I was looking at them I though "wow, what a great time to balance out the tank with a new species". With Acara (Green Terrors being part of this family of cichlids) and Convicts, as well as my main tank denizen, a Green Severum (Heros efasciatus), coming from similar waterways in Central and South America, I figured they'd be a great addition to my tank. I bought four of them, introduced them into my tank, and then spent the next couple of days getting ready to go to Sweden. Since I was going to be gone for awhile, I figured giving the tank a good thorough cleaning and larger than average water change would be good for all involved, as well as a perfect time to introduce the new fish.

Now we fast forward to Monday evening, November 11th. As I came home from work that day, my younger daughter said "Dad, there's something wrong with Kite!" Kite is the name for the large Green Severum; he's really placid and just drifts around the tank like a big kite, hence the name. I asked what "wrong" meant. She said that his whole body looks like someone poured salt all over him.

Uh Oh!!! I know what that means. We have an "ich" infestation.

Now, I've seen these before, and I've treated them in the past, so I figured, well, this shouldn't be too big a deal. Since I'd needed to get medication anyway, I figured I'd pick it up the next day and start treatment when I got home. For good measure, I'd do another large water change so that I could limit the spread of the problem. Unfortunately, my hospital tank was not set up. Even if it was, I'd need a larger tank to put the Green Severum in; a 6 gallon quarantine tank isn't going to cut it for a 10" fish! Therefore, it meant I'd have to treat the whole tank. Turns out that would have to be the main step anyway, since when I got home, I noticed that the signs of the disease had spread to several of my Convicts as well. With that, I started measuring out the medicine and dosing the entire tank. I also followed the directions and removed all of the carbon and chemical filtration materials from the filters.

Within three days, I saw that almost all of the fish were erupting with the parasites and the tell tale signs on Kite were becoming even worse. He looked like he was coated in a layer of plaster that was cracking away, and his fins were decaying at an alarming rate. With that, I knew it was only a matter of time. Some of the smaller convicts were the first to go on Wednesday, then some of the larger Convicts followed suit. Kite, my oldest and longest lived veteran of my tank, at 12 years, succumbed to the disease on Friday morning. Over the next three days, roughly every twelve hours, another fish would die until finally I was left with only three fish. Looking at the two surviving Green Terrors (two had likewise died during the week), and my longest lived male Convict, I took a look at the two Green Terrors and realized that, if anyone were likely to survive, they had the best chance. With that, I set up the 6 gallon hospital tank, and pulled them out to be monitored and treated. My oldest Convict, I had to leave him in the big tank, and hope for the best. Alas, the end came for him too, last night. As of now, there are no fish of any kind in my main tank. They are all dead.

As of this morning, my two Green Terrors are still holding on, one looking like it might be a hard recovery (he's lost a fair amount of scale over the left side of his head and flank), and the other having what looks like a real fighting chance. My 6 gallon tank is not much, it's definitely not the environs I just pulled them out of, but it will have to be home for the next three weeks, and on the plus side, they are currently still alive. For the first time in 19 years, though, my main tank is now devoid of life, except for what may well be a colony of parasites that I will now wait out the next three weeks, to make sure that they are all dead before I try to start the tank up again.

Many things have been going through my head since this all happened. What did I do wrong? The answers are telling. Most critically, I broke one of my most important rules, and I did it out of impatience. My hospital/quarantine tank wasn't set up. It hadn't needed to be for some time. I was not prepared, and I didn't have the necessary materials in place. Cautious, intelligent me would have set up that tank first, and would have let it cycle for three weeks, then bought new fish, and had them wait in the quarantine tank for three weeks, before introducing them to my main tank. Instead, because of a moment where I was making a major change in the ecology of the tank, I figured "why not?", and I just added them to the tank. What's the worst that could happen? I really hadn't imagined "the worst" would mean "wipe out my entire environment", but yes, that is exactly what happened.

Was it just the introduction of the fish? If that's the case, why were they not sick? Why did none of them show any signs of the disease? Could there have been another potential cause? Yes. Pretty much all fish carry parasites. It comes with the territory. "Ich" is expressed when fish have a stress episode, and those parasites are excited and activated. They then push out of the fish to reproduce and look for new hosts. Could the two large scale water changes in less than two weeks have contributed to that? Well, yes, potentially. The fact is, water pH is probably the one thing, outside of ammonia or nitrite spikes, that will most stress/affect a fish. I try to keep the pH as close to 7 as possible, but when I checked the water late last week, the pH was 7.8 (and yes, that difference is significant). That large a pH swing could have triggered the change.

Could the medication have exacerbated the problem? Entirely possible. One of the dangers of mediating a large tank is that the dosing is very hard to determine. What would be normal for one fish might be too little for another, or way too much for a third. This is why it's best to treat fish individually in a hospital tank if you can. Treating a whole tank can have wildly varying results. It's also possible that the dosing of the tank was too late for Kite, who already showed advanced symptoms.

Could I have done anything different? Sure, and the last option is  the one that really makes me cringe, but I know the truth of it, and didn't heed it. I could have left them alone. I could have resisted the urge to add some new fish to the tank after a major "depopulation". I could have not bothered with the water change before leaving for Sweden. I could have let the disease just run its course. Yes it would have likely killed Kite, but he was 12 years old, already beyond his life expectancy, and having had a really great run. All sorts of coulda', shoulda' woulda's, but no, the thought of doing nothing terrified me. I did what any irrational pet owner would do when their animals are in distress. I tried to fix it with all the tools at my disposal. The net result is a ghost town. Over a dozen valuable fish, but more to the point, fish that were good and dear friends I'd raised for many years.

Why am I mentioning all this? Simple, this is my blog. This is one of my biggest hobbies outside of testing, and one of the ways I observe and learn about the semi-natural world. Often in tanks, there are two things that are killers; overt neglect and over meddling. The middle ground is sometimes referred to as "benign neglect", where we do the bare minimum necessary, and let them sort it out for themselves. I've never been guilty (at least not that I know of) of "overt neglect", but yes, I've frequently been on the "benign neglect" scale. Sometimes, that's just the best way to deal with things, but it makes us feel heartless when we do it. It seems this would have been a time where more "benign neglect" would have been far more beneficial. As it stands, I now have a recovery project underway. I will rebuild, and I will renew this tank. New life will take root here again, but sadly, it will be with a whole new family. All my "best friends"are gone, and they are gone because I over-reacted.

Update: I'm happy to report that both of the Green Terrors seem to be doing OK, even the one that's missing half the scales on the left side of his head. He's being feisty, sparring with the other Green Terror, and thankfully, he's even eating, which means he really does have a fighting chance. I tend to name the fish that stand out in my tanks, and thus, if this little guy pulls through, since it's likely he'll have a bit of scarring that will look like a Pirate's eye patch, I'm going to call this little fighter "Harlock" after Leiji Matsumoto's legendary space pirate. Here's hoping I can make good on that.

A grainy shot of "Harlock" in the hospital/quarantine tank.
I'm pulling for ya', dude!!!

That's Great, But How is This Helping Your Testing?

When I went to Øredev last week, I had a whirlwind of emotions, experiences, learning and changes of perspective. While I enjoyed many of the sessions I attended, and certainly enjoyed giving the two talks that I did, I think it's safe to say that one of the most valuable lessons from this trip happened between sessions I attended, at a table in the lounge area, during a conversation I was having with James Bach.

James and I have had a number of chances to talk in the past, but usually they have been in group settings. I think this may have been the first time that James and I had an extended conversation that was just the two of us. He was commenting on the fact that I had been writing a great deal recently, and that I'd been reading a lot and talking about what I'd been reading in my blog.

During the course of the conversation, we were discussing a number of the books and ideas I'd been writing about, and James homed in on a particular question: "Can you tell me which of these books you have been reading have had a definite impact on your approach to testing, and if so, what is it?" I talked about a variety of books, including my beloved James Burke's "The Day the Universe Changed", and its focus on the interconnected nature of events and discoveries, and how I strive to look for those interconnection points. I gave several examples, and he said "That's great, but how is this helping your testing?" I had to think about it, and I tried explaining the nature of understanding what I know and why I think I know it, and referenced several other books in the process, including "Good Math" by Marc C. Chu-Carroll and how understanding and articulating logic has helped me be more focused and attentive to my assumptions. Again, the same question was asked: "That's great... but how is that helping your testing?"

Through this conversation, I came to a realization... I enjoy reading, writing, and applying ideas to how I test, but I struggle with making clear connections in my own narrative and how I work to actually bring home that point. Sure, I read a lot, and I get ideas, and I can focus on key principles that are interesting, informative, and certainly applicable, but if I cannot readily explain why what I am reading is applicable, or how I am personally applying it, then my effectiveness as a tester is not going to reach its full potential. James emphasized that there are many things that we do as individuals that we struggle to explain. He said he realized he was at a similar point several years ago, and decided that he wanted to make sure he could ground his ideas very clearly, and with unambiguous language, wherever possible. He said he wanted to not just explain what he was doing, or how he was doing it, but why he was doing it. Not just for himself, but so that he could readily articulate it to others and be sure that they understood it.

At the end of the conversation, James handed me a book and asked that I give it a good read and ponder its message. That book is "Rethinking Expertise", by Harry Collins and Robert Evans. It emphasizes a different perspective on how we look at "tacit knowledge", which is knowledge that we have, and skills that we use, but that we have difficulty explaining. James made the point that, as he saw it, I had developed a broad body of tacit knowledge related to testing, and that I was trying to explain it in my writing, but that I had difficulty articulating exactly how I was applying the knowledge I had gained. He suggested that might be something I work on going forward.

I am happy to accept the challenge. My plan is to do exactly that. In future posts, if I am reviewing a book, discussing a technique, or considering a controversy, I will make every effort to try to explain, either in the narrative or in its own side bar, exactly what I feel this topic, book, tool, or skill is bringing to my testing. I'm also willing to bet it will be a much harder challenge than I am currently anticipating it will be. Either way, this fits into my talk and personal philosophy about "not faking it", and I welcome the opportunity to make good on that promise :).

Another Day, Another Live(ish) blog from Øredev 2013

Good morning everyone and welcome to day three of Øredev (yes, I was traveling for the first day of the conference, so you will need to look through #oredev tweets or other people’s blogs to see the first day’s contents). Networking is spotty here. Sometimes it works and sometimes it doesn’t, so I will try to update these details when I can.

One of the first session highlights was to show how Julian Harty has been gathering and purchasing Kindles for schools in Kenya. He has shown how, but using second hand and refurbished materials (3G wifi hotspots, solar panel packs, power cable distributions, etc., and they are distributed to a number of schools, so that gift vouchers, free books, etc. can be distributed to the Kindles, and the ability to change the world is being achieved, one school and one student at a time.

World of Minecraft with Jens Bergensten

The morning keynote started where the conference organizer introduced his 9 year old son, and mentioned how, at his age, he would now be starting to learn English, and during the process of the introduction, it was clear that the boy knew more than a year’s worth of English. Why? Because he had been playing for years the world of Minecraft. With that, it was shown how a generation of kids have learned a significant amount of English through playing and interacting with the game.

Minecraft is a game that has been developed in Stockholm, Sweden, and have about 30 million users worldwide. Though it’s several years old now, they still sell tends of thousands of copies each day.  What is the cultural impact? You can see it in a variety of game magazines, it’s shown up in South Park, and various late night television shows. It’s used as an education tool in about 1300 schools. It’s used to teach geography, geology, history, math, architecture, programming, etc. It’s been said that it may be the only tool to be used in all education levels (primary through university).  This game has become a game changer to go beyond just schools, but also is being used with world development initiatives like blockbyblock.org and UN-Habitat. The idea behind Minecraft is that it is meant to teach children how to create, rather than the typical option of games that focus on blowing things up.

Minecraft was originally developed by Markus ‘Notch’ Persson,  Games like “Infiniminer” were influential on helping to develop the ideas behind Minecraft. From the beginning, Minecraft was created to be simple. It’s a classic “pixel game”, and everything is boxes. It’s like legos for the Internet generation. Example video of the early days of development showed how people have made small projects all the way up to mega objects like a 1:1 model of the Start Trek ship Enterprise. It’s been described as being like Lego with infinite bricks. From simple to complex structures, all is open to the players depending on the resources they gather and implemented. One of the interesting things to see is just how much can be done in Minecraft to simulate construction and building of projects using nothing but a variety of blocks.

---

My talk was next, and this time, I attempted to do a live demo of Socialtext wikiQTests and how we interact with them, use them, and how they fit into my overall talk which is leveraging concepts of ATDD, GUI Automation and Exploratory Testing. I say attempted to because, with me in Sweden, and our test servers being in California, the execution delay was just too great, and it would have resulted in too much dead air. I did, however, do some screen captures and restructured the presentation, so I now have a Prezi presentation that shows the newly revised version. For those who want to see the presentation as it currently stands, go here :).  

---

After my presentation, I sat down with Scott Barber to be interviewed for "Geek Speak", which is a video program for Smartbear. We talked about my being invited to Øredev, and the idea that our messages were being well received and quite popular sessions. I also talked a bit about the BBST courses offered by AST and the SummerQAmp program and what they are about. If we got a good recording, I think it should be posted in the next few weeks, so when it is, I'll let you all know :).

---

I hopped into Anne-Marie Charrett's "Coaching for Testers" talk, which was augmented and made even more fun by the fact that her two subjects (James Bach and Michael Bolton) were both in the session and offering color commentary on the examples and the intended actions and takeaways. I've seen variations of this talk before, but I like to see how she tailors this talk for different audiences. Good fun, and lunch time. I'm hungry, so I'll see you all later :).

---

After lunch, I sat in on Cyrille Martraire’s talk “ Refactor Your Specs”. This talk centered around the idea of the  3 Amigos concept for creating specs and stories. Cyrille broke down the traditional method of writing specs and then changed up and showed where each group has specific skills that are able to contribute. The product owner, Programmer and tester all ned to be represented, and each needs to be active in the process. 

Testers do not, and must not, wait until development is all done with a feature. Specs, for that matter, need not exist at all (gasp!). Wait, what? Active conversation, early and often, can be a big step into being rid of hard and concrete specifications. In organizations that use BDD, the Cucumber/Gherkin statements for your tests can be used as you specification and documentation steps. By treating these as living documents, we are able to keep them up to date, real and rational examples, that can be modified if necessary to be end user documentation or reference-able specifications. 

---

Another benefit to being "out of session"...
seeing Iris Classon walking on a tightrope
(tight belt ;)? ).

I had a chance to sit down with James Bach in between sessions, and what had started as a casual conversation turned into something much deeper, and something I need to do a blog post all by itself for, but suffice it to say James gave me some excellent food for thought towards something I'd been wondering about for a long time, and am getting closer to wrapping proper vocabulary around it.


I missed the sessions during that time, but this brings home the fact that, sometimes, the most valuable interaction and lessons learned may come not inside of a session, but instead between peers and friends chatting at a table in the hallway. This counts as one of those times.

---

Michael Bolton did a sessions specifically focused on Regression testing, or what we think we mean when we talk about or focus on regression. What do we really mean when we talk about regression? Is it that we are afraid of things going backwards? Is it that we are afraid something will break due to our recent changes? Are we afraid of losing face because things seem to break that we have fixed it already? 

One of the interesting things that Michael made a pint about, tangentially, is that test cases are treated as nouns, as things. Testing isn’t an object, it’s a performance, just like notes written on a sheet of paper are not music. It’s music notation. Performing the notes on the page, that performance, is music. So likewise with testing and test cases. test cases is to music notation as testing is to musical performance.

Michael made a point about checking, and that he feels he made a mistake early on in that he cast the discussion of checking vs. testing.  When we are doing fact checking, we are doing a part of testing, but calling it testing leaves out a lot of aspects of testing that  go beyond fact checking: forming hypothesis, observations, questioning, studying, modeling. Those are all aspects of testing that go beyond checking.  

An interesting question... is regression really the biggest risk? Regression Problems are symptoms of the fact that, perhaps, we have a regression friendly environment. Maybe fear of regression is also a symptom. What do the costs of regression structure, and how it affects all of the things we could be doing, might also be worth looking into. More to the point, what tests do we leave on the table when we focus out of proportion energy on regression? It may be a worthwhile trade, but again, maybe we might want to consider what energy we are applying in these cases.

---

We now come down to the final talk of the night, and of the event. Linus Willeij is a long time and core committer to the Linux kernel, so it's a pretty good bet that, if you do anything in the world of computing,  you are running his code. The Fairlight movement was formed out of the West Coast Crackers movement, and was named after the synthesizer used by Jean Michel Jarre. Linus' talk was a restrospective of 25 years of the pirate group and what they accomplished (some may have conflicting opinions as to what that record is, of course).

Linus was more focused on discussing "The Scene" that developed in the early 80's around computers, games, and ways to crack systems and gain access to them. Each community had a computer scene that was, in ways, analogous to music scenes in different communities and countries. In the early days, the scenes were predominantly middle class, white males. It was a self selecting group. There was no organization to join, no management to reign in people, your participation was determined by your participation.

We joke about people being called "elite" hackers today, but once upon a time, you actually had a real way of gating people. Elite hackers were really just those who had access to or owned fast modems. If you had a 28.8K modem in the late 80s/early 90s, you were pretty elite, you had something rare! There were many roles in the scenes, Suppliers, crackers, swappers, spreaders, phreakers, fixers, people who "carded". Additionally there were people who started making their own games and demos.

Why did this group get so big in Sweden? the first reason was that people were bored, and they wanted something to do. There was no game industry in Sweden, so people with interest in making games turned to cracking to fill the need. Linus has provided a retrospective on the techniques used by hackers in the run up from then until today, which has made for a very interesting historical tour.

With that, it's time to bid adieu (or "farväl" to keep in the Svensk ;) ), and I wish to give my thanks to everyone who made it possible for me to be here. To Maria Kedemo for inviting me, to Emily Holweck for making my travel arrangements and helping me to be as prepared for everything as possible, and to old and new friends. Thanks for making my time in Sweden so memorable.

Tack och vi ses snart!

Hej från Sverige: Somewhat Live, and sort of awake, at Øredev 2013

Hello everyone, and welcome to another stream of consciousness from your truly. If I seem a little bit more stream of consciousness than usual, please understand, it's 11:30 p.m. on my biological clock. I'm trying to overcome a nine hour time differential. I wasn't feeling it at all yesteday... I'm really feeling it now :).

To start this off, I want to say thanks very much to Maria Kedemo, since she is, first and foremost, the reason I am here in Malmø, Sweden. Maria is the one who extended the invitation for me to speak, so my giddy, bleary and somewhat sleep deprived state of mind is because of her, and I am genuinely grateful :).


Denise Jacobs starts us off with a talk about the Creative Revolution, which for a conference dedicated to The arts, seems to make perfect sense :). She starts by describing a tiny coral polyp and declares that this little piece should well be called "Darwin's Wing Man" since had it not been for this polyp (and we should add quite a few polyp siblings, there would not be a galapagos Islands for darwin to discover and contemplate the Origin of the Species. Denise is one who considers herself a "Creative Evangelist", and the interesting thing is that "creativity" is highly valued in the attributes we consider important in others, but more than that, it is a huge element in transformation. For something we consider so valuable... how can we more effectively use it?  The first thing is that we need to focus on creativity not just for ourselves, but in groups as well. "Creativity is all about making connections and seeing patterns."

Denise makes the point to say that she is talking about a (R)evolution, which should not be confused with "Revolution". With this, we come back to our friend the coral polyp. That polyp is important, but it cannot do it al by itself. It needs others, like itself and with their own genetic structure, to come together to make a coral reef. Sorry I can't give a visual of this, but an entire Swedish audience just did the wave (I kid you not ;) ). Denise used this visual to show that everyone together made this really cool thing happen.


One of the problems that hampers most of us is  that we tend to be too over-aggressive and optimistic with what we want to do. We want to do *BIG* things, but very often, it's a collection of tiny things that get us to the big things. We are even more likely to do something if we make it positive, and even more effective if we make it present (as in present tense). Anchor to a current habit if you want to make a change stick. More to the point, congratulate yourself when you do it, your dopamine receptors will thank you for it ;).


One of the killers of our creativity is that we get talked out of who we are and what we do. We hide our brilliance and our spark because we don't like being nails that stick up (we all know what happens to the nail that sticks up, right? It gets pounded down). When we over emphasize working on our weaknesses, we tend to have very minor improvements i n those areas (and we tend to resent the improvement). If we focus on our strengths, and really leverage them, we can really kick start amazing transformations. If you really want to see this in action, hang around some young kids, as they will be perfect examples of this. Kids don't stress on what they are not good at, they jump into things with what they genuinely love doing. We should do likewise.

We were asked to talk with our chair mates to discuss one of our new topics that we can make talks about. I enjoyed talking with Bjorn Granvik and his ideas about "Joy in Diagrams", which soulds kind of brilliant, to be totally honest. Me? I shared Ministry of Testing stickers with my chair mates and told them about the value and beauty of diverse geographic communities and how we are raising the visibility of software testing. Here's hoping we get a chance to present on those items :).

Creativity is supra-linier; the more we interact, the greater the possibility of creativity. We need to escape our silos, whenever possible, so that we can break out of "sticking with what we know". Ceativity is kick started when we have a broader group and more people to interact with. Getting people together is easy. Doing something with them being together is the harder part. because we tend to tear each other down. Instead, let's try to see if we can "plus" the ideas and opportunities that come our way. There's no guarantee that we will do something awesome with everything, but start where we are, and let's see if we can "let's and" rather than, yeah, but". Oh and for Denise... the plural of "ethos" is "ethe" or "ethea" ;).

---

Next up is Woody Zuill, and the idea behind "No Estimates".  This is tethered in the world of Agile, so Woody said that, if anyone was working in a traditional development environment, there might not be a lot of hope. I know from my own experiences that most estimates are ranging anywhere from ineffective to completely unreasonable. The problem is that we are looking for certainty in places where certainty really doesn't exist.


Time, cost, potential revenue, these areas certainly make sense for us to consider while we look at creating new products and services, but as Woody said, if he was actually good at doing estimates, he wouldn't be making software, he'd be getting rich betting on sporting events (heh, interesting point ;) ).  Estimates are educated (or not) guesses about work we do not understand. Seems that understanding is needed before the estimate, right? How many of the estimates we make turn out to be completely wrong? Do we make bad decisions based on what we think we want, or do we start to get defensive as soon as we make our decisions?


Woody is suggesting we do something un-natural. How about, instead of making estimates, making something that we can quickly put into use and evaluate? How about if we prove value in small chunks, rather than trying to take large pieces of functionality and finding ourselves endlessly surprised at what we end up implementing that doesn't hit the mark? Estimates are used to attempt to predict the future. Add to that "the only sure thing about forecasts is that they are (often) wrong. Unknown multiplied by unknown is... I think you get the point ;). Wouldn't it be great to call Estimates what they really are, which is "WAGs" (Wild Assed Guesses)? If we were to be more vocal about calling them that, we might be able to get some managerial traction on understanding the futility of estimates.


Agile is about discovery and steering. Napoleon Bonaparte was quoted as saying "One jumps into the the fray, then figures out what to do next". It worked for him most of the time, with the exception of that whole Russian Winter thing or Waterloo, but otherwise, he really did have a heck of a run!

"But my customers demand estimates" Really? Do they demand estimates because they want/need them, or because they've been burned too often to believe that we can actually deliver? What if we were to give them a direction, high level, without trying to fake and add minutiae that isn't real world?


 jIf we want to work without estimates, we need to do real work. Focus on delivering quickly, in small batches, and get a gauge as to what it actually is doing. Sounds a lot like Agile, doesn't it ;)?


---

Anne-Marie Charrett is talking about “Curiosity Killed the Cat, but What Kills Curiosity?” and is about a less than stellar consulting gig she took part in. Testing is questioning, and when nwe stop questioning, or when we stop being engaged and providing valid and valuable information, we are in trouble.


Anne-Marie is proud of her role as a coach, and in her view, one of the primary roles of a coach is to be dispensable. She doesn’t want to have to be there forever. She wants to help the teams work better, and then move on from there to work with others. This particular company had three teams, a mix of disciplines, and a handful of dedicated testers for each project. The key focus was to help bolster the testers and improve the testers capabilities.

After talking to the testers, some pictures emerged. The testers felt they were isolated, they had no one to help them, they had excessive points to test, i.e. the hidden work that appears. They were able to make some wins, testers worked together to help solve problems, they did work on cross knowledge, they added coaching to help facilitate exploratory testing, and they revised their automated testing strategy. There was also some wins with regard to quality (what done means, agreement on Quality, checking vs. testing, etc.).

This doesn’t mean everything went well… there was little in the way of stand-ups or communication, Cliques abounded, bugs were not getting fixed, and stories were either under defined or ill defined. Add to that the company owner was s into “Lean startup” that it seemed their trajectory was being changed all the time. Testers were afraid to speak up, afraid to question stories, and afraid to question developers decisions. Anne-Marie said that there was a point she realized that she had made a number of assumptions that, when looked at in hindsight, stood in the way of her being successful. Anne-marie saw that what was the root problem was a loss of curiosity. What kills curiosity?

Being Intimidated
Lack of Understanding
Lack of Authority, Clarity or Trust
Lack of Knowledge or Culture
You can’t kill curiosity if it’s already dead.

Curiosity is a weird thing, it’s hard to spark it when things are making it difficult to be creative and interested. Review your goals regularly and see how the culture of the company might impact your overall strategy.

--

The next section was “Practical Tools for Playing Well With Others” with J.P. Rainsberger.  J.P. stated with a short film about the fact that people are made of meat (the protagonists are aliens observing humans who live on Earth and the way we interact with one another).

In a diagram about debugging a conversation, we start with Intake. In short, what do I see or hear? Conversations go sideways when we are trying to interpret something and they get a different interpretation than what they thought  they heard (or wanted to hear) Meaning follows on.  If we say a statement in English, for some, translating to another language may lose key elements from the original statement. The significance of a message may vary (why do we care about this?). Finally, there is a response, which starts the reverse process again (Intake, Meaning, and Significance). 

If we have an intake problem, we call it a “misinterpretation”, when we have  Meaning Problem, then we have a “misunderstanding”. When we miss the significance, we may have a “misinterpretation” , and then there’s the really difficult area. the path from “misinterpretation” to “response”.  Conditioning, culture, System 1 or Lizard Brain thinking often come into play when we try to mitigate or control significance or response. This was a cool reminder that, often, we think there are culture or personality differences, when in truth, anyone “can have a failure to communicate”. This was an interesting breakdown and reminder about how we get into this situation, that we intercommunicate all the time. Some key takeaways: Think of three ways to interpret what just happened. Ask “what did you intend by that?”, communicate in “E-Prime” to reduce judgment perceptions. Warn the other person when you need to say something uncomfortable.

---

My apologies to the Lightning Talk presenters, but I was running on fumes by the end of J.P.’s talk, and I had to get some quick shut-eye (blessing of the venue being immediately next door to the hotel means I could go and do exactly that).  I have come back now for the afternoon sessions (including my own) and Scott Barber is next up with “Lifecycle Integration of Performance, Simply and Creatively”. Scott starts out with the idea that different users and different roles, performance means different things. Profiling, code design, load testing, production monitoring, etc. all play a hand in these expectations. Load testing, stress testing, etc. are all components of performance. Using a simple math analogy, performance is to load as rectangle is to square. 

The performance lifecycle needs to run from “conception to headstone” as Scott puts it, and likewise puts a spin on the cradle to grave metaphor (meaning it goes further back and further forward). Whenever an idea for an application is conceived, performance needs to be considered. 

An example that Scott discussed was with the Victoria’s Secret fashion show that was live streamed for the first time in the early 2000’s. Research showed some very different profile information than what they anticipated, with a rather large guy audience, and a spike that came later in the broadcast. They did really good research of their target market, but missed the ball when they were talking about the total potential audience. The performance hit was such that they have determined to never be such “Internet Pioneers” again, though the live streaming fashion show does keep going. The healthcare.gov rollout in the U.S. is a current iteration of this. The performance issues with the site is doing more than just being an embarrassment on a technical side, but it’s coloring public opinion for the entire program. 

To prevent poor performance, you have to check regularly and et a feel for performance perspectives as they are developing. We can’t just react when it happens. We have to look for problems first. Ultimately, everyone is responsible for performance, but ultimately, the past has indicated that it is left to the end of the lifecycle way too often. Ideally, it would be baked into every sprint, every story, every iteration. Typically, we look at performance as a sum of Software Performance Engineering + Profiling + Load Testing + Capacity Planning + Application performance Management == Inefficient and Ugly Delivery and Maintenance. Consider the cycle of Target, Test, Trend and Tune. The whole team needs to be invested in the performance of the product. Prevent poor performance with a little work, every day from everyone.

---

James Bach is riffing on testability and what exactly that means. Chuckles abounded when he asked the audience if they were still doing "manual programming", but I think he got the point across. Programmers do have automated programming; it'c called compiling, linking and building. They realized that they were different actions from programming. Hopefully, there will be some dispersion of the idea that manual testing and automated "checking" are different things. Testing, as James puts it, is "learning by experimenting, including study, questioning, modeling, etc.


James talked about the "Risk Gap"; what we know, and what we need to know. Testing helps us close that gap. The larger the gap, the harder it is to test. We don't need to drive with our headlights on during the day (running lights on my car notwithstanding, i.e. I can't turn them off :p ). However, in the dark and the fog, lights are vital. Need a big term for the Risk Gap? James calls it Epistemic Testability.

Testing is all about control and observe. Products have both general and custom components. The general components are tried and tested. The custom (new) components, probably not. There are explicit and implicit requirements. The higher the implicit requirements, the more challenging the testing process will naturally be. Project related testability, Intrinsic testability, Subjective Testability, Value Related Testability and Epistemic testability all ned to be covered to have a chance of effective testing to occur.

James just planted an amazing mental image in my head. As he was talking about so many people who look at software testing as being easy because they use tools such as Selenium and Cucumber. But what about the things you can't test with those tools? Huh, what could that be? That's then James started pantomiming a Disney song, with chimney sweeps and talking, singing mice and a spoonful of testing... go ahead, just let that image run wild in your brain for a minute. You can thank or curse me later ;).

Excellent testing is just like science. Repeat that with me, software testing is *just8 like actual scientific method, with one exception. Scientist only get one build, software testers have to deal with regression. therefore, we have to be able to observe and control as much as possible. In order to test well, we need to be able to control the execution to visit each important state, see everything important and control the variables that might influence it (plug made for the game Sporkle, and yes, I plan to play it later :) ). Logging is huge. If you test and don't analyze log files, you're missing a treasure trove of information that can inform your testing. Use fact checking to back up your creative experimenting.

James used a cool example of a simple random number generator. If we generate lots of runs and plot those runs, and we sort the output, we see that the result is not a straight line. the fact that there is a curve in the line shows that the output over time is not truly random. Some additional issues were shown in the fact that the actual random generator math makes it so that two numbers never appear (999 and 1000). Cool and fun example :).

Next up is... ME :). Tweeters who are here and who attend my session, I'd love it if you can tweet during my session so I can storify them. In any event, I've got to go and get fitted and teched out. Wish me luck :)!!!


More to come... stay tuned :)!!!