Aedificamus: Feet Don't Fail Me Know - TESTHEAD's Fitness Journey Continues

One of the entertaining aspects of fitness is the fact that there are lots of things we can do to keep us motivated and targeted to meet our goals. Over the course of three months, I've gotten into walking for long distances, using various resistance devices (bullworker, etc.), doing yoga, lifting weights, etc.

A couple of months ago, I added something to my training that I hadn't used in years, but made a lot of sense to put back into play. In short, I broke out my old PlayStation 2 and several volumes of Dance Dance Revolution (DDR) to help get me back into "fighting shape".

This experience reminded me of a testing situation that I got to deal with about 12 years ago when I worked at Konami Digital Entertainment, and how it influenced my purchasing decisions back then. By virtue of working for Konami, and having made friends with several of the people in marketing and distribution, I was able to get a number of the DDR games for free. To that end, I picked up Dance Dance Revolution Konamix (a PS1 game but playable on PS2), DDRMAX, DDRMAX2, and Dance Dance Revolution Extreme (these later three released for PS2, the latter two in development while I was at Konami). The games themselves had their quirks, as do they all. It's funny to look back today and see a variety of misspellings, or menu options that don't flow quite right, but that went to production nonetheless, back in an age when a bug, if released, was eternal. Still the games themselves were, and are, still fun, and the music especially brings back a lot of nostalgia.

The issue that became a big deal was not with the games themselves, but with the dance pads that were made for Konami. These dance pads had a fairly high number of pads that had an odd sensor issue. Over repeated use, if you were to step on the back arrow while stepping on another pad (common for jump steps and just making movement more efficient), the sensor would either intermittently not work, or it would just stop working entirely. This was not an isolated issue, it turned into a big deal heading into the new year in 2004. In fact, I had been "seasonally laid off", after the Christmas rush of 2003 was over (which was, truthfully, expected, and since I was back in school at the time, I didn't necessarily despair at such news). The problem with the number of pads was large enough that I was actually called and asked if I'd be willing to come back in to help them deal with the issue. I said "of course" and subsequently was rehired and worked with Konami all the way through the remainder of my time back in school. The dance pad issue was a manufacturing defect, and it would be a significant portion of my side customer support work for the remainder of my time there.

Because of this, when I decided to pick up these DDR games for my kids to play with, I was happy to have the games, but I opted to buy different, non-Konami dance pads. There were ranges of designs from foldable soft pads that cost about $30, to hard metal and plastic pads similar to what the DDR machines in arcades had, and these cost around $250 each. Through my research, i discovered a set of pads in between made by RedOctane. These pads used rubber mats internally to make the pads semi rigid, but light enough to be moved easily and stored (in this case, behind the couch in our upstairs family room). During the course of a couple of years, the various games were played by my kids, and myself as well, but then, like many things, the pads were tucked behind the couch and sat there for years. the games were tucked away into the PlayStation 2 games drawer, kept for a later date and time (I believe in the replayability of games, so I tend to hold onto titles for years, because I enjoy revisiting older titles to play them again after a long absence). In November of 2015, DDR and the RedOctane pads made their emergence from behind the couch and from within the storage bins, and returned to center stage in my reality.

DDR has a workout mode on each of the games. What's nice about the workout mode is that you can set a number of parameters. By entering in your weight, preferred step settings, and calorie targets, you can customized a workout that can be as short or long as you need to meet your goal. I've experimented with a variety of the settings, with the goal of hitting 1000 calories. Averaged out, it turns out that 1000 calories is about an hour and forty minutes of "dancing", which really is more stepping on arrows in time. Another benefit of workout mode is that you can turn off the "typical game behavior of "failing when you don't hit the steps well. It's a great feature for game play, but a lousy feature when you want to keep going regardless of steps and score (and believe me, after close to ten years, my step accuracy at standard mode and higher leaves a lot to be desired ;) ). Another nice benefit of having this as a workout option is that it allows me to combine workout goals and step goals. Instead of trying to walk 10,000 steps, on certain days I can "dance" those steps, or at least a fair number of them. this does tend to make calorie counting and averaging a little challenging, but I'm not stressing over it too much. If I'm able to burn 1,000 calories by playing, that's plenty for just about any given day.

As of this morning, I am holding at 214.8 pounds, or just over 45 pounds down from 260 when I started this whole thing August 14, 2015. Variety is the spice of life, and today, I am thankful for an old amusement for coming to the rescue and offering me a bit more variety to add to my activity mix. Though I can't guarantee 1,000 calorie burns every day, every little bit helps, so here's to keeping on :).

Integral Quality - Live at #AgileTD

Wow, we are at the closing keynote. Didn't I just get here? Seriously, I know it's Thursday afternoon, but time has sort of lost its meaning to me these past few days. Nevertheless, we are at the final keynote talk, and Olaf Lewitz will be closing out Agile Testing Days.

Have we considered the ways that amazing things get created? Is it all an obvious need that just gets met, or does it happen because we notice something, and then we push forward because we believe in the cause and delivering something to meet a need. I think truly great initiatives start from the latter, and many times, I think serendipity has a lot to do with it as well.

Too often, I think we look at what others do, but we don't turn that lens on ourselves. rather than "what can the organization do to be successful, with me coming along for the ride" perhaps a better question is "what can I do to make this organization amazing?"

Olaf asked us to say what we are grateful for through this conference. It would be too messy to do this in person, but there is something I can do, and I'll do it here :) :

Thank you, Madeleine Greip, and the Agile Testing Days organizers, for inviting me to speak at this wonderful event.

Thank you, Meike Mersche, for being a wonderful tour guide, showing me around Potsdam, and buying me Red Bull Cola, as well as being a bright and happy face to see every morning.

Thank you to each and every person who attended my talk, gave positive feedback, retweeted or wrote about what I said (especially Kim Knüp, who dedicated a full blog post of her own to my talk).

Thank you, all speakers, for your time and your talent and energy. You've given me so much to write about these past few days.

Thank you, Albert Gareev, for being my partner in crime and asking me to make 2015 a year of Accessibility, and challenging me to make it the primary focus of what I wrote and spoke about for the year. I have learned a lot because of that, and I think there's so much more we can do :).

Thanks to the readers of TESTHEAD, for being willing to follow along with me when I go on these mad dashes at conferences and posting a dozen or two posts in just a few days.

One of the interesting comments Olaf shared was the idea that, if we remember back to The Matrix, there's a metaphor of a blue pill and a red pill. Blue pill means ignorance and just going with the flow. Red pill means waking up and seeing things as they really are, good and bad. Interestingly, when we have the ability to make choices, we tend to be solidly on the side of the option that gives us choice, and specifically those options that we genuinely understand what is happening.

"Options have value. Options expire. Never commit early unless you know why."

Quality is, frankly, a bizarre thing. It's not elegant and clean. In fact, quality is messy, nebulous, and wholly subjective. Jerry Weinberg's statement of quality is "quality is value to some person". With the number of persons out there, there are just as many definitions of quality as there are people to perceive it. Therefore, the first person who has to decide that quality is sufficient is me. Point blank, would I want to use the software I am testing? If so, why? If not, why not? If I have a steady litany of why not's, then I have a duty and obligation to voice those concerns, even if I may be the only person who recognizes them as such. In short, I have to know what I want first. From there, I need to know what the organization wants, and then I need to know what my customers want (and by that, I mean what all my customers want).

Human organizations have had several revolutions. First was the Tribal Revolution, followed by the Agrarian Revolution, then the Industrial Revolution, and currently the Information Revolution. If James Burke is right, we are in a period of transition, where what was once known and owned by an elite few, will be available to everyone. The bigger question is... what's next? What's the next big revolution? What will the new paradigm be when it comes? How will we fit in it (assuming it happens in our lifetimes)? We have a chance to shape that new future, and we have the opportunity to start with ourselves and our organizations. If we want to see change and better quality. Let's start with ourselves, and take it from there.

Testing my Biases - Live from #AgileTD

Oana Juncu makes a straightforward statement right out the gate... We make decisions based on our invalidated assumptions that we take for granted facts. Life may be better if we become aware of this.

Every one of us has biases that we use to create a short-hand for our world view and thinking.  Most people are unaware of this, and they feel as though they are being very rational and analytical, when in truth they are reacting via a system that has been honed over eons of time. The fact is, we all cope day by day by making assumptions. We make decisions based on our assumptions that we take for reality. We act on a survival instinct. We can make very quick decisions and we can seem very forceful and decisive, but in fact,  we are often behaving in ways that are wholly irrational.

Each of us has had an experience where we have convinced ourself of a reality, only to be given new information that opens up our view, and when we see the new "reality" we cannot unsee it.

Cognitive dissonance is what happens when we have an experience where an outside "reality" interferes with our own perceived reality. If we are open to the possibility, it may be very low. It may be much higher if we resist the outside reality. The greater the resistance, the greater the cognitive dissonance.

As testers, we love playing with biases. We try to recognize when they are present, we do our best to de-bias ourselves, and then we feel smugly superior that we have gotten beyond all that. I question that premise, because I think that there are several layers of bias that we need to work through. There's the superficial biases, and then there are those that associate with the core of our beings. Some of these biases are not so easy to set aside. Take belief in a higher power. I have no problem with feeling there is one, regardless of now illogical or irrational it may be. I've had many experiences in my life that have convinced me there is one. For other people, they may have had the exact opposite experience. In a scientific approach, there is a far greater burden of proof on me, in that I cannot prove that there is a higher power. Were I totally rational, I would then say "well, then there isn't one"... and I'm not willing to do that. I understand full well that that is a bias in action, and it is a bias that I can play with, I can consider, but at the end of the day, as it stands right now, I will not put down. Not really. That's how powerful that bias is, and that's why I struggle when I see things that contradict my view, and feel at ease when I see situations that confirm my view.

I sometimes feel smug when I discuss cognitive biases surrounding politics, because it's so easy to see which biases are being applied on both sides (I'm from the USA, so for all practical purposes, there are two (arguably) separate parties with different views of the world). Some people are partisan for one party or another. I've decided to have no affiliation with either, so I can step back and see both the intelligent and ridiculous when it comes to political discourse.  I can see the biases in action, but more important, I am at a point of indifference where I can be dispassionate either way. By having this outlook, I can more readily see the fallacies and biases in action with other people. The more closely I've held a bias, the less likely I will be objective with my observations.

Think of the old television program "Let's Make a Deal". For those who don't remember this old game show, one of the premises was that there was a part of the show where a contestant could pick from three doors (Door #1, Door #2, and Door #3). Two of the doors have goats behind them (iow, no prize). One door has a brand new car behind it. We make a choice, and someone else makes a choice. We see that their choice is wrong. Do we change our decision, or do we hold our place? The Status Quo fallacy tells us to hold on to the value we have, because we have a 50/50 chance at this point, but we will very likely hold onto our original choice, and not change it. Why? Because we've already made a choice, and the surety of our choice is more comforting than making a new choice. The odds are equal either way, but most people will not make a change even though the odds are even that they have made a right or wrong choice.

In the world of finance, we are often affected by the Loss Aversion Bias. What impacts us more, receiving something of X value or losing something of X value. Most people react more strongly to loss then they do to gain. Studies have been done (sorry, don't have them off the top of my head, you'll have to trust me for now ;) ), that it takes an almost double level of gain to negate the feelings of loss. Mathematically, it doesn't make sense, but we value the loss more highly than the gain, or perhaps we more acutely feel the loss than we do the gain.

Imagine that you have a chair in front of you. You are asked to draw the chair. Taking out the relative artistic skill of the people drawing, what might we think the outcome will be? Each of us will draw the chair from a slightly different perspective, depending on where we are sitting, but generally, we will draw a chair, because we know it's a chair. Now, let's imagine that we can somehow lose all perspective of the fact the item we are drawing is a chair. It's a form, we can draw it, but we lose all perspective of the item being a chair... do we end up with something different? Can we separate our view? Do we make something different? Chances are, we make something simpler or abstract; it's just a shape. The strange part of this for me is mentally blocking out a shape that I *know* I am seeing. What's interesting is that, for some, they were able to make a more accurate representation of the chair when they were trying to defocus from what it actually is. Others went with a simpler and more freeform design.

From Reality to Obvious

There are steps and filters that shape what we consider to be obvious. Reality is what exists, regardless of our feelings of it. Obvious filters through our experiences, our fears, our frustrations, and our beliefs. Therefore, what is "obvious" to us may not be obvious to someone else, or at least, not in the same way.

“We don't see the world as it is, we see it as we are”
― Anaïs Nin

If you want to test your biases, here's a process to play with:

- State an hypothesis about how a given product should work to meet a customer’s needs
- Define a set of question to validate/invalidate the hypothesis
- Define metrics in respect to what type of answers received
- Collect facts
- Present results

Does this look a lot like the scientific method? It should, because that's really what it is. If we are applying the scientific method appropriately and honestly, the process behind the scientific method will help us defocus our biases. It may not entirely eliminate them, but it is very likely going to make you aware of them.

Nowhere and Back Again - Live from #AgileTD

Today's middle of the day Keynote is being provided by Thomas Bradford. You have to love a guy that describes himself as "a Certified Software Organization Failure Expert, and has personally witnessed the implosion of dozens of organizations. He is dedicated to creating a world where those organizations don’t drag good people down with them."


Thom worked for PayPal, and was looking for a new opportunity. He was contacted by a friend who was describing a company that needed a lot of help. He declined originally, but ultimately, he gave in and decided "OK, I'll see what I can do to help!" He grilled the company asking what they would be willing to do. They had zero tests, and needed someone willing to come in and help them resolve that. Through some continued conversation (and perhaps a few insults here and there) he said OK, and took the job.

The company's product was a Java monolith. It was a mess, and it had methods that were five hundred lines long. Ultimately, they decided to move away from the monolithic app and convert it to micro-services.  He also suggested they walk away from the app they are developing, moving off of Java and coding a replacement in NodeJS.

Key takeaway:

If someone told you you could be twice as productive at work, what would you say? Would that excite you, or would it actually terrify you? It's not like you are going to get more money, have to work less, or get any real benefit out of it (well, there is equity, if you are lucky). Truth is, most of us who work in tech aren't doing bad, realistically speaking. We tend to be paid pretty well, but we have also inherited a lot of dysfunction because of this need for speed. Agile itself doesn't really fix that. Not by itself. People have to decide to do better because they want to make their lives better and the lives of their customers better. Sometimes that means doing something totally insane, like burning down your original infrastructure and starting over.

Sometimes it is essential that we break free of our comfort zone. When enough people create comfort zones, they create entrenched processes that are often inviolable. They are safe, but they are non-productive, regardless of what the charts and reports say.

The key to the success is being willing to start over, to stop doing things that are useless, and put the value of people over process. If the organization cares about the process over people, you are not in a good place. Sadly, that's probably 80% of companies, but someone has to be brave enough to say "enough".

Test Management Revisited - Live from #AgileTD

Today's theme seems to be BBST remembrance. Selena was one of the participants in my first BBST class, and Anne-Marie Charrett was one of my instructors for that class. In many ways, I've always considered Anne-Marie one of my favorite teachers, and therefore, I tend to make a point of attending any of the talks she presents at any conference I attend. To date I have not been disappointed, and I have no reason to believe today will be any different :).

The Main Statement for Anne-Marie's talk is "Test Management is still vital for large organizations but it needs to be re-invented to be able to work in an agile context".

In my own world, I have been a Lone Tester more times than not, so Test Management was by default my domain. Today, I am part of a small team that has two dedicated testers, one contractor who does automation almost exclusively, and a bunch of side stuff that I do as well. Test management happens, but it's probably a bit more haphazard than I would like.  In that guide, it helps to think about what Test Management actually means. Test Leadership might be a better terminology.

When Anne-Marie started at Tyro Payments, she joined a team that had five testers as the test manager (and then lobbied to be called the test lead). Tyro prided itself on being a very Agile shop in the programming sphere. As you might guess, the testers were *NOT* Agile (sound familiar? yeah, I'm sure it does). This is what happens when testers are treated as a control, but are not perceived as being part of the overall programming flow. The developers were doing lots of automation and also some of their own manual testing, so why did the company need testers again? Anne-Marie came in to help solve this problem.

The first thing that Anne-Marie focused on was creating a culture for the testers to decide who they wanted to be and what they wanted to be perceived to be. the team wanted to be autonomous, responsible, autodidactic, be able to identify an effective test process, and to be courageous. Anne-Marie introduced a lot of coaching, and generally coaching is focused on specific tasks. As a test manager/leader, the coaching works best when a specific task is being performed, and the coach can be there to give 1:1 feedback. Having experienced Anne-Marie's coaching first hand over the years, I can say that this is probably a really cool experience.

This type of opportunity worked well with a smaller team, but as the team grew and developed, there started to be a break down in the effectiveness of the approaches she was using. Doing 1:1 time with a team of ten is rather hard, if not impossible. At this point, Anne-Marie decided that they needed to look at an alternative to the approach they were using. One of the key decisions they made was to delegate a lot of the traditional test management responsibilities to the rest of the team. They created a Trello board and asked everyone to take over key areas like hiring, training, retros, reporting, etc. so that Anne-Marie could focus her attention on the area she was best suited for, which was coaching and mentoring. She also allowed the decision making to be delivered down to the teams, so that she didn't have to make all the decisions. This worked until the team got larger once again. Delegating the tasks was a help, but now with fifteen testers, the coaching was becoming rote and check list oriented. How can she get back into the key area she wanted to be to help people get skilled up?

Slack was a lifesaver in the company, even though the company was anti-electronic communication. The test team decided to buck that trend, since the team of testers was becoming more distributed. I completely understand this, as my company lives and dies by Slack ;). The other benefit of a tool like slack is that it captures learnings and sideline conversations that can prove to be very beneficial later on.

A challenge of being a tester is that a lot of the work we do goes unrecognized. If we have worked well on a product that is in good shape, who is going to know what you have done. As Anne-Marie points out, if you don't tell your story, someone else will tell your story for you. Reports will likely not be read, but blog posts have a lot better chance of being read (I can attest to this :) ).

And they grew again, and the system started to break down again. Noticing a pattern here? One challenge of delegating and allowing people to make decisions is the fact that they WILL make decisions, and some of them you WILL not agree with. It's vital that you can be OK with that, or at the least, have a chance to share your thoughts but still be willing to step back and let others make decisions and grow. A cool quote to remember is "when a flower doesn't bloom, you fix the environment in which it grow, not the flower (Alexander Der Heijer).

Infographs were a modification that they started to use rather than create standard status reports, and they were able to visually represent things that were oftentimes hard to describe or demonstrate in other means.

As of today, Tyro has twenty two testers (up from five) and the changes and modifications are consistently coming. They have to keep adapting and changing their approach, and ultimately they want to break down barriers. In short, they have learned how to pivot, and going forward Anne-Marie hopes to look at listening to her organization and better understanding their needs.

Ultimately, testing is a practice, like medicine. It's not up to the doctor to keep you healthy, but they can help you if you decide you have something wrong and need help. keeping healthy is ultimately the person's responsibility, and in an organization, testing is everyone's responsibility as well. Test practices are there to help when help is need, create information and sharing that information. The test team is a brand, and it needs its own sales pitch. It's vital to think about how you and your team is perceived. Doing good work is not enough.

There's a lot of things we can do to make test management effective. Ultimately, that needs to be the primary goal.

Agile Leadership Lessons - Live at #AgileTD

Selena Delesie and I have known each other for about five years. I met Selena as one of my co-participants in the BBST classes, and we have had an ongoing correspondence and bumping into each other at events over the past few years. Selena has focused on being a coach and a consultant. She has a broad range of experiences and a unique presentation style, and I'm excited to see her delivering a keynote today :).

Ask yourself, if you could have dinner with any person alive, who would it be? Why? What do like about them? For me personally, I'd like to hang out with Gerald Weinberg and earn a bit about how he got where he is today. I'd also like to hang out with Larry Winget for awhile because I think he's a hoot and his personality is bigger than life.

Selena emphasized that her "must meet" is Richard Branson, and while she didn't get to meet him directly, she did get to interact with him at an event she was attending. She said that some of what she admires about Richard is his ability to listen deeply. We tend to want to make our views known, and by doing so, stake our claim on our knowledge and experience. More important is being able to listen deeply and learn to understand the challenges people are facing. My expertise doesn't matter if the expertise I have won't help the people I'm conversing with or hoping to lead or help.

How can we improve on collecting information and ideas? In general, the best thing is to just stop and listen to the people we are working with. Ultimately, it's all about the people on your teams that you work with. It's important to realize that, if you are going to be a technical leader for a team, your goal is not to make yourself shine, but to make the entire team shine. As a leader, your goal is to help other people be successful. If that's not your thing, you need to consider a different line of work. Additionally, do all you can to make people smile. When people smile, they open up and amazing things happen.

Who can you improve your relationship with? For me, I think it is important to have a good overview of the business as a whole, so foster relationships with people outside of your immediate team. Build relationships with people who can help you understand what is happening in the entire organization. As you learn what other people in your organization deal with, and what their pain points are, we can help alleviate that pain, or look at our work differently.

Be addicted to learning. Discover what domain knowledge exists in your organization, and be prepared to go where the needs are, rather than just what you want to do. For me, the most pressing need in our organization at a time was to understand the entire build process for our software, and that led to me becoming the release manager for our company. Do i know everything about the process? Hardly, but I have a chance to learn and experiment regularly, and provide basic improvements to the process here and there, and that's made a world of difference in my work reality this past year.

We don't learn by following rules. We learn by experimenting, by doing, and yes, by falling over and getting back up again. It's a challenge to learn new things, especially in areas that are not comfortable to us. It's also important to carve out the time to get good at what we do. Part of that requires us being willing to say "how may I be of service to you?" It's not enough to just show up and do things for our benefit alone, we need to be wiling to be of service to each other and our organizations.

Another question to consider is "what problem are we helping to solve?" One member of the audience said "harnessing all of the brainpower of the organization". Another said "to get a better shared understanding of the software we are developing". Another said "hiring more team members". For me, it's "making sense of the infrastructure and feature needs to help identify the real critical issues that our customers need".

Agile means being adaptable and flexible, and yet we still find that old habits die hard. We may think our teams are agile, but in many ways, there is a lot of tradition and process to overcome, and many of the methods we use are often counter-productive. Remember that change is a given, but how you respond is a choice. Don't be afraid of adapting and trying something different.

 

Early Morning Pub Chats - Live from Agile#TD

Day three. Lots of conferring, lots of fun, way too little sleep (LOL!).

It’s always a challenge going to these events because my body fights the local time. It’s frustrating to realize that it’s two AM local while your body still thinks it’s 5 pm at home, and regardless of what your body thinks time is, 6 a.m. local time will arrive and it doesn’t matter what your time back home is, you have to get up and go.

This is the third Lean Coffee of the conference, and will sadly be the last. I enjoy thee gatherings because we have a totally impromptu discussion on topics I might not have considered asking about, but I learn new things each time.

Target Coverage and How to Get There:

What do we do when we have a long term team that seems to work everything out of their heads? The challenge is when we are trying to get a baseline understanding of the coverage that is being applied. How much testing is actually being done? Do we know? can we figure that out? How do we implement an approach that lets us see what is being covered? There are a variety of Code Coverage tools out there, but that helps if the people doing the primary testing and the code optimization are the same people.

However, in the case of the person presenting their dilemma, those are not the same teams. They are automating acceptance tests as they are creating them, but their legacy system doesn’t have much in this regard. the trick is that coverage is often hard to quantify. If the idea is statement coverage, that’s easier to get a handle on since unit tests can give you statement coverage, but test coverage is a bit more nebulous, since there are so many potential permutations. Using an API testing approach can help to fill in the blanks here. Buy setting up tests that utilize the service layer, many of the business rules can be automated or exercised through the API rather than trying to use the UI for this. visualizing coverage (drawing diagrams of the workflows) can help to make the visibility of areas to test more clear.

Coaching Developers to Test Earlier:

With the idea that Agile encourages testing being an activity rather than a role, many developers are getting into the role of doing testing as well as writing code.

Kim mentioned that there has been a challenge in her organization with trying to help the developers get into the habit of testing. From my own experience, there needs to be buy in from the programmers to ensure that testing is happening with the programmers. There's a benefit to asking the programmers to share their unit tests with you, the tester. By asking about the unit tests, and saying that we need to see what is happening so we understand better what is being covered, it sends a clear message.

Also, in our organization, no story is considered done if there are no unit tests or integration tests written by the programmers, so that helps make sure that unit and integration testing are done. For many programmers, they consider that "enough", but there's a lot more we can encourage them to do to test as well as having us do explorations and cover other areas. It's really helpful to communicate that we are trying to not be a bottleneck, so having the group work together to cover testing needs and to spread out the testing effort among the whole team helps encourage that philosophy. Some programmers will be resistant, but if the cultural expectation is that everyone tests, then we can get everyone else involved easier.

Distributed  Testing and Team Integrity:

A challenge with teams that are distributed is that many people fall through the cracks and the sense of team unity disintegrates. When testing gets spread among a number of groups, and people are assigned to different groups for differing periods, there's a struggle to get everyone to share what they are doing, specifically domain knowledge. The idea of sharing ideas and developing a "community of practice" can help here.

Having a rotating book club, or getting the testers together to say "what are you all working on, and would you be willing to give a quick summary of something you are learning?" Lean Coffee is actually a great mechanism for this. It can be a challenge to have teams that report to different managers, so it may be helpful to get the managers on board with the community of practice concept. The key is that there needs to be  real knowledge exchange, not just another status meeting to have to sit through.

What's New in Agile Testing?:

The area of DevOps and Continuous Delivery is an interesting avenue that is becoming more prominent. Containerization is a hot topic, and the tools discussion are able to become a runaway train very quickly. there's always something new and shiny to get involved with, but the principles of testing in an Agile context are still pretty consistent. The real newness is the experiences that people are bringing to it. Agile itself is not exactly "new". It's fifteen years old now, which in technical terms is fairly ancient. For each organization, though Agile may be brand new to them, and there's lots of opportunities to go in and have a broad range of experiences. Tools come and go, and what's the new hotness one year may be old hat the next, but each organization gets the ability to try those things as they mature and determine what matters to them.

Sad to realize I won't be doing this tomorrow morning, but fun to realize I have lots to ponder and consider when I get back together with my team. Thanks for following along, day three proper is about to get underway.

We're all Searching - Live from #AgileTD

One of the interesting things about being a member of the “Twitterati” is that a lot of people can get to know you and what you represent, and they can get a good idea of who you are and what you look like. Mike Sutton spotted me from about 20 yards and yelled out “hey, it’s Michael Larsen, the TESTHEAD! Good to see you!” When I noticed it was Mike, I gave him a big hug, and we chatted for a bit. It was an awesome experience of two people who knew each other but never met knowing enough about each other to be fast friends in person.

Mike started his talk from the premise of asking “How much do you really care about your organization? Do you really care enough to test beyond the basics of your product? Are you willing to really go down the rabbit hole?"

Can you say that your work has an enormous impact on your personal growth and joy? If so, that’s awesome. If not, why not? Do you have the power to shape your work so that it can bring you joy? Mike’s not trying to make this sounds like some twinkly stardust idea, he’s saying that we put so much of our life energy into our work, we should do all we can to make it be something that brings us joy and purpose. If what we do is making us miserable, we should do what we can to either find joy in it, or break free and find a place where we can experience joy.

Mike’s core point of his talk is searching. Growth is challenging, it can be painful, and it can be frightening. but growth is what brings us new experiences, and new experiences can bring joy if they are positive. Companies do the same thing. They make be searching for revenue, for people, for markets, and each level of growth makes the search that much more intense.  If everyone is searching, and everyone is, what does that mean about what we are searching for? What does this search impact? In short, what do we care about, and how far are we willing to go to follow through on our search?

To be frank, most of the time, when we make a business decision, we are effectively making a guess. It may be a really well educated guess, but ultimately, it’s still a guess. There’s enough variability in the world that we don’t really know what will happen when we do most things. Chemistry is one thing, emotional economics is something else entirely. Agile teams are ultimately places we can roll with different guesses. We don’t have to take the safe gamble or structure things in a rigid fashion. Agile asks us to experiment, and if we fail, let’s learn quickly from it and regroup. Great in theory, a little more chaotic in practice. Development may be agile, but what about the rest of the organization? Are they harmonious or are they cacophonous (yes, I’m referencing yesterday’s keynote ;) ).

Think about what you are great at. Most testers love exploration. We are curious as cats. We have a passion to collaborate, and ultimately we want to make things better. That’s second nature for our software, but why isn’t it second nature for our organizations? Are we as willing to poke at the holes of our organization? If not, why not? Is it from an informed place, or is it from fear? Are we scared of what might happen if we explore our organization? Do we run the risk of offending others? Possibly, but we might discover something important.

We don’t nee to ask permission, though we may want to make sure we’re not breaking something that could get us arrested. Be OK with the fact that some people will not approve, but if you are willing to test the organization, you may find that you discover something deeply valuable to that organization. Counter intuitive? Maybe. Start asking what value we provide. Why do we exist? Beyond the money we are earning, why does our company exist? What kind of organization do we want to have?  Dare to ask, and let's take on the ultimate testing project. Find out what makes your organization tick, and find the bad points as well as the good points.

Ask questions. See where they lead :).

Designing Inclusively - Time Delayed from #AgileTD

As you might guess, it is not possible to live blog and present at the same time, and the network has been dropping frequently with the number of participants, so I'm a little late getting this one out ;).

My talk was about Accessibility foremost, but I also made some recommendations to consider using Inclusive Design to help the process. With this being an Agile testing conference, it fits well with the idea of moving the testing forward. Rather than trying to shoe-horn Accessibility after the fact, what about designing up front with the idea that you will make your products effective for the broadest number of users as possible. Wouldn't it be great if you didn't have to make special accommodations for that, or have to make multiple paths to make that happen? Inclusive Design makes that possible.

Accessibility deals with the absolutes on the disabled scale. The fact is, an app that is visual will be unusable for a person who cannot see, unless special accommodation is made to allow for interacting with assistive technology. For many of us, we may be able to see, but we may be developing challenges around the clarity of that vision. I fit that model right now. Readers are a part of my reality, whether I like it or not. Anything three feet away from me? Crystal clear. Anything within three feet? I start to lose clarity. Text? Ugh!!! I've gotten to the point where I have to have readers to interact with my phone.

What I've described is what would be considered a secondary, or situational, disability. I'm OK in most cases, but for a particular range of interactions, I need help. I don't need Accessibility level of interaction, but there are some methods of displaying information or controls that would make my life a bit easier if I don't have to dig for my glasses every time I want to look at my phone or my computer.

I highlighted an app I am currently using, and that several people have heard me discuss on my blog in the past couple of months, called LoseIt. It's been a terrific app for counting calories and tracking exercise, and it's helped me meet a key goal, that of losing weight and getting into better physical shape. Additionally, I appreciate the decisions that LoseIt has made, intentional or not, to make many parts of their app usable by a broad group of people, even those of us who struggle to read small screens and even smaller type. The main screens are accessible with a side swipe, and the main displays are based on dials, sliders, pie charts and bar graphs. What does this mean? A lot of information can be communicated in that small space without my having to hunt for my glasses. Yes, the areas where I have to interact intensively I still need them, but for a quick glance at overall stats, the displays are such that I can look at them and get feedback that is meaningful even without my glasses on. That's a good example of inclusive design in action. I have no idea if LoseIt did that for that purpose (and truth be told, if they did, they could use some bolder contrast options) but it's appreciated nonetheless.

I had some fun questions after my talk, and a really good point was made by one of the participants, in that she told me she was working with a company that developed games for young children, and that try as they might, they were not able to effectively test the games at a level that was effective for their target audience. She likened this to the limitations of testing with personas for other disabilities, where we can imagine that we understand the issues, we can empathize with the issues, but we can't really be stand-ins for those individuals and the challenges they may have or the development level they are at. I agree completely. At the end of the day, I will likely never be able to listen to a screen reader at the speed that a friend of mine who is sightless can listen to it and make sense of it (literally ten times faster than the default setting). We can be surrogates, but we are ultimately poor surrogates. Our experiences in their shoes can help, but it can't replace the feedback they can give.

In-Famous Plethora of Piñatas - Live From #AgileTD

Oh, come on, did you really think I could attend a workshop based on the Three Amigos Principle and not reference the Chevy Chase, Steve Martin and Martin Short movie? All right with that out the way ;)...

Sure, we all have heard about the principe of the Three Amigos meeting. Many of us may actually participate regularly in those meetings (it's a core part of every story kickoff where I work) but do we really utilize these meetings in the best way? When I saw George Dinwiddie and Stephan Kämper were presenting a workshop on this topic, I had a good feeling that this would be time well spent.

What does the Three Amigos mean to you? In my organization, three amigos are fairly well represented and consistently so. In our organization, we have a programmer, a product owner and a tester. Each kickoff has a review of the story in question, and we look at the story in question to voice questions and concerns. It's a time to talk about basic implementation, but not specifics. It's a time to ask testability questions, and to see what assumptions have been made and what ones haven't been made. After we have all had our say, we consider the story kicked and away we go. That's fairly typical for us. It's worked pretty well, but could we do better?

Though I think we have done a pretty good job articulating the stories and their details, we might be more prone to rubber stamping when we get the same people together too often. I'm not saying this is deliberate or in some way nefarious, but it's a natural by-product of how we work together and get to know how each other works. Occasionally, we can all miss something because we've gotten a little too comfortable with the process.

Several questions to consider when it comes to the Three Amigos approach are as follows:

• What might happen if you have fewer or many more than three participants?
• What is different about the viewpoints of the business, the programmer and the tester?
• What other roles/points of view might be useful, and why?
• What could you do if one of the the roles was not available? What are the dangers to avoid?
• How should decisions be made? Based on merit? Democratic? Other? Why?
• Should the Amigos document something? Why or why not? What? How?

One of the more telling examples we shared was the ability to communicate requirements "blind". In the process of trying to share requirements, three easels were set up, one with a diagram of the requirements (a triangle, a square and a circle that overlapped). The goal was for one of the participants to describe the shapes and their placement, and their ability to communicate the requirements effectively to others. As you might guess, no one had the same image. When all was said and done,  Communicating requirements is hard.

We are on a break at the moment, so more when I get back (this is the first part of a two-parter :) ).

In the second part of the hour, we are looking at a Global Parking example. This is significantly more involved than the simple example we tried before the break. While we worked through and tried to discuss the requirements and semantics of the document, we started considering a broad range of questions. Among them were:

• What was our Shared Understanding?
• Did we use a Common Vocabulary? (short answer: no ;) )
• Could we describe the rational of our decisions?
• What are the "rules" of the system?
• Do we have examples that illustrate those rules?
• What assumptions do we have based on these discussions? Do we have questions that developed by reviewing the document?

It's been interesting to me to see how many of the interactions with my team in similar situations were much smoother because we had a shared set of tacit knowledge. I could imagine our meetings being much more involved if we were to bring someone in cold in one of the roles who had never been part of the process, more so because they don't have the shared history of the team to draw upon. That's a powerful undercurrent, and it should not be underestimated. This exercise took significant time to clarify meaning and make sure we understood each other and our assumptions. I can see in teams that are more in sync with one another that friction being much less. 

One thing that was very helpful is the idea of "Example Mapping", where we too the basis of the story, determined rules of the story requirements and created individual examples that mapped to each of the rules. By doing this, we were able to block out the needs of the app, and some questions that we developed by blocking out the examples and mapping them to the rules. This is a technique I have never used before, or at least not in this manner, and it looks like something that would be tremendously helpful as a preparation for a Three Amigos meeting. As a tester, it could be very helpful to confirm if the rules are essential, or if there are things that are out of scope. If you notice you have a lot of examples, maybe the story is too big. Could you split the story into one story for each rule? How about one story for each example?

This Example mapping is a method of "testing before development", or as Jon Bach once described to me, an example of "provoking requirements". He doesn't mean that he's being deliberately confrontational, but that he is looking to talk out the requirements, and be sure that we understand if the requirements as we think they are presented are understood, as well as communicated.

the last part of the workshop was an example showing how to use Cucumber to automate a test scenario. Though this workshop is not a Cucumber workshop, it's a good follow-through to describe how the process could be used to generate test steps and the automation that could happen based on the requirement requests.

IF I CAN DO IT, SO CAN YOU - Live from #AgileTD

Dr. Sue Black starts off the morning by describing what her life was like before she made a sojourn into developing a technology career. Her life was not one of stable means, she had three small children, a broken marriage, and being a single parent at age twenty-five, with a question of “how am I going to support my children on my own?” From here, she did a degree in computing and started a PhD with three small children (I can’t imagine how she did this, to be honest, but she did :) ). It took her seven years to complete it, but she did, and she focused on reverse engineering and doing research on systems measurement and “ripple effects”.

One of the biggest challenges for Sue when it came to going to conferences was the focus on talking to other people. She really struggled with trying to talk with people, especially since she was one of the few women attending these conferences. this changed when she attended the Women in Technology Conference in Brussels, and she discovered the advent of online networks. She decided she wanted to create a group for Women in Computing, where they could meet online and discuss things.

Sue was also instrumental in an initiative to save Bletchley Park (the scene for Alan Turing and the many code breakers that worked on breaking the Enigma code. For those who have seen “The Imitation Game”, this is where that all happened). Additionally, it was a neat discovery to Sue to realize that most of the participants in the Bletchley Park initiative were women. Sue and her group worked on a oral history project to capture the memories of many of these women that worked on the code breaking project.

Through a social media campaign, she was able to generate and develop interest in Bletchley Park and generate a true grassroots movement to help get people involved, including many prominent people who helped the cause. As it was Twitter that I learned about Bletchley Park and what it meant, I probably have Dr. Black to thank for the fact I received awareness about it :).

Beyomnd Bletchley Park, Dr. Black has also been actively engaged in an effort called "Techmums", which is the idea that children, especially girls, will be more likely to be encouraged to approach technology if their mothers specifically had tech skills and a comfort with technology. Techmums is an outgrowth of that idea, and she is changing lives one family at a time, and I'm hopeful to see how the demographics for these children will change because of this initiative.

What I am taking from this is the fact that many of the great opportunities in our lives come about because of genuine interest, a passion for seeing something happen, and being willing and able to drive that passion. If you have a passion for a topic or cause, it's a good bet you will be able to find others who share in that passion. Opportunities often arise because someone has a genuine drive and desire to see something happen. I have myself sen this in my own reality, and I've been grateful for the opportunities that have come my way because I've shared my own passions and determination to see something happen around my goals and desires.  So yes, I do agree, if we can do it, you can too (my "I can do it" is a bit more modest than Dr. Black's, but the main message is still relevant). Put your passion out there, and don't be surprised if you find many people willing to help you develop and keep momentum going.

Early Morning Enlightenment - Live from #AgileTD

It's another full day ahead for us, including me talking in a couple of hours in the "big room". I'm both excited and anxious, but I'm grateful that I m covering a topic I've been actively engaged in for quite some time, and that I am covering a topic that Albert Gareev and I have been actively working on the better part of a year.

It's been a year of learning and experimenting, and I am hoping the details I am providing about Inclusive Design will prove to be interesting and possibly game changing for some. For obvious reasons, I will not be live blogging my own session today, but I hope to have a recap about the experience a bit later in the day.

After a fun Wild West themed party last night, some die hards are in bright and early to do Lean Coffee once again. It does often astound me how many people show up for these early morning events, especially after a late nights revelry. Work hard, play hard, I guess ;).

The range of topics as always is wide and varied, and based on the top votes, we started out with the topic of "Relevant Test Metrics in Agile". It's frequently a push and pull in the Agile space that we don't over emphasize metrics, but the fact is, measurement happens in organizations. We need some way to determine if we are succeeding or failing, or how long it is taking us to get stories created, tested and out in the wild. One challenge that we have when it comes to working with areas such as TDD, ATDD, BDD, etc., is that the number of bugs is often nebulous. In my own experience, since I work in a Kanban shop, bugs found in the process of development are reworked inside the story. We find a number of things, we fix a lot of things, but the number of "bugs" in most of these cases is zero, because the work is done as the "product" moves down the line. In our world view, bugs are what happen after that feature "ships", whether they be found on our staging server or in production. We definitely keep track of and focus on those, since they are genuine bugs and issues that made their way through testing. For us, this is relevant because it gives us insights on areas that we can provide greater focus during testing. Other organizations look at things like the financial cost to the business for delays or for issues that make it out in the wild. I find that intriguing and wonder how that would work, but it certainly "bottom lines" the approach.

"No UI Tests" looks at the dichotomy of the value of automated UI tests (or supposed lack thereof) and the fact that a lot of tests do have to happen within the UI. Part of the challenge is the fact that, traditionally, UI tests and running them from the front end are more brittle than similar unit tests that look at atomic functions and procedures. Still, the UI is the interface that most users will be using, so those tests still have a value and are important to run. Getting a balance between writing tests that focus on unit testing, integration testing and a few key tests that are built around the UI is important. Having a Page Model approach helps a bit, and there is a definite value to making sure that surface level changes don't introduce problems in the testing and create an undue burden on the test maintainers. Tests that need to be frequently reworked are going to be problematic. Some rework is, of course to be expected.

"Building and Sustaining Internal Communities in Organizations" is another topic that received a lot of votes, and this is going to depend considerably on the size and culture of a company. In my case, the community is relatively small. At present, we have three software testers and nine programmers, so we are pretty solidly integrated. Larger companies I would imagine have a harder time with integrating and talking with one another. One way to encourage this level of discussion was to cover a particular topic, or to do some kind of tester games, and make a way to make it applicable to the broader group. By doing that, they were able to get more of the testers together to share ideas and develop comraderie within the various teams.

"What do you do Against Agile KPI's"... put simply, Key Performance Indicators are going to vary dramatically from company to company. Each organization is going to determine which aspects matter to them, and many organizations look to fish out "metrics" to answer this. Positive, they are values that are objectively measured. negative, metrics are almost never objective. They are filtered through the audience and the people that are interpreting them. A question to ask is "What caused the organization to look to Agile as an approach in the first place? Generally, the goal is to be more efficient and more responsive, to create better software out the gate, but ultimately, the goal for most organizations is to do well, and to keep themselves viable. That means that the Excel needs to line up at the end of this, so it's key that any and all performance indicators ultimately support the organization, and there's really no way to totally escape that.

All right, that's a good start, heading into the main room and getting ready to get day two underway, including my own talk. See you all soon :).

Human Refactoring for Agilists - Live at #AgileTD

If you have spent any time whatsoever with an Agile project, you should be well acquainted with the idea of Refactoring. The simple explanation of Refactoring is to clean up any duplication and remove any waste so that the end result is as sturdy and error free as possible.

That's all well and good, but what in the world is "Human Refactoring"? It's the concept that, the methods we use to clean up and strengthen our code, can also be applied to ourselves. Our diet, exercise and sleep habits can be refactored (and considering the last almost 90 days I've had, boy do I understand this :) ).

We can refactor our brains by encouraging our brains to do new things. Activities that excite or calm the brain can be mutually beneficial. Sleep is a big component to helping us achieve our health objectives. Too little sleep prevents optimal healing (read: refactoring) of our bodies. The food that we eat, the substances we drink, and the air we breathe can be both beneficial and detrimental. Ultimately, it is up to us as to what we consume and in which quantities. To not beat on this too hard, I've come to really appreciate the solid benefits of dropping soda in favor of water, dropping packaged foods in favor of fresh foods, and looking to boost my intake of unique fruit and vegetables each given day. Additionally, I've moved to considering meat as a flavoring, rather than as a primary item at the center of my meals. The net result is a 45 pound drop in 90 days, with a goal to lose another 30 in the next 90 days.

Exercise can be very basic, and it doesn't take a lot to make small changes, but if you want or need to make radical changes, then you will need to put in a significant amount of time in addition to reducing calories to reach your goals. It may well be unpleasant, but it is bearable, and if you take time to get to your goals, and make small changes each day, then reaching that optimal burn rate will be possible. It will take time regardless, and dramatic changes will require dramatic effort, at least at first. I've found ten thousand steps a day to be effective, and I've also added a goal to eat 225 calories of fresh fruit every day, with 200 calories coming from fresh vegetables every day. The fruit calories are pretty easy to meet. The vegetable calories are a bit harder, but still doable with planning and paying attention.

Think about the environment you live and work in. Think of your desk. Think of your chair. think of your mental environment and your co-workers and their attitudes. Can they affect you? Answer is, certainly.

Something to consider it the idea of 'The Mental Limit". People need to believe that it is possible. the sub four minute mile was a barrier for a long time, but it quickly was surpassed after Roger Bannister became the first to break that limit.

Bottom line is, we have the skills and tools to refactor code, so let's also use those skills to help refactor our selves; our minds, our bodies, our spirits, our well being. You name it, you can refactor it.

Scaling QA With Docker, Jenkins and Mesos - Live from #AgileTD

Adé Mochtar & Maarten van den Ende put together a workshop based around the idea that we don't have to spend so much time manually setting up Selenium Grids. What's more, each of us were given a USB stick with the files and exercises to work with. The goal of the sessions is to be able to set up scalable and solid Selenium Grids, as well as writing maintainable and scalable Selenium / WebDriver tests.

At the moment, we have been setting up our environments so that we can load the environment and get it up and running. If you haven't seen much of me the past hour, well, that's why ;).

There are a bunch of components that are part of this package, including vagrant, selenium, selenium grid, jenkins, docker, a few virtualbox machines and scheduler called Mesos. For this process of scaling Selenium Grid, even in this small example, Mesos gives the flexibility that will allow as many CPUs and RAM that you can throw at the system. In our example, the CPU's are limited to the number of virtual machines we have created and are spinning up.

One additional cool aspect of Mesos is that it's a generic scheduler. It can be used to schedule anything, so any test and configuration can be run using it.

Very interesting model, I've just barely scratched the surface, but I am curious to play with it some more, seeing as I have it set up and all that :).

Wait, I'm Dying?! - Live from #AgileTD

The talk is a little misleading by the title. The talk is called "Testers Are Dying" and my first reaction was "OK, joy, another 'testing is dead' talk" but no, not really. The real issue is not that testing is going away, we actually need to keep up with the demand for testing.

But wait, how is there an increase of testing demand while we are seeing the role of traditional testing disappear?  What gives?

Karen Greaves and Sam Laing are both with Growing Agile, a company located in South Africa. South Africa has a unique problem when it comes to electricity. They have significant power shortages and rolling blackouts. Thus South Africa has had to be creative when it comes to conservation of electricity.

The fact is a number of companies have taken  steps to either eliminate or greatly reduce the headcount of their test teams. Yet there's more testing needed than ever. Again, what gives?

In many ways, we are dealing with a situation where multiple people are focused on a need for testing, but we have a shortage of people that need to use it. Going forward, the chances are the dedicated role will continue to see attrition, while the actual efforts and needs for them will increase.


The challenge that I see is that there is a dis-connect happening between the need for good testing and the questioning of the value of dedicated testers. If the issue is that the testers are seen as being of limited value, then there are two possible courses of action. Remove the testers (generally a bad idea) or improve the quality and understanding of the testing being performed, and extending the value of that testing to more and more people. Paradoxically, the more people are involved in the testing activities, the more likely dedicated testers will be retained, because the value of their efforts and what they bring to the table becomes clearer the more people actually test (shocking, isn't it ;)?).

Additionally, skills increases can help to make it possible for testers to leverage their skills. If the challenge is too many testers but, not enough testing, then having software testers that are very good at testing being able to spread the skills they have around, and encourage/effect the other members of their team will be a net positive. On the whole, many software testers are not so much dead weight but radically underutilized, or utilized in a very poor way. By having testers get involved earlier in the process, and having testing performed by as many people as possible, the visibility of testing improves, and an understanding of what testing actually is grows.

Automation in Testing - Live at #AgileTD

Richard Bradshaw is a name a few of you out there are probably familiar with. Test Automation and Richard tend to go hand in hand, and Richard opens his talk saying that that might be a bit of a problem, and that he wanted to break free of that way of thinking.

In this talk, Richard is keen to look at the idea that "checks" are more accurate a phrase as in regards to automation. The bigger question to ask is "what does it mean when we perform test automation"? Are we "automating tests", or are we "automating checks"? What does the computer actually do for us? Computers are fast, accurate and stupid. Humans are slow, faulty and brilliant. Together, we can do magnificent things, but we are best suited to doing the things we are best adapted to. Automating is important, it needs to be done, and in many cases, it is a real lifesaver for a harried and overworked test team.

The key point to the whole "testing vs. checking" is that there is a need to use our brains to cover more and more areas. We can't remember it all, and frankly, we don't want to. There are so many steps that we have to keep track of that having a system that can keep everything running in sequence is wonderful. In these cases, I love having automation. It's especially helpful when you know that very step as defined will run the same way every time. The more that I interact with applications and I try to find things that are known issues, the more I find that I end up with a collection of terms and phrases. Each of those terms and phrases are areas I can search for next time. More to that point, commands I run over and over again, save a couple of variable changes, are wonderful areas for creating miniature tool chains (they can be a simple as a single line to parse a log file, or as large as an entire build sequence with a variety of possible conditions.

There are a lot of tools and programming environments out there, and many testers feel frustrated that they don't know how to use these tools. Yet these same "non technical" people do shell manipulations all day long, and many of them are saving those commands in executable files so they can save some keystrokes. These people are the unsung automators. Yes, they are doing automation. They just don't give themselves credit for it because they feel their scripts are not "sophisticated" enough. This is totally OK. This is actually a core part of the journey, and these early steps are key to getting the chops necessary to do more advanced automation.

We have to ask ourselves, why do we test? It's not to run the same things over and over again. Instead, it's to get new information about our product. Automation can help us find new things, but in many cases, it sequences events we know well, and looks for an event we expect to see. In these cases, green tests provide some comfort, but they don't tell us anything genuinely new. Automation will rarely lead us into new vistas, but exploratory testing certainly can. Every initial test we run is exploratory in nature, and as we get a better feel for what we expect to see, then we have space to create automation to cover the steps we know for the paths we have determined are important.

Add Some "Docker" To Your Testing - Live from #AgileTD

I am one of those people. I use Docker. It's part of our infrastructure. I get the basics of containerization. I can start an instance, I can do work in them. That's all well and good, but how much do I know vs. how much do I just think I know? When I saw a session titled "Using Docker for Testing", I figured now was as good a time as any to see how much I actually knew about Docker and whether or not I could pick up some new things (the answer, to save you all some suspense, is "of course" ;) ).

first off, what is Docker specifically? Docker is one of a number of "container" technologies available. Containers allow you to package an application, with all of its dependencies, into a standardized unit for software development and testing. What that ultimately means is that a container is able to load an environment, and it should run the same way each time. the nice thing is that you don't necessarily need to know the machine internals to be able to share an app with others.

One of the nice implementations of Docker and a very helpful one in my work is that we use Docker to containerize our testing environments for automated tests, as well as our development environments and our customer appliances. The beauty of this is that we can create a variety of parallel machines, and we can run tests in a number of containers that can be set up rapidly and destroyed as soon as we finish. Instead of building machines from the ground up each time, we can open as many Docker hosts as we need, which helps make our tests run faster.

The tricky stuff starts to happen when we want to run multiple test runs, or with multiple different release versions, or some variety of tests that require a variety of machines. Here's where having a variety of docker containers help provide interchangeability.  Jenkins provides a variety of Docker plugins that allow the user to be able to create new containers and destroy them after jobs are completed. Additionally, the containers can be created completely independent from any other job, and can be used with any slave, or can be called uniquely/individually.

One of the interesting approaches that can be used is to create a container that has Selenium, the app you want to test, and the configuration options so that the tests are run with the browser you intend to target. All of it is in the respective containers. One of the options for running across multiple hosts is a tool called Kubernetes. Kubernetes starts multiple nodes which in turn allocate container to nodes. It's an interesting paradigm, and worth looking into.

"Muse"-ing on the state of Agile - Live from #AgileTD

Agile Testing Days is celebrating it’s biggest year yet. The total number of attendees at this event are numbering over 600. additionally, they have announced a variety of new conference dates in different locations in Europe for 2016, as well as an Agile Testing Days event scheduled for the U.S. in 2017.

One of the things that Agile Testing Days does is they give a “sponsors rapid fire round” so that the people who are sponsoring the event and are in the expo area get a chance to share their products and what they are offering. This gives the attendees a chance to hear what they are doing and offering, as well as to give them a few moments to “sell the crows” without doing so during the sessions themselves.

An additional fun element of this event is a Wild West theme. Contrary to popular belief, the "Wild West" goes well beyond the mid-west and western part of the United States. It also includes Canada, Mexico and South America for good measure (which makes sense, because as far as Europe is concerned, the entire "New World" counted as the Wild West, with lots of opportunities and new horizons to learn about).  Lisa Crispin and Janet Grogory did a fun little session to help encourage everyone to get the most out of the conference, and dressing like prospectors helped get that point across.

Alex Schladebek and Huib Schoots handled the first keynote with "Where Words Fail, Music Speaks...", and it's not common to see a violin and a trombone as an opening remarks, but yet, here we are :). With renditions of music from "Star Wars", they explained how they learned how to play and why music is important to the discussion of software testing. Music is everywhere, it invokes emotions and passions, and it also helps inform about who and what we are. Therefore, the goal of the talk is to show how music can help inform and develop an appreciation for software testing and agile software development.  One of the interesting things about music is that you get instant feedback. If a note is clean, you hear it. If a note is not clean... you hear it :). Music and learning have similarities. You get feedback, you reduce the complexity to practice, you learn the fundamentals, and then through muscle memory and practice you get a better feel for what you are doing. Also, in music, you don't practice what you are doing front to back, generally you practice different areas, and some things require more time and energy than others.

They played two examples of music. One song was the theme to James Bond, and another was "The Wild Asparagus". Almost everyone knows the tune to the James Bond theme, but not everyone is as familiar with the second song, so the mental image of the music had a much broader interpretation and "mental image".

Agile teams also have ways of interpreting their themes and their performances. As there are more performers, there is a greater need for coordination and focus, more so than a single performer will require. Additionally, different groupings will require different levels of formality. A session is more free form and open, while an Orchestra is more scripted and focused. Sessions have a structure, and a heuristic we can use is called STAR (Structured, Tune, Accompaniment, Rhythm). All of these are emphasized in different levels, but each performer needs to be aware of what they are doing and how they are doing it. Testers also have a variety of heuristics they can use.

Music also has what are called "cadences". There are definite cadences, or full cadences, that come to a conclusion and a sense of completion. and there are incomplete cadences, often min minor keys, that seem like they are going to end, but don't really, if they do, they "feel incomplete". testing has its own set of cadences as well, and if you are focused, you can tell when testing has reached a full or half cadence, or if it feels complete or not.

Exploratory testing has a correlation to music as well. if you follow the sheet music precisely, then you are following a defined script. By contrast, if you perform without sheet music, and play it by memory, you will likely vary and embellish the song. in short, you will not play it exactly the same way, and the more musicians you add, the odds of variation increase exponentially.

Music also contains certain patterns. If you know the patterns, then it is easier to improvise. By improvising, there's a greater chance you can vary your performance and your ability to adapt to different situations. As your team learns and grows, you will also get the ability to recognize patterns in applications, and how to interact and react as you are testing.

Nicely done, Alex and Huib :)!!!