Now that the program announcements have been made, I can actually talk more about this. In November 2013, I will be attending my first ever International Conference as a speaker. Technically, since I went to POST in Calgary in 2012 as a facilitator, and did deliver a talk on Weekend Testing, I guess that counts as International, but somehow I don't see Canada or Mexico as being international. Maybe its just me ;).
So what's the event? I'll be speaking at Øredev 2013, which will be held in Malmo, Sweden. What makes this additionally exciting is the fact that I will be a very short distance from Copenhagen, Denmark, which is where a branch of my family (and my last name) comes from. Will I be trying to arrange a day or two so I can play the sight seer in Copenhagen? Oh yes, bet on it!
Back to Øredev... I've been asked to speak on two topics, so I'll be presenting two sessions:
First, for those who have seen my Emerging Topics talk at CAST 2012 about Balancing ATDD, GUI Automation and Exploratory Testing, that talk has been expanded and will be given an actual case study to explore.
Second, as the conference is using "Year of The Arts" as its theme, I will be presenting a talk on shaking up the way we learn and practice our respective crafts. "Let's Stop Faking It" is going to focus on things and initiatives that I've been part of and strive to continually do so that I can get beyond just copying others work and internalizing as much of what I do as possible.
Now comes the fun part, crafting these into coherent presentations. Scared? A little. Excited? A lot!
Friday, May 31, 2013
Thursday, May 30, 2013
Because Sometimes, the First Time Just Isn't Right
A couple of days ago, I mentioned that I started working on some bead-work for my daughters scalp feathers. I got it started, and along the way, as it was taking shape, I liked it a lot, and then I noticed it was rather "bulky". More than bulky, it didn't seem to be fitting snugly against the leather wrapping. I'd used too many beads to get it started, so the rest of the way, it just made for a thick and bulky cylinder of beads.
I could have done a number of things, but I decided the best thing to do was to just twist the beads, break the anchor thread, slide them off, and start again. The cool thing is that the cylinder I've already made is free standing and sturdy, I can use it on something else, but I want to have these feathers look good for my girl, so starting over again really isn't a big issue. Just re-thread, count the beads all the way around, divide by three, and make sure we are snug at the start.
Too often, we find ourselves doing things, and we realize they are taking a lot of time. Sometimes, because of the time it is taking we either don't realize when we have made a mistake, or we try to do something, anything, to recover. Why? Because we've invested so much time already. Yep I put in two hours on these beads, so my first inclination was to figure out some way, any way, to not have to start over. The problem is that all of the imperfections and issues would be compounded the farther along I went. it's a sunk cost fallacy. I may lament that I spent all that time, but the truth is, I can't get that time back anyway. It's already been spent. Rather than take it as an opportunity to rush through and complete something in a less than satisfactory manner, I undid it and I started again. I failed fairly fast, and that made me less reluctant to just say "let's kill this and start over".
Sometimes in our testing we can get a bit too "dogmatic". We want to follow our procedures and our methods because we have worked a long time to perfect them. It can be frustrating to realize that, for a particular job, our pet method may not actually be the best choice. The lesson isn't to dig in our heels and make it work, it's to consider what we could do instead that would be a better and more natural fit. This is why I like the idea of not having rules, but having heuristics. Rules are often iron clad, and they are hard to break (at least mentally and emotionally so). Heuristics I have no such issues with. If a heuristic doesn't prove to be working out, there are several others I can use. There's a difference between doing things right, and doing the right things. Sometimes one counts more than the other. Experience is what guides us to the ability to make those determinations.
I could have done a number of things, but I decided the best thing to do was to just twist the beads, break the anchor thread, slide them off, and start again. The cool thing is that the cylinder I've already made is free standing and sturdy, I can use it on something else, but I want to have these feathers look good for my girl, so starting over again really isn't a big issue. Just re-thread, count the beads all the way around, divide by three, and make sure we are snug at the start.
Too often, we find ourselves doing things, and we realize they are taking a lot of time. Sometimes, because of the time it is taking we either don't realize when we have made a mistake, or we try to do something, anything, to recover. Why? Because we've invested so much time already. Yep I put in two hours on these beads, so my first inclination was to figure out some way, any way, to not have to start over. The problem is that all of the imperfections and issues would be compounded the farther along I went. it's a sunk cost fallacy. I may lament that I spent all that time, but the truth is, I can't get that time back anyway. It's already been spent. Rather than take it as an opportunity to rush through and complete something in a less than satisfactory manner, I undid it and I started again. I failed fairly fast, and that made me less reluctant to just say "let's kill this and start over".
Sometimes in our testing we can get a bit too "dogmatic". We want to follow our procedures and our methods because we have worked a long time to perfect them. It can be frustrating to realize that, for a particular job, our pet method may not actually be the best choice. The lesson isn't to dig in our heels and make it work, it's to consider what we could do instead that would be a better and more natural fit. This is why I like the idea of not having rules, but having heuristics. Rules are often iron clad, and they are hard to break (at least mentally and emotionally so). Heuristics I have no such issues with. If a heuristic doesn't prove to be working out, there are several others I can use. There's a difference between doing things right, and doing the right things. Sometimes one counts more than the other. Experience is what guides us to the ability to make those determinations.
Wednesday, May 29, 2013
The Power of "Right Now"
It's not often that we have the luxury of choosing exactly what we want to work on right at the moment we want to do something. More times than not, we have to deal with the situations that pop up at the time that they do. The Urgent often takes precedence over the Important. Some times the Urgent is Important, but very often, it's not. The danger is that the things that we want to be doing or think we should be doing take a back seat to the things that someone else has told us we need to be doing.
Case in point... this past weekend, my daughters and I went down to participate in a Pow Wow event in Newhall, California. This is the annual Spring Witayapi, put on by the California Indian Hobbyist Association (CIHA). Me and my girls are avid participants, and each time we go down, we get inspired by outfits or accessories, make commitments to come home and do something about them... and then they go on the pile of "someday maybe", while the hustle and bustle of real life takes over once again and we deal with the urgent things, while hoping to someday get time to do the fun or interesting things.
This time, I tried something different. I decided i wanted to do something relatively small for my youngest girl, and that was to make some new hair feathers for her. She found a pair of really cool pheasant feathers that our friend Paul Birmingham brought with him from his ranch up in Oakdale, California (Paul is very active in the Pow Wow scene and runs the Wakeda Trading Post). My daughter had an idea what she wanted to have made. She wanted two feathers that she could attach to her braids at the crown of her head. She wanted the two feathers grouped into a cylinder. She wanted a loop to attach the feathers to her hair. Finally, she wanted to have the cylinder wrapped with different colored seed beads. To do this, we would use a "peyote cylinder stitch" technique.
The feather grouping? Easy. The leather cylinder? Also easy. That part we could do in five minutes and then let the glue dry. The beading? Ah, now there's the rub. That takes time. It also takes patience and an eye towards a clever design. Typically, here is where the story would end. I'd make a comment that I will work on it when I have some time... and that time would never come. On Monday, though, I made a different commitment. I unpacked the car, put away our camping gear and our dance clothes, said hello to my wife and son after so many days away, got caught up on the details of the weekend while we were away, and then I broke out the bead box, my needles, my thread and the feathers, and I started beading. I gave myself a simple goal. One hour. No more. Just to see how far I would get. truth is, I got five rows of beads done in an hour. Not very fast, but it was a start. At the end of the hour, I put the box away, and made a commitment that as soon as I got home the next day, I'd put in another hour. this time, I got further along, about fifteen rows. I also got into a rhythm where what seemed impossible to start or get traction previously started flowing smoothly and took shape fairly quickly.
Historically, Native Americans used the winter months to do many of these artwork pieces, because there were long periods where, because of inclement weather, they couldn't do other things. It's been said that this process of making beaded items, among other crafts, was "medicine", not in the way we use the term for pills and pharmaceuticals, but in that it was a meditative period, one where we could focus on a specific goal or task, and the repetitive process of it allowed our mind to go where it would go. I experienced that quite a bit in these couple of hours, and I must admit, it felt quite good. A friend of mine told me that he used this one hour a day approach to make an entire set of beaded gear for a grass dance outfit one year. When he looked at the requirements, and how much time it would take, he quickly grew disheartened, but then he decided that he'd spend one hour every day, rain or shine, commitment or not. If he absolutely could not do it on a day because he was away or otherwise it would be impossible, he would "bank hours", but always in advance. If he knew he would be gone for several days, he would double up the hours in the front so that he could take the time away as needed. He never let himself count on his "future self" to make up the difference.
At the end of the year, he had completed a beautiful set of precision beaded pieces (choker, neck drop, harness, arm bands, gauntlets, side tabs and head band. He said there was roughly 380 hours all told in the work he had done, nine and a half weeks worth of working "9 to 5". In reality, though, he said he hardly felt it, since he was able to spend an hour each day working on it. When I asked him what he felt made for it being a successful project, his answer was that he made a commitment, right then and there, to get started, and that set the stage for the rest of the project.
How often do we say "I'll work on that when I have time" or "I'll read that article later" or "I'll install that tool when I get a few moments". If you're anything like me, you say it a lot. I'm also willing to be that, often, that later moment never comes. While we do not always have the opportunity to act on something immediately, I challenge everyone to pick something (anything, really) that they have been putting off and making a commitment, right then and there, to start it, partition an hour a day to do it, and then do everything in your power to get it done. It may have to wait for lunch, or it may have to happen on the train ride home, or in the car, or at the dinner table, but somewhere, and some way, pick something you've been meaning to start, but just haven't had the time. Make the time, and get started. You may surprise yourself on how much you can do when you dive right into it.
Case in point... this past weekend, my daughters and I went down to participate in a Pow Wow event in Newhall, California. This is the annual Spring Witayapi, put on by the California Indian Hobbyist Association (CIHA). Me and my girls are avid participants, and each time we go down, we get inspired by outfits or accessories, make commitments to come home and do something about them... and then they go on the pile of "someday maybe", while the hustle and bustle of real life takes over once again and we deal with the urgent things, while hoping to someday get time to do the fun or interesting things.
This time, I tried something different. I decided i wanted to do something relatively small for my youngest girl, and that was to make some new hair feathers for her. She found a pair of really cool pheasant feathers that our friend Paul Birmingham brought with him from his ranch up in Oakdale, California (Paul is very active in the Pow Wow scene and runs the Wakeda Trading Post). My daughter had an idea what she wanted to have made. She wanted two feathers that she could attach to her braids at the crown of her head. She wanted the two feathers grouped into a cylinder. She wanted a loop to attach the feathers to her hair. Finally, she wanted to have the cylinder wrapped with different colored seed beads. To do this, we would use a "peyote cylinder stitch" technique.
The feather grouping? Easy. The leather cylinder? Also easy. That part we could do in five minutes and then let the glue dry. The beading? Ah, now there's the rub. That takes time. It also takes patience and an eye towards a clever design. Typically, here is where the story would end. I'd make a comment that I will work on it when I have some time... and that time would never come. On Monday, though, I made a different commitment. I unpacked the car, put away our camping gear and our dance clothes, said hello to my wife and son after so many days away, got caught up on the details of the weekend while we were away, and then I broke out the bead box, my needles, my thread and the feathers, and I started beading. I gave myself a simple goal. One hour. No more. Just to see how far I would get. truth is, I got five rows of beads done in an hour. Not very fast, but it was a start. At the end of the hour, I put the box away, and made a commitment that as soon as I got home the next day, I'd put in another hour. this time, I got further along, about fifteen rows. I also got into a rhythm where what seemed impossible to start or get traction previously started flowing smoothly and took shape fairly quickly.
Historically, Native Americans used the winter months to do many of these artwork pieces, because there were long periods where, because of inclement weather, they couldn't do other things. It's been said that this process of making beaded items, among other crafts, was "medicine", not in the way we use the term for pills and pharmaceuticals, but in that it was a meditative period, one where we could focus on a specific goal or task, and the repetitive process of it allowed our mind to go where it would go. I experienced that quite a bit in these couple of hours, and I must admit, it felt quite good. A friend of mine told me that he used this one hour a day approach to make an entire set of beaded gear for a grass dance outfit one year. When he looked at the requirements, and how much time it would take, he quickly grew disheartened, but then he decided that he'd spend one hour every day, rain or shine, commitment or not. If he absolutely could not do it on a day because he was away or otherwise it would be impossible, he would "bank hours", but always in advance. If he knew he would be gone for several days, he would double up the hours in the front so that he could take the time away as needed. He never let himself count on his "future self" to make up the difference.
At the end of the year, he had completed a beautiful set of precision beaded pieces (choker, neck drop, harness, arm bands, gauntlets, side tabs and head band. He said there was roughly 380 hours all told in the work he had done, nine and a half weeks worth of working "9 to 5". In reality, though, he said he hardly felt it, since he was able to spend an hour each day working on it. When I asked him what he felt made for it being a successful project, his answer was that he made a commitment, right then and there, to get started, and that set the stage for the rest of the project.
How often do we say "I'll work on that when I have time" or "I'll read that article later" or "I'll install that tool when I get a few moments". If you're anything like me, you say it a lot. I'm also willing to be that, often, that later moment never comes. While we do not always have the opportunity to act on something immediately, I challenge everyone to pick something (anything, really) that they have been putting off and making a commitment, right then and there, to start it, partition an hour a day to do it, and then do everything in your power to get it done. It may have to wait for lunch, or it may have to happen on the train ride home, or in the car, or at the dinner table, but somewhere, and some way, pick something you've been meaning to start, but just haven't had the time. Make the time, and get started. You may surprise yourself on how much you can do when you dive right into it.
Thursday, May 23, 2013
TESTHEAD is Bringing You Ice Cream
Am I being funny? Actually, no, I'm being very serious.
A number of us decided to sponsor one of the breaks at CAST this year. Often people would sponsor a happy hour or something. I don't drink, so that's not something I would sponsor, but Ice Cream? You bet :).
Again, think I'm kidding?
http://cast2013.sched.org/event/2883cbeeac41d1e9b609bdd4f8a0ab02#.UZ61vitARQU
OK, it's not just me. JeanAnn Harrison, Matt Heusser, Anna Royzman, Pete Walen and I decided to pool together to bring this little sweet spot of CAST to the attendees.
Oh, and I should also note that, while my bio says Socialtext, they're not covering this. I am. Therefore, "TESTHEAD is bringing you ice cream"!
Don't say I never did anything for you ;).
A number of us decided to sponsor one of the breaks at CAST this year. Often people would sponsor a happy hour or something. I don't drink, so that's not something I would sponsor, but Ice Cream? You bet :).
Again, think I'm kidding?
http://cast2013.sched.org/event/2883cbeeac41d1e9b609bdd4f8a0ab02#.UZ61vitARQU
OK, it's not just me. JeanAnn Harrison, Matt Heusser, Anna Royzman, Pete Walen and I decided to pool together to bring this little sweet spot of CAST to the attendees.
Oh, and I should also note that, while my bio says Socialtext, they're not covering this. I am. Therefore, "TESTHEAD is bringing you ice cream"!
Don't say I never did anything for you ;).
Gaming and Skills Acquisition
Over the past couple of years, I've been involved in learning about, as well as developing, ways to teach software testing to others. One of the aspects that is appearing in many social interactions, from the trivial to the fairly high stakes, is an aspect called "gameification". If this term is new to you, it's the idea that, by adding elements of gaming to the skills we are working on, and sharing those details, we can both inspire ourselves and inspire others by our performance. Also, there's something that's just kinda cool about going somewhere, pointing to a screen and saying "see that high score? Yeah, that's MINE!"
The question that constantly comes back to me, though, is just how much gameification, or gaming itself, actually lends to skill acquisition. To experiment with this, I decided to resurrect an old friend and some old memories. Some background; I played some video games in my youth and teen years. We owned an Atari 2600 console, and had several of the 8 bit games available at the time. I did not, however, follow on to the "Golden Age of Gaming" the way my brother and elder younger sister's generation did. My own gaming experience wouldn't be brought out of hibernation again until 2003, when I went to work for Konami. It was a prime time to start looking at video games once again, since my kids were just becoming old enough to be aware of things like Pokemon, Yu-Gi-Oh, etc. ). With that, I decided to buy a couple of GameBoy Advanced handheld consoles and start playing along with them. Shortly afterwards, the PlayStation 2 invaded our house, followed by the Nintendo Gamecube, the Nintendo Wii, the Playstation 3, and subsequent updates to the GBA and Nintendo DS formats (I still have my original cobalt blue DS I bought in 2004; it works perfectly). For grins, I plugged in a favorite game that I spent many hours with a decade ago; "Castlevania: Aria of Sorrow".
One of the things I learned from this game in particular is that there are two types of gamers, when you get right down to it. The first type of gamer is what I call a "finesser". These are the people that learn the special moves, practice their hand/eye coordination, and their overall speed in moving through games. If I had to use a sports analogy, I would call them "boxers", a la the Muhammed Ali type. These are the type that, to carry the boxer metaphor forward, would wear out their opponents, and then through grace and yes, finesse, finish off the fight. The second type of gamer is what I call the "statmaster". These players know what it takes to beat a given level, and they build the stats necessary. When you hear about people who grind through levels to maximize skills, points, equipment, amass money in games to get top notch equipment, it's the "statmasters" that make up the far end of the spectrum. These are the ones that believe in "victory by overwhelming firepower". Level up to 15, and taking on a Level 10 boss is almost boring. These people are, to carry on the boxing metaphor, are what I would call "punchers", a la Mike Tyson in his prime. They don't have a lot of finesse, they don't play elegantly, but they are devastating when they hit, and they hit really hard.
So why does it matter if you are a finesser or a statmaster? Personally, I think it matters a lot. Gameification of objectives needs to consider the fact that people are a spectrum, and that, typically, they fall on either far sides of the finesser or the statmaster, or anywhere in between. Elevate the stats aspects, and people will gravitate towards that will grind to meet the stats. Focus on the finesse aspects and those who are most adept at those aspects will learn how to finesse the game. Give an experience that is too heavy one side or another and you will alienate or underwhelm the participants that fall to either side.
My question is, as I consider activities and goals is to see how do we actually balance these two aspects? Why does Aria of Sorrow speak more to me than, say, Metroid Fusion, even though both games share a lot of the same anatomy and approach? It's because, at least for me, Metroid Fusion rewards the finessers early on; there's little in the way of grinding to get better. Either you figure out how to win the battles or you do not advance. Aria of Sorrow, on the other hand, lets you level up and build strength if you want to. Granted it can take a lot of time, but by doing so, you can both get the stats you want, as well as develop the moves necessary to win (though frankly, at a high enough level, the moves aren't even all that important, just hit and hit until the enemy goes down).
Note, the examples I'm using are a bit old now, but I think the dialog still applies. As we think about the skills we want to acquire, and we say to ourselves "make it like a game", there's more to that statement than meets the eye. Not only if you like to game, but how you like to game, will determine which model and approach works best for your personality and style. As an admitted statmaster, I realize what works for me won't necessarily appeal to the finesser, which means I either have to consider two different methods and models, or try to find a happy medium ground between the two. How about you? Do you consider your gaming style when you engage in these types of things? Does the gaming metaphor work for you when you try to learn new things?
The question that constantly comes back to me, though, is just how much gameification, or gaming itself, actually lends to skill acquisition. To experiment with this, I decided to resurrect an old friend and some old memories. Some background; I played some video games in my youth and teen years. We owned an Atari 2600 console, and had several of the 8 bit games available at the time. I did not, however, follow on to the "Golden Age of Gaming" the way my brother and elder younger sister's generation did. My own gaming experience wouldn't be brought out of hibernation again until 2003, when I went to work for Konami. It was a prime time to start looking at video games once again, since my kids were just becoming old enough to be aware of things like Pokemon, Yu-Gi-Oh, etc. ). With that, I decided to buy a couple of GameBoy Advanced handheld consoles and start playing along with them. Shortly afterwards, the PlayStation 2 invaded our house, followed by the Nintendo Gamecube, the Nintendo Wii, the Playstation 3, and subsequent updates to the GBA and Nintendo DS formats (I still have my original cobalt blue DS I bought in 2004; it works perfectly). For grins, I plugged in a favorite game that I spent many hours with a decade ago; "Castlevania: Aria of Sorrow".
One of the things I learned from this game in particular is that there are two types of gamers, when you get right down to it. The first type of gamer is what I call a "finesser". These are the people that learn the special moves, practice their hand/eye coordination, and their overall speed in moving through games. If I had to use a sports analogy, I would call them "boxers", a la the Muhammed Ali type. These are the type that, to carry the boxer metaphor forward, would wear out their opponents, and then through grace and yes, finesse, finish off the fight. The second type of gamer is what I call the "statmaster". These players know what it takes to beat a given level, and they build the stats necessary. When you hear about people who grind through levels to maximize skills, points, equipment, amass money in games to get top notch equipment, it's the "statmasters" that make up the far end of the spectrum. These are the ones that believe in "victory by overwhelming firepower". Level up to 15, and taking on a Level 10 boss is almost boring. These people are, to carry on the boxing metaphor, are what I would call "punchers", a la Mike Tyson in his prime. They don't have a lot of finesse, they don't play elegantly, but they are devastating when they hit, and they hit really hard.
So why does it matter if you are a finesser or a statmaster? Personally, I think it matters a lot. Gameification of objectives needs to consider the fact that people are a spectrum, and that, typically, they fall on either far sides of the finesser or the statmaster, or anywhere in between. Elevate the stats aspects, and people will gravitate towards that will grind to meet the stats. Focus on the finesse aspects and those who are most adept at those aspects will learn how to finesse the game. Give an experience that is too heavy one side or another and you will alienate or underwhelm the participants that fall to either side.
My question is, as I consider activities and goals is to see how do we actually balance these two aspects? Why does Aria of Sorrow speak more to me than, say, Metroid Fusion, even though both games share a lot of the same anatomy and approach? It's because, at least for me, Metroid Fusion rewards the finessers early on; there's little in the way of grinding to get better. Either you figure out how to win the battles or you do not advance. Aria of Sorrow, on the other hand, lets you level up and build strength if you want to. Granted it can take a lot of time, but by doing so, you can both get the stats you want, as well as develop the moves necessary to win (though frankly, at a high enough level, the moves aren't even all that important, just hit and hit until the enemy goes down).
Note, the examples I'm using are a bit old now, but I think the dialog still applies. As we think about the skills we want to acquire, and we say to ourselves "make it like a game", there's more to that statement than meets the eye. Not only if you like to game, but how you like to game, will determine which model and approach works best for your personality and style. As an admitted statmaster, I realize what works for me won't necessarily appeal to the finesser, which means I either have to consider two different methods and models, or try to find a happy medium ground between the two. How about you? Do you consider your gaming style when you engage in these types of things? Does the gaming metaphor work for you when you try to learn new things?
Seasons Change and Energy Fluctuates
It's been interesting to look at the last few years of my blog's existence. In it I can see certain trends and also I can look back and see what mattered to me, what I chose to expend energy on, and what took me away from posting on the blog or making good on things I said I would do.
Why am I thinking of this right now? Because it's been several weeks since I've done an update to the Selenium Practicum, and I've been averaging about a blog post a week, which many people who follow my blog know is abnormal for me. However, it really isn't that abnormal. If I look back at the past few years of data, January and February are strong months of lots of activity, multiple posts (often twice a day or more), and then as the weather gets better and the days get longer, the posts become less frequent. Typically around May, the post spigot dries up to about one every five days, or perhaps one a week.
Now that I've had a chance to review it a bit closer, I realize why. The past few years, I've been involved in a number of initiatives, and each of them seems to have a life cycle of their own. SummerQAmp has a life cycle, preparing for conferences has a life cycle. Posting for other blogs has a life cycle. Add to that the activities my family participates in and its easy to see that the energy isn't really growing or diminishing, it being redirected. For some reason, it's easier to take on a big learning initiative during the winter months. Preparing to write articles also seems to be something that I am better primed to do in the early spring. Summer is about developing presentations and talks. Fall is when I go into gathering mode and try to put it all together and see if I can condense and explain the avenues that I have done down. This may not be absolute, but if the past three years of blog data is to be believed, it's a pretty accurate description of how and where my mind is going.
I had a chat with a fellow tester some weeks back where she shared with me that she really appreciated my blog, and the fact that "she could relate to me as an individual, not just as a tester". I think in some ways, that's what makes writing TESTHEAD critical for me. In some ways, this blog is more than me pontificating on some cool test idea. Very often, test ideas are few and far between in my posts. Events take up a fair amount of space, but they really are dictated by what I actually participate in. While there's a lot of opportunities to learn and practice out there, events happen when they happen. That leaves one more aspect of the blog, and that's the one that really matters the most. Interaction. I interact with this blog in many ways. Its my accountability partner. It lets me know when I'm doing a great job, and when I'm not doing so great. It lets me know who finds what I say interesting, and who doesn't.
Most importantly, though, it gives me a chance to talk about things that I am, dare I say it, not so good at. This is an idea and a philosophy I picked up from Merlin Mann several years ago, in which on one of his podcasts, he said (paraphrased) "I don't blog about this because I'm good at it. I blog about this because I'm actually pretty lousy at a lot of this stuff!" I find it interesting that, when taken on a whole, I am "endorsed" by more people for test automation than I am any other skill. Personally, I find that ironic, because test automation may be the skill I struggle with the most. I'm not innately good at it. I spend a lot of time trying to figure things out that it might take a seasoned programmer just a few minutes to do. Still, because I do want to get better at it, I write about it. A lot. I write about the challenges I face. I write about the frustrations I have. I write about the fact that a lot of the explanations made just aren't that easy to understand and I share my confusion. Maybe that's why so many have endorsed me for test automation, not because I am good at it, but because I have a clear understanding of just how frustrating it can be, and I can offer lots of proof to that fact :).
In any event, Spring is almost over, Memorial Day weekend is coming up (and I am deliberately going "off the grid" to celebrate it :) ). Lots of interesting stuff is going on, and as soon as I know for a fact that we are good to go on a number of things, I'll be talking about quite a few more things, including getting back on the hobby horse that is my Selenium WebDriver Practicum.
Why am I thinking of this right now? Because it's been several weeks since I've done an update to the Selenium Practicum, and I've been averaging about a blog post a week, which many people who follow my blog know is abnormal for me. However, it really isn't that abnormal. If I look back at the past few years of data, January and February are strong months of lots of activity, multiple posts (often twice a day or more), and then as the weather gets better and the days get longer, the posts become less frequent. Typically around May, the post spigot dries up to about one every five days, or perhaps one a week.
Now that I've had a chance to review it a bit closer, I realize why. The past few years, I've been involved in a number of initiatives, and each of them seems to have a life cycle of their own. SummerQAmp has a life cycle, preparing for conferences has a life cycle. Posting for other blogs has a life cycle. Add to that the activities my family participates in and its easy to see that the energy isn't really growing or diminishing, it being redirected. For some reason, it's easier to take on a big learning initiative during the winter months. Preparing to write articles also seems to be something that I am better primed to do in the early spring. Summer is about developing presentations and talks. Fall is when I go into gathering mode and try to put it all together and see if I can condense and explain the avenues that I have done down. This may not be absolute, but if the past three years of blog data is to be believed, it's a pretty accurate description of how and where my mind is going.
I had a chat with a fellow tester some weeks back where she shared with me that she really appreciated my blog, and the fact that "she could relate to me as an individual, not just as a tester". I think in some ways, that's what makes writing TESTHEAD critical for me. In some ways, this blog is more than me pontificating on some cool test idea. Very often, test ideas are few and far between in my posts. Events take up a fair amount of space, but they really are dictated by what I actually participate in. While there's a lot of opportunities to learn and practice out there, events happen when they happen. That leaves one more aspect of the blog, and that's the one that really matters the most. Interaction. I interact with this blog in many ways. Its my accountability partner. It lets me know when I'm doing a great job, and when I'm not doing so great. It lets me know who finds what I say interesting, and who doesn't.
Most importantly, though, it gives me a chance to talk about things that I am, dare I say it, not so good at. This is an idea and a philosophy I picked up from Merlin Mann several years ago, in which on one of his podcasts, he said (paraphrased) "I don't blog about this because I'm good at it. I blog about this because I'm actually pretty lousy at a lot of this stuff!" I find it interesting that, when taken on a whole, I am "endorsed" by more people for test automation than I am any other skill. Personally, I find that ironic, because test automation may be the skill I struggle with the most. I'm not innately good at it. I spend a lot of time trying to figure things out that it might take a seasoned programmer just a few minutes to do. Still, because I do want to get better at it, I write about it. A lot. I write about the challenges I face. I write about the frustrations I have. I write about the fact that a lot of the explanations made just aren't that easy to understand and I share my confusion. Maybe that's why so many have endorsed me for test automation, not because I am good at it, but because I have a clear understanding of just how frustrating it can be, and I can offer lots of proof to that fact :).
In any event, Spring is almost over, Memorial Day weekend is coming up (and I am deliberately going "off the grid" to celebrate it :) ). Lots of interesting stuff is going on, and as soon as I know for a fact that we are good to go on a number of things, I'll be talking about quite a few more things, including getting back on the hobby horse that is my Selenium WebDriver Practicum.
Wednesday, May 15, 2013
The Sound of "White Noise"
Sometimes the most challenging thing we face is trying to balance out multiple and competing demands. When we have a lot of good things we want to do and accomplish, and on the surface, each of them seem to be, if not easy, at least manageable.
The frustrating thing is when each item seems to come at us simultaneously, and we try to cover all bases at the same time. I've long believed that human being cannot really multi-task. We can do a number of things adequately with distractions, but we cannot really do our best work with competing goals. I've also come to see that there's more to this, and that there's an insidious distractor that we often don't give enough heed to. That distraction can be best called "White Noise".
This may make more sense to people who have done multi-track tape recording in the past... you know, that ancient method that we used before digital recording on hard disks became all the rage? One of the cardinal rules of doing tape recording and gathering tracks together is what we called the "law of the bounce". When you recorded multiple tracks, and you needed to make more room, you had to take your currently recorded tracks and "bounce" them down to one or two tracks. However, this came at a price. Each time we did that, we would add about 3dB of white noise or "hiss" to the recording. Doing it once, probably not noticeable. Doing it multiple times quickly overran the recording with hiss and made the sound quality intolerable. Why? Because each time you add 3dB, you get a multiplication of the effect, and soon, that hiss becomes ever present. You no longer hear the music, instead you find yourself distracted by the hiss. In short, the "White Noise" overtakes the quality of the signal.
When we find ourselves with too many good goals and too many things that are demanding our attention, again, it's the same effect as bouncing multiple individual tracks into one. We add white noise, and soon that white noise becomes a constant rumble, to the point that we often lose track of the things we want to be doing to take care of whatever is demanding our attention at that given moment. In short, the White Noise prevents us from actually focusing our attention on what really matters.
In the recording world, we typically do all we can to isolate unique sounds until the very last step. The mix down process for a song can often be a very labor intensive process, where filtering, muting and un-muting, and external effects help us to keep each sound at its proper level until exactly when we need it. The end result is a two track stereo master that has a minimum of artifacts. In our own general work lives, we would do well to take the same lesson. While it is impossible to isolate everything we do into its own sphere and just deal with them one at a time in complete isolation, the quicker and more directly we can focus on thee areas, the less likely they will be to have to be incorporated with other activities. In short, we need to try our best to minimize the bounces, or have a backlog of things we need to do build up to the point where there is a lot of rumbling. By doing so, we can prevent the White Noise from becoming a monster that requires our full attention, to the detriment of the things that we actually want to accomplish.
The frustrating thing is when each item seems to come at us simultaneously, and we try to cover all bases at the same time. I've long believed that human being cannot really multi-task. We can do a number of things adequately with distractions, but we cannot really do our best work with competing goals. I've also come to see that there's more to this, and that there's an insidious distractor that we often don't give enough heed to. That distraction can be best called "White Noise".
This may make more sense to people who have done multi-track tape recording in the past... you know, that ancient method that we used before digital recording on hard disks became all the rage? One of the cardinal rules of doing tape recording and gathering tracks together is what we called the "law of the bounce". When you recorded multiple tracks, and you needed to make more room, you had to take your currently recorded tracks and "bounce" them down to one or two tracks. However, this came at a price. Each time we did that, we would add about 3dB of white noise or "hiss" to the recording. Doing it once, probably not noticeable. Doing it multiple times quickly overran the recording with hiss and made the sound quality intolerable. Why? Because each time you add 3dB, you get a multiplication of the effect, and soon, that hiss becomes ever present. You no longer hear the music, instead you find yourself distracted by the hiss. In short, the "White Noise" overtakes the quality of the signal.
When we find ourselves with too many good goals and too many things that are demanding our attention, again, it's the same effect as bouncing multiple individual tracks into one. We add white noise, and soon that white noise becomes a constant rumble, to the point that we often lose track of the things we want to be doing to take care of whatever is demanding our attention at that given moment. In short, the White Noise prevents us from actually focusing our attention on what really matters.
In the recording world, we typically do all we can to isolate unique sounds until the very last step. The mix down process for a song can often be a very labor intensive process, where filtering, muting and un-muting, and external effects help us to keep each sound at its proper level until exactly when we need it. The end result is a two track stereo master that has a minimum of artifacts. In our own general work lives, we would do well to take the same lesson. While it is impossible to isolate everything we do into its own sphere and just deal with them one at a time in complete isolation, the quicker and more directly we can focus on thee areas, the less likely they will be to have to be incorporated with other activities. In short, we need to try our best to minimize the bounces, or have a backlog of things we need to do build up to the point where there is a lot of rumbling. By doing so, we can prevent the White Noise from becoming a monster that requires our full attention, to the detriment of the things that we actually want to accomplish.
Thursday, May 9, 2013
Web Performance S.F.: A TESTHEAD Live Blog
I needed to spend some time taking care of some other adventures, one of which, as you all might know by now, was the launching of the Miagi-Do Blog. With much thanks to David Greenlees, we now have our own little place on the web to call home. I wrote the second missive to appear there. If you haven't read it, please do.
Also, I was immensely surprised and given a big reason reason to smile yesterday when I saw that Cem Kaner wrote about "credentialing in software testing", in which he said about Miagi-do:
"I think this approach is probably reasonably attainable, and to me, it is definitely credible. Whether it scalable and commercially viable has yet to be seen. I think this is a clear and important alternative [...] I hope it is successful".
We hope it is, too :).
Tonight, however is not about Miagi-do. It's about Meetup Culture in San Francisco and elsewhere in this area that I call home. This continues my thought experiment that you cannot swing an umbrella in San Francisco without hitting a meet up someplace. Tonight brings us to Yelp, and a conversation that's a little different than what I normally come up for. Since STP-CON, however, I have felt that performance is an area I definitely want to beef up my knowledge about, and thus, here I am.
 |
| Some early arrivals/Yelp employees playing pool before the talk starts. |
The Top 5 Performance Shenanigans of CSS Preprocessors
with Nicole Sullivan
Thursday, May 9, 2013
7:00 PM
Yelp
706 Mission Street,
San Francisco, CA
Tonight's topic is focused on a specific aspect of performance, the front end display of web pages and the use of CSS. More to the point, CSS preprocessors and their overall effect on site performance, usability and maintainability, and what we can do to help tip the odds of keeping them on their good sides in our favor.
The sessions started with a conversation about "Living Style Guides". A style guide used to be all about a definitive guide for every item (logo size, spacing, colors, etc.)... do we really care about how the logo for AOL should look on a hat? Structured style guides don't really work. They take months to produce, they are often out of date before they are finished, and they are design centric. Living style guides focus on existing site styles, it lives in code, so that it evolves as the app evolves. Plus, engineering and design teams can work together with it. Design and Engineering have a cap between them, and that gape is often where performance gets optimized or falls all over itself.
An example using Trulia was presented. They demonstrated a process that used a number of steps:
Visual Inventory: Finding the right data to make decisions.
Trulia chose ten pages to analyze, which was meant to get an idea of the site as a whole in the smallest footprint. Often styles are duplicated over and over again. Analyzing duplication and finding variations are the most important first steps. grep is a good tool to start this process. grep for various selectors, properties and values. The main point is to determine how big a mess you have, not a granular count.
Examples shown from Trulia's audit showed lots of duplication (font size appears over 2,000 times, for example. Padding appears almost 4500 times... and this is actually pretty typical). Many of these values can be put into classes to greatly decrease the amount of repetition. Unused CSS and background images can be a huge hit to performance. Remember, all that stuff needs to be loaded, even if it isn't actually having a visible effect for the page. Positioning shows up a lot, and may be a good indication that an abstracted way of laying out the page would be hugely helpful.
Design inconsistency can also be a killer. Profiling and looking to see how often items appear, or don't appear, can help make systems consistent (imagine having dozens of almost the same but not quite the same color of blue. Each one is being used individually, instead of one declaration.
Going through and creating a reference library of the items used, the images, the layout boxes, and any number of element types (images, headers, light boxes, font sizes, font styles, buttons, text boxes, etc.) can help to create a reference for each of the items so that they act as a living style guilde, one that can be seen in real time and more easily determined which aspect and element is preferred to be used, or which items are used frequently vs. one offs.
The gosl is to do this for all component types, and try to identify ans many variations that are there.
Rationalized Styles
When we see the cumulative effect of a million tiny choices, we can see how styles proliferate, see how many styles don't do anything. It can show all present the tangled web of options that are listed and how many of them are "just there', not doing anything.
Get people involved early in the process. This can help make sure that everyone has the time and the focus to see which items are most important. Decide on a single aspect or item so that they can be iterated later. Try to match current styles where possible and appropriate.
Component Library
Once all this is done, we can create a legitimate style guide, and in this process, the discusion shifted to SASS. Some examples shown were the idea of nesting CSS so that you don't have to repeat the class names for every mention. Another option described was the use of mix-ins. when you have a small number of property value pairs or groups. Using @include and @extend allows the designer to create and design a variety of element groups in one wrapper.
Additionally, if you want to see what your output for SASS will be, you can check in the config.rb file. You may be surprised how much complexity is created when you are hoping to simplify CSS calls with extends and includes.
Several examples show how we think that we are simplifying our code and layouts, when in reality, we are very often adding way more than we think we are.
In the process of describing this style guide, we went well beyond five Performance Hits, we're up to number none now, which is "semantic grids are a terrible idea". It causes massive duplication, unreadable HTML and CSS that solves too many problems.
Build simple components first, as they often get used in complex components. An example, they create variables for colors rather than using the direct color value. Create basic typography before more advanced and specialized styles. Creating base variables make it much easier to make changes where needed, and it's easy to see what the changes are and what they represent. Anyone can make changes (well, almost anyone ;) ).
The last part was a live demo of the style guide, which would be way too difficult to explain here, but suffice it to say it was pretty cool to see. It helps me make sense of a lot of the stuff I've seem my friend Rich do for the past couple of years :).
Deployment
Choose the most trafficked pages, most important flows, go for 80% of Page Views. Only convert other pages as new features are added. For new features, add additional functionality to the library first. Use real user measurements (what matters to the users?). The example of the changes made caused a 40% reduction to the overal HTML code transmitted, and they increased page load speed by about 60%.
The examples shown helped me see where a number of areas could be improved in ways I hadn't considered. There's a lot of duplication in sites, and there are some relatively simple tools to find out where. Using OOCSS and SASS together can help people make performant pages. Also, it's important to remember, good performance is a feature :).
About the presenter:
Nicole Sullivan (@stubbornella):
Nicole is a front-end performance consultant, CSS aficionado, and author. She started the Object-Oriented CSS open source project, which answers the question: how do you scale CSS for millions of visitors or thousands of pages? She also consulted with many companies including Facebook, Salesforce, the W3C, Adobe, Paypal, Trulia and Box. She is the co-creator of Smush.it, an image optimization service in the cloud, and CSS Lint (http://csslint.net), a tool that helps correct common CSS errors before they are pushed to production. She is passionate about CSS, web standards, and scalable front-end architecture for large commercial websites. She co-authored The Web Performance Daybook, Vol 2 and Even Faster Websites and blogs at http://stubbornella.org.
Friday, May 3, 2013
So, what is the "Miagi-do School of Software Testing?"
We've been a bit cagey with this over the past few years, but we've decided that we want to do more, be more, and actually draw a line in the sand and say "this is what we stand for, this is who we are, and this is why we are here".
Miagi-do officially placed itself in a place where it could be found today. If you would like to see our opening salvo, Markus Gaertner has written about who we are and why we do what we do. This will be a place where many of us (including me) will be discussing what we do, how we do it, and how others can get involved. With a lot of the conversation going on right now on Twitter regarding certifications, being anti-certification, questioning the validity of certification, questioning the validity of those questioning the validity of certification, and a Twitter account that, at least on the surface, looks to call into question the motives of all in question (pause, long deep breath)... I wanted to make the point that I feel is missing from all of this.
I distrust any certification or course of study that doesn't, in some way, actually have a tester demonstrate their skills, or have a chance to defend their reasoning or rationale behind those skills.
I dislike metrics. I find them easy to exploit and easy to politicize. I find it much more valuable to give someone a challenge and see how they actually do. I value seeing why someone feels the way they do about a topic. I want to hear them explain their position and persuade me, or defend their position if I disagree. I want to watch them sweat through real world problems. If there's any one certification I actually see of real value that commercially available, it's the Cisco Certified Internetworking Expert, because they have had to prove multiple times in actual labs that they can solve a problem and fix issues in real time.
That's why I gravitate towards BBST, Weekend Testing and Miagi-do. I want to see an emphasis on real skill transfer. To borrow my martial arts metaphor from earlier this week (and really, from three years ago), you may or may not have the skills needed to progress and be effective if you pass a MCT. Just like in Aikido, you may know the ins and outs of dozens of Kata moves. You may even be able to explain them real well, but if three guys with knives rush you simultaneously, one of two things is going to happen. You will either fend them off, or you will be taken down. I'm all for you being able to explain what to do. That's great. More important, I want to see that you can also fend off the knife wielders. I may be impressed with your intellect by the former. I'll put my trust in you if you can show me the latter. My goal, and the goal of Miagi-do, is to help as many testers as possible be firmly in the second option.
Miagi-do officially placed itself in a place where it could be found today. If you would like to see our opening salvo, Markus Gaertner has written about who we are and why we do what we do. This will be a place where many of us (including me) will be discussing what we do, how we do it, and how others can get involved. With a lot of the conversation going on right now on Twitter regarding certifications, being anti-certification, questioning the validity of certification, questioning the validity of those questioning the validity of certification, and a Twitter account that, at least on the surface, looks to call into question the motives of all in question (pause, long deep breath)... I wanted to make the point that I feel is missing from all of this.
I distrust any certification or course of study that doesn't, in some way, actually have a tester demonstrate their skills, or have a chance to defend their reasoning or rationale behind those skills.
I dislike metrics. I find them easy to exploit and easy to politicize. I find it much more valuable to give someone a challenge and see how they actually do. I value seeing why someone feels the way they do about a topic. I want to hear them explain their position and persuade me, or defend their position if I disagree. I want to watch them sweat through real world problems. If there's any one certification I actually see of real value that commercially available, it's the Cisco Certified Internetworking Expert, because they have had to prove multiple times in actual labs that they can solve a problem and fix issues in real time.
That's why I gravitate towards BBST, Weekend Testing and Miagi-do. I want to see an emphasis on real skill transfer. To borrow my martial arts metaphor from earlier this week (and really, from three years ago), you may or may not have the skills needed to progress and be effective if you pass a MCT. Just like in Aikido, you may know the ins and outs of dozens of Kata moves. You may even be able to explain them real well, but if three guys with knives rush you simultaneously, one of two things is going to happen. You will either fend them off, or you will be taken down. I'm all for you being able to explain what to do. That's great. More important, I want to see that you can also fend off the knife wielders. I may be impressed with your intellect by the former. I'll put my trust in you if you can show me the latter. My goal, and the goal of Miagi-do, is to help as many testers as possible be firmly in the second option.
Subscribe to:
Posts (Atom)