Green Thoughts: Day Two at #esconfs

It really puts into perspective how much of a time difference eight hours is. I was mostly good yesterday, but this morning came way too fast, and I am definitely feeling the time change. A bit of a foggy morning today, but a brisk walk from the Maldron Pearse and a snack on a peanut bar, and I'm ready to go :).

Convention Center Dublin, aka Where the Action is :)

The first keynote for today is being given by Isabel Evans and its titled "Restore to Factory Settings", or to put simply, when a change program goes wrong. We always want to think that making changes will always be positive. the truth is, there are some strange things that happen, and its entirely possible that we might find ourselves in situations we never considered. Isabel works with Dolphin Systems, who is associated with Accessibility issues (hey, something in my wheelhouse, awesome :) ).

The initial problems were related to quality issues, and their idea was that improved testing would solve these problems. Isabel figured "30 years of testing, sure I can do this, but there's not just testing issues here". Starting with issue #1, improve testing. First, there were no dedicated testers. Testing was done by whoever would be able to do testing. Seemed an obvious first step was to do some defect recognition, and develop skills to help them discover defects and actually talk about them.

Isabel suggested that she sit with the developers and work with them, and even that was a request that was at first a difficult transition. She had to fight for that position, but ultimately they decided it made sense to work with that arrangement. By recruiting some of the support team and getting others involved, they were able to put together a test team.

With a variety of initiatives, they were able to improve defect recognition, and requirements acquisition also improves. Sounds great, right? well, the reality is that the discovery of issues was actually adding to the time to release. They improved the testing, which identified more bugs, which added a greater workload, which adds pressure to the release schedule, which means more mistakes are made, and more bugs are introduced. Now, for those of us who are familiar with testing, this is very logical, but the point Isabel is making is that testing alone, and focusing on a greater emphasis on testing will not automatically mean better quality. In fact, it has a significant chance of making the issues worse at first, because they are now being shown the light of day.

The talk title "Restore to Factory Settings" is that, when things get tough, the natural reaction is to go back to doing what everyone always did. there are enthusiastic adopters, people against the whole idea, and then there are waverers in the middle. The waverers are the ones who hold the power. They will revert back to their SOP when things get tough. Even the enthusiastic adopters, if they are not encouraged, will revert back to SOP. The people against will go back to the old ways the second they get a chance. Management, meanwhile, is getting agitated that this big movement to change everything is not getting traction. Sounds absurd, but it happens all the time, and I'm sure we've all experienced this in one form or another.

The key takeaway that Isabel was describing is that changes to testing are often icing on a much thicker and denser cake. Changing testing will not change the underlying culture of a company. It will not change the underlying architecture of a product. Management not being willing to change their approach also adds to the issues. If the rest of the cake is not being dealt with, testing alone will not improve quality. In fact, it's likely in the short term to make quality issues even worse, because now there is clarity of the issues, but no motivation to change the behaviors that brought everyone there.

This all reminds me of the four stages of team development (forming, storming, norming and performing), and the fact that the testing changes fit clearly into the storming stage. If the organization doesn't embrace the changes, then the situation never really gets out of the storming stage, and morale takes perpetual hits. Plans describe what likely won't happen in the future, but we still plan so we have a basis to manage change. Risk management is all about stuff that hasn't happened, but we still need to consider it so we are prepared if it actually does happen. In short, "Say the Same, Do the Same, Get the Same".

Change is hard, and every change in the organization tends to cause disruption. Change programs bring all of the ugly bits to the surface, and the realizations tumble like dominos. To quote Roland Orzabel's "Goodnight Song", nothing ever changes unless there's some pain. As the pain is recognized, the motivation for change becomes more clear. Prioritization takes center stage. Change has a real fighting chance of succeeding.

Ultimately, there is a right time for implementing changes, and not any one thing is going to solve all the problems. Continuous improvement is a great pair of buzzwords, but the process itself is really tricky to implement and, more important, to sustain.

---

Next up, "Every Software Tester has a PRICE" with Michael Bolton. I've come to this session because I am often curious as to how we present the information we find, and the ways that we can gather that information. Ecery test should have an expected predicted result. Makes sense for checks, but it doesn't really hold up for testing. Testing is more involved, and may lead you to completely different conclusions. Often, the phrase we hear is "I don't have enough information to test". Is that true? It may well be, but the more fundamental question is "where do we get the information we need in the first place?"

Our developers, our company web site, our user guide, our story backlog, our completed stories, our project charter, our specifications, our customers, other products in our particular space, etc. Additionally, the elusive requirements that we are hoping to find to inform us are often not anything that is written down. Tacit knowledge that resides in the heads collectively of our organization is what ultimately makes up the requirements that matter. The tricky part is gathering together all of the miscellaneous parts so that it can be made actionable. Think about it this way. For those of us who have kids, do we know the exact address of our kids schools or where they go for their extra curricular activities? I'm willing to bet most of us don't, but we know how to get there. It only becomes an issue when we have to explain it to someone else. As a tester, we need to consider ourselves that person that needs to consider how to get those addresses for all of those collective kids and where they need to go.

The fact is, there's lots of information that is communicated to us by body language and by inference. Requirements are ultimately "collective tacit knowledge". What we require of a product cannot be completely coded or ever truly known. That doesn't mean that we cannot come close, or get to a reasonable level that will help generate a good enough working model. One of the interesting aspects of the iPhone, for example, is "charisma"... what makes an iPhone an iPhone, and what makes it compelling? Is it its technical capabilities, or does it just "feel good"? How do we capture that charisma as a product element, as a feature to be tested?

One of the best sources of information, and one not talked about very often, is the process of "experimentation". In other words, we develop the requirements by actively testing and experimenting with the product, or with the people responsible for the product. Interviewing individuals associated with the product will help inform what we want to be building (think customer support, customers, manufacturing, sales, marketing,  subject matter experts, senior management, etc.) and our experimenting with their input will give us even more ideas to focus on). We also develop oracles to help us see potential issues (in the sense that an oracle is some mechanism that helps us determine if there is an issue before us). The product itself can inform us of what it could do. We can also do thought experiments of what a product might do.

What this shows us is that there are many sources of information for test ideas and test artifacts in ways that most of us never consider. We place limits on our capabilities that are artificial. So many of our ideas are limited by our own imaginations and our own tenacity. If we really want to get deep on a topic, we are able to do that and do it effectively. Often, though, we suffer not from a lack of imagination, but from a lack of will to use it. So much of what we want to do is dictated by a perceived lack of time, so that we try to limit ourselves to the areas that will be the quickest and most accessible. This is not a bad thing, but it points out or limitations in our efforts. We trade effectiveness for efficiency, and in the process, we cut off so many usable avenues that will help us define and determine how to guide our efforts.

---
Next up, "How Diversity Challenged me to be Innovative as a Test Team Leader" with Nathalie Rooseboom de Vries - van Delft.

What does diversity really mean? What does it mean to embrace and utilize diversity? What happens when you go from being a team of one as a consultant to wanting to be a team leader an manage people? How can we get fifteen unique and different people to work together and become a single team? What's more, what happens when you have to work with a team and a culture that is ossified in older practices? This is the world Nathalie jumped into. I frankly don't envy her.

One of the biggest benefits of being a consultant is that, after a period of doing a particular job or focus, you can leave, and the focus is temporary, and you don't have to live with the aftermath of the decisions that follow on. When we make a commitment to become part of a team long term, we inherit all of the dysfunction, oddity, and unique factors that the team is built from. The dynamics of each organization is unique, but they tend to have similar variations on a theme. The ultimate goal of an organization is to release a product that makes money. Testers are there to help make sure the product that goes out is of the highest quality possible, but make no mistake, testers do not make a company money (well, they do if you are selling testing services, but generally speaking, they don't). Getting a team on the same page is a challenge, and when you aim to get everyone working together, part of that balance is understanding how to emphasize the strengths of your team mates.

Nathalie uses an example of what she called a "Parent/Adult/Child" metaphor to transactions. The Parent role can have over Positive and over Negative issues. the Parent role can nurture, but it can also be controlling, it can be consoling and yet blaming. the child role is both docile and rebellious, unresponsive and insecure. In some early interactions, there may well be Parent/Child interactions, but the goal is to move away over time to a more Adult/Adult interaction. To get that equality of behavior, sometimes you have to use the parent relationship to get the behavior from the "Child", or if you want to get the Parent to respond differently, the Child needs to use a different technique to get that behavior to manifest.

The ability to challenge members of your team will require different methods. Diversity of the team will make it impossible to use the same technique for every member. They each have unique approaches and unique interests and motivations. One of Nathalie's approaches is to have a jar with lollipops and a question and answer methodology. If you post a question, you get a lollipop. If you answer a question, you get a lollipop, too. The net result is that people realize that they can answer each other's questions. They can learn from each other, and they can improve the overall team's focus by adding to the knowledge of the entire team and getting a little recognition for doing that. She also uses a simple game called "grababall" which has a number of tasks and things that need to be done. The idea is that when you grab a ball, you have a goal inside of the ball to accomplish. If you accomplish the goal, you get a point. At the end of the year, the highest point accrual gets a prize. By working on these small goals and getting points, the team gets engaged, and it become a bit more fun.

Diversity is more than just the makeup of the team, of having different genders, life experiences or ethnic backgrounds. Diversity goes farther. Understanding the ways that your team members are motivated, and the different ways that they can be engaged can give huge benefits to the organization. Take the time to discover how they respond, and what aspects motivate them, then play to those aspects.

---

Next up, "Introducting Operational Intelligence into Testing" with Albert Witteveen. Albert has had a dual career, where he has spent time in both testing and in operations (specifically in the Telco space). Testers are all familiar with the issues that happen after a product goes live. The delay, the discovery, the finger pointing... yet Operations discovers the problem in a short period of time.

What is the secret? Why do the operations people find things testers don't? It's not as simple as the testers missed stuff (though that was part of the answer), it's also that the operational folks actually utilize the product an manage and monitor the business processes. Operations people have different tools, and have different focuses.
Testers can be a bit myopic at times. If our tests pass, we move on to other things. Small errors may be within the margin of error for us. In Ops, the errors need to be addressed and considered. Operations doesn't have an expected result, they are driven by the errors and the issues. In the Ops world, "every error counts".

Operations managers have log entries and other issues that are reported. With that, they work backwards to help get the systems to tell them where the issues are occurring. In short, logs are a huge resource, and few testers are tapping them for their full value.

So what does this mean? Does it mean we need Operations people on the testing team? Actually, that's not a bad idea. If possible, have a liaison working with the testers. If that's not a reasonable option, then have the operations people teach/train the testers how to use logs and look for issues.

Sharing the tools that operations uses for monitoring and examining the systems would go a long way to be able to see what is happening to the servers with a real load and a real analytics of what is happening in the systems over time.  If there is any one silver bullet I can see from doing Ops level monitoring and testing, it's that we can objectively see the issues, and we can see them as they actually happen, not just when we want to see it happen.

--

I'm in Adam Knight's talk "Big Data, Small Sprint". What is big data, other than the buzzword that talks about storing a lot of details and records? Who three years ago even really knew what "big data" was? When you talk about big data, you are talking about large bulk load data. Adam's product specifically deals with database archiving.

This model deals with tens of millions of records, dozens of partitions and low frequency ingesting of data (perhaps once a week). their new challenge was to handle millions of records per hour, with tens of thousands of partitions. The ability to work within Agile and targeting the specific use cases of this customer, they were able to deliver the basic building blocks to this customer within one sprint. Now imagine storing tens of billions of records each day (I'm trying to, really, and it's a bit of a struggle). Adam showed a picture of an elephant, then a Titanosaurus, and then the Death Star. This is not meant to represent the size of increase for the records, but the headaches that testers are now dealing with.

In a big data system, can we consider the Individual? Yes, but we cannot effectively test every individual uniquely. Can the data be manipulated? Yes, but it needs to be done in a different way. We also can't manage an entire dataset on a single machine.  we an back up a system, but the back up will be too big for testing purposes. Is big data too big to wrap ones head around? It requires a different order of magnitude to discuss (think moving from kilometers or miles to astronomical units or light years to describe distances in space).

OK, so this stuff is big. we get that now. But how can we test something this big?  We start by changing our perspective, and we shift from focusing on every record to focusing on the structures and how they are populated with representative data (from records to partitions, from data to metadata, from single databases to clusters). Queries would not be made where they would pull a row from every conceivable table. Instead, we'd be looking at pulling representational data over multiple partitions. Testers working on big data projects need to develop special skills beyond classic testing. There is a multi-skill request, but the idea of getting multiple testers that have all of the skills needed in one person is highly unlikely. Adam discusses the idea of developing the people on the test team to strive to be "T" shaped.  A T-shaped tester would have many broad but rudimentary or good  test skills, as well as a few core competencies that they would know very deeply. By combining complementary T-shaped testers, you can make for a fully functional square shaped team.

Adam mentioned using Ganglia as a way to monitor a cluster of machines (there's that word again ;) ) so that the data, the logs and other detail can be examined in Semi Real times. To be frank, my systems don't come anywhere close to these levels of magnitude, but we still have a fairly extensive amount of data, and these approached are interesting, to say the least :).

---

I promised my friend Jokin Aspiazu that I would give him a testing challenge while we were here at EuroStar. Jokin humored me for the better part of an hour and a half showing me how to tackle an issue in the EuroSTAR test lab. I asked him to evaluate a time tracking application and either sell me on its implementation or convince me it was not shippable, and to find a scenario significant enough to kill the project.

He succeeded :).

Of course, this app is designed to be a TestLab app to be puzzled through and with, but I asked him to look beyond the requirements for the Test Lab's challenge and look at the product holistically, and to give me a yes/no in a limited amount of time (all the while articulating his reasoning as he was doing it, which I'm sure must have been mildly annoying ;) ).

With that, I determined Jokin earned advancement as a Brown Belt in the Miagi-do School of Software Testing.  For those of you here, high five him and buy him a drink when you see him, he's earned it!

---

A last minute substitution caused me to jump onto another talk, in this case "The Silent Assassins" by Geoff Thompson. These are the mistakes that can kill even the best planned projects.

Silent Assassin #1: Focus on Speed, not on Quality. Think of the idea of a production floor taking up more space to fix problems coming off the line than is allocated to actually developing new product well.

Silent Assassin #2: The Blindness to the True Cost of Quality. Supporting and maintaining the software costs a lot more than putting it together initially. Consider the amount of money it will take to maintain a system.

Silent Assassin #3: Go by Feel, Not by Facts. Metrics can be abused, and we can measure all sorts of worthless stuff, but data and actual deliverables are real things, and therefore, we need to make sure we have the facts on our side to say if we are going to be able to deliver a product on time. In short, we don't know what we don't know, so get our relevant facts in order.

Sinet Assassin #4: Kicking Off a Project Before the Business is Ready. Do our customers actually understand what they will be getting? It's not enough for us to deliver what "we" think the appropriate solution is, the customers need to have a say,and if we don't give them a say, the adoption may be minimal (opr even non-existent). Which leads to...

Silent Assassin #5: Lack of Buy-in From Users. Insufficient preparation, a lack of training, no demonstration of new features and methods, will likewise kill the adoption of a project with users.

Silent Assassin #6: Faulty Design. Software design defects compound as they go. The later a fundamental design issue, the harder it will be to fix, and in many cases, the problems will be exponentially more difficult to fix.

OK, that's all great, but what can we actually do about it? To disarm the assassins, you need to approach the areas that these problems fall into. The first area is processes. It's the way you do the work and the auto-pilot aspects of the work we do. The next is People. Getting people on the teams to work with each other. Getting buy-in from customers and communicating regularly, and taking the people into consideration of our efforts. The last area is tools, and its listed last because we often reach for the tool first, but if we haven't figured out the other two first, the tools are not going to be effective (or at least not as effective as they actually could be). Focus on effectiveness first, then shoot for efficiency.

Shift Left & Compress: put a clear focus to deliver the highest quality solution to customers at the lowest possible cost point. In my vernacular, this comes down to "review the work we do and get to the party early". Focus on the root causes of issues, and actually do something to stop the issues from happening. The Compress point is to do it early, prioritize up front, and spend your efforts in the most meaningful efforts. easy to say, often really difficult to do correctly. Again, the organization as a whole needs to buy in to this for it to be effective. This may also... actually, scratch that, it will need to have investments in time, money, energy, emotion and commitment to get past these assassins. These are difficult issues, and they are costly ones, but tackling it head on may give you a leg up on delivering a product that will be much less costly to maintain later. The money will be spent. The question is how and when ;).

---

Yes, this happened, and yes, it was glorious :)!!!

...and as an added bonus, Smartbear sings a Tester's Lament to the score of Frozen's "Let It Go" :)

---

Wednesday's closing Keynote is with Julian Harty; the topic is "Software Talks - Are You Listening?"

First question... why bother? Don't we know what we need to do? Of course we do, or so we think. However, I totally relate to the fact that software tells us a lot of things. It has its own language, and without listening, we can do many things that are counter to our best intentions.

The first way that our software talks to us is through our user base and through their interactions. If we remove features they like, especially in the app world, the software will tell us through lower ratings (perhaps much lower ratings). Analytics can help us, but yet again, there's much more we can learn earlier (and actually do something about) than do it later when it's been released.

Logs are our friend, and in many ways, the logs are the most loquacious artifact of all. So much information is available and most testers don't avail themselves of it, and that is if they look at them at all. analytics can be filtered from devices, churned into a number of different breakdowns and then we try to understand what is happening in real time. The information we gather can be helpful, but we need to develop insights from it. we want to gather design events, implementation events, field test data, evaluations, things that will tell us who is using what, when and where. A/B Testing fits very well in this space. We can see how one group of users reacts compared to another group. We can gauge precision and accuracy, so long as we don't conflate the two automatically. It's entirely possible that we can be incredibly accurate, but we are missing the target completely.

There are darks sides to analytics, too. One cardinal rule is "Do No Harm", so your app should not do things that would have negative effects (such as having a flashlight app track your every move while it is in use and upload that location data). We can look at the number of downloads, the number of crashes and the percentage of users that use a particular revision.  If we see that a particular OS is in significant use, and that OS has a number of crashes, we can deduce the priority of working on that issue and its effect on a large population of users.

The key takeaway is that we can learn a lot about our users and what they do, what they don't do and what they really wish they could do. We leave a lot on the table when we don't take advantage of what the code tells us... so lest's make sure we are listening ;).

Well, that's it for today, not counting socializing, schmoozing and dinner. Hope you had fun following along today, and I'll see you again tomorrow morning.

So Many Shades of Green: Day One at #esconfs

A first glimpse of Ireland from the air and in the airport.

Hello all and welcome to another Live Blogging extravaganza from yours truly. It's been a while since I've done one of these, but I am happy to be back in the saddle one again. My journey has already been an eventful one, starting with a flight from San Francisco to Washington DC, changing to another plane, then changing to another plane because an oven was on the fritz int the plane, and then a trans-Atlantic flight which literally just ended about an hour ago. A trip through Immigration, a hop on the Green Bus, and now I'm sitting in a large auditorium with Paul Gerrard chatting about what to expect over the next three days.


---

The first talk I am witnessing is courtesy of Andy Stafford-Clark and it's about "The Internet of Things ...it's Coming!" What is the Internet of Things? It's the interconnection of devices and information details that are not necessarily associated with the devices we typically refer to as Internet enabled devices. We've been focusing on the past three decades talking about computers, and phones and tablets and communication devices. Those are things that we are now well used to seeing, but what about the lights in our house? Our refrigerator? Our home thermostat? The train station display. Many of these devices are using homebrew tools (think Arduino/Raspberry Pi or other devices that can be created to control or set up servers that we can query, modify and update. To some, this is the epitome of nerdy, and for others, it's genuine and valuable information that helps us make decisions about what we can do (hmmm, that sounds familiar :) ). The goal of this initial and primitive "Internet of Things" as it stands today is that it is more of a fun curiosity for front minded nerdy types, but the promise of what it can offer is very compelling. What if we had the ability of actually putting together a clear understanding of how we use energy, as an example? We know we use water, electricity and gas for various purposes, but do we really know when we are using water? What really is causing the largest percentage of usage? Is it family showers? Laundry? Me changing out the water of the fish tanks? garden maintenance? How cool would it be if I could get an hour to hour breakdown of water usage each day and drill down to see various times? That is a perfect adaptation of the Internet of Things, if we choose to set it up and look at it.

Shall we get even more crazy? How about making a mousetrap that actually tells you when it has caught a mouse? Sound weird? well, with an Arduino board and a mechanical mouse trap, it's doable and Andy and his family did it.

All interesting insights, and novel uses, but how will this engage and interest the average everyday user, and when will we see the move away from the "nerdy" crowd towards the everyday people to use them. More to the point, how will we actually be able to test this stuff? Embedded systems knowledge will certainly help, but in many ways, Arduino?Raspbery Pi gives those who want to work in these areas some of the best up front training imaginable. So many of the systems use simple languages like Scratch or JavaScript (well, simple by comparison ;) ), and there will certainly need to be a change of focus. Awareness and familiarity of working with circuit boards helps, but the interfaces are not *that* foreign, thank goodness :). Some interesting issues sill need to be considered, such a how to power all of these devices, and utilizing ways to limit how they are powered (the goal is to make these options available without adding a large additional power load. Much of these devices are being positioned as solutions for helping people save power, so that's a creative challenge to consider. Additionally, there's the question of how to simulate thousands of devices running. How will we do that? How will we test that? These are questions that the next few years will probably start to provide answers for us. No matter how you look at it, this will not be boring ;).

---

Next up, Adapting Automation to the Available Workforce with Colm Harrington. This is a topic that has long interested me and has likewise vexed me in a variety of workplaces. Colm started with an anecdote referring to Einstein and examinations he was giving his students. They were the same questions, and when called on it, he replied "the questions are the same, but the answers have changed". Automation has changed in the last several years as well. The commercial tools have lost a lot of ground. WebDriver is currently king. The needs for automation are extending, and manual testers who exclusively do just manual testing are becoming more and more rare. All of us are doing some level of automation, but not all of us are seasoned programmers and software developers. We need to do a better job of bringing more people in the organization to be able to use and modify automation to be useful for more of the organization. It's a great promise and a wonderful goal, but how do we bring those to the table who do not already have a strong automation background, and more to the point, can we get the software out on time, under or at budget, without embarrassing errors getting into the hands of our customers? Automation is secondary to that, but still very important.

Colm's goal is not to have people get too detailed in the code, which makes sense with the topic. The goal is not to force testers to write automation, but to encourage them to get involved in a meaningful way and at the level they can be comfortable with. Automation can cover a lot of ground, but for me, the biggest issue is the tedious stuff of setup, population and traversal. Automation that addresses that area alone makes me very happy. Yes, it takes time to set a lot of this stuff up, but at least we have the ability of setting everything up from start to finish so I can get more deeply into the corner areas. When we have to set up everything manually, by the time we get to the places that are interesting, we end up exhausted, and less likely to find interesting things. To that end, automation can be done that doesn't require the programmer have an in depth knowledge of all the internals. Instead, we can be engagerd in focusing on the traversal steps we know w do all the time.

One of the biggest challenges that organizations have is that they do not have the ability or the time to take a full team and train them from scratch. However, if the team has taken the time to implement a framework that is easily modified, or that allows individuals on the team to get some quick wins, that will definitely help speed the success of individuals making their way in getting involved with automation. Using a Domain Specific Language or API, many of the steps can be compartmentalized so that the whole team can communicate with the same language. Will the toolsmiths have an advantage? Of course they will, but they will also be able to make a system that all of the participants will be able to leverage (think of Cucumber and the ability to write statements that are well understood by everyone). When the testers write the tests and cover various test cases, the testers knowledge is being used in a way that is most effective, with the programmers able to help fill in the blanks for the testers to be better able to focus on test design and implementation, rather than trying to wrench the tool to work for their benefit.

Some of the best ways to help make it possible for the testers and others to be effective is to keep things simple, consistent and intuitive. Keep data and test scenarios as clear from each other as possible, do the best you can to encourage a common language and linguistics between the code and the test implementations (use labels and methods that make sense by how they are names and what they actually do), and keep tests as atomic as possible (one test from beginning to end, in as few steps as necessary to accomplish the goal. Additionally, a key consideration is to balance the ability of the tests nd methods to be humane over minimal. Refactoring to where the intention is obfuscated is much less helpful as compared to allowing a little more verbosity to give all the participants a clear understanding of what's happening. Also, use the option to create soft assertions, which allow the user to check 50 different fields, notice the one place it fails, an inform at the end of the test rather than stopping cold at the first error it discovers with a hard assert.

Other important considerations: don't make something reusable if all you are doing is adding to its reuselessness. Let the client code shape the API, and don't have the API be set in stone. Dev's and QA need to work together, in either proximity or communication. If you can sit together, sit together, or share screens and talk together in the same time and space, if not the same proximity.

---

Next up is Rikard Edgren and "Trying to Teach Testing Skills & Judgment". This particular topic is near and dear to my heart for a variety of reasons, the most important reason being the fact that my daughter has started the process of learning how to write code with me. More than teach her how to code, though, I want to teach her how to test, and more to the point, teach her how to test effectively and with the ability to learn about what is important, not just doing the busywork associated with general testing. Rickard's model he is describing is a 1-2 year education arrangement, with internships and other opportunities to actually get into real situations. Rickard's approach and philosophy is as follows:

- Motivation is key
- Not for the money
- It's not about us
- Encourage new ideas
- Don't be afraid

Rickard mentions the value of focusing on Tacit Skills and Judgment, including asking good questions, applying critical thinking, understanding what is important to the customers, learning quickly, looking at a variety of perspectives, utilizing effective test strategies, and looking for those opportunities to "catch lightning in a bottle" from time to time (i.e. serendipity) and of course, knowing when good enough actually is ;).

Rickard  shred a story where he was working with a programmer who decided to try to be a tester and how, while he could see the problems left and right, the programmer didn't necessarily see the issue, or made assumptions based on how the code was being used. the key was, the tester wanted to see the problems. The programmers often want to get the work finished and of their plates (I totally understand this, and believe me, I make the same excuses when I am the one writing the code). This is also why I find it imperative that I have someone else test my code that I write, and not be afraid to tell me my creation is ugly (or at the very least, could be substantially improved ;) ).

Critical thinking isn't just that we question everything. We need to be discerning in the things we question. Start with "What if..." to get the ball rolling. This will help the tester start thinking creatively and get into unique areas they might not automatically consider. Also, be aware of the biases that enter you purview (and don't ever say you don't have biases, everyone does ;) ).

Everyone thinks differently, and the ability as a teach to be able to explain things in a variety of ways is critical. Likewise, we want to encourage those we are teaching to try a variety of things, even if the attempts are not successful or lead to frustration. we need to step back, regroup and give them a chance to look at what they did well, where they could improve, and how they can get the most out of the experiences. There will be theory and hard topics, and those are important, but always couch the concepts in practical uses. The names are not essential, the use and the understanding of how things work does (well, the names are seriously helpful to make sure that we do what we need to and can communicate effectively, but focus on what is being done more so that what it is called, at least at first. Once they get what is happening, the names will make sense ;) ).

Rikard has a paper that covers this topic. I'll reference it as soon as I get time to get to the link and update this stream of consciousness. Oh, and lookie lookie... green and yellow cards to manage question flow... now where have I seen that before ;)?

---

Next up, the closing keynote for Tuesday with Rob Lambert about "Continuous Delivery and DevOps: Moving from Staged To Pervasive Testing". I've often heard of this mystical world of DevOps, I've even heard of Continuous Deployment and heard rumors of people doing it. We do pretty well where we are, but we don't currently have a full scale Continuous Delivery system in place.  Still, there is a sense of wonder and appreciation whenever I hear about this in practice.

Rob spent the first part of the talk discussing what many of us know all too well, the long slog march of staged development, testing and release. Don't get me wrong, I am not a fan of this approach at all (too many years suffering through it), especially because, at the tail end, they would pull in everyone humanly possible to test a release (and ultimately, a condemnation for why software testing is ineffective, slow and boring). Yet ironically, the next project gets run exactly the same way.

This brought the big question to the fore; "why do we keep doing these massive, slow running releases?" When the customer needs change, we need to change with them, and big cumbersome releases don't allow for that. Major releases also require a lot of testing of a lot of code at one time, and that invariably means slow, cumbersome, and most likely not fully covered. Releasing in smaller and more frequent chunks means that less code, has to go out, less overall thrashing takes place, and the feedback loop is much tighter.

How to do that? Rob's Company chose to do the following:

- Adopt Agile
- Prioritize work
- Bring Dev and Ops together (DevOps, get it ;)?)
- Everyone tests. Testing all the time.
- The team needs to become one with the data, and understand what the servers are telling us about our apps and services

They removed testers from the center of the team. Note, they don't remove testing from the center, in fact that's the very switch they made. Testing always happens, and the programmers get into it as well. This goes beyond Test Driven Development. It means that automation is used to verify tests where possible, and a more aggressive approach to canning as many tests as possible, with a progressive march to get more coverage and more tests in place with each story. this is very familiar to what we do on my team. the automated tests are the things we want to run every time we do a build, so we emphasize getting those tests reliable, understandable, and easy to modify if needs be that we need to modify them. Ideally, the idea is to automate as much of the drudgery as we can so that we have fresh eyes and fresh energy to look at actual new features and learning what those new features actually do.

Cycle times vary, and each organization can modify and tweak the cycle times as they choose. If weekly is the shipping schedule you want to use, then your cycle time needs to be somewhere between four and five days. Dog fooding (or pre-production) is a life that we understand very well. It helps us se the real performance and actual workflows and how they are processed, and the good bad and ugly that surrounds them. Rob emphasizes exploratory testing be used along with the focus on automation, and an emphasis on the testing that is most critical. The key to success is a focus on continuous improvement and questioning the effectiveness of what you are doing. there will be political battles, and often, there will be issues with people rather than issues with technology or process. Additionally, everyone knows how to test, but not everyone knows how to test with relevance. Remove the drudgery where you can, so that opening the testers eyes and having fresh energy to tackle real and important problems is emphasized. If "anyone can test", then examine the tests that anyone can do, then ask critically if that testing is providing value.

---







More to come, stay tuned :)!!!

TESTHEAD Paddling Through "Uncharted Waters"

A couple of months ago, I agreed to come on as part of the team that writes an IT blog over at IT Knowledge Exchange called "Uncharted Waters". This blog was started by Matt Heusser a couple of years ago, and Matt invited Justin Rohrman and myself to write articles for the blog as well.

Since September, I have contributed a few pieces to the blog, and so far the reaction has been quite positive.

What did I not do? I didn't tell anyone HERE that I was writing them (well, outside of my little Twitter feed that appears in the corner of my blog). Needless to say, I am not doing well in the sphere of self promotion, but I aim to change that going forward.

For obvious reasons, I want to encourage people to read them. If you read them, and enjoy them, and comment on them and share them with others, that gives IT Knowledge Exchange, and other outlets, reasons to have me write more articles for them. It also gives me a chance to do more research, learn about different things, and develop ideas that I hope can benefit all of us.

So to that end, here are a few links to recent entries.

Twenty Years, Seven Companies, Nine Different Styles of Testing

Your First 30 Days in the New Gig (and if You’re on the Old Gig, They Begin TODAY)

Create Your Own Career Trajectory

Using Collaborative Tools To Improve Software Work

The Art of “Making Time”

My View of the Future: Mixed, but Guardedly Optimistic


These articles have been interesting opportunities for me to go into areas I don't normally talk about, and share my message with people who may not otherwise read it here. I would also like to encourage my regular readers to check out these articles as I write them, and perhaps add Uncharted Waters as a regular part of your daily or weekly read (Matt and Justin publish some great stuff). It's been a pleasure to get into the groove of this initiative with them, and I look forward to future entries, both there and here.

From TV to Social to Accessible: "Meandering" Through 23 Years of Software Testing

An interesting milestone just happened today, and I wasn't really even aware of it. I came in to work this morning and received a nice message from a co-worker in another division wishing me a Happy 2nd Anniversary with Socialtext.

Wow, two years?!

It seems like so much time in some ways, and it seems like so little as well. I remember first getting here, being nicely thrown off the deep end into our setup and getting my development environment running, and acclimating to life in a testing team after so many years of going it alone. Within those two years, we have seen changes, we've seen ups and downs, we grown and contracted, we've realigned and integrated, and I've had my chance to learn a few new tricks.

Looking back, I realized that I hadn't updated my Meandering posts for the last couple of years. This is meant to be a chronicle of my career path and the many places it has taken me. It also seems appropriate to mention a few other things that are taking place in my reality that might explain the limited postings lately here on my blog. For those curious about both, please read on.

As we last spoke, I was working with a young and energetic Agile team in the guise of Sidereel.com. The work I was doing introduced me to performing automation in a way that was unique to a front facing role, while still allowing me to delve into writing automation for myself and my efforts. The code was treated like development code, checked into Git, distributed with each release, and expected to run and pass before we went forward with deployments. It was an enjoyable experience and gave me a chance to dive into Ruby and Rails more than I had previously. I dedicated much of my free time to absorbing Zed Shaw's book "Learn Ruby the Hard Way" and putting those skills into practice. Any book on Cucumber, BDD, ATDD, Ruby or automation I could get my hands on was fair game, and I devoured as many of them as came my way.

Part of me was hoping that this would light a spark in me to become more enthusiastic about writing code and taking on more coding responsibilities. Well the latter definitely proved to be true, and I will say that I found myself learning quite a few neat tricks around object-oriented programming. I also picked up some understanding of modern web design and full stack development. However, that boost in joy and confidence and a surging love for programming, that didn't quite happen. In some ways, I still look at writing code the same way I do about cleaning out the garage. It's a necessary task at times, but not something I want to do every day. Actually, to be honest, I like cleaning the garage a little more than that.

One indelible change in my life happened while I was at Sidereel, and it's one I will feel the after effects for the rest of my life. On August 29, 2011, while I was riding my skateboard from work to the train station, I hit a crack in the road, and I was sent flying. The landing was bad. I broke through my right tibia near my ankle, and snapped my right fibula up near the knee. The resulting surgery, and plate put in my leg to allow the tibia to knit back together, took me of my feet for a month, and made it necessary for me to work from home full time for six weeks, until I could get back to walking far enough to make the trek from the train station to the office. The resulting experience showed me that I could be effective both in person and even when I was on my own at home for an extended period. At the same time, it made me start to wonder how much of the team I actually was, if I could do so much of my work outside of the core scrum team.

As many testers have probably seen, integrating with an Agile team is often an unusual dance. I would have to say that Sidereel did a good job of balancing the programming requirements and fulfilling the goals and objectives that makes for an Agile team, but more times than not, I felt like my being an embedded tester was a secondary thing. The Programming team was Agile, but I was a Waterfall tester. to be fair, I do not think that was at all the intention, but that's just how it worked out. Often I found myself struggling to understand what issues really mattered, what areas belonged to who, and how I could communicate effectively. If I asked too many questions, I was a disruption. If I asked too few questions, I was aloof. More to the point, I found that I didn't have anyone else I could really talk to if I had questions about my methodology and approach, and how I could work more effectively with the team. Over time, this became a wedge. I didn't want to see it then, but I can now appreciate the fact that my desire to insert myself inside of the team early in the process was what I wanted to do, but it wasn't what they wanted. My view of an Agile tester and the teams view were different, and I didn't appreciate that fact until later.

As a lone tester on such a massive product with so many moving parts and interactions, I had my share of misses and "whoops" moments. There were times when things that seemed like obvious "why didn't you catch this" situations happened regularly enough to where I just didn't want to talk about them. In my mind, just keeping up and doing my job, and being careful were the essential elements to being successful. However, that slowed me down, and I was perceived to be the bottleneck. For many of the situations, I think it was absolutely correct.

One of the most frustrating situations to find yourself in is to have one on ones with your director and to hear "you are doing a good job, but...". As the months progressed, I felt like the "but" in that line was becoming more and more pronounced. You missed this issue. You are taking up too much of the developers time. You need to be more independent. You need to focus on deeper and more critical bugs. Every one of these was true, don't get me wrong, and every time I sought to do exactly that, yet every time we cam back around, it felt like the same conversation. My friend Matt Heusser calls this situation the "I want a rock" problem. The idea is that someone asks for a rock. When you bring them a rock, they say "that's not the rock I want, I want a different rock". Over time, as we keep bringing different rocks, it becomes clear that what is being requested is not the rock being presented, it's who is doing the presenting. It was becoming clear to me that being a Lone Tester in this environment was perhaps too much for me. Perhaps if we had all been clearer on the expectations from the outset, or how we all wanted to work together, the outcome could have been different. Regardless, I found myself in a situation where there was mutual frustration. the programmers weren't happy, and neither was I.

I sent out a message to a few of my friends, saying I was feeling frustrated, that perhaps my role as a Lone Tester was burning me out, or that I was possibly not the best fit for Sidereel at this stage of the game. In short, I wanted to explore other options. I was open to managing a team, or mentoring other testers, or doing something with an organization where my only stipulation was "I don't want to be a Lone Tester this time around". Shortly after I sent that message, my friend Ken Pier contacted me and asked if I'd be interested in joining his team at Socialtext. Ken had met me two years before through Matt. He'd been to several conferences and meetups where I had participated and been a correspondent. He'd attended a few of my talks, including my "Balancing ATDD, GUI and Exploratory Testing" presentation. He had also read my blog for the past couple of years. In short, Ken knew what I could bring to the table, and what I could not. He explained that he was building a team of seasoned testers; he wanted people on his team who really understood software testing, and he proved to me that he understood it to, as well as what it can and cannot do. Through further conversations with him, and some casual conversations with some of his co-workers, I made the decision to hang up the Lone Tester mantle and focus on being a team tester once again.

Over the past two years, I have worked with a team of awesome people. They introduced me to a Kanban approach to software development, had me get intimately involved again in automation, albeit in a way that was totally different than anything I did at Sidereel. I also was asked if I'd be willing to take on a special initiative. We had performed an accessibility audit and had discovered many areas where we needed to make improvements, and the testing needs for that would require someone willing to spend a fair amount of time with screen reader and dictation software, among other things. I decided that, yes, I would be interested in doing that. I had no idea at the time that what I'd be asked to do would have such a fundamental effect on what I do, but in the ensuing two years, accessibility has become one of my core competencies, and the language of and advocacy for accessibility features would come to permeate so much of my world view. Prior to this, I had next to no understanding of what Accessibility really meant. Now, I'm the go to person.

Another thing that was also very helpful is the fact that Ken (my director) is a member of the Association for Software Testing. He understands my involvement as a board member and as an instructor, and has actively encouraged the initiatives we have championed through AST be used here at Socialtext. I've also been able to use Socialtext as an application for various testing challenges, such as Weekend Testing and the Software Testing World Cup. that feedback has helped us make a better product, and that connection to a broader community of testers has been a long term commitment of Socialtext as well (did I mention that Matt worked here before I did? If I didn't, let me fix that. Matt worked at Socialtext before I did, so he plowed a lot of ground that allowed me and the rest of my team to reap the harvest he'd sown years before).

This year, I was selected to be the President of AST, with the full backing of my team at Socialtext. Being able to be the advocate for testing that I see myself being, as well as doing work at a company that is fun, engaging and interesting, with a team of people with as much experience as I have, if not more, and the opportunity to mentor younger testers when we get the opportunity... it's been a lot of the reason these past two years feel like they have gone by so fast.

So what pearls of wisdom can I share since my last Meander?

-- it's important to understand how your team works. More important is understanding how your team wants to have you work with them.  It may seem trite or silly to say "make sure you understand what your programmers want from you as a tester", but it's not a trite question at all. They are your customers, you provide a service to them. It is in your best interest to understand what makes them comfortable and helps make for a mutually effective relationship.

-- you cannot test quality in, you can only tell people where issues may be. This keeps getting hammered into me everywhere I work, but I think it bears repeating. At the end of the day, I do not make the choices as to what ships and what doesn't. I can be overruled, and I need to be OK with that. If my information helped them reach a decision, then that is good enough.

-- being a lone gun is hard, and it can be lonely. Moving to a team does not automatically fix that. A team has to engage in a different way, but it also require a meshing of personalities and work styles. I came in with an idea of "I know testing, I'll be able to swing everyone around to my way of thinking in no time. truth is, I learned a whole lot more from my team than I thought I would, and realized that I didn't have all the answers. Not by a long shot! With a team of seasoned veterans (of which I am one of the younger ones, I might add ;) ), we've melded our skills and abilities quite well.

-- be willing to take on a "problem child" issue when it is presented to you. When the opportunity came up to work on accessibility issues, no one else was enthusiastic about working on it. I could say "ignorance is bliss" because I said "sure, I'll do that" with the attitude of "how hard could it be?". Well, when you find yourself surrounded by machines that are rapidly talking at you, or you find yourself plugging in a headset mike to "talk to" your computer on a daily basis, it can get irritating. Still, working through the irritations can help you develop unique proficiencies, and then being the person people can rely upon to consult on issues around that area makes up for a lot of annoyances, and now, I actually like tinkering with the accessibility tools.

-- automation is an ongoing need, and more and more businesses are utilizing it to get the repetitive stuff off of their plates. Do not fight this, in fact, do your best to become part of the flow. Whether that means you actually program, or consult with those who do, put yourself into the process. What you learn may have large impact on the amount of time you spend doing repetitive tedious busywork. If you can automate that busywork, then you save your eyes and your energy for much more interesting territory to explore :).

My thanks again to Socialtext for what has thus far been a very rewarding and engaging two years. I look forward to what tomorrow brings!

The Sins of Those Who Came Before

I'm tired, I'm bumped up, I'm skinned up and I have learned a whole lot more than I intended to when I went in. Sounds like  I got into a bar fight, doesn't it. Actually, I had a three round bout with my bathroom sink. The good news is, it's been replaced, it works as intended, and I know a whole lot more than when I first started this whole process.

A few weeks back, we noticed that the upstairs bathroom sink was leaking. Just a little at first, but over ensuing days, it got progressively worse, to the point that I had to do something about it. The last time this happened, it was just a washer to be replaced. Fairly simple, I can do that, and did a few years ago. This time, I went in and did the same thing. I put everything back together, and when I turned on the hot water, it came out as a trickle. What? What would be causing that? I looked at everything again, checked to make sure that everything was seated right, turned on the water again, and yet again, hot water was a trickle. Hmmm, this meant I was going to have to go under the sink to figure out what was going on. I never relish this process, not b ecause I'm afraid of plumbing, but because I'm afraid of finding what one of the previous owners of this house did to make the system work in the first place.

Some back story... when we bought the house fifteen years ago, there had been a number of remodeling jobs done to the house, including an upstairs addition and a partial kitchen update (mostly lighting. A couple years in, we decided we wanted to redo some of the kitchen, and we called a contractor to help us scope the job. The contractor brought an electrician over to help with the estimate, and when he saw the switches on our wall, he yelled out to his partner "Hey Kenny, come get a load of this!" Trust me, a sentence like that does not instill confidence. The switches that were being used were from an industrial site. They were not up to code, or even close to it. Turns out that the previous owner who did the remodels was an industrial electrician, and apparently he "scavenged parts from his various jobs" to do the remodels. We had to pay a lot extra to undo much of what they did. We had thought we'd seen the last of the surprises, but no, I got to see another one first hand. Under the sink was a range of snaking pipes, strange silicone wraps, and parts that looked like they'd been welded together, In addition, I saw what had happened, the copper pipe had twisted, and was constricting the flow, mainly because the pipe was wrapped around a tight corner. Again, I don't want to think of how this was put together, but now I had to take it apart.

An early morning trip to Lowe's (thinking about Mike Lyles the whole time and thinking he'd get the biggest chuckle out of this situation), I picked up a nice, modern, clean looking wide spread bathroom faucet, and then went home to read instructions and brace myself for the mother of all home repair fights. Yep, it turned out to be just about that bad. I had to cut hoses, break pipes, and pop welds to get the parts loose, not to mention gobs of silicone in the threads that made getting it out a royal nightmare. I pride myself on not cursing, but today, you would have hear my inner sailor loud and clear at pivotal moments.

After what should have been a fairly routine lunch time break, I emerged victorious, but a bit humbled, a bit bloody in spots and frustratingly realizing I may have more "sins of my predecessor" to deal with in the future.

All of this is to say, for those of you in the here and now, I know it may be tempting to take a shortcut, to avoid some area because it's too time consuming, or think that you are able to do something at an incredible discount because you have access to stuff. Truth is, parts misused can cause tremendous problems later on, and in most cases, the person cleaning up the mess will have no idea what happened or went on before, just that they have a royal mess on their hands and they get to be the person to clean it up. To that end I am really trying to be a good steward with my home, and also when I test or hack code. Pennies saved now, a little time shaved off here and there, in some cases are positive and efficient, but in other cases, they can be really tricky, really annoying, and potentially fill a future homeowner, programmer or tester with murderous rage, at least temporarily. When in doubt, figure out how to do it right, or at least as right as you possibly can. Don't make people in the future pay for your sins, it's really not nice.

There's Nothing Wrong with "Ordinary"

One of the things that I have found interesting over the past few years is the perceptions people have and how they deal with them in regards to their own potential, and what they can actually do. I've been struggling as of late with a harsh realization. I am not brilliant. I am not amazing. I am not a genius. In most ways, I am noteworthy for the fact that I am so very "ordinary". Yet many would rebut that statement and say "that is not true, you are far from ordinary", as though ordinary is a curse word or an epithet.

I've been thinking a lot about this the past several weeks as I have watched my daughter and her growing tribe of people who appreciate the efforts and abilities she has in the artistic sphere. Here I risk no hyperbole. My daughter is an excellent artist, for her age or any age. She has gone from being someone who loves to draw and making cute picture to making really good pictures to making "oh my goodness, where in the world did that come from?!" pictures. Her Instagram account has 30,000+ followers. That's more followers than I have in every single social media account combined ;). So many people post comments to her pictures and say "wow, that is incredible, I could never do that!" She handles the compliments with a very sweet grace and courtesy, because only she knows the truth. In most ways, she is a very ordinary girl, and in some ways, she has several unique challenges that put her at a deficit compared to many of her peers.

My daughter has a triple whammy of vision issues. She has amblyopia, strabismus and astigmatism. On top of that, she is also far-sighted. Most people don't realize that, when she wears her general purpose contact lenses, people are blurry if they are more than 30 feet away from her. The glasses she needs to wear when she doesn't have her contacts in, that allow her some better distance vision, give me a headache to try to look through. Yet with all these frustrations, she has one very neat positive effect... she can see up close very well. It's because of this little quirk that she has been able to develop an eye for close details that has enabled her to become exceptional as an artist over the past few years. Still, even with the talent, and the close up ability, what has set her apart is the fact that she put in an incredible amount of time to hone and perfect what she does. She stays up way too late for my personal comfort most nights. She sometimes struggles with other aspects of her life, such as school work, organization, and at times her health has taken a hit or two. Yet she perseveres, because she knows that she is ordinary, and she has decided that the only way to transcend ordinary is to work at what she can, and use every day to get a little better.

She's a stellar reminder to me that we are all ordinary, and there's nothing wrong with being ordinary. What's wrong is if we use "ordinary" as an excuse, as a way to say "oh, I could never do that, I don't have the talent or a special gift". Here's the good news... you don't really need special talent or genetic blessings, at least not for most things. Being an NBA basketball player, OK, you may have some problems if you are 5'4", but that doesn't mean you still can't play an excellent game. Likewise when I find myself frustrated with my own technical skills, or lack thereof, and I want to wallow in the comfort of being "ordinary". It's OK to be ordinary, everyone is, but it's the one's that work hard enough to push past others that make them "extra-ordinary". My thanks to my daughter for the continual reminder, and a desire to keep pushing the level of what "ordinary" can do.

An Alternative Approach to Teaching History?

Over the past several years, I've found Dan Carlin to be one of the most entertaining and thought provoking podcasters that I've listened to. For some, he is grating, irritating, and frustrating. He doesn't use the standard narrative. In fact, he steadfastly refuses to. Both of his podcasts, Common Sense and Hardcore History, strive to look at current events and history from what he calls a "martian" perspective. In many ways, I consider Dan to be the most "testerly" of podcasters. He strives to take views and commentary from all sides, consider the possibilities and the arguments made, and then presents them in a way that boils down to central themes and core ideas.

In his most recent podcast (Common Sense 281 – Controlling the Past), he makes a few points that I think would be immensely helpful in regards to not just K-12 education as it relates to history, but the entire way that we teach any subject. Perhaps it's the contrarian in me, or perhaps it reflects my own frustrations and misgivings with the way that school is taught, but I think we do several things wrong, and the net result is that many children develop a serious aversion to actual learning and discovering the joy of learning and education.

I am currently living this reality with my three children. I now have a college freshman, a high school sophomore, and an eight grader. I see what they are currently trying to do to get through their days in their various schools, and the adaptations each has to make. Ultimately, though all three are slightly different, they tend to suffer from the same problem. We operate our schools on the notion of facts and figures and dates and formulas that need to be memorized, need to be spit out on tests, evaluation is made, and then we move on to the next bit. Sometimes, this works well. Sometimes, it doesn't. As an adult who works in an ever changing landscape, I've had to embrace a different approach to learning. Also, as a software tester, I've had to often approach learning from a skeptical and often even cynical viewpoint. I'm not paid to say the product works. I'm paid to try to find out where it might be broken. My entire workaday life is the process of disproving and refutation... and I get paid for that ;).

Back to Dan and this podcast... one of the things that Dan highlights, especially in history, is that we tend to go through waves of revisionism. Fifty years ago, the Founding Fathers were near mythical deities. today, in many circles, they are seen as greedy despotic "white men" who built a society on a veneer of freedom at the cost of slavery and subjugation of others. every few years, there seems to be some tug of war about whether or not we should be exposing every one's sins, or instilling virtue through printing hagiography. Dan's thought, and one I share, is "why are we doing either?". In other words, if we truly want to teach history and what has come before, why are we necessarily giving one narrative more air time than others? What if, instead, we did something similar to what the news magazine "The Week" does? For those not familiar, The Week is a journal that presents many of its stories and headlines as a distillation of a variety of views from different sources. If a topic is going to be presented, it would take headlines and stories from both "liberal" and "conservative" pundits, publications and writers, and generally avoid making an editorial of its own, with the exception of actual editorials that it publishes, and clearly states as such that the writers are doing exactly that.

What is the purpose of this type of presentation? It actually allows for the reader to synthesize what they are reading, see the various viewpoints, the pros and the cons, and even the inherent biases of each side, and then leave it up to the reader to reason out what they are reading and what it actually means. It also helps give a more balanced view of the events and the key players. Rather than force a viewpoint based on an ideology, it allows the reader to process what they are seeing and apply their own litmus test to the material, and let them look for the coherence or the inconsistencies, something that testers are very well familiar with doing. Think about what history would look like if we allowed this same approach. We don't tell the story or George Washington or Geronimo or Martin Luther King from just one side. It isn't hagiography or character assassination. It isn't sanitized or prettied up to meet an agenda. It's given as is, with the idea that the reader discovers who the people actually are, and that they really are just that, they are people. Possibly extraordinary, possibly flawed, almost always misrepresented. Gather multiple views, present them as is, and then let the student actually practice some critical thinking skills, synthesize the data presented, and then (gasp!) actually give an opinion or discussion on what they've covered.

It's possible I may be completely insane proposing such a thing, but ultimately, I think the benefits would be huge. We talk a mean game about the importance of critical thinking. Wouldn't it be awesome to actually let students, I don't know... critically think?! Also, and I may just be speaking for myself here, but wouldn't this also make the idea of studying history (or any other subject) way more fun? As a tester, the ferreting out of the causes and effects, and advocating for the information discovered, is a huge part of the fun of testing. How great would it be to actually let students experience that in their everyday learning?

Again, it's a scary and bold proposition, but I'm just crazy enough to think teenage students are able to handle it, and might actually learn to enjoy these subjects in a way they've never really been able to before. What do you think? Realistic objective? Pie in the sky dream? If you had the chance to reshape how primary and secondary education were presented, what would you do?

Does Net Neutrality Matter to You? It Does to Me!

As I'm sure many of you already know, today is the 'Internet Slowdown".

Tens of thousands of websites are currently running the slow-loading icon to symbolize what the Internet would be like without Net Neutrality. TESTHEAD is part of that tens of thousands. I'm happy to join with sites like Netflix, Vimeo, Google, reddit, Kickstarter, Meetup, Upworthy and countless others who also taking part in this.

The FCC's comment period ends in five days! If you want to make your voice heard, please feel free to use the Internet Slowdown widget that loads when this page loads to do so.

In fact, don't just feel free to do it, I urge you to do it :)!!!

If you've already commented, you can also use the widget to call Congress.

Below is the statement from Team Internet, one I am happy to share:

We believe in the free and open Internet, 

with no arbitrary fees or slow lanes for sites that can't pay. 

Take a stand for "Title II reclassification," the only option 

that lets the FCC stop Team Cable from breaking 

the key principles of the Internet we love. 

Will you join us? 

Take Action.

When Things Just Aren't What They Seem

Truthfully, I hoped I would never have to write a piece like this. However, the last couple of weeks have made it so that I can't seem to write anything without this taking up the forefront of my mind.

Twenty seven years ago, I met a guy, a little older than I was, in the San Francisco Bay Area music scene. We were both relative newcomers, working on getting our first bands into the clubs. We had similar backgrounds, similar family lives, we were elder siblings with wild dreams, and we were both a bit on the gaudy and goofy side. I mean that in the absolute best way possible. We both had a penchant for garish clothing, big poofy hair, enjoyed being creative, and making things that we felt spoke to our individuality. We also both loved combing through the bargain bins at Tandy Leather Company, picking up whatever inexpensive notions we could find or afford, and making our own stage clothes with them. One night, I went out to promote for one of my band's early shows and ran into this guy, doing the same for his band. We looked at each other, pointed, laughed and said "dude, nice Tandy Leather bargain find"... and then laughed some more. We started talking. That's when I first got to know a wonderful man, and a friendship developed that would span several years and several bands, for both of us.

We became good friends, albeit in a "band rivalry" kind of way at first. We'd always high five each other for the shows each other was playing, but always in the back of our minds, we kept a tally:

"Hey, congrats on your first Friday night gig!" (we just nailed a Saturday slot).
"Dude, you're opening for Band X? Awesome!" (we just inked to play support for Band Y).
"Hey congratulations for headlining at the Omni!" (we're headlining at The Stone).
"Aww, dude, we're playing the same night? What a bummer!" (I'm totally stealing your crowd).
"Dude, you're gig drew 700 people? That's awesome!" (ours drew 800).

and on and on and on... and we would always laugh about it. We started as rivals, became friends, and in time, became like brothers.

We'd been there through each others ups and downs, the high points and the low points, the transitions that looked like bright futures and the valley where we felt we'd screwed everything up. In 1989, I really felt like I had missed everything, that I'd made a terrible mistake leaving a band that had a solid track record & history and venturing out on my own. It looked all so promising at first, but then, misfire after misfire, in the latter part of the year, I was band-less and alone, and felt like I might never perform again. He jumped on top of me at a club one night while I was feeling down, and in his ever sunny, ultra-cheerful way, gave me a pep talk, told me I just needed to have some faith, keep pushing, and not give up. He believed in me, and knew I'd find something much better than anything I'd been through thus far.

He was right. About two months after that particular pep talk, I agreed to go check out some friends from another band that I'd actually written off before, but decided to give them another look due to the fact that they had two new guys join the group, and they brought a whole new sound and energy to what they had been doing. With that, I decided I had to give them a listen. Subsequently, I joined High Wire, the band that would ultimately be the best group I'd ever perform with.

As things tend to happen, life wanders and meanders, and ultimately, my time with High Wire and with professional performance would come to an end. I'd get married, start a family and change careers, becoming a software tester. My friend would likewise move in different circles, relocate to Los Angeles, and have his own meandering river to follow. We'd reconnect several years later, first through mySpace, and then through Facebook. We'd touch base a time or two, here and there, we'd talk about old gigs, new challenges, where each other was in life, and how we'd gotten knocked down but always got up again. Through it all, my friend had that super sunny disposition, that "Shaka" sign we'd alway throw each other, telling each other to just "hang loose". We'd been buffeted, we'd tumbled and been knocked about, but we always knew we were all right and we'd deal.

On August 26, 2014, the biggest miss of my life took place. Me, the software tester, the one who says never to take anything truly at face value, woke up early to work on a project, and while reading Facebook, saw a post that shook me to my core. It was my friend, my long time, happy go lucky, super positive friend, saying goodbye. Goodbye to everyone. Goodbye to life. And with that, all went quiet. I couldn't believe what I was reading. I wanted to believe it was a joke. It had to be. Maybe it was some trigger and he'd come back and apologize, say he was sorry for getting carried away, and all would be well. We who were his friends went and checked with his family, other friends, those of us who could spent the next few days talking to each other, getting the word out, trying to do anything, by whatever means necessary, to find him. We donated money to Search and Rescue efforts. We asked for friends to share details about him with their friends. Most of all, we did not sleep, we did not eat, we stood at hair trigger attention. We had to know. Was he OK, or not? Was he with us, or not?

Sadly, on Friday, August 29, 2014, we discovered the news. He had been found, on a remote beach in Maui. He was gone. Our efforts to alert the media, to get Search and Rescue teams out to look for him, to get flyers all over the island of Maui and other islands in Hawaii, were what had primed the Park Ranger to be looking for him. When he was discovered, they were able to make an identification; it was indeed him. A bright candle in many of our lives had been put out.

The days since have been challenging. I have so many questions. My heart aches to realize that a friend who was always there for so many of us, to cheer us up in our darkest moments, reached out to none of us in his. We had no clue. Many of us would never in a million years have believed this would happen, certainly not to him. It just made no sense. Yet once we started looking back, over the years, to the challenges and issues he faced, and the ups and downs that went with them, we realized a deeper pattern, one we hadn't seen, or really, one we didn't want to see. That bright and sunny disposition was masking what were to him years of deep disappointment and unfulfilled dreams, of recurring problems and painful memories, to a point where he believed that it would be better to end it instead of moving forward.

I'm left here today to think "What could I have done? How could I have helped? Couldn't he call me?" and realizing that I was asking someone to make a step to a friend that was casual at best today. Of all people, why would he have called me? If so many much closer friends were not reached out to, why would he choose to reach out to me, an old band acquaintance from 20 years earlier? The fact is, my connection with him wasn't strong enough to be that kind of a lifeline... and that realization stings now.

For those who have kept reading through all of this, I thank you. It's not my usual topic, and I'm afraid I'm stumbling here, but if there is anything these past two weeks have taught me, it's to trust those weird feelings we sometimes get. It's to not believe the gloss and the sheen on the surface. I know this from software. The prettiest products often hide the most devastating bugs. I fundamentally know that about products I test, but putting that same reasoning to human interactions is much harder. Still, part of me now feels, after looking back at conversations and interactions, the clues were there. They seem obvious now, but I missed them then. In software, when we miss a catastrophic bug, we learn, we regroup, and we try again, to make sure it doesn't happen to another release. Sadly, today, this miss can't be called back, It can't be patched. We cannot release an upgrade.

My hope with this post today is that I can ask my friends, my readers, and anyone who comes across this post in the future to do me a favor. Never take those relationships you have for granted. Be they your friends, your family, your co-workers or even casual pals from a scene you may share, look to see if there is something that might be a warning sign. If you think you may sense something, and your gut reaction tells you things may not be all right, reach out to them. Talk to them. Let them unburden if they choose to. If they don't, let them know you are there for them anyway. Do everything you can when things just aren't what they seem. You may do more than just cheer someone up. You may save a life. My friend has shed the pain he was feeling. It is no more for him. For those of us who are left behind, we will always wonder "What could we have done?" The simple answer at this point, and the painful one, is "Nothing, but maybe, just maybe, we can be more alert to help see that it doesn't happen again".