I think it’s certainly worth considering – I mean, how’s the old saying go, something about learning something new every day? In our day and age, and especially in the software development arena in which I work, there’s always something new going on, a new challenge to overcome. Dan Pink, author of Drive, talks about our desire for Autonomy, Mastery and Purpose — Mastery is the urge to get better and better at something that matters. I hope you’re not stuck in a position where you’re not learning, where you don’t have an opportunity to improve your skills.

So, assuming that you’re learning something at least once a week, what are you doing with that knowledge? Are you sharing it with your co-workers, with your peers, with others in the industry?

There are plenty of reasons why some people don’t blog publicly. Some ideas are considered proprietary; sharing them outside of your company is frowned upon or may even be a fireable offense. Consider though, are you at least sharing your learning with others inside your company – via an internal Wiki, blog, or newsletter? Does your team get together for lunch and talk about what they’re doing and how they’re doing it? If not, what does this say about the investment you and your company are making?

Once you walk out of the office at the end of the day, your brain (hopefully) doesn’t stop working, and neither does your opportunity to learn and to help others. During my time as a leader in a Boy Scout troop, one of our ongoing philosophies was that we learn best by teaching. When a boy said they didn’t know how to do something, we’d get them somem instruction and ask them to be ready to teach a few other boys at the next campout.

So when you’ve just overcome a problem that’s been bugging you for a few hours, learned a new programming pattern, or discovered a new tool that saves you some time, it’s time to teach someone else. Generalize the challenge, so you’re not giving away any of your company’s trade secrets. Start by explaining it to your favorite rubber duck, then get your explanation down on paper – or at least in a text editor. Send it out to a few trusted colleagues, or start a simple blog. You don’t have to advertise it widely if you don’t want – just the act of writing it will solidify the concepts and lead you to learn it more in-depth. This is also a really great confidence-builder: As you keep doing this, you’ll start to realize that you are becoming an expert, that people are looking to you for answers, and that your boss should realize what a valued employee you really are.

Here’s an advanced step. When you’re ready — or even better, before you think you really are — stand up. Give a talk on the subject at your office. Get involved with a tech meetup in your area and offer to present it there. People aren’t looking for perfection; they’re looking for you to share what you know and how you’ve learned it (including the stumbles along the way).

Of course, to circle back to Adam’s point (or what I believe it to have been), perhaps the lack of blogging from your team is pointing to a lack of challenge, a lack of learning. Then yea, “you likely have a problem.”

Agree? Disagree? Add your thoughts to the comments here or join the discussion over on Twitter.

I am trying to find the answer to one apparent shortcoming when compared to other services.

When I create a “radio station” on Pandora, I can seed it with as many songs or artists as I’d like.

I haven’t found a way to do this with Google Music All Access – once a station is created based on one artist there doesn’t seem to be a way to add more variety or refinement to the station’s definition.

If you’ve figured out a way to do so, please let me know.

Over the past week or so, Andrew Fuqua (@andrewmfuqua) has given workshops on Acceptance Test Driven Development for both the Atlanta Quality Assurance Association — an organization that, I’m embarrassed to say, I didn’t know existed until I heard about it via Twitter (of course) — and the Atlanta Scrum Users Group.

Andrew comes to the topic from his role as an Agile Coach and emphasized communication, communication, communication. ATDD, as we discussed this evening, is all about getting “the three amigos” — Product Owner (a role he asked me to fill for the AQAA workshop), Developers and Testers — together to communicate. The intent is to discuss the details of requirements (often written as User Stories these days) and distill them down into a minimum set of examples in order to provide clarity. Another, perhaps better, term would be Specification By Example.

Here are a few of my scribbled notes from the two evenings:

• Why do software have bugs? Many reasons, but most often because of miscommunication between humans – especially around requirements.
• We humans have a tendency to assume ill intent (why is this?) where often misunderstanding is more likely the cause.
• A feature or product request often starts with some sort of concrete example, which gets thrown away as more general requirements documents are written. Let’s get back to examples as part of the requirements
• Business rules are more likely to be stable than user interfaces. Therefore examples should be in business language.
• Cognitive dissonance (discussion between people with different viewpoints, different skill sets, different ways of thinking) can facilitate exploration and improve understanding. Involve product owner, developer, tester, business analyst, customer if possible.
• Don’t get lost in the details.
• We all have too many meetings. Don’t create another one for this discussion/distillation activity. Hold a specification workshop instead.
• Discuss, Distill, Develop, Demo (explore). Lather, rinse, repeat.
• Distill the list of examples down to the bare minimum, a minimal set of both “passing” and “failing” examples. One example per business rule.
• There is value in the discussion and distillation even if the examples are never codified into automated testing. Communication is the goal.
• ATDD != TDD. TDD guides design of code. ATDD guides clarification of requirements.
• ATDD is done before — and throughout — coding/testing.
• Best captured in some sort of living document (no specific tool recommended, but a wiki was mentioned)
• The results should be owned by the product owner, not developers or testers.
• It’s not about testing, it’s about communication.
• “Don’t invest in something that nobody gets value from.” – Claire
• “Design a level of testing that is commensurate with risk tolerance. Don’t dabble in automation. Do it well to keep it – or toss it.” – Sellers
• Understand Brian Marick‘s Agile Testing Quadrant model. (see this and this) – Alex

And some of the resources Andrew mentioned:

• Specification by Example: How Successful Teams Deliver the Right Software, and its predecessor Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing.
• ATDD by Example: A Practical Guide to Acceptance Test-Driven Development
• The ATDD Arch and Driving Development with Tests: ATDD and TDD by Elisabeth Hendrickson (@testobsessed).

The discussions did also touch on the topic of test automation. Again, no specific tools or technologies were covered or recommended, but a couple of good points were raised. I was especially pleased to see many heads nodding in agreement when Andrew said that “test automation is software development, and should be treated as such.”

This was a good workshop, and I’d like to thank Andrew for his time (and for letting me help where I could be of assistance).

On day two the question was raised: “what are you reading or do you recommend?” The following is the list that was produced. This is completely non-edited, everyone was welcome to post their recommendations and talk a bit about them. I am not endorsing all of these; many I’ve not read and a few I’d not even heard of before. Heck, there wasn’t agreement among all the participants on every book, some resulted in quite a discussion.

Note to the participants – I went from our hand-written notes on the wall; if I’ve mis-read something or found the wrong book, please let me know and I’ll update this.

disclosure: all these links are tagged with my Amazon Affiliate code — if you purchase through these links I’ll get a small percentage (which will undoubtedly go toward more book purchases), and I’ll be able to see what books were purchased (but not by whom; Amazon respects your privacy at least that much).

• Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
• The Catalyst Leader: 8 Essentials for Becoming a Change Maker
• Start with Why: How Great Leaders Inspire Everyone to Take Action
• The Hero with a Thousand Faces (Bollingen Series, No. 17)
• Artful Making: What Managers Need to Know About How Artists Work
• Orbiting the Giant Hairball: A Corporate Fool’s Guide to Surviving with Grace
• The Checklist Manifesto: How to Get Things Right
• The Five Dysfunctions of a Team: A Leadership Fable
• The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t
• Cutting Through Spiritual Materialism (Shambhala Library)
• Self-Compassion
• What Every BODY is Saying: An Ex-FBI Agent’s Guide to Speed-Reading People
• Getting to Yes: Negotiating Agreement Without Giving In
• Negotiate This!: By Caring, But Not T-H-A-T Much
• The Trusted Advisor
• The Secret Knowledge of Water : Discovering the Essence of the American Desert
• House of Rain: Tracking a Vanished Civilization Across the American Southwest
• The Monkey Wrench Gang (P.S.)
• The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
• Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty
• Leadership on the Line: Staying Alive through the Dangers of Leading
• Switch: How to Change Things When Change Is Hard
• Read This Before Our Next Meeting
• Zen Mind, Beginner’s Mind
• Zen in the Art of Archery
• Zen and the Art of Motorcycle Maintenance: An Inquiry into Values
• Zen and Now: On the Trail of Robert Pirsig and the Art of Motorcycle Maintenance (Vintage Departures)
• The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)
• Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)
• God & the Big Bang: Discovering Harmony Between Science and Spirituality
• Impact Mapping: Making a big impact with software products and projects
• The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)
• Speaking of India: Bridging the Communication Gap When Working With Indians
• D-Day: June 6, 1944: The Battle for the Normandy Beaches
• Citizen Soldiers: The U. S. Army from the Normandy Beaches to the Bulge to the Surrender of Germany
• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
• Who Moved My Cheese?: An Amazing Way to Deal with Change in Your Work and in Your Life
• Where Good Ideas Come From – UTPA
• The Magic of Recluce (Saga of Recluce)
• The Goal: A Process of Ongoing Improvement
• Lean Thinking: Banish Waste and Create Wealth in Your Corporation
• No Shortcuts to the Top: Climbing the World’s 14 Highest Peaks
• K2: Life and Death on the World’s Most Dangerous Mountain

Enjoy!

Let’s look at — in human terms — what we’re talking about. Imagine for a moment that your extremely strict boss wants to know what colour taxi he’ll be taking to the airport, and sends you outside to look.

He knows the car’s due to arrive in the next five minutes, so his instruction is a simple one: “Go outside and wait five minutes with your eyes closed. At the end of that time, open your eyes. Look at the car at the curb and come tell me what colour it is.”

Can you see any problems with that task? I see two right away. First, it’s potentially a waste of your time and his. What are you to do if the taxi arrives before the five-minute mark? Nothing. He expressly told you to wait five minutes, then look at the car. If the driver’s having a good day and shows up early, too bad. You wait uselessly at the curb; he waits impatiently for an answer that you could have delivered earlier.

Secondly, he gave you no instructions on what to do if traffic is bad and the taxi isn’t there on time. You’ll have to go back and deliver a non-answer. Next time, he may decide that five minutes wasn’t enough, so he’ll try giving you a ten-minute wait time.

This is decidedly non-optimal.

“But wait,” you say to your manager, “Why don’t I just wait until I see a taxi, then come and let you know.” That is what you’d say, right? Of course it is. That’s exactly what we want our computers to say, too.

That’s the purpose of until. Give the computer a specific condition, and the flexibility to wait just long enough until that condition becomes true. In my previous Ruby/Watir example, we waited until an element existed, or until one contained a particular text string. Other language/testing frameworks have similar syntax. Using WebDriver, for example, you’d use wait.Until()

Until our computers get a bit more intelligent and understand what we mean rather than what we say (and given the potential state of computer intelligence maybe that’s not a good idea), we need to be explicit in our instructions while making those instructions flexible enough to work well in the real world.

My software testing (QA) team has grown over the years, often at a frantic pace. Like many others, I’m sure, there’s always been more work to do than time to do it in, and so saw sharpening has never gotten high enough on the priority stack. Instead the answer was to work more hours or hire more people, and continue with manual testing. As you can imagine that becomes unsustainable and stressful. At one point, while the development team was in the midst of a large re-write project, I carved out a bit of time get started with something that we had been talking about for years: automating some of our testing. This is the beginning of this tale, a story that — for that team — is not yet complete.

Where to start? The products under development are web applications, all custom-built using Ajax and JQuery running on a home-grown web servers and not created with automation in mind at all. One of the developers had even told me that there was “no way” I’d be able to drive the app from any tool or framework. The developers were as busy as ever, so I started poking around to see if I could find any methods that could work for us.

My goals were a bit loose at this point, but I knew that we needed a way to drive our application and check results for regression testing. We would need to be able to do it across multiple browsers, and that it would need to be done — at least initially — by the testing team without much assistance from the developers. Oh, and because this was still a side project, it needed to be free.

I looked at several tools and combinations of tools and decided to start with a combination of Ruby and Watir. My decision was based, I will admit, partially on Watir’s documentation and claims of ease but also on the fact that I wanted an excuse to learn Ruby. Let’s take a look at a few of those first faltering steps together.

The first difficulty was that of determining when the application was actually ready for interaction. This application never loads a new page or changes the URL at all. My first attempts were admittedly ugly and involved sleeping in loops waiting for elements to be created. Bad, bad, bad. Don’t do this. On the upside, here at least the developers had added id properties that I could use to locate the elements I needed on the login page.

require 'watir-webdriver'
username = 'AUserName'
password = 'APassword'
b = Watir::Browser.new :ie
puts 'loading page'
b.goto('https://testsite.mycompany.org/')
puts 'logging on as ' + username
b.text_field(:id => 'UserNameText').set username
b.text_field(:id => 'PasswordText').set password
b.checkbox(:id, 'agreeCheckBox').set
b.button(:id, 'LoginButton').click
d = b.div :id,'documents'
until  d.exists?
  # puts 'watiting for documents page'
  sleep 1
end
puts 'login complete'

The next step was to navigate to a specific page. Here I’m performing some user actions and then waiting for a particular item to become available. This is a slightly better method than the sleep above; looping until a specific element is set to a known text string. Error handling takes care of things until that condition becomes true, which makes the loop a bit longer, and perhaps more ugly, but it’s at least a bit informative. My debugging-via-stdout lines remain for your entertainment:

# go to Passenger List
# click the menus
b.link(:id, 'navPassenger').click
b.link(:id, 'PassengerList').click
# wait for the page
d = b.div(:class,'pageTitle')
begin
  until 'Passenger List'.eql?(d.text)
  end
  rescue Watir::Exception::UnknownObjectException
    $stdout.write('.')
    retry
  rescue Selenium::WebDriver::Error::ElementNotVisibleError
    $stdout.write(',')
    retry
  rescue Selenium::WebDriver::Error::StaleElementReferenceError
    $stdout.write('+')
    retry
end
s = b.select_list(:id => 'jumpPerPage').select '100'
puts 'List displayed: ' + d.text 
d = nil

At this point I was in a place to actually look at what’s important – to make sure that all the rows displayed had a memberID. There’s nothing here to see if the data’s actually correct; just to see that the app’s not returning any records that don’t have data in a particular column. This does assume that this page has all the data displayed, that there’s no pagination. Also, looping through through the .count method isn’t speedy, but for this proof-of-concept that wasn’t a concern.

# Get the rows of the table (assuming there is just one dataTable)
table_trs = b.div(:class, 'dataTable').table.tbody.trs
rows = table_trs.count
puts 'total rows on page: ' + rows.to_s

#Find how many rows have data in the 5th cell
rows_with_data = table_trs.count{ |tr| tr.td(:index, 4).text != '' }
puts 'rows with MemberID: ' + rows_with_data.to_s

Here’s where I began to run into the second challenge, one that is pretty prevalent not only in this application’s code but wherever developers don’t have testability as an up-front design priority. Since the app’s pages are written to be as multi-purpose as possible — from the developers’ point of view — there are many places where they “just know” the structure of the elements and fill them with the correct data, the elements aren’t given id properties at all. That means that I also had to know the structure and code to it, and that when the application changes this test code will need to change as well. This application also lets the user determine which columns are shown, which will further complicate matters to say the least. Suffice to say, there’s a lot of room for improvement here.

Note that there’s no actual testing (or checking) being done here; no desired outcomes are defined and the script doesn’t report any sort of failure or success, it just shows some information about what the application’s displaying. At this point, though, I had enough to show my testing team what could be done if they’d dig into the world of automation, and to show our management what could be done if they’d provide some time for us to do so. It was also pretty obvious that I needed to get the development team involved, discussing ways of making the application more testable from the get-go, using elements, controls, and properties in a more well-defined and consistent manner. We also started looking at other tools, expanding our goals and perhaps even adding some funding.

As they say on TV, “to be continued…” — though the rest of that team’s story will written by others.

The department I’m joining is in Austin Texas. No, we’re not moving. I’ll be working out of my home office (and Atlanta Hartsfield-Jackson International Airport). As telerik’s Test Studio Evangelist, I’ll be engaging with the testing community: attending and speaking at conferences, visiting customer sites, blogging, webcasting, and the like, all with the purpose of raising awareness of methods & techniques of software test automation.

Most of all, I’m looking forward to learning a lot. Fortunately I’m going to be surrounded by some of the best people in software development & testing.

The adventure begins!

I’ve left a company I’ve known for almost five years. The product is a good one, being built and sold by good people. As I told them, I believe the company is strong and has a good future ahead, and I wish them well. 

My course leads me in a different direction; an opportunity lies ahead of me simultaneously exciting and terrifying. 

Onward! 

I’ve been busy working on a new business: How to Watch. This new business aims to help people find where a movie or TV show is available via online streaming (e.g. Netflix, Hulu, Amazon Instant or iTunes). I got sick of having to search on each of the platforms to find “my stories”. The result is this site and mobile apps (Android, Windows 8, Windows Phone and Kindle; iOS is coming soon if I can get Apple to certify the thing!).

What a great idea! Check it out: http://howtowat.ch

Hop over to Amazon and search for a movie, choosing the Instant Video category

Now, look over there on the right-hand side of the screen. See the “Add to Watchlist” button? Click that and Amazon will remember it for you.

The next time you’re in the mood for a movie, you don’t have to try to think back, to remember that conversation. You can just go to your watchlist and choose.

The basic idea behind TDD is that a developer should not only write code to test their code (in itself a recommended practice, though not widely enough embraced), but that those tests should be written first. In a way, this falls into the “measure twice, cut once” idea of making sure you’re doing the right thing. If you’re a software developer and haven’t heard of TDD, stop right now and go start reading.

Friday I was working on a project, a small application I’ve been writing to compare data on multiple systems. I had started off earlier in the week rather idealistically, designing a few classes and writing the tests for them first. That all went well. Then I got to the “real work” of the app, opening connections to the databases, getting data from them, combining & comparing data. I ran into some difficulties, and I must have spent about two hours trying to figure it out including about an hour of one of our senior developers’ time. Once we found the problem, it was one of those simple “oh, I should have seen that!” moments. Problem solved, only three “man-hours” spent.

Then this morning, over my Cheerios and coffee, I’m reading a little of Robert Martin‘s Clean Code, specifically Chapter 7 on Error Handling. There’s a section on writing one’s try-catch-finally statements first, and while I’m thinking about that I realize that – though I did that Friday – what I didn’t do was to write any tests for all that database code. I was catching exceptions and all that, but I’d never actually tested what the catch was reporting. Doh! If I’d taken half an hour to do things “right” on Friday morning, the afternoon would have been a few hours shorter.

So why didn’t I do it “right” the first time? Because it’s not a habit. It’s not the way I’m used to working. Even though I know I should, when things get rolling it’s just not the first thing that my brain and hands jump to. And again, I’m not a full-time, “real” developer with years and years of ingrained habits.

Peter Provost writes that Kata are the Only Way to Learn TDD. I don’t know about only, but without forcing yourself into some repetition, the habits won’t be formed and you’ll too easily find yourself three hours into fixing a problem that shouldn’t have existed in the first place.

Ready Player One, by Ernest Cline.
[Hardcover]
[Paperback]
[Kindle]

The year is 2045, and the world has finished it’s fast-track slide to the bottom of the heap. Pick any dystopian movie setting; this fits right in. There is one bright spot for people, and that’s that they don’t have to actually spend time there — they can instead put on a headset and live in OASIS, a full-time virtual world. When the creator of the world dies, he leaves behind the ultimate game – with the winner taking his enormous fortune and control of OASIS. And the creator was — wait for it — a huge fan of 1980′s culture, so the game has more references than you can keep up with.

For a good SQL intro/refresher, I would recommend Murach’s SQL Server 2008 for Developers: Training & Reference by Bryan Syverson and Joel Murach. It is, as the title suggests, targeted toward the use of Microsoft SQL Server, but the 90+% of SQL Language features will apply to other SQL-based databases as well.

added later: also check out Craig Earl‘s SQL for Testers.

Another very good resource is Learning SQL, by Alan Beaulieu; this book covers the SQL language as a whole, without being specific to any one implementation.

[added later] As you progress, these also look to be good if you’re interested in learning more about SQL development:

• Microsoft SQL Server 2012 T-SQL Fundamentals by Itzik Ben-Gan
• Inside Microsoft® SQL Server® 2008: T-SQL Programming (Pro-Developer) by Itzik Ben-Gan (I don’t see a 2012 version available yet.)

For a practice environment, you can download and setup either MS SQL-Server Express or Oracle Express on your computer.

• Microsoft SQL Server Express – 2012 is the new version; we happen to be using using 2008, an express version of which is probably still available if you dig through the site.
• SQL Server 2008 Management Studio Express
• Oracle Express 11g
• SQL Developer

There are some basic differences between Oracle and Microsoft SQL Server, I’d recommend wandering through these if you, like us, will be playing in both worlds:

• Google search for differences between Oracle SQL and Microsoft SQL
• a Stack Overflow discussion about the differences.
• an article on Migrating from Oracle to SQL Server
• articles from Microsoft on Getting started with SQL Server

The first difference that we will see right away (from the StackOverflow question above): Transaction control. In Oracle everything is a transaction and it is not permanent until you COMMIT. In SQL Server, there is (by default) no transaction control. An error half way through a stored procedure WILL NOT ROLLBACK the DDL in previous steps. There are settings that can change it, but this is the default behavior.

There are also excellent courses available at Pluralsight, and they have a 10-day free trial available. You may also wish to check out the SQL University (start here).

Enjoy, and let me know if you have other resources that have worked well for you.

Among the nice features of the Kindle software is the ability to hilight blocks of text and to take notes. This is hardly something new; I often hilight passages in paper books too, and use Post-It notes to leave my comments, questions and thoughts. The hard part is in remembering exactly which books on my shelf held the quotes I marked or notes I left. With electronic books and notes, I should be able to let the computer do the remembering and searching for me. Unfortunately the Kindle is pretty much a closed system; I’d found no easy way to get to the highlights or notes other than through the Kindle itself. That makes the use of hilighted text in blog posts, letters or presentations difficult.

All that changed today, thanks to this article and a comment left by someone named Zach. I’m happy to have found a way to get information out of Amazon’s system. It’s by no means perfect or automatable, and there’s no guarantee that Amazon won’t change this or take it away at some point in the future, but for now it’s better than nothing.

Go to kindle.amazon.com, log in using your Amazon account, and click on Your Books. You should get a listing of Kindle books you’ve purchased from Amazon.

If you’d like to use their system to keep track of your reading, you can do so under the Reading Status column, and you can rate your books as well. You also have the option here of making your status, ratings and notes public from this page, though I’ve not figured out yet how someone else would see them. update: use the “Hello <name>” menu at the top right-hand corner of the page to view your Profile, then people can use a link like this (thanks to this post by Scott H for helping me discover it).

Now for the good part – click on Your Highlights at the top of the page and you should see a listing of books along with your notes and hilights.

From here you can copy the text and paste it wherever you’d like.

This changes the decision of what format to purchase books – electronic or paper – for me.

This is not meant to be a method for wholesale plagiarism, of course.

(btw, if there are other ways of getting notes & highlights out of Amazon’s locked box, please let me know in comments below.)

Interesting juxtaposition: my initial search for “how to copy text from hilights” came as I was trying to decide what format of a book to buy, paper or Kindle. The book in question is The Innovator’s Cookbook, by one of my favorite non-fiction authors, Steven B Johnson. The article I reference above, where I found the comment, is in response to something Steven wrote. And today, at about the same time as I was creating this very post, Steven was posting to his own blog about a tool to “capture what I was reading.” The tool is Findings, and it includes a way to grab data from the very kindle.amazon.com page I had just discovered!

This isn’t the first time that this has happened, by the way, see Accidents and Emergence.