One of my favorite shows on TV these days is (don’t laugh) the show Property Virgins on HGTV. In it, an experienced Realtor walks first-time home buyers through the house selection and offer process.

A lot of times the “let’s watch a couple pick a house” type shows highlight the inexperience of the buyers. Buyers tend to focus on the wrong thing, like paint colors or light fixtures, and gloss over things that are hard to change, like room layout. But the best part of the show happens right at the beginning, in a brilliant move to reset the usually unrealistic buyer expectations.

At the beginning of the show, the host asks the buyers a few key questions to identify both their budgetary constraints as well as their aspects of a home they most value. It could be location, layout, lot size, etc. But the buyers always have some sort of dollar amount they won’t go over.

The next step the Realtor does is rather brilliant – they take the first-time home buyers to a house that meets all of their aspects for an ideal home. It has the perfect layout, the perfect location, all the amenities they want, in the right condition, at the right size and so on. The buyers inevitably love this home, at which point the Realtor asks the buyers to guess how much the home costs. Also inevitably, the buyers are pretty far off the actual price, and inevitably their ideal home is typically at least double, if not triple or quadruple the buyers’ budget.

And inevitably, the buyers have sticker shock!

Talking buyers off the ledge

This fantastic approach accomplishes two important goals:

• Convey what perfection costs
• Force a prioritization

The host is never mean about showing the expensive house, but instead presents it as something to aspire towards. This also resets in the buyer’s minds that every house they see from there on out is going to have some subset of their valued aspects.

But instead of discouraging the first time home buyers, this approach tends to force them to focus on what is most important to them in a house.

Resetting expectations

We often have clients that are first-time software buyers, or first-time-with-someone-who-knows-what-they-are-actually-doing software buyers. A lot of what we do in the initial part of the project is framing the project for success. We look at everything the client wants, talk about scope and budget, then reset expectations back down to an attainable level.

What we don’t want to see happen are those buyers that look at dozens or even hundreds of homes looking for that house that checks every single checkbox and comes in at their budget. That house might exist, or it might not, but a lot of time can be wasted searching and searching.

Constraints force prioritization and hard decisions. Having an experienced guide (like that Realtor host) ensures that the buyer understands what’s feasible for their budget, as well as the guiding hand on helping to share experience on what things matter (the electric wiring needs replacing) or do not (the bedroom has shag carpet).

Delivering value is really only half the equation. It’s up to us as developers to make sure the buyer understands what they are getting for their money (or time), relative to what’s out there in the market. If you bought a house in isolation, it’s hard to know whether you’re getting taken to the cleaners. But by having frames of reference (Product XYZ is similar to yours, and took ABC man hours/dollars to build), we can center the conversation around “what’s most valuable to me” instead of “how can we squeeze everything in”.

I’m kicking off 2012 conference season with what should be one of the top conference I will have the opportunity to attend this year. The Mobile World Congress is THE place to be if you’re involved in the mobile world. The annual attendance is generally between 50,000 and 60,000 people! Theme for this year is perfect: Redefining Mobile.

As mobile takes more and more importance into the life of consumers and become a primary focus for Enterprise business, we at SOASTA are trying to stay ahead of the game and provide the best testing products to address this ever growing market. As you know, we’ve announced our new mobile test automation solution a couple of weeks ago and so far the feedback is INCREDIBLE! We’ve held our biggest webinar in our history for the occasion and we’re looking for a repeat 2 weeks from now at a convenient time for our European customers. I’ve been doing demo of our new technology all last week and it really opens up some very interesting discussions and open a realm of opportunity for developers and testers. The fact that we don’t rely neither on simulator/emulator or OCR makes complete sense for them. They’ve been abandoning these inappropriate approaches for a while now and are looking at investing into what looks to them the only way to properly test their apps. Being able to test INSIDE the app, record every single events, actions, gestures received by the application is very, very appealing. Being able to use validations they’re familiar with because they’re CloudTest users is also a definite plus. They’re also very excited about the concept of Private Device Cloud (and by its possible public extension!). As you know, when testing with TouchTest technology, your devices don’t have to be tethered. It means that I can run a test on a device located on the other side of the world for example. Now imagine, a company having 3000 employees and developing mobile apps. Before TouchTest, to validate your application on a broad number of devices, you had to either buy the actual hardware or rent some VERY expensive lab provided by third party relying on OCR. Wouldn’t it be nice to leverage my employee smartphones to run my tests? When you think about it, they all have different smartphones you app should support (whether it’s iOS, Android, Windows Mobile, etc.), they’re all connected to different carriers … They’re a very good representation of your market! Because TouchTest doesn’t require your devices to be tethered, you can tap into this pool to not only run functional tests on all of them but also capture performance information during execution! Oh, and you don’t have to mess up your employee’ smartphones because TouchTest doesn’t require jailbreaking. How about that for redefining mobile test automation? Definitely a game changer the industry was expecting.

What’s also very interesting to notice is that every single customer we talk to about mobile test automation, is also interested to hear about our solution for load and performance testing. Validating functionally the application running on an actual device is one thing. Making sure that the full ecosystem the application rely on, whether it is the customer’s backend/infrastructure or third-party, is probably as important in 2012. Being able to reproduce actual traffic whether it is coming from desktop’s browser or actual mobile devices is today a reality every customer wants to take advantage of. Having one platform covering the whole end-to-end test requirement is key to them.

My goal at the World Congress will be to discuss our new technology with application developers and testers to get their feedback and ideas. Meeting with companies to understand their challenges testing their apps and show them that they don’t have to go back to the dark ages (aka manual testing) to ensure the robustness of their deliverable. I also want to discuss with potential partners who wants to provide the best technology to customers and are willing to be part of the best ecosystem today for software testing. In the past few months, Correlsense, AppDynamics and OpTier have join our rank to provide the best services to customers and I’m confident I’ll have some great conversation with partner with a compatible DNA so we can strengthen our platform.

I will also formally meet a number of Spanish customers during a business breakfast and roundtable organized by our partner Testabil. There are still a few seats left so if you’re interested to participate, drop me a note at fberinger [at] SOASTA [dot] com! It would be great to meet you!

This is going to be an AWESOME week!

• Tweet This!
• Share this on Facebook
• Share this on LinkedIn
• Share this on Reddit
• Email this via Gmail
• Stumble upon something good? Share it on StumbleUpon

Get Shareaholic

Related posts:

1. Mobile Test Automation the SOASTA way with TouchTest
2. Getting started in mobile web performance
3. Is the world cup killing Twitter?
4. Cloud Testing days in London – Join me!
5. The Cloud: A game changer to test, at scale and in production, SOA based web and mobile applications.

I released version 0.4 of Jezebel last week. It now works with Node.js 0.6.2. Ben Rady

I saw a blue being from another dimension clawing its way through the ceiling the other day.

If only.

The building I work in is being redecorated and on the way to the canteen  I noticed that the painters had covered a smoke detector with a rubber glove. You don't need to be a health and safety officer to realise that this is not standard policy and potentially risky.

But, paint fumes can set off smoke detectors and there were plenty of people around and there are many other smoke detectors in the building and the lack of other detectors covered with gloves suggested that decorators would be likely to remove it when they'd moved further down the building so I decided to do nothing about it. A clear spec violation, but mitigated by other factors. A reasonable short-term solution to an acute issue, but on the way home I still walked that way and checked that it had gone.

You'll sometimes hear testers described as pedantic and it's true that the detail and process-orientated aspects of our work are apt to be misinterpreted as (or can actually slide into) the rigid adherence to requirements.

It's not worth getting worked up about the term itself because, for example, to people who operate at helicopter altitudes on projects, the details are often just that, the details, the potential stains on the big picture and not their main focus or responsibility. And let's not kid ourselves. It works both ways and I'm sure you've got a few favoured adjectives for the teams you work with on a regular basis.

It is worth thinking about whether the description has some validity, and trying to demonstrate that it's not a fair blanket description of testers all the time. Look at yourself and wonder whether (a) now is the right forum and time for raising questions of detail; (b) whether any particular wrong you're concerned about really is not right given all the context or (c) whether despite being wrong it's also perhaps not not right for now and (d) whether you should monitor it and/or record the need to change it later, when it's more likely to be invalid and risky to have a spot fix buried in the codebase.

I've been pretty quiet in recent times, but that's going to change somewhat in 2012, so I thought I'd write this(*) to catch up.

As of last week, I am the QA Lead for the Wikimedia Foundation. My job there will be to create, codify, and execute the software testing and quality assurance regimes for the software that powers Wikipedia and its associated properties.

I've worked some other interesting places, among them Thoughtworks and Socialtext. I like open source and wikis. I have been a dedicated telecommuter/remote worker since 2006. Depending on when you read this, I'm in either Santa Fe NM or Durango CO, or somewhere else.

I have written about software a lot. Most of my writing in recent times has been for SearchSoftwareQuality.com  (warning: registration wall), but I've also written a lot for StickyMinds.com  and a couple of articles for PragPub.   I wrote a chapter for Beautiful Testing.

I created the Writing About Testing peer conference and associated mail list and wiki. I like to think WAT has had some influence on the testing/QA field over the last couple of years. I've given presentations at a couple of Agile conferences, once at PNSQC, a couple of AWTAs, and some smaller peer conferences from time to time. I attended two GTACs.

I've been using browser automation tools (Selenium  and Watir) since they existed. I know a lot about their history and something about how to use them well. As a programmer I am slow and simple. What programming I do is usually in Ruby.

I play fretless electric bass guitar with a couple of jazz bands, but outside of the WAT conference I'm more well known for playing irreverent tunes on a cheap green ukulele at software conferences.  I'm a pretty good musician.

I'm @chris_mcmahon on Twitter, christopher.mcmahon at gmail and gplus. I ignore LinkedIn and I don't have a Facebook page, don't try to reach me there.

* props to Warren Ellis, from whom I stole the idea of this post.

For testers like me, coding beyond batch/routine like scripting is a bit exotic in the main. In my experience most testers are doing VBScript on you-know-which-tool, maybe some Java on pretty much every tool as it’s the defacto language it seems. There’s a smattering of Python in use but the ardents seem few and far between. Then there’s fan boys like me doing some Ruby stuff all mixed with a smattering of other languages depending on the environment the tester works in.

I guess it’s more like doing testing which involves a bit of coding, instead of coding which involves a bit of testing. It’s great if your role involves you touching code at some point a few days a week. That way you can get your coding skills up and keep them up to. A lot of testers however are looking to start coding so they can develop professionally and of course utilise it for automation, testing, etc.

One problem I found was deciding which language to pick. So, simply put:

Step 1: Pick a language

There’s a multitude to pick from, the TIOBE index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) is said in some circles to be worthless but if you don’t know what’s out there it’s a good start point for reference.

What are you using at your current workplace? What are they developing in? Well there’s your starter for 10. Is there a particular tool you want to get good at, which involves some coding? Bingo, go learn that then.

There are languages that are flipping everywhere. Java, PHP, VBScript, JavaScript, C, C#, C++ and of course the handy ones such as SQL and Perl that have been in utility use forever.

If you can, pick one that’s going to see you able to use it day to day, ideally one that those around you are competent in too. It’s easier to learn that way.

Step 2: Find learning Resources, make a plan

In order to learn you need to find some trusted sources of tuition, I’m assuming you’re doing self-directed study here and not going on a course. Have a look at www.codeyear.com for example, how about http://www.sqlcourse.com or just searching for “Learn [language] online” and see what comes up. There are too many resources to list but plenty to get started.

Create some form of learning plan and set yourself a goal as to how many hours you’re going to spend learning your chosen language. I picked 100 hours after a suggestion on the Software Testing Club. I have a goal but not a how-many-hours-a-week goal, I study when I can. If you can set time aside then great. Regarding a plan, simply list out what topics you want to learn and tick some off or add some more as you go.

Step 3: Share your learning

There’s nothing better than backing yourself up against a wall, putting yourself in a corner, etc. by telling the world you’re going to learn to programme. Head over to http://www.softwaretestingclub.com and start blogging about your plan and progress.

Also, have a look at www.codepad.org where you can paste snippets of code, then post the link in your blogs. Set up your free Github repository over at https://github.com, there’s an easy to follow tutorial there and it’s 3 commands day to day to maintain your library. Don’t forget to use the Wiki you get to document what you’re adding.

Overall…

Just get started, whatever you learn will be of use!

Good luck and I look forward to reading your updates.

Just shy of the end of 2011 I started to do ‘100 Hours of Testing Practice’ prompted by a post from Phil Kirkham over at the Software Testing Club. Find his post here: http://www.softwaretestingclub.com/forum/topics/100-hours-of-testing-practice

First question - does 100 hours feel a lot or a little?

It’s an odd one, if you think about how we do on average 40 hour weeks in work then it’s not a lot. If you think about how much time you get to spend on your hobbies/pass times/interests then it’ll take more than a few weeks to get 100 hours in! In those terms 100 hours is a lot.

Either way, that’s the goal that was proposed and that I’m working too. 100 hours which I’ve not decided to dedicate fully to learning Ruby ‘stuff’. By that I mean the Ruby language of course, as I’ve defined it ‘beyond simple scripting, but also automation, frameworks and tools using Ruby.

I decided a few years ago that Java wasn’t the language for me, I did a formal course with the Open University as part of my degree. It was OK, but didn’t get me excited, far too verbose even if it is admittedly ubiquitous and probably a good language to learn career wise. (never say never and all that…). Ruby got me excited, it seemed very learnable like Python but more widely used.

The Blog Posts

Since Phil’s post was essentially an invitation to participate I decided to do so and share what I’ve been doing over at the STC. Each member has a blog space provided so I’ve been blogging my adventures there.

I’m currently at hour 22 of 100 and will be officially ¼ the way through early next week. So, does it feel a lot in reality? Well, yes actually. It’s taken a good few weeks to get this far and on the way I’ve learned a fair bit. I’ve also uncovered a lot I want to look at too.

This is a side benefit, the extent of my ‘view’ on what resources, sites, blogs, books there are has increased. So has my hit list of things to look at!

A little Git!

One other side benefit too is I set up a public Github repository for the scripts I’m creating. Not only is it’s sensible place to put scripts but it’s another tool I’m learning along the way.

Have a look at: https://github.com/MarkCTest/Script-Bucket

Why not join in the fun? Read Phil’s post and get started on your 100 hours, then blog over at STC to keep everyone involved and yourself motivated!

Have fun!

I wish I could remember where I first read it because perhaps it deserves attribution.  But many years ago I read about the two world views of physicists and they resonated with me.  One world view is that prescibed by things like General Relativity and Maxwell's Equations.  These have, in some sense a great mathematical beauty to them.  This is the "the universe is made out of marble" viewpoint.  Nice clean fields.  Very solid.  Then there's the other perspective, this is the perspective you have in systems like Quantum Electrodynamics.  There are lots of particles flying all over the place and probabilities.  Lots of statistics.  The universe is a messy organic place.  It might have been tempting to take those people and lock them away or something but darn it if they didn't keep getting great results.  So Marble and Wood.  The highly regular vs. messier put powerful.  I soon started using this analogy in computer science and that's what I'm writing about today.

One place this comes up is when programming with promises, or really any notification system even ad hoc ones.  In the case of a promise the situation is that you have some work that needs to be done "later" after some asynchronous operation has completed:  let's say that you are waiting for some data and when it arrives you're going to validate and extract some values from it, it doesn't much matter.  The natural way to do this with a promise would look something like this:

p.then( () => {do your work} )

or in javascript you might write

p.then( function() { do your work } )

In fact you can keep combining these things, if you have more work that has to be done after the first batch asynchronously completes you might end up writing something like this:

p.then( () => {do your work} ).then( () => {do more work}).then( () => {even more work});

Now the next thing that's going to happen is you're going to put this in a loop for your various 'p' read operations that need to happen and presto magico your application is done.  And you've fallen into the wood trap.

The reason that I try to avoid this pattern is that what's happened now is that on every iteration you're creating delegate objects and new promise objects that connect the various stages for each operation.  But the thing is they're all the same!  Despite the fact that all the objects are being handled identically (typical) we get no savings, we are using the most general dispatch mechanism to dispatch the very same code thereby creating far more garbage than is needed.  Of course each one of these promise chains encourages the next guy to keep doing the same thing.  You could even add stages that merge, select, batch, whatever you need, more stages, more wood.

The hallmark of the wood pattern is that the same chain of dependencies/computations is re-represented in data repeatedly -- achieving no savings for its sameness.  It is the most flexible choice, each datum could be handled seperately in a unique fashion but they probably are not.

How can you make it better?

Well of course a different pattern alltogther might be the right choice, something that looks more like this:

datasource.handler += () => { do your work }

or maybe

w1 = new {worker stage one object }
w2 = new {stage 2 handler};

datasource.handler += w1;
w1.stage2 += w2;

Now this isn't as flexible but it is much more economical.  With one fell swoop we're saying that they are all going to be handled symmetrically and we do not have allocation cost per datum.

Even if that kind of refactoring isn't possible just this simple thing might be very helpful.

var d1 = () => {do your work};
var d2 = () => {do more work};
var d3 = () => {even more work};

p.then(d1).then(d2).then(d3);  // this in your loop

This second form avoids creating a whole new delegate/closure in each loop iteration so in some sense it's at least partly marblized. 

Now of course this kind of transform isn't universally possible but if you start by saying "what are the rules for all my data" and then encoding that then you tend to end up in a place where you have low-to-zero overhead costs for each item and you just do the work.  If you don't you can easily end up in a place where there most flexible pattern is being used in a very regular way, at great cost.

I've often admonished people to use the simplest programming technique that will do the job to get the best performance.  Specifically, don't use virtual methods if non-virtual will do.  Don't use interfaces if virtuals will do.  Don't use delegates if interfaces will do.  This discussion has in some ways been a rehash of that point.  But then I always found that grounding a concept in an example is helpful so hopefully you all found it worth the read.

P.S. I'm putting the "wood" programming technique in a bad light here but it has its place.  And that doesn't mean I'm down on "wood" physics.  I happen to think QED is every bit as cool as cool as relativity :)

I recently joined the British Computer Society I also joined the BCS Configuration Management Group, and I’m now on the committee. To me it’s important to understand the place of CM on...

Visit The Build Doctor for the full article.

This video explains automatic client-side profiling of performance issue with Selenium 2 (part 1) and answers questions about the presentation (part 2). Slides of the presentation

By James Whittaker

This will be my last post on this blog. Tomorrow is my last day at Google. It was a great ride and a great pleasure to work alongside such brilliant engineers. I will hand over this blog to another test director and then find a new place for whatever blogging I do in the future.

Follow me on Twitter (@docjamesw) if you are interested in where I land and to find my next blog outlet.

Peace.

I haven’t worked this hard in years. Sorry for the delay in posting anything. Accurev just attempted to make a corporate version of git. I think most of the enhancements that they’ve...

Visit The Build Doctor for the full article.

I will be talking about MVC and it’s environnement today at the OttawaCommunity.net in… Ottawa.

For those who attended, or about to attend, here are the slides that are going to be used:

The Slides

I love Git. It’s very powerful tool that lets me bend my repository to my will, with commands and features that blow the other source control providers I’ve used out of the water.

However, the tooling just doesn’t do it justice. From the download, installation, integration and CLI experience, it always feels like (in Windows land) that you’re playing in someone else’s back yard.

Over the next few posts, I’m going to compare the experience of using Git with that of Mercurial, who has, in my opinion, lesser features, but a much MUCH better experience.

The Mercurial download experience

Let’s look at searching and downloading the Mercurial client. When I google “Mercurial” or “Mercurial Windows” or “Mercurial Windows Download” or variants, two of the top results are the official Mercurial home page, or the official Windows client, TortoiseHg.

From there, I want to download Mercurial. Both websites offer very clear ways of doing so. The Mercurial site:

And the Tortoise Hg site:

Two very large “download buttons”. These buttons are interesting in that:

• They link directly to the file to be downloaded.
• They both link to the exact same installer
• They know what OS you’re using, and display the correct installer accordingly

TortoiseHg is the official Hg client for Windows, and includes:

• The command line interface
• Windows Explorer integration
• Visual tools (Workbench etc.)
• Visual Studio integration
• Merge tools

It’s a completely out-of-the box client that includes EVERYTHING that you might need to run Mercurial, all in one package, and consistently presented to the end user.

Next, let’s look at the Git download experience.

The Git download experience

When searching for Git downloads, you’re primarily directed to one of two sites – the official Git site, or the official Git tools site for Windows, hosted on Google Code (and also GitHub, curiously enough). The Git site is clean enough:

Except I have 3 download links instead of one. Not a big deal most of the time, but already choices are presented to the end user over the Mercurial site. Clicking on the Windows link takes me to this page:

Instead of linking me directly to the installer file to download immediately, I’m directed to the downloads page of the Google Code site, where I am presented with yet even more options. There is nothing in this screen that screams “THIS IS THE INSTALLER YOU WANT IGNORE THE OTHERS”. As someone new to Git, how do I know which to choose? Probably the first one, and most people would choose the first one, but presenting choices here is pointless and confusing.

Not to mention, I’m whisked away to a site that has nothing to do with the original Git site. The official Git site didn’t mention “msysgit” but now I’m on the msysgit Google Code site. Even more confusing is that the file has the name “preview” in it, and the installer is labeled as “Beta”. So is the right one or not? I might be inclined to search for the last “good” release and not a beta/preview one.

The Git installer is also less featured than the Mercurial one. The official Git Windows tools include:

• Windows Explorer integration (very limited)
• A CLI through the Git Bash or directly in a command prompt
• Visual tools (OK tools)

However, I typically don’t point folks to the official Git client. Instead, I point them to Git Extensions, a more fully featured toolset that includes:

• Windows Explorer integration
• Visual Studio integration
• Richer visual tools
• Bundled merge tool
• Bundled Git installer

This isn’t the official Git Windows client, so you basically have to know it exists to find it. Almost none of the online tutorials recommend it, even though it matches much more closely to what Mercurial provides out of the box.

Improving the Git download experience

In two easy steps:

• Have the official Windows client be as full featured as the Hg one. Could just start with Git Extensions and go from there.
• Copy the Mercurial website’s behavior

In short, prefer Simplicity over Choices. Have defaults, and obvious ways to get to the non-defaults.

I've tried multiple approaches to storing application configuration with Node.js but most have been painful until I found this solution.

tl;dr: Executable configuration FTW via exports.

With Node.js you can export an object or function for use within another module. This is key to keeping your Node.js application readable and structured which as I've found can be an art-form in itself.

My current approach is as follows.

I have a config.js which looks like this.

var url = require('url')


var config = {}


config.google = {};
config.redis = {};


config.google.id = process.env.GOOGLE_ID || 'DEVELOPMENT.googleusercontent.com';
config.google.secret=  process.env.GOOGLE_SECRET || 'DEVELOPMENT';
config.google.callback=  process.env.GOOGLE_CALLBACK || 'http://127.0.0.1:3000/google/callback';


config.redis.url=  url.parse(process.env.REDISTOGO_URL || 'http://127.0.0.1:6379');


module.exports = config;

Because it's a standard JavaScript module, when Node.js loads the file it will be executed with the config hash created. This has two important aspects.

Firstly, I can include other helper modules, such as being able to return a parsed url.

Secondly, I can take advantage of the current environment to determine if production or development values should be returned. This is great when combined with Heroku.

With the configuration defined, the logic to access the configuration looks like this:

var config = require('./config')
var id = config.google.id
var url = config.redis.url

No if statements, no redefining variables, no swapping files around. Clean, simple, effective.

If I wanted to have additional confidence then if NODE_ENV equaled production I could ensure all environment variables are not undefined.

This is working for me, but has anyone found any better solutions? Leave a comment or tweet me @Ben_Hall

Storing data in the session state is a little bit naughty as HTTP should remain stateless but there is a trade-off. In this case I wanted to test an assumption around a potential feature for Mayday. I felt it was more important to release than over architecture the entire solution with the possibility of dropping the  feature the next day.

When it comes to Node.js, session state is stored in-memory meaning any restarts or new deployments will delete the data.

Enter Redis

Redis is an ultra-fast, open source, advanced key-value store. To make it even easier, RedisToGo offer a hosted version with a Heroku plugin. After adding the plugin, an account will be created with a database URL provided as a configuration variable.

$ heroku config
REDISTOGO_URL   => redis://redistogo:PASSWORD@SERVER.redistogo.com:9712/
NODE_ENV        => production

To use this as your session store you will need to configure the middleware by defining a RedisStore from the connect-redis npm.

The require statements should look like this:

var express = require('express');
var RedisStore = require('connect-redis')(express);

var url = require('url')


For development you will want to use your local server.
app.configure('development', function(){         
  app.use(express.session({ secret: "password", 
                            store: new RedisStore({
                                          host: "127.0.0.1",
                                          port: "6379",
                                          db: "name_of_my_local_db"
                                        })  
          }));
}); 


For production you should use the RedisToGo URL provided. 
app.configure('production', function(){
 var redisUrl = url.parse(process.env.REDISTOGO_URL);
 var redisAuth = redisUrl.auth.split(':');


 app.use(express.session({ secret: "password", 
                           store: new RedisStore({
                                        host: redisUrl.hostname,
                                        port: redisUrl.port,
                                        db: redisAuth[0],
                                        pass: redisAuth[1]
                                      })  
         }));
});

Node.js and Connect-Redis will do the rest for you.

The key will be the session id for the user with the value being a JSON serialised object of req.session.

We’ve put a lot of effort to get to this point and there’s a huge amount of work still to do, but I’m proud to officially announce the event, Romania Testing Community Conference 2012 will take place on March 7th, at Opera Plaza Hotel in Cluj-Napoca

We have international speakers, we have [...]

Last week I was in Mountain View and very much looking forward to SFSE! I'm happy to report that it was packed, and if you missed it, before reading my take on it, you may want to check it out yourself without my biased point of view interfering at http://saucelabs.com/blog/index.php/2012/01/sfse-meetup-video-keeping-selenium-tests-100-blue/

I'm interested in learning more about selenium, well, to be specific, I'm interested in using Web Driver with Python and Ruby to automate tests where it makes sense and basically expand my capabilities in web testing. I believe automated testing is very important, and automated checks should be created, maintained, and relied upon as one aspect of quality by the development team. The whole team. I mean that when you ask who is responsible for quality the whole team says, "We are." When asked, "Who fixes the automated tests when they break?" I also want a clear, "We do and we don't develop new features until they are fixed." Anything less means your automation really isn't working to the level that your team can depend on it, so it doesn't have a bright future at this point, or should be rated "needs improvement" by the team. I've seen great test automation only twice. Both times the team owned it, relied on it, and would literally fix it right then. No shutting off tests. If it isn't sacrilege to turn off broken tests that used to work, the automation just isn't reliable enough to be counted on by your team.

So, with all of this in mind, let me share first the happy.  So many things to love about San Fran and Mozilla. The patio over there is WOW. Mozilla's got some bucks. That's all I'm saying! I almost felt bad about drinking their soda for a minute, but I think maybe they can afford even my Diet Coke for a night.


Also, a kind fellow took this shot for me! Volunteered even. That makes for a happy tourista. No, my hair hasn't turned black, it's was just a bit dark outside at this point.

Lest you think I was cranky, I had a blast that day. I've been waiting for a huge merge, and my devs did testing together! Yes! They fixed bugs and swarmed for the first time. This team had NO testers, and now they are testing their own code and I feel so proud of them I could burst because they are showing just what a team can accomplish together, and they care about testing their own work. Then I spent the day finding issues, and I even handed off a feature I coded, so I'm learning and teaching on the job which basically means that my self-esteem is at an all time high. I'm seeing a great friend who I enjoy, the sun is shining. I had a new type of food, even red wine the night before. I've basically been drinking free cool Diet Cokes between lovely sun breaks, and despite being pale I'm not sunburned at all since the sun is so mild in the Bay Area this time of year. I'm expecting to learn more automation and even see some developer testing, which I believe is essential for delivering quality software.

During setup, the meetup hosts had some problems, and I was able to suggest ways to use the seating already there so everyone could see. I felt helpful, competent, happy, and above all, like a part of this group excited to see what new things companies are doing with Selenium. It doesn't matter to me where the testing is happening. I am a fan of all testing. I believe that different companies and contexts can tolerate different amounts of risk, so I don't assume that every single company has a use for a test team.

Now the Sad Part

When the talk started, I had an open mind. I am learning more about presenting for developers and mixed tester/developer crowds. Personally, I felt that the slides weren't attractive and that they looked a bit "retro" like a 1995 slide-deck, but I said that before I was upset at all. Honestly, it's a great point that the content is all that really matters. The speaking was good and the story did flow. People were extremely engaged. At least you can tell from this blog, that despite the lack of beautiful fonts or lovely photography in the slides, that the presentation did invoke some emotion in me.



Large crowd had about 100 people. All polite and friendly.


By the time the speaker was done, I felt totally deflated. The presenter said things to me that felt derogatory to testers and dismissive to testing. I felt this way specifically because of the following statements, which lI'll try to be careful to quote and please verify via the recording to get the tone used.
1. We run 90 minutes of tests so we KNOW that everything is safe.
2. We do not have a QA team and we never want one.
3. It is ALWAYS best to automate every test. (this was said despite admitting vast difficulty with automating some tests)


It isn't only that the speaker said these things, but that many others in the room were nodding with such sycophantic vigor that their heads nearly fell off. As I looked around I envisioned the sinister large framed hipster glasses hiding evil eyes identifying me as a tester, and I felt like I wasn't welcome. The inexperience reeked to me, and I felt as if I was the only person who noticed that the demos AREN'T on a real website.

Then--want to know the secret? How they keep the tests all BLUE? It's this secret we've called resetting the baseline in testing for the past 15 years. They aren't even testing the actual THING. They are just notifying themselves of what has changed. It isn't new. If they had testers they might have found that solution sooner. It's a great way to resolve the false positives that are always a part of the normal complexity when doing automated checks. It is sad to me that developers who are inexperienced at testing are so certain that they have all of the answers that they don't even attempt to get any training in testing from those of us who have been doing testing for many years.


I find these slides retro, and note that code review is for people who don't like each other, pairing is for folks who do, but as a tester, especially as a tester who shines in the areas of integration, collaboration, usability, and finding requirements gaps, my opinion was irrelevant in this case. Perhaps a title change from Test Lead to Overlord of Automated Checks (90 minutes to total perfection code confidence) is in order. Maybe some provisos can be added such as "So long as they happen in Chrome, we thought to validate them, they weren't an issue that needed human judgement, and they were in the subset of important tests that we picked, but other than that we are 100% confident."



I feel pretty awful as a public speaker saying anything negative about any person, and especially a fellow member of the tiny group of females in technology who speak, and I want to be clear that this isn't personal. Not only were the speaking skills very good, but her enthusiasm for automation was infectious in a good way. If I've misunderstood, or misquoted, I apologize in advance and will make edits. I do believe that this is a common view in the Bay area, and just a team approach that was being candidly shared for the benefit of other people. I do appreciate hearing the plain truth of the work that is done by the doers and I know that having a good set of automated tests is hard work that takes technical skill and persistence. It isn't just what was said, but the feeling of such enthusiastic agreement and unquestioning that really emotionally resonated with me. The speaker was an experienced Automated Test Creator also speaking on team philosophy. While she's not likely up for Testing Advocate of the Year award(if such a thing existed), but she may be nominated with a few others for "Most Divisive Talk 2012". I've got many more talks and conferences to attend, so this may not even make the top 5 before the year is out, but I sure hope the "Let's trash all testing done by humans for any reason" trend can make the rounds in the Bay area and the rest of the country can keep doing good teamwork, like the agile teams have been lately. I'm seeing progress in developers and testers working together. I'm seeing good classes in mobile testing. From what I understand, this dismissal of the value of all human testing isn't what is happening in Europe. I think this is common in the start-up community and also in the web space specifically where there is venture capitol. It's less prevalent elsewhere from what I can tell so far.

It isn't that they don't have or want testers that bothers me. Why do you hate testing? Without understanding what you are dismissing why don't developers even ASK for our help to learn testing? I promise, we want you to test. Our numbers are shrinking. I never want to visually compare data again. Nearly all of the testing I do is tool assisted. There is lots of testing going on outside of the bay area. If you look, even in the space of the web, the secret shame of even the large companies is the human testing is STILL being done because it is finding critical issues that the automation still isn't finding. Even the boatloads of cash Google and Microsoft have thrown at automating all testing hasn't solved the issue.

When you aren't writing all new code, what then? When you ship your first catastrophic error and find that the dashboards you have aren't really as good as you thought, will that 90 minutes seem like it was enough? Or, when you simply want a human to test for usability, error handling, or the code you forgot to write or put in which even the best code coverage can't check for, the few of us who still put up with the emotional battering it takes to actually give two craps about testing in this hostile environment will be here to help you. How would you feel if a manager took a look at a code generation tool and because it gave an impressive demo felt it wrote better code than you do because it was more consistent? It couldn't replace your talent and experience. What if despite evidence to the contrary, they insisted it was true, and the room full of people clapped? Why are you still sending it to uTest? Because you've only checked it. If no humans have used it, you really have no idea what you are shipping to the public. That may be an appropriate risk in your business. Unlike you, I'm not one to tell people in other professions what is and is not true in their business.

I'm just thankful that there are places where developers and testers still work together. I'll be found in those places. It was difficult to write this. I'm glad I did, because I'm not sure I could give an overview without getting teary at our Seattle meetup tomorrow.

Oh San Francisco Selenium Meetup, you've got yourselves some major fans. On the way there in the traffic Marlena and I joked that the California state motto is, "Keep up or Get Out!" Well, I'm out. I also feel thankful that I work for a client who's been in business with NO testing team for 20 years. I'm the first tester. We now have a team! I'm working full time and another tester is working part time, and even our developers are learning to test. I'm also coding some features, shockingly enough.

It makes me very happy that now the person who hired me says, "I get it! You don't have to explain testing any more to me. I'm seeing it!" Yes. He can survive without testing, but we can all deliver features that have value to the customer faster and more reliably when we all care about and do testing. We don't have all of the automation we would like, and yes, I'd like more of a balance. I care too much for my profession to wish for anything other than forward progress for the industry. I love using software, not just earning a living. That is a big part of why I love testing. Each person I prevent from having a bad experience with software is a point of pride for me. That is true if I do the testing, or even if I teach one developer of a test he might run himself. If I teach a tester one idea they may not have tested before, I'm as happy as if I'd prevented the bug with my own code or my own test (I use both manual tool assisted tests and automated checks).

It isn't the unintentional innocence that upsets me. It's the willful ignorance combined with marginalizing an entire profession.  I have more than one skill. I'm not terrified that testing will die, because if it does, there are many other possibilities. I fear for the users of this software, because I am a heavy user of software. I also worry about who you are going to hire to do this totally boring work that no one wants to do. This repetitive droning work that so many companies keep trying to staff. You don't get it. You don't get why you suck at hiring testers. You don't understand why your SDETS are all moving to be full coders now? No one wants to be treated like an idiot and to be your code monkey boy. Stop treating people like they are less than human and then wondering why it's so hard to hire and retain the test coders with your laundry list. Then again, that's for another blog. I'm just thankful that the trip didn't end on this note, or I may have started to drink shots on the plane ride home to soothe my sore feelings rather than working on my testing ideas. There is a reason I'm working so hard to talk beyond just testing. A story of how easy it is to feel "100% safe" after running 90 minutes of automated tests is seductive. There is nothing that can be said to that. You can't warn. You just let it run it's course. Either there will be pain or there won't. I'm certainly at my limit when it comes to fighting a gorilla with a toothpick. I'm here for those who want to work with me, not to convince those who've got the answers already.


The bridge was still beautiful later. The structure wasn't as visible, but it was still there holding up the cars. The lights were far more shiny when the sun was down. It didn't make the supports less useful. I hope when they were last tested, it wasn't just in the emulator.

So, for me, the Selenium SF meetup was the most depressing night of January. I'm happy I met some nice people, and I don't let the opinion of a few folks lead me to assume that everyone shares the same opinion. I have hope for the future, and I am really optimistic to have a happier report for you about the Seattle meetup, which I'm going to be participating in. I'm still planning to take a class to improve my understanding of testing using Selenium, hopefully from Adam Goucher. By the way, if you think testing isn't important, please ask Sauce Labs what they think of the importance of testing and if they have any QA team or testers. I believe they have an agile team, which includes testing in many forms, including developer testing and other agile testing, including some thoughtful human exploratory tests.

Now, on to February and BEYOND! I hope the happy post from earlier was enough to sustain you through this long and pretty sad post.

Today I crossed my review comments for the Apprenticeship Patterns which I wrote back in 2009. I wrote a blog entry back at that time about My long road. Reflecting back over the past – maybe – 3 years, I noticed something I wanted to write about: alternatives to apprenticeships – most of them I came across at my current employer it-agile. I remember that we discussed the topic of apprenticeships a few weeks ago at the local software craftsmanship user group meeting in Münster. We found that the apprenticeship model does not fit well into Germany’s working model in the IT industry. So, we tried to come up with alternatives. Here are the ones I have seen implemented at different companies: Mentoring and Peer-Groups.

Mentoring

Mentoring consists of a mentee and a mentor, and a topic on which the mentee gets mentored. While this sounds like a bogus statement, I have found this mentor – mentee model in different places – sometimes with some kind of drawbacks.

In the Miagi-Do school we work with mentors. Well, after you found us, you usually need to pursue a challenge. An instructor will pass you a challenge, and then work you through it, eventually debriefing afterwards as well, and reflecting on your course of action. If you decide to stay with the school, you become a member of our group, and are encouraged to find a mentor if you want to follow up on higher levels. A few years back I was the instructor of Michael Larsen which really knew where his next challenges were, and I myself found a mentor in Matt Heusser through whom I eventually became an author.

But there are also other places you can look out for mentors. Some are offering free coaching on Skype, other might want to be contacted first. The most amazing place I was able to find mentors is my current workplace.

We have a mentor and apprentice model. You can basically pick any mentor for any topic that interests you, and you want to pursuit. Of course the mentor has to take on the additional time for mentoring you. That said, we have developers picking a more senior programmer to extend their skills, or they pick up a consultant in order to master their skills in this direction. Some of my colleagues are more interested in technical topics, others want to dig deeper on soft skills. There is virtually no boundary, as a senior consultant may also decide to be mentored by a programmer. Some of my colleagues even have three to four mentors at the same time.

One thing I found out over the course of the past years. When it comes to mentoring, it’s crucial that you pick your own mentor by yourself. First of all your intrinsic motivation will be higher to work with the one mentor that you picked. Another advantage is, that you can talk to your mentor about his contract with you, what the areas are, besides risking that there is another stakeholder in this game – the one who imposed the mentor on you. When it comes to mentoring the level of trust can not be undervalued. That’s why I picked some of the people I learned from the most outside my workplace. If my memories of the apprenticeship patterns recall correctly, finding a mentor is one pattern in the book. I whole-heartedly took it on multiple levels.

Peer-Groups

In the past year we played around with deciding about salaries. So far we had a system in place that didn’t scale: a group of four senior consultants decided about salary increases. Back in March we decided that every employer has the chance to self-select a group of peers which then work with the employer, and give recommendations for salary increases to the senior consultant group. Sounds crazy? Well it is.

Peer-Groups meet together from time to time, reflect on what the particular colleague did, and try to come up with recommendations for the future. In my particular case, I got some feedback from three colleagues, some of them I implemented, some of them I decided to keep stale for the moment. In our second meeting, I laid out my reasons to not pursuit this particular goal, and got some more feedback with some more goals, that I might pursue or not. So far, I found this group fully worth the time based on the feedback and recommendations I got.

In January we even decided to have a full day of peer groups. We met in the morning, working in a World Cafe on the idea of peer groups. Then we set up a market place with peer groups that wanted to meet and give and provide feedback. Some plans previously laid out were changed then, but we spent a full day with colleagues, talking about peers, how we see each other, and recommendations for further improvements. So far I found this feedback very valuable, nonetheless we are experimenting with 360°-feedback now. So, there might be more to come.

Conclusion

Picking the right mentor, and the right peers to listen for feedback and recommendation can help you personally grow. For both approaches it is crucial to keep an eye on the self-selected aspect of it. If this sounds like selection bias to you, maybe consider some of the constraints we initially put on the selection of peer-groups: at least one peer that is more senior than you are, at least one peer that is less senior than you are. We eventually re-formulated that into: at least one consultant, and at least one programmer in our final discussions, yet the constraints help you to decide about it.

One final thought. I myself consider me to know about the goals and directions that I want to pursuit. There are tendencies which I take up. So, meeting with mentors and peer groups far less is fine with me – so far. I hope to notice the right point in the future to change that. You might have a different cadence for similar get-togethers.

I still get questions that amount to "should I ngen my <something>" from time to time and the best answer I can give is still "it depends."  I wrote this article many years ago, and I'd say it's still pretty accurate: http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Essentially the situation is this: if you ngen your IL then of course the jit will not have to run but you will have to do more I/O because the compiled code is bigger than the IL.  If that I/O is likely to be cached because either:

1. The code is going to be loaded "a goodly amount of time" after ice cold startup and it's commonly used so superfetch is likely to fetch it, or
2. The code is in a library shared by many programs and so only one of those programs at most will have to actually read it at full cost

then it's likely that ngen will help you overall.

If that's not the case then ngen isn't likely to help you.  But really you need to measure for yourself.

Remember also that the code generation for ngen'd binaries is going to tend to optimize for maximum sharability which may come at a (typically small) cost in raw speed so that's a factor as well.

The most common framework DLLs, like mscorlib, system.dll and friends, tend to be get the most benefits from ngen.  Single-use application libraries and executables tend to get the least benefit.

It's really hard to say more than that with any kind of precision.