• Sauce RC – Windows installer and launcher for Se-RC from Sauce Labs. (On here not just because I am doing some work for them, but this could be an important event in the Se timeline. Think along the lines of the launch of Ubuntu’s commercial offerings of Debian for example.)
• PHPUnit and Selenium – Seems Se has official blessing of the PHPUnit folks since they have a dedicated chapter to in their official docs.
• Though I cannot canonically claim to be the first one who thought of it, the idea of integrating YSlow and Se is getting a bit of traction.
  • Performance Feedback with YSlow & Selenium
  • Automated Performance Collection and Reporting – from this year’s GTAC. (Slides and video)
• Run selenium ruby scripts in parallel from Team City – Parallelism is the next wave of Se trickiness I think.
• Batch Script to Start Selenium RC Server on Windows – It’s appalling that kids these days don’t know how to write batch scripts; here is an Se focused howto
• FitNesse vs. Robot Framework – Agile Testing Tools – A bit of a shootout between the two tools using Selenium tests
• How to test your web apps in the cloud with Selenium from a recent JS.Chi()
• Talk on Selenium RC Testing In Grails – Robert Fletcher is showing off his Se Grails plugin in London November 20.
• Cucumber + Selenium + Machinist – like the title says
• Behaviour Driven Development with Cucumber and Selenium
• Web Application Testing With Selenium – If you Glasgow on November 10, this might be fun
• Creating Firefox Profile – Sooner or later, most teams tend to want to do this
• Testing GWT Libraries With Selenium and Maven
• Automated Integration Testing with YUI Test, Selenium and Hudson
• Using CSS Selectors – While not Se specific, CSS Selectors are important things to understand
• cesTestSelenium – no idea wheat ‘objective symfony testing harness for selenium with lime integration’ means, but…
• Grails Selenium RC Plugin – Been mentioned before, but now it is released

• How are you increasing Joy? For yourself? Your team? Your company? For your customers?
• How are you enabling Awesome?

• we’re very serious
• we attract bright young people
• the entire firm gathers
• we talk only about architecture
• it’s a learning office
• people are engaged
• People say, “We love working here.”

How many of these things apply to your office?

Why not?

Elisabeth Hendrickson was in Europe recently and gave a keynote in which she identified a number of Key Practices of Agile Testing. While I wasn’t there, she did list them off on Twitter.

• Collective Test Ownership
• Continuous Integration
• Rehearsed Release
• Automated Technical (code-level) Tests
• Test Driven Development
• Exploratory Testing
• Automated Business (functional) Tests
• Acceptance Test Driven Development
Of these Key Practices, three of them directly involve automation at the web level: ATDD, ET and Automated Business (functional) Tests. If you want to get really specific, then they also touch on CI and Collective Test Ownership too so clearly we need to be able to succeed in our web automation efforts if we want to succeed in Agile Testing.

The problem is, that teams rarely come close to succeeding with them. So much so that automating the front-end of applications is considered a flagrant waste of time and effort in some circles. I’ve had success though. And I think the reasons for it are applicable outside of just the projects I have worked on.

If we are aiming for successful automation, we should look at some of the attributes of a successful script commonly has. In other words, successful automation is…

• Paranoid – Never ever, ever, ever, ever, ever, ever, ever trust the client. Just because something says something happened does not mean it has. Account information claimed to be updated? Check the database! As soon as you find yourself trusting things, you will get burned. Get burned too publicly too many times and you will find your time to work on automation being removed and / or the results just shrugged off as inaccurate. Perhaps ‘never trust’ is too strong. How about ‘trust, but verify’ instead.
• Efficient and Effective – A script exists to exercise a single piece of functionality. Just because you test your whole freakin’ app in one script does not mean it is a good idea. True, there will be likely be a huge number of ways in which your script could not complete successfully, but those specific failure modes would be pointedly exercises by some other script. For example, in order to get to the page you want you have to login to the system. Don’t check the whole login process, just take for granted that it will work. Your login scripts will verify the functionality of the login system. Don’t worry about it anywhere else.
• A Student of History and Linguistics – Automation isn’t new. There have been lots of research and experience generated in the area over the last 10 – 15 years. Sometimes you have to invent a better wheel, but you should know about the design of earlier wheels as well. Do your research and build up a library. Something like xUnit Test Patterns should be available on the bookshelf of anyone doing automation for instance. Also know which language to use when. Don’t fall into the trap of thinking you need to automate in Java just because that is what your application is written in. I, for example, automate in either Ruby or Jython usually; regardless of what the underlying application is written in.
• Intelligent and Wise – In Dungeons & Dragons, Intelligence is your intellect or smarts and Wisdom is how you apply it to the talk at hand. Your scripts should be strutting about with 19s or higher in both categories. They should be able to interact with their environment to build their own data and even decision trees. They should also include their own oracles to determine whether the right thing happened, at the right time, in the right manner.
• Modest – I kept switching between ‘modest’ and ‘humble’ for this slide. The concept here is that when your script breaks, it doesn’t try to hide the fact. It says very obviously I couldn’t do what you asked here because of this. When this happens it should clean up the mess that it left behind so your environment is not in a completely untrustworthy state.
• Automates Checks and Facilitates Testing – Michael Bolton has a meme running right now with the difference between Testing and Checking. The key difference between the two is whether the oracle is automated or not. Automation can include the oracle as a check or it can zoom through your application to a specific page to help facilitate a human to do testing. Don’t confuse the purpose of your script when creating it. Though of course your facilitation script could have a number of checks so the tester knows the environment is, at minimum, ready for their sapience.

Now that you know what your end scripts will look like, you are ready to start writing stuff. Right? Well, not quite yet. Before we do that we need to know a bit about who is going to be the creators, consumers and maintainers of them. I broadly break these categories into two divisions: those who can code and those who can’t. It is my experience that you have a far greater chance of success if you target the geeks of the organization first.

Geeks know how to code. They are comfortable inside a text editor and seeing xUnit style automation with all its quirks is not going to phase them in the least. They also know how to Build their own Lightsaber and by applying the DRY principle will abstract out common sequences of commands into helper methods/fixtures. These helper methods will form the basis of your organization’s DSL.

Non-geeks are not second class citizens in successful automation by any means, they just have a different skill set that they bring to the table. Often this is in the form of Subject Matter Expertise and what they need is a way to using it efficiently and effectively within the framework. This is best achieved through a DSL that abstracts the technical details away from the business details. And because you had the geeks work on automating stuff first you already have the beginnings of that. The non-technical tester doesn’t care that there are 250 steps behind the scenes for building 50 shares of AAPL; they just want to be able to call ‘buy_stock(AAPL, 50)’ and have it magically work.

Yes, now you can start actually creating an automated script.

Record

The first step in a successful automated script to to record the basic skeleton in some means. With the Selenium suite, you use the Selenium-IDE extension for Firefox. In the actual talk I did a recording of a search operation on a local Wordpress installation in the IDE. Don’t forget to add your verify and assert statements in. If there is no way for the script for fail, it is not testing (or even checking) in my opinion.



I almost never save a script within Se-IDE. Instead I’ll export it out to a real language and run it from within Se-RC. Yes, even if it is just a ’simple’ script. ‘Simple’ scripts have a tendency to increase in complexity over time.

Add Power

The real power of Automation is unlocked when you have a real language, not just vendor-script. I’ve argued before that Se-IDE is powerful enough to stay in it, but not powerful enough to really get stuff done.

Here is the script as exported from Se-IDE into Ruby.

require "selenium"
require "test/unit"
 
class direct_export < Test::Unit::TestCase
  def setup
    @verification_errors = []
    if $selenium
      @selenium = $selenium
    else
      @selenium = Selenium::SeleniumDriver.new("localhost", 4444, "*chrome", "http://change-this-to-the-site-you-are-testing/", 10000);
      @selenium.start
    end
    @selenium.set_context("test_direct_export")
  end
 
  def teardown
    @selenium.stop unless $selenium
    assert_equal [], @verification_errors
  end
 
  def test_direct_export
    @selenium.open "/"
    @selenium.type "s", "pirate"
    @selenium.click "searchsubmit"
    begin
        assert_equal "pirates are way better than ninjas", @selenium.get_text("link=pirates are way better than ninjas")
    rescue Test::Unit::AssertionFailedError
        @verification_errors << $!
    end
  end
end

But like most things in the open source world (especially the Ruby part of it), the code that the IDE produces isn’t up to the latest coolness. So with a bit of modifications to use the selenium-client gem, we have this code.

require 'rubygems'
require "test/unit"
gem "selenium-client", ">=1.2.15"
require "selenium/client"
 
class CategoriesTest < Test::Unit::TestCase
  def setup
    @verification_errors = []
    @browser = Selenium::Client::Driver.new "localhost", 4444, "*firefox", "http://localhost:5500", 10000
    @browser.start_new_browser_session
  end
 
  def teardown
    @browser.close_current_browser_session
    assert_equal [], @verification_errors
  end
 
  def test_search_for_pirates
    @browser.open "/"
    @browser.type "s", "pirate"
    @browser.click "searchsubmit"
    assert_equal "pirates are way better than ninjas", @browser.get_text("link=pirates are way better than ninjas")
  end
end

Power!

Or at least the potential for power. The first step for adding power is often to data-drive your script. This is the process of abstracting your script to read data from an external source which is something Se-IDE can’t do (easily). In an environment of geeks and non-geeks this is often accomplished through the use of CSV files. The chief advantage of this is that you can add to scenarios without actually having to change the commands that are executed; just the inputs change. Here is the same script modified to be data driven through csv.


require 'rubygems'
require "test/unit"
gem "selenium-client", ">=1.2.15"
require "selenium/client"
 
class CategoriesTest < Test::Unit::TestCase
  def setup
    @verification_errors = []
    @browser = Selenium::Client::Driver.new "localhost", 4444, "*firefox", "http://localhost:5500", 10000
    @browser.start_new_browser_session
  end
 
  def teardown
    @browser.close_current_browser_session
    assert_equal [], @verification_errors
  end
 
  def test_search_by_word
    require 'faster_csv'
 
    FasterCSV.foreach('data_driven.csv') do |word, link_text|
      @browser.open "/"
      @browser.type "s", word
      @browser.click "searchsubmit"
      assert_equal link_text, @browser.get_text("link=#{link_text}")
    end
  end
end

More Power!

We can go even further though. We want scripts that can are Intelligent enough to data-drive themselves. Because we have the full power of a real language at our disposal we can hook into the database directly and let the script do its thing. Of course, in order to do this you need to understand at a very deep level what is going on in your application. That knowledge acquisition is a Good Thing though. The more you understand the system, the more complete your mental model becomes and the better testing and thorough checking you can accomplish.

Again, same script, but driven from the database.

require 'rubygems'
require "test/unit"
gem "selenium-client", ">=1.2.15"
require "selenium/client"
 
class CategoriesTest < Test::Unit::TestCase
  def setup
    @verification_errors = []
    @browser = Selenium::Client::Driver.new "localhost", 4444, "*firefox", "http://localhost:5500", 10000
    @browser.start_new_browser_session
  end
 
  def teardown
    @browser.close_current_browser_session
    assert_equal [], @verification_errors
  end
 
  def test_search_by_word
    require 'mysql'
 
    begin
      dbh = Mysql.real_connect("localhost", "root", "", "selenium")
 
      res = dbh.query("select post_title from wp_posts order by rand() limit 1")
      while row = res.fetch_row do
        @browser.open "/"
        word = row[0].split(" ")
        @browser.type "s", word[rand(term.size)]
        @browser.click "searchsubmit"
        assert_equal row[0], @browser.get_text("link=#{row[0]}")
      end
      res.free
    ensure
      dbh.close if dbh
    end
  end
end

OMG! Cosmic Spider-man-esque Power!

This is where you want to have your scripts function at for true success. Once you are here, you can have your scripts run continuously if you have a smart runner that notices when new scripts are added into the mix.

One problem this doesn’t solve is Permutation Madness problem. This comes from there being a boatload of browser and OS configurations we need to care about in today’s environment. Selenium Grid is designed to solve this problem. Using a centralized machine you can farm out your script execution to various slave machines which could all have a different configuration.

This solution doesn’t scale so well though. Suddenly you need a whole farm of machines to run your tests and that will suck of scare resources to make sure they are all patched, etc. Virtualization helps, but you still need to manage the VMs. Companies like Sauce Labs and Browser Mob exist to remove that maintenance burden from you (and other value add stuff too).

(Had I been thinking I would have run my script through Sauce Labs but I wasn’t and didn’t know how sketchy the wireless was at the venue.)

Thus far we have covered what a successful script will look like and a recipe for achieving it. But how do you know when you are at risk of running off the rails? In programming terms, you check for smells. Here are the ones I mentioned in the talk. There are assuredly more.

• I need to re-record – This hints that you are staying the Record phase to long and have not added things like error handling and the robustification that is possible in a real language. If the application has changes significantly (intentionally) that your script no longer operates at all, throw it out and start with a clean slate. Don’t try and fix the existing one.
• Number of Steps – Various companies are learning and publishing the optimum length of script for ease of maintainability and readability and they seems to be averaging around the 200 step / action mark. If you have 1000 steps in a script then you really need to examine what it is doing. Odds are it is really a couple scripts that have organically grown as a single one.
• Automate Everything – The Cult of Automation is alive and well in the Agile community. Somethings should be automated, somethings should not be. Learn the difference.
• Staying too long at phase of maturity – Similar to the first one; don’t get stuck in Se-IDE, Se-RC or Se-Grid. Just because it was the right level before does not mean it is the same one now: new problems surface, new variations of old problems occur. If your Se-RC scripts take 9 hours to run because they run synchronously, then you likely are (well) overdue for the move to Se-Grid or one of the commercial offerings.
• Trust – Again, never trust in automation. Verify everything isn’t a lie. Even if it is a well-intentioned one.

The last thing I talked about was Patterns for Success. I put them last because I didn’t know if I was going to run out of time and figured it was more important to get the Smells (Danger!) in than the Patterns. I didn’t run out of time so the decision ended up being irrelevant.

• Build a web – Approach your application from multiple angles in order to build a web across it. Just as a spider catches bugs in its net, you automation can catch them it its. (This was one of the key points of Chris McMahon’s Agile 2009 talk.)
• Tags – I was taught to organize my scripts by functionality (in Mercury training circa 2000), but the rise of User Stories has people also grouping by User as well. Both systems can work to great success, but there are inherit issues of overlap in these. I’ve been messing with the idea of ‘tagging’ scripts in addition to these structures. This removes the overlap problem as it is actually an important part; scripts are organized on disk by functionality, but tagged with the User(s) they affect. Runners need some modification though. As do Test Management Systems (if you are stuck using them)
• Metaframeworks – I publicly demonstrated for the first time the Metaframework I am working on in my ’spare time’ (heh, no wonder it is taking forever). A Metaframework will run and aggregate the results of scripts written in a number of different languages which lets people write them in whatever they are most comfortable. The point is to exercise the application, not your power in dictating the language tests must be in.
• Sync ‘n Run – See this post for a larger discussion, but essentially, it is ‘check everything into version control so deployment is just a sync operation.
• Design for Parallelism – It is better to design your scripts initially in such a manner that they can be run (massively) parallel from the get go rather than have to hack it back in later. Things like file and database row contention become issues. The same techniques application developers use to deal with these problems apply just as well to your automation.
• Data Doesn’t Have to be Real – Input data has rules and as long as it adheres to those rules then you are golden. It doesn’t matter that you cannot pronounce the First Name the script generated, because, well, you don’t have to. It just needs to be accepted, processed and returned correctly by the system.
• Test Discovery – Mentioned before, but having a runner which can automatically detect a new script added into the available scripts pool is powerful. This means that you never have to turn off your scripts.

And after a couple clarifying questions, that was it.

]]> http://adam.goucher.ca/?feed=rss2&p=1287 2 http://adam.goucher.ca/?p=1287 http://feedproxy.google.com/~r/AdamGoucher/~3/uofU-c_acOg/ http://adam.goucher.ca/?p=1284#comments Wed, 28 Oct 2009 02:09:46 +0000 adam http://adam.goucher.ca/?p=1284 Declan Whelan is a local-ish Agile Coach who has started to appear on the speaking circuit (which is a Good Thing). One of his talks is ‘Building a Learning Culture on Your Agile Team’ which he has done at least a couple times before Agile Tour landed in Toronto. That practice showed as he was confident in the front of the room and knew his content; unlike my umms and aaahs. His main argument is that high functioning Agile teams are ones that are good at learning. This makes sense with the traditional doctrine of spikes to learn, releasing quickly, etc. While learning isn’t the only attribute that is important, it is I think an important one.

• Learning is the bottleneck on teams – JB Rainsberger
• We need to find effective ways to respond to change. That’s learning.
• There is no short circuiting the learning process
• If we get really good at learning, we can reduce the learning cycles. And thus deliver value quicker.
• Learning and Long Term Value are two sides of the same thing. Think Yin and Yang.
• Need to make the environment safe for learning to happen
• Book – Overcoming the Five Dysfunctions of a Team
• Learning is the acquisition of knowledge and the continuous practice of it
• Book – The Fifth Discipline
• We learn in three different ways: auditory, kinesthetic, visual
• Visual learning needs to be an actual image; just ’seeing’ words is not enough
• Book – Pragmatic Thinking and Learning: Refactor Your Wetware
• Shu Ha Ri
  • Wow, I am sick of this. Though in most cases it comes of as ‘Hey! a cool idea from Japan! Let’s take it!’, but it made sense here. I’m still sick of it though…
  • The way you learn and the way you coach are different at each level
  • The expert may not be the best teacher
  • The Curse of Knowledge
• In the beginner’s mind there are many possibilities, but in the expert’s there are few. – Shunryu Suzuki
• The opportunity for learning is deeper in the beginner than in the expert
• Paper = Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience
• Stuff from the Fifth Discipline
  • Personal Mastery – know yourself, biases, models
  • Mental Models – be able to articulate and put up for critique
  • Shared Vision – goal and purpose
  • Team Learning – align learning around the bottleneck in the system
  • Systems Thinking – end-to-end thinking is better than thinking in terms of silos
• Tinkering School – go watch the video.
• Agile leadership is not about directing, but learning it in the right direction
• Learning need…
  • to be intentional
  • an infrastructure
  • is incremental
  • safe
• The single most important thing in Agile? Honest retrospectives
• James Shore’s Etudes
• Book – Fearless Change
• Tribes Learning Communities – “After years of “fix-it” programs focused on reducing student violence, conflict, drug and alcohol, absenteeism, poor achievement, etc., educators and parents now agree, creating a positive school or classroom environment is the most effective way to improve behavior and learning”
• Functional teams are like a nurturing family
• Our tendency is to be interested in something that is growing in the garden, not in the bare soil itself. But if you want to have a good harvest, the most important thing is to make the soil rich and cultivate it well. – Shunryu Suzuki
]]> http://adam.goucher.ca/?feed=rss2&p=1284 0 http://adam.goucher.ca/?p=1284 http://feedproxy.google.com/~r/AdamGoucher/~3/Rs9Jdlc89jU/ http://adam.goucher.ca/?p=1282#comments Tue, 27 Oct 2009 13:31:44 +0000 adam http://adam.goucher.ca/?p=1282
• Configuring the Selenium Toolkit for Different Environments using the Selenium Toolkit for .NET
• Sauce Labs has a new website and commercial support for Selenium
• Ruby, Selenium, and the Snow Leopard dance – another how-to-make-Selenium-work-in-Snow-Leopard post
• Selenium 2.0 downloads – You want bleeding edge? Here is your bleeding edge.
• Selenium and ABAP video from SAP TechEd 2009 Demo Jam
• Django Selenium test runner
• Automating boring tasks with Selenium IDE has a nice example of hacking in loops to Se-IDE (though the ‘proper’ solution is of course to drop to Se-RC and do it cleaner in-language)
• Automated Website Testing with Selenium is an experience report from Jodie Miners about using Se on a 3 month contract.
• Se-RC plugin for Grails
• Cuke4Duke brings Cucumber to several programming languages on the JVM. And of course you can write steps in Se
]]> http://adam.goucher.ca/?feed=rss2&p=1282 0 http://adam.goucher.ca/?p=1282 http://feedproxy.google.com/~r/AdamGoucher/~3/kowidZ2rJz4/ http://adam.goucher.ca/?p=1280#comments Tue, 27 Oct 2009 02:38:23 +0000 adam http://adam.goucher.ca/?p=1280 I spent a bit of time today looking into the redistribution requirements for things that ship with Visual Studio for someone today. (Part of testing is of course to see that we stay in compliance with the various licenses of tools we use to produce software after all.) Here is the verdict.

According the the Microsoft Software License Terms Microsoft Visual Studio 2008 Standard Edition section 3ci you can distribute:

REDIST.TXT Files. You may copy and distribute the object code form of code listed in REDIST.TXT files, plus any files listed on the REDIST list located at:
http://go.microsoft.com/fwlink/?LinkID=100327&clcid=0×409.

I don’t have Visual Studio installed on my machine, but John D. Cook sent me the copy of REDIST.TXT from his install which I have put online to view here.

I last had to look up this sort of thing 5 or 6 years ago and seem to recall hoops of extra licensing being required. It’s nice to see that no longer being the case.
]]> http://adam.goucher.ca/?feed=rss2&p=1280 0 http://adam.goucher.ca/?p=1280 http://feedproxy.google.com/~r/AdamGoucher/~3/Tx1J_geQ5To/ http://adam.goucher.ca/?p=1276#comments Thu, 22 Oct 2009 15:05:20 +0000 adam http://adam.goucher.ca/?p=1276 Stelios Pantazopoulos delivered a nice presentation on useful metrics for project health. Because of the health idea, his metaphor was a patient in a hospital and the graphs and metrics were the output of the machines. It worked really well, but it almost seems to have the starting idea that your project is in the hospital. While not as grounded in science, I think a better idea would be to use some sort of holistic, preventative medicine one. The same things can be tracked, but the perspective and positioning changes completely.

• Has a chapter on the subject in The Thoughtworks Anthology
• Metrics need to show how and why a project is on track
• What you want is simple, quantitative, near real-time metrics
• PMBOK (apparently) has 4 ‘levers’ which affect a project. I of course didn’t write them down…
• He adds a 5th: Team
• The goal of vital sign checks is to bring visibility to all 5 levers
• The Vital Signs
  • Scope Build Up
  • Current State of Delivery
  • Budget Burn Down
  • Delivery Quality
  • Team Dynamics
• Make all these public! The last place you want stats like this is buried in a status report. Transparency builds shared team responsibility and trust
• These metrics (once the framework is in place) should only take 2 – 3 hours per week

Edit: The PMBOK levers are: Budget, Scope, Schedule, Quality. Thanks to Michael Glenn who apparently took better notes than me.

]]> http://adam.goucher.ca/?feed=rss2&p=1276 0 http://adam.goucher.ca/?p=1276 http://feedproxy.google.com/~r/AdamGoucher/~3/VPBXo8EO_X8/ http://adam.goucher.ca/?p=1274#comments Wed, 21 Oct 2009 21:25:24 +0000 adam http://adam.goucher.ca/?p=1274 Thanou Thirakul did a nice experience report on a project he worked on for awhile which was having trouble continuing to use some of the Agile toolkit on. Specifically, their automated build and test infrastructure was failing them.

That was actually the illness, the symptoms, and more importantly how they addressed them were as follows:
• Team lost faith in the build – The team, having lost faith in the build system would just ignore the results and even more damaging, would sometimes just skirt around it entirely. To address this they formed a specific team to restore faith in the build by tackling the other problems. One thing they did intentionally was to add people not currently in the project team to help figure out the solutions. This meant fresh eyes and ideas to a problem people might have tunnel vision towards.
• No one wants to touche the build script – Being a 6 year old java project, their build was a series of cobbled together ant scripts that had grown organically. To fix this they maven-ized their build and got it running inside Hudson. In my experience, this is exactly what you want to be doing, though Ant + Ivy would likely work as well. Sometimes starting over really is the correct idea.
• Too many false build failures – An analysis of their build failures showed they were largely environment related. To solve this they rebuilt their test machines as virtual machine snapshots. This meant they could quickly return things back to a known clean save removing the problem of environment degradation.
• Integration tests taking too long – Since their environment was now virtual, they solved part of the length problem by just spawning more VMs to test with. That just moves the problem around though really. Now you need a runner which will distribute your tests. They solved that problem by building their own test distribution server. It was slick!

Here are some other notes I took:

• Don’t contort your tools; use the right tool
• Use the length of past test runs to estimate how long your next one will take.
• When using VMs, for maximum performance assign each its own disk as I/O rapidly become the bottleneck.
• More times than not, the first (correct) sultion is not to build yeat another tool

My major complaint about this talk was his commentary a couple times that ‘the best part about writing something cool like the test server is that you get to release it as open source’. When I asked where I could grab it I got something that sounded like a sales pitch. Even after talking to him afterward I’m not sure if I would have to part with money to doing something. Just release it! The community will find it and try it out in ways you can’t begin to think about.

Aside from that, it was a well done talk.

]]> http://adam.goucher.ca/?feed=rss2&p=1274 1 http://adam.goucher.ca/?p=1274 http://feedproxy.google.com/~r/AdamGoucher/~3/23l0HrXdj9k/ http://adam.goucher.ca/?p=1272#comments Wed, 21 Oct 2009 13:19:29 +0000 adam http://adam.goucher.ca/?p=1272 Scott Ambler delivered the keynote at Agile Tour Toronto 2009. I could have sworn I have met him before, but I’m not sure anymore. He is, umm, unique it seems and I think I would have remembered it clearer. Scott is the Practice Leader Agile Development at IBM and it would seem that his views are, not unsurprising, widely tainted by the size of customer IBM Consulting attracts. I’m also not sure where he fits into the political structure of Agile; he seemed rather anti / bitter / pissed at a number of people in the community at large. But I might be the only one who interpreted it that way and perhaps he was striking his tone to help reinforce his points of the talk.

• We don’t know what the laws of IT physics are, but they haven’t changed
• Agile Scaling Model
  1. Core Agile Development – construction focused, small teams with a straight-forward systems
  2. Disciplined Agile Development – full lifecycle from conception to release, retire risks early, self-organization with adult supervision
  3. Agility at Scale – one or more scaling factors are being controlled
• That stack of requirements have come from somewhere — up front modeling and planning
• Scaling Factors (All are a scale, not binary. Easy to hard.)
  • Geographic distribution
  • Team size
  • Compliance requirements
  • Domain complexity
  • Organization distribution
  • Technically complex
  • Organizational complexity
  • Enterprise discipline
• Agile teams are good at delivering high-quality siloed applications
• Traditional teams are good at delivering low-quality siloed applications
• Different teams/projects are at different places, so how can you have a repeatable process across all of them.
• Repeatable results beat repeatable process every time
• Scott’s theory: Agile scales better than traditional and we are only 5 – 10 years away from having hard evidence to back t up
• In distributed Agile, don’t use colocated team tools
• Agile needs to ‘grow up’ – his survey number show less than 50% of teams are working with legacy data. The implication being that they are building new silos
• In meetings, focus on the value aspect rather than the status
• If there are technical dependencies, there are functional dependencies
• Our tools should generate the metrics we need
• Bureaucracy is bureaucracy. AUtomate the heck out of it to get accurate and timely results
• Part of failing early is to do the risky parts first
]]> http://adam.goucher.ca/?feed=rss2&p=1272 0 http://adam.goucher.ca/?p=1272 http://feedproxy.google.com/~r/AdamGoucher/~3/nugRE1Ypb-c/ http://adam.goucher.ca/?p=1271#comments Wed, 21 Oct 2009 01:56:29 +0000 adam http://adam.goucher.ca/?p=1271
• Advanced Selenium RC logging with MSpec – like ruby’s selenium client’s rspec report; but for mspec
• The Play framework uses Selenium as its acceptance test layer
• Automated Testing with Selenium – Webinar by G2iX. Likely the same as last week’s, but if you missed it then you can undo that missing. (Anyone post any notes or anything from it?)
• corey-projects is where Corey Goldberg is now stashing his publicly consumable scripts
• CaptureScreenShot Can’t Work on “Non OK” Selenium Response – bug PHPUnit when using captureScreenShot* commands. Who wants to create a patch?
• Selenium Inspectory – another of the many frameworks / products that use Selenium as its core platform
• Essentials of getting started with Selenium Grid and Ruby – Not as great as the title suggests, but some teases of ideas that might help you troubleshoot
• 
  Running Selenium tests in Visual Studio – as the title would suggest
• Capturing screenshots from remote Selenium RC – seems like screen capturing was the thread of the week with a number of people arriving on irc specifically about it
• setWindow not working outside of HTA environment – bug, and fix for Se-IDE by the PushToTest kids
• Code Kata – do we need something like this for Selenium?
• Maven, Selenium and a hint of Groovy – don’t forget to include the surefire-report plugin to see your results
• Testing Grails Apps With Selenium-RC – my ‘value chain’ idea claims another victim!
• ‘Selenium Internals’ book – Manish Chakravarty is starting to write a book on Selenium
• How to use Webrat and Selenium to test the parts of your application that rely on AJAX or some form of Javascript interaction with the user – a screencast about, well, what it says it is

• Never chase after a bus, there is always another one coming. Well, except when there isn’t or the next one is a really long time
• Father always knows best. I really like this one, but it typically fails in large degrees when my wife is around.

I don’t know what got me thinking about it on the walk into the office, but it occurred to me that we all carry around with us a vast array of heuristics we apply to everything we do in life. The trick is to be able to recognize which we are applying in what situation. So that is what I did. Here are my (current) heuristics of getting from Place A to Place B.


• Always go towards the goal, never backwards
• Arrive no earlier than 5 minutes before planned arrival
• Arrive no later than 3 minutes after planned arrival
• Have a planned arrival time
• Don’t stop moving. Rather than wait for a light, continue along the street until the next opportunity to cross
• Observe and understand traffic pattern and flow
• Know where the closest washroom is. (Don’t ask)
• Know ish where you are going to
• Know where you are coming from
• Have a mental model of the area you are in. (The first thing I buy when visiting a new city is a street map)
• Back streets have some of the more interesting things to see
• Know how you would pull the emergency cord if necessary
• Have landmarks that work. (Buildings in hilly cities like San Francisco don’t work.)
• Landmarks are relative to your point of reference. (The lake is to the south in Toronto, but the East in Chicago — that confused me to no end)

As testers, we can likely rattle of similarly long lists for ‘forms’, ‘installers’, ‘windows’ and other archetypal testing situations. But just recording those lists for distribution isn’t necessarily useful or desirable. Like my traveling heuristics above, they develop based on your own biases and experiences. And that is something that cannot be transfered. Even if two people witness an event simultaneously they will experience it differently.

]]> http://adam.goucher.ca/?feed=rss2&p=1270 1 http://adam.goucher.ca/?p=1270 http://feedproxy.google.com/~r/AdamGoucher/~3/OVNoUPdCX7U/ http://adam.goucher.ca/?p=1269#comments Wed, 14 Oct 2009 12:58:12 +0000 adam http://adam.goucher.ca/?p=1269 The kick-drum of the TDD rhythm is Red, Green, Refactor.

At its core, it is just a tight loop of writing a failed test, writing code to make it pass, then make it better without (silent) breakage due to the test.

On this week’s Writing Excuses they used the term Discover, Decision, Action and it dawned on me that is the rhythym of exploratory testing.

• Discover – Something happened! How did we notice it? Using our senses and trained intuition to reference our catalog of heuristics
• Decide – Does our new Discovery matter? Alter what we are doing? Change our tactic choice or course? Lead us further into the rabbit hole or out of the brambles entirely?
• Action – Once we have come to a Decision (or number of Decisions) we act on one, some or all of them. This action causes us to return to the Discovery state.

And the process continues until we decide to take a ‘Stop Testing’ Action and pop out of the loop.

(Now all I need is a nice graphic showing this cycle and we’re off to the races)

]]> http://adam.goucher.ca/?feed=rss2&p=1269 1 http://adam.goucher.ca/?p=1269 http://feedproxy.google.com/~r/AdamGoucher/~3/InxlmmWxiQQ/ http://adam.goucher.ca/?p=1267#comments Tue, 13 Oct 2009 23:13:07 +0000 adam http://adam.goucher.ca/?p=1267
• SAP TechEd 2009 Demo Jam – Automate Web Application Testing with Selenium for ABAP, Siteco Beleuchtungstechnik GmbH is a finalist
• According to this tweet, Axe 2.0.3 has Selenium support
• How to run Selenium RC with Ruby codes – a quick beginner guide for using the ruby gem
• JavaScriptMVC used Selenium and Rhino under the cover for their testing
• Automated Functional Testing tools, QTP V’s Selenium
• The death of Selenium?
• Firefox 3 handling of SSL Certs is broken
• Selenium RC in C# using NUnit: An End-to-End Example
• Selenium extension for typo3
• Automate Software Testing With Selenium
• Test Automation for the Masses
• Running Cucumber Tasks Through Selenium on Internet Explorer
• Functional Test suite in C# or Java… Why?

• Winning on the Uphills -
  The best time to do great customer service is when a customer is upset. The moment you earn your keep as a public speaker is when the room isn’t just right or the plane is late or the projector doesn’t work or the audience is tired or distracted. The best time to engage with an employee is when everything falls apart, not when you’re hitting every milestone. And everyone now knows that the best time to start a project is when the economy is lousy.
• “All I do is work here” -
  If you’re not proud of where you work, go work somewhere else. You don’t get the benefit of the brand when it’s hot without accepting the blame of the brand when it’s wrong.
• Willfully Ignorant vs. Aggressively Skeptical –
  If you want to change what your boss believes, or the strategy your company is following, the first step is to figure out how to be the best informed person in the room.
• The modern Talking Pad -
  Now, when you make your presentation, sit next to the person you’re meeting with and go through the booklet page by page, writing directly on each page. As you work your way through the ideas in the booklet, the two of you can talk about what’s in front of you and mark it up.
  
  It’s not a brochure, it’s the outcome of a working session. Leave it behind when you go.
• Competing with the Singleminded -
  When you have someone who is willing to accomplish A without worrying about B and C, they will almost always defeat you in accomplishing A.
• Spare No Expense -
  It’s certainly possible to build a brand without going to (c) [spare no expense] (witness the way Google almost never gets embroiled in special cases or even answers the phone–I know that they’re certainly not eager to fix my imap problems), but once you’ve trained your customers that (c) [spare no expense] is an option, it’s awfully hard to scale back.
• Chai Wallah – Or you can be a wallah. Someone who does only that one thing.
  
  When you go all in, it focuses your attention and effort, doesn’t it?
• Things to ask before you redo your website – What is the goal of the site? (This was first in the list. Everything else hangs on being able to answer it.)
• Win the Fight. Lose the Customer -If someone thinks they’re unhappy, then you know what? They are.
  
  Trying say this to yourself: I have no problem acknowledging that you’re unhappy, upset or even angry. Next time, I’d prefer to organize our interaction so you don’t end up feeling that way, and I probably could have done it this time, too. You have my attention and my empathy and I value you. Thanks for being here.
  
  If you can’t be happy with that, then sure, go ahead and fire the customer, cause they’re going to leave anyway.
• Launching Brands In Public – You can’t control what people are saying about you. What you can do is organize that speech. You can organize it by highlighting the good stuff and rationally responding to the not-so-good stuff. You can organize it by embracing the people who love your brand and challenging them to speak up and share the good word. And you can respond to it in a thoughtful way, leaving a trail that stands up over time.
• Sell like you Buy – If it’s not good enough for you as a consumer, why should it be good enough for you as a marketer?

• The mission of her company is to ‘make the complex simple’. Nice.
• It is the job of leaders to eliminate uncertainty
• The bar for presentations is (currently) so low in most places.
• There is a scale at play here. Document -> Telepromptor -> Presentation. Obviously you want to be on the right hand.
• The Presentation Landscape is a great reference for what type of presentation you should be creating for which audience and for what purpose
• The default template in PowerPoint makes ‘documents’ not ‘presentations’
• Rule of thumb – If a slide takes longer than 3 seconds to absorb, it has too much stuff on it. (She then did a fun trick of showing a couple slides for 3 seconds to illustrate the effect. Awesome.)
• Only one message per slide
• Make the illustration match the messages. For example, is a line drawing Marilyn Monroe right for a quote about simplicity?
• Think like a designer
• Design creates higher perceived value
• The first, most obvious idea is not the best idea
• Slides are free. Have lots.
• Have only what you are talking about now on the page
• What is the best way to display the information you need to convey the meaning you want?
• Rule of thumb – Make you presentation look like it could be a magazine spread
• STAR – Something They will Always Remember
• As a presenter, you have the opportunity to deliver a profound experience
• She is doing a series of for-cost webinars which expound on these topics, and more

One other cool thing about the webinar is all attendees get 45 days access to the book in Safari. Of course, if O’Reilly wanted to send me a dead-tree copy, they have my mailing address…

• How to test Ajax Apps with Selenium
• Easy Automated Web Application Testing with Hudson and Selenium
• Automated Acceptance Testing with Selenium (course)
• Database Transactions in Cucumber Breaking Selenium
• Selenium Testing and SWFUpload
• Selenium test support for Plone
• Selenium – Basic Course (German) – translated to (english)
• Cucumber meets Selenium meets Integrity

+ cap deploy
  * executing `deploy'
  * executing `deploy:update'
 ** transaction: start
  * executing `deploy:update_code'
    updating the cached checkout on all servers
  * executing "some command"
    servers: ["monkey.goucher.ca"]
Password: stty: standard input: Invalid argument
stty: standard input: Invalid argument
stty: standard input: Invalid argument

Ugh-oh. No key means no access which means no deploy.

An hour later I did manage to figure out a nice, neat solution.

The trick is to tell Cap, not the shell, where the key you want to use is. In order to do this you need to add this somewhere in your Capfile

ssh_options[:keys] = %w(/hudson/.ssh/id_rsa)

Obviously, if you user is not ‘hudson’ you would change it to whatever it is. Likewise if you are using DSA rather than RSA for your key.

Now you can run your Cap tasks from within Hudson. And not have a busted build.

1. Trust – If your team doesn’t trust that you will do what is in their best interest it is really hard to get them on board with new ideas as they will be met with significant amounts of skepticism. Sometimes you have to make decisions which which are unpleasant for the team, but necessary for the company. When that happens, be honest about the reasons behind them. Problems happen when it appears you have your own agenda to push. Especially if you are still just new to the group. Blowing the trust of the team from the start is a fantastic way to hobble yourself in a new position.
2. Respect – This is a companion to Trust. I won’t go so far as to cite the Golden Rule, but treat your team as the adults they are. Ask for their input on decisions. In a development environment, they actually do know more about how things are wired together. And don’t just ask for it then do your own thing anyways. That is an altogether too common pattern, but is a killer.
3. Belief – A team needs to be able to believe that what their manager says. Without belief you end up with ’sure, of course we are going to do x. riiiight’. Soon they are just a talking head. Not a manger. Certainly not a leader. Just the person who gets in your way.

Any high-functioning team, or even just a functioning team has those three elements. Both to and from management and within. But the disconnect between management and their teams is often where this appears most often and causes the most damage.

Paul Carvalho

• Prefers to hire new grads
• New tester training has three parts: domain, system, testing skills
• When reviewing SBTM sessions, the magic number of tester’s work to review seems to be 2. Any more testers and the review process become more time consuming than the actual testing
• Change reviewing assignments among the group on a weekly basis
• When looking at a graph, ask ‘what is the story behind the graph’
• Trends in graphs give like to bigger possible questions

Michael Cookson

• Managers (at IBM) are measured on their mentoring of minions
• GROW model – Goal, Reality, Options, Way forward
• If you do coaching in a prescribed manner, all the time then it will fail
• Forced coaching doesn’t work
• Often we are coaching, even when we don’t realize it
• Look for the motivation behind the goal
• Don’t take on the problems of the person you are coaching / mentoring
• It is important to understand ‘why’ someone likes something. Maybe some life event, maybe they are good at it, etc.
• Can use the GROW model for teams as well as individuals
• To origins for a coaching relationship: the person approaches you for help, or you see that they need help

namespace :maintenance do
  desc "start maintenance"
  task :start do
    run "ln -s #{deploy_to}/shared/maintenance/maintenance.html /tmp/#{application}-maintenance.html"
  end
 
  desc "stop maintenance"
  task :stop do
    run "rm /tmp/#{application}-maintenance.html"
  end
end

Fairly self explanatory, but for the cap impaired what it is doing is creating a symlink in /tmp to a file in the deployment directory.

Notice that this is not in ‘current’ or ‘releases’. We want this outside of the deployment so we can control its content very tightly and always know which file is being served. You will have to put this there yourself.

Of course, just creating a file is not enough. We need to tell apache to do something special if it is there. This mod_rewrite rule will do that. I put it at the beginning of all my rules.

RewriteCond %{REQUEST_URI} !\.(css)$
RewriteCond %{REQUEST_URI} !\.(png)$
RewriteCond %{REQUEST_URI} !\.(jpg)$
RewriteCond %{REQUEST_URI} !\.(gif)$
RewriteCond /tmp/monkey-maintenance.html -f
RewriteRule ^.*$ /tmp/monkey-maintenance.html [L]

What this does is return the file we created with cap above if it exists. Because it is the first rule, then users will always get that page. And because we are not applying it to css or images requests our static page can have them in it. Without them the page would just be all text.

Customers will be still annoyed if they are doing something while you kick into maintenance mode, but at least there will be some sort of explanation saying what is going on so hopefully you don’t have to do this too many times in one day. In order to try and stave off that you can test the app before opening it up again.

Except you can’t if you show a maintenance page for every request. But this is easy to work around with 2 lines of apache config and a dns entry.

The first change you need to make to apache is create a ’secret’ alias for your webserver using the ServerAlias config directive.

ServerName monkey.goucher.ca
ServerAlias s3kr3t.monkey.goucher.ca

You will need to add that new host into your DNS records to point to the same server and the non-s3kr3t one.

Next we add an additional rule to the ones created around the maintenance page.

RewriteCond %{HTTP_HOST} !^s3kr3t.monkey.goucher.ca$

Now the rule will be not be applied when going to the s3kr3t page so you can test it before taking down the window. For the hyper paranoid you could also restrict it to only the office’s gateway IP as well.

Ideally, you would have cascading deployments which result in no downtime for any customers, but is non-trivial and can result in greater hardware requirements than you might have at your disposal. For small to medium applications, I think this would work just fine.

• A 10 day course
• How to run Selenium tests with Hudson
• Another ‘run Selenium in the cloud’ vendor
• Testing Nexus with Selenium – part one, part two, part three
• Javascript character key codes
• PreparedEval – Prepares Java strings for JavaScript evaluation, similar to SQL prepared statements. Saves you from quote escape nightmares! Great for Selenium tests.
• Selenium Examples – the blog
• Creating Firefox profile for your Selenium RC tests
• Data Driven Testing with Selenium and TestNG
• 
  Automated Testing with Selenium – webinar next Friday (October 16, 2009)
• Putting Selenium in the right place
• Example of using Selenium to automate Drupal configuration changes across several servers Chris Shattuck – a video, on, well, what it says it is about.
• Running Selenium Tests with Maven
• Auto Exec Server – in Japanese, but google claims it is ‘Using the Selenium AES, Selenium run regularly every day of the HTML format tests, and can easily send e-mail the results.’
• HTMLSuite – a bunch of enhancements to running suites of selenese based tests (also in Japanese)
• And still another run-your-tests-in-the-cloud provider

• Do you have dedicated support channels for people to contact through
• Who is answering the phone? An intern? Or someone who actually knows the product — and its use in the Real World.
• Are they separate from Sales?
• How empowered are they within the organization?
• Is there development resources available to the Support group?
• When not fighting individual customer fires, are Support members proactively contacting customers?
• Are there dedicated people for specific key clients?

I think that if you do those things then things that slip into production, and there will always be some, can be overcome from a customer retention / warm-fuzzy view.

Ecosystem

The other area that helps you win the market is the creation of an ecosystem around your product. Linux is the classic example of this. There are a lot of rough edges to the Linux experience (admittedly less than when I learned it way-back-when) but it grew, and grew based on the support users were able to give each other in the ecosystem.

With the rise of Web 2.0-ish companies and greater corporate transparency, the patterns for ecosystem development are starting to be (more) well known. The two big items for my current thinking are:

1. Have a Community Manager (or similar title) to be the face of the company in the ecosystem. They will monitor forums, email lists, etc. to gauge the pulse of the community. They will also work hand-in-hand with Support to answer questions from customers, and prospective customers
2. Don’t let the community stagnate. A healthy community is a healthy product/company. When I’m looking at either of those, I check the traffic on their user forums and mailing lists. If the most recent post is 3 months ago, thats a yellow flag.

This is actually the second time I’ve written this post. The first time ended up sounding too Quality Is Dead. You could make the argument certainly, but I don’t think that is what I am saying. Quality is still an important feature; but if you have high quality Support systems and community/product ecosystem then you can often (more than) compensate for minor (and sometimes major) quality deficiencies. And that is what gives you the win.

• Talks to the customer
• To find out what they need
• Interacts with both development and test
• By prioritizing work
• And accepts or rejects it before it gets to the end user

All of those thing have a HUGE impact on what gets released. If the product owner is all over the place, then the product will be too. If the product owner only pays lip service to quality, it will be evident when it gets released. If the product owner doesn’t have the pulse of the consumer / market then they will be leading the project down the wrong road.

There is a whole industry around training testers to think better and to write better automation to make them more efficient. There is an even bigger industry around training developers to write (more | any) tests, loosely-coupled objects, etc.. What I don’t have any insight into is what we are doing to make our Product Owners better in terms of Quality.

I suspect this might be a potential role for an evolved tester. Usually the roadmap is junior, intermediate, senior, lead, manager. Perhaps there is a fork in the road somewhere that takes you up into the business side of things where you can drive a Quality Agenda from.

Food for thought.

• Don’t fix bugs on features no one uses. I would go further and question why something is in the product at all that is not used.
• At it’s core, CD means ship more frequently
• Regarding automated testing: now we’re playing for keeps
• That is a huge problem for me though. That implies that we know what the automated tests should look like to replicate human behavior the first time. We, as humans, are very bad at looking into crystal balls regarding the future.
• CD implies at a very deep level that tests will be executed in parallel. That can only be a good thing in my books.
• As is the idea to run tests in random order even when there is no commit-triggered build in order to find race conditions.
• Debug all failures. No excuses. Your automated tests are the only thing between your IDE and the customer.
• The most powerful idea in Timothy’s talk was about creating an Immune System for your application. I completely want to steal this idea. Essentially you instrument the application out the wazoo and it will automatically back out changes that cause a rush of white blood cells. Things like ‘number of registrations per minute’ or ‘conversion rate in 30 minutes’ are monitored; real business drivers not low-level server stuff. Well, likely in addition to, not as complete replacement.
• The crux of CD is that you are putting code in front of real users as soon as humanly possible so they can derive the most value from it. This is standard Agile theory, pumped up on steroids to clown-like proportions as you could be delivering code 30+ times a day easily.
• But customers are also the primary human means of problem discovery as well. Which is the principle problem with CD from a ‘tester’ perspective. I don’t want my customers to experience annoyance, frustration or confusion from my application and take their money to a competitor and tell their friends why they couldn’t do X as advertised on the system. CD seems to have accepted that ‘customers will find bugs’ and are ok with it. I accept that they will find bugs (perfect software is a myth, etc.), but I’m not ok with letting it happen with just a shrug.
• Lock the repo when something fails since you are now in an unstable state.
• Integrate the operations team into the development team. Again, nothing new here. We want to develop a culture of ‘the product team’ not silos.
• We don’t have QA people writing tests, we have engineers writing tests. Ummm, ya. I’m having deja-vu here. This sounds a lot like early Agile/XP where testers were not needed because ‘the bar is green dammit!’. What is state-of-the-art now? Oh ya, having ‘agile testers’. Guess that didn’t work so well, did it.
• Wow. What a shock. CD is also related to Lean thinking. That metaphor has taken a beating recently in the testing world.
• You have to make sure your application/platform can handle every edge case. Which of course means you can predict them all.
• You can’t just start doing CD; your application needs to be built around it.
• At 58:30 he says that another option is to deploy not to production, but to a production-like environment. That’s the winning idea
• Have ‘dials’ for all features. The volume of the dial determines how much of the cluster gets the new feature.
• Gradual deployment is also a component of CD. That is the great backstop that lets your pull things out of production if they don’t work.
• In response to a question about whether to use it in a ‘mission critical’ (which I’m going to take as ’someone could die’) he admits that CD is likely not right in that situation. This reinforces the notion I’ve had from seeing other stuff on CD that it is fine for ‘toy’ applications (where things like even large social media things like Twitter and Facebook could possibly be lumped as ‘toy’), but if you are in the ‘enterprise’ or higher then you need to really, really think twice about doing ‘pure’ CD
• Once a failure is rolled back from production you need to write unit and acceptance tests for it so you don’t find that problem in that way again. Fine. But what about all the other ways?
• Engineering problems quickly become people problems. Ain’t that the truth.

• … she entered a three-month management training program …
• While traditional perks such as pensions and health insurance still have their place, more companies are finding inventive ways to attract, retain, and motivate their youngest employees—using everything from work-from-home programs to faster promotions to financial benefits that kick in a few years down the road. Says Adam Kling, a workplace consultant with RHR International: “They’re using those and other perks to help offset what you’re seeing in your monthly paycheck.” Or more to the point, what you’re not seeing in your monthly paycheck.
• The Big Four firm still attracts more than 3,000 highly sought-after accounting students each year with extensive training and mentoring programs, performance bonuses, and the promise of face time with top executives—including an annual trip to Walt Disney World (DIS) for all U.S.-based interns, where they get to mingle with the powers that be.
• To make the most of their recruiting efforts, many companies are scaling back their scope. In recent years, Philip Morris USA dropped nearly 50 campuses from its program, leaving it with just 34. Philip Morris President Craig A. Johnson says the quality of new hires is up as a result, and that more interns are being converted into full-time hires: 47% in 2007, up from 32% in 2005.
• For many companies, though, the bigger problem—far bigger than recruiting—is retention.
• Indeed, one reason high pay alone is no longer enough to guarantee loyalty is that many members of Gen Y, who have been entering the workforce since 2004, have other priorities. For them, issues such as community service and serving the greater good are among the most important, according to the 2008 Universum USA survey of U.S. undergraduates.
• By making a big impression when it matters most—in the first year of employment, when a lot of entry-level hires jump ship, or at the three-year mark, when boredom and frustration often set in—employers can get their young charges over the hump and, with luck, motivated to stay on for many more years.
• While many companies award promotions only when a vacancy exists, several, including Philip Morris USA, have shifted to a system that considers employees for new positions whenever they’re ready—vacancy or not—thereby removing one of the biggest obstacles to promotion.
• And Whirlpool is now giving employees a chance to fast-track their careers by offering them opportunities to work on special projects that will enhance their skills, thus making them eligible for promotions earlier. The projects can be anything from a 60-day stint with HR to six months spent designing a new appliance. The pilot program was started in July, but the company expects it to be popular with young employees and to improve retention, which is already the best among consumer products companies in our ranking. “The more opportunities we can provide our employees to engage in meaningful work and challenging assignments, the more quickly we can help them achieve career goals,” says Jeff Beavers, Whirlpool’s director of global university relations.

Reading between the lines then, training and non-monetary carrots combine for low(er) turnover and thus better reputation the company has in the market. Better company reputation, the better you look for having worked there. If your employer has high turnover, no training plans or other schemes to better you, it is a warning sign.

Article two is The Companies Headhunters Avoid and reinforces the deductions from the first. In fact they are back-to-back in the dead-tree version.

• The question: Which companies do they largely avoid recruiting from? Some of the most cited are known to be in turmoil …
• Recruiters also singled out companies that are widely viewed as successful.
• The conclusion among headhunters is that the very attributes that make Coke a great company—an iconic brand and an unmatched global distribution system—also make it too easy for young managers to rise without having to develop the entrepreneurial skills necessary to compete in other arenas.
• Whether it’s their quirkiness, poor leadership development, or political culture, these players have become the corporate equivalents of the Hotel California: You can check in and enjoy your stay, but the risk is that you can’t leave.
• Three of the companies named as problematic by recruiters made this year’s ranking of best places to start a career.
• One trait that puts a company on the blacklist is excessive bureaucracy.
• … recruiters take issue with what one describes as a “patrician culture of conflict avoidance,” which tends to make some alumni ill-equipped to handle crisis
• One peril is a tendency at some companies to relegate managers to narrow duties, thereby fostering limited skill sets.
• Several Silicon Valley headhunters say they’re now hesitant to recruit from two of the tech sector’s most successful companies because of their testosterone-driven, take-no-prisoners cultures. Managers who thrive there, they say, are often bad fits anywhere else.
• … a culture that seemed to reward executives more for political skills than results.

It is accepted that most upper-level positions in business/management do not get advertised on Craigslist but are instead handled by an agency of some sort. As testing evolves, this will become more normal in this field as well. But even before that, hiring managers will see your resume and see your employer. Is that going to tilt the scales in your favor or against? It might be worth seeing what the market has to say about your employer and then seeing how you can offset or escape it if necessary.

1. Feature Flow – These are the classic type of scripts where you automate a flow through an application in a long series of steps.
   
   selenium.type(”Search”, “monkey”)
   selenium.click(”sButton”)
   
   For additional maintainability and reuse, you will evolve things to include helper methods/fixtures. I would guess that the vast majority of scripts are of this type.
2. Page Object – If Feature Flow is ‘functional’ programming, then Page Objects are OO. The webdriver project (which is what is going to power Selenium coming version 2.0) has what appears to be the definitive reference on Page Objects. Essentially, each Page is an Object.
   
   myPage = searchPage()
   myPage.search(’monkey’)
   
   with all the implementation details are tucked into the search method code.
3. DSL – This method is an abstraction layer on top of the implementation details which typically makes the script more consumable by non-technical persons, but also to hide lots of details from technical persons that they don’t want to worry about either.
   
   go_to search_page
   search_for monkey

What I realized is that they are not really exclusive. You can use bot Feature Flows and Page Objects as the underlying logic for a DSL. And in fact, the implementation details that are encapsulated in the Page Object methods will look like Feature Flow code.

There has got to be other patterns also out there that I haven’t heard of. But what are they?

Neither of A or B are precluded from offering their smaller bubbles back in into the the core projects (IDE, RC, Grid) at some point in the future if they desired. But at the same time, the Foundation wouldn’t be obligated to accept them if they were too specific to a certain problem.

Of course, the venn diagram starts to break down pretty fast once you get more than two participants, but I think the model in-general resembles something close enough to the Debian / Ubuntu one that it still will scale out. The devil is of course in the details and the political will must exist among the existing vendors in order to make it happen.

• Either give the little blighters the knowledge and skill required to become good scouts, or keep them at home and give out badges for ordering pizza.
• Indeed, there is a thin line between savagery and civilization, but there is also one between civilization and demoralization, and somehow we have to civilize boys without turning them into ciphers.
• I hasten to add that girls are just as disadvantaged by the ban, as girls need to be just as prepared as boys. What’s next? Confiscate all the needles from the sewing kits? No tent pegs?
• “Be Prepared … a scout must prepare himself by previous thinking out and practicing how to act on any accident or emergency so that he is never taken by surprise.” And: “The boy is not governed by don’t, but is led by do.” – From the Boy Scout manual

I don’t have a nice, tidy connection to testing with this (yet), but I think it goes something along the lines of: In the context of Scouting, a knife is their primary tool and they need to know how to use it effectively in their context. In testing, our primary tool is our brain. We too need to know how to use it effectively in our context(s). Relying on ‘best practices’ promoted by people who do not know or understand your context is akin to handing over your knife to someone in order to keep you safe.

Actually, that did come out rather tidy.

And while we’re talking about Scouting, my son is now a Beaver and I’m one of the Colony’s three leaders. That means I get a subscription to Scouting Life magazine. In the August / September 2009 issue they have an article on which forms you need to use for different types of activities which included:

Leaders and Participants are:

Seems like a good set of guidelines for a lot of different situations, like building a team, or even a company.

• Don’t put off layoffs – procrastination isn’t good for anyone
• Always make an outline
• Mind the generation gap – don’t try to give them a snow job
• Research before hiring – find out who you both know and ask them their perspective
• Run efficient Meeting – send materials out in advance and make sure everyone reads them
• Enforce punctuality
• Target your message – worry more on what the audience needs to hear than what you want to say

Leadership lessons from Home Depot’s CFO, Carol Tome – article

‘ve learned a lot. I’ve learned that it is really about the power of the team and the importance of alignment. You’ve got to break down silos, particularly in an environment like this. The only enemy we have is the company headquartered in North Carolina [Lowe's]. We need to be aligned as a team, and we have made great progress in that regard.

I’ve learned that you’ve got to have a sense of humor. We’ve had some dark days, and the ability to just crack a joke or laugh for a minute really does help. It really is important to laugh at yourself and to say, Okay, I blew that, but that’s okay. Pick yourself up and keep going on.

And never lose sight of the customer. At the end of the day it all comes back to the customer. The more time you can get out of the office and spend time talking to the customer, the better it is.

The new rules dealing with the downturn (and setting yourself up for the rebound) – article

• Narrow your focus – Strategic cutting wasn’t the end. It was the means for positioning the company to grow.
• Accelerate innovation – The more you do, the more you can do
• Aggressively leverage what you can control
• Obsessively search for the right growth – not just any old growth, but the right growth

And the last paragraph is also really good:

No matter what business you are in, no matter what you’ve done till now, there is still time to change your attitude from that of fighting for survival to seeking opportunities for growth. Face the tough decisions, but don’t let cutbacks stop you from seeing the windows of opportunity that are suddenly open. Think creatively. Act aggressively. We can’t predict with certainty when the broader economy will recover. But your company’s recovery can begin whenever you’re ready.

Four strategies for managing a company – article

1. Make a big business feel like a small company
2. When things get complex, do your homework
3. Acquire to grow, not cut
4. Know where your business is heading