Recruiter subtext

A few subtexts from recruiter emails – remember, good news rarely arrives by email.  It’s electronic version of junk snail-mail 🙂

  • “Apologies if this email is irrelevant …” : This email is irrelevant.
  • “Only 20 mins from Paddington … “ : Job is in Slough and commute is hell.
  • “I really liked your profile … “ : I’m bored and been surfing LinkedIn.
  • “… if this role is not relevant, feel free to forward to any colleagues who may be interested” : I am struggling to find anyone, please help me!
  • “Shoreditch startup needs … “ : A startup, hoping to ride on the back of it’s trendy location, want underpaid skilled professionals.
  • “It’s backed by Rhianna” : I made up this job.
  • “Long contract at blue-chip company” : I vaguely hope you will be impressed, and overlook the tedious job description.
  • “Calling all testers!” : I am a control freak.
  • “Are you Agile?” : Because the client isn’t.
  • “Large international broadcaster needs tester …” : Sky/BBC gets hiring testers wrong, yet again.
  • “Great opportunity … “ : Crap work for crap pay in unpopular location.
  • “Perm Developr Role 30k …” : I haven’t checked your profile and I can’t spell very well.
  • “Yo!” : This is my first job.

This week, I will be mostly documenting

Executable Specifications Over Static Documents

Best Practices for Agile/Lean Documentation

Test strategies and plans – I have done many, obviously.  The most unread documentation you could ever find on a project.  Sure, you can promote and sell what you are writing, and gain support from people who are never going to disagree with anything with “quality” tag.  My focus is whether client is happy with progress or not – what better indication on how a project is going, than when you customer is happy.  The woefully under-estimated definition of done has more importance that a test plan.  Test strategies serve best at higher level, describing not hard and fast rules, but an approach to QA generally.  If you are going full BDD, then a test strategy become a little pointless. You are re-working a strategy that does not need that document, with BDD, testing is part of the pipeline from story to sign-off.

While testing strategy is important, it has little bearing on actual work and the place of testing in team dynamics. Documentation is largely a self-promotion exercise or time-killer, let’s be honest. How to slot testing into existing way of working, recommending change, as well as throwing measured hissy-fits at bad attitude/process.  In my earlier days, the documentation was key to making first good impression. As I care less and less about opinions about me, and never suffer fools gladly, I find the best way I can contribute is to start working – seriously, start working, don’t waste time beyond a week with your waffle about processes, tools and documentation.  Just do it how you feel is best.  As contractor, you are being paid not only for skills they see on cv, but your independent mind. Don’t have one?  Then why are you a contractor when you need validation from a crowd?

In the workplace, a sheep mentality is common – waves of people switching allegiance on sometimes daily basis.  It’s an easy crowd to play with, if you have a mind to.  But I am not in a contract to accommodate pack-like behaviour patterns.  I don’t judge anyone by documenting or presenting skills – I judge by an old-fashioned benchmark – results, and that is broad area. You want me to dazzle you with terminology and jazzy documentation, about a newer-faster-smarter approach, so you can be impressed, I can do that.  To give you the impression following a certain approach, will make your project run better, I can do that too.  But I would be doing you no favours.

By separating out testing into it’s own entity, is missing keys parts of Agile/Lean development.  Your scope is defined by the schedule, which you, in a QA capacity, had input into already (right?).  Outlining risks, introducing new testing tasks such as exploratory, accessibility or cross-browser/device testing.  It’s part of the project.  A test report at the end of automation or manual testing, indicates the test coverage.  Attaching labels and process is separate test documentation, will end up covered in digital dust.  To be truly useful, the documentation needs to grow with the projects.  I say projects, plural, as strategy documents should take a high level view. Reuse is not only a principle for coding, it’s relevant to test documentation also.

Documentation is part of the reason QA got such a bad name – over-documenting, the prime directive of the paranoid employee. The second directive is product-plugging, solutionizing by recommending open source products, as if they are your own.  That somehow you have risen above the chaos, executed a half-decent search on github, and found something no-one else could of (really?).  Get back to your 1990’s cave, because unless your documentation is helpful, and your product-plugging amounts to something real, then that is where you belong.

#1 Scapegoat

Tester as scapegoat. Yes, it still happens sadly, and not all are equipped to see it coming. My gut instinct has matured to see this kind of situation, though it is very rarely deliberate. The first sign is the feeling on your first day, you have been lumbered with a mess someone has left behind. So the strategy is hire a contractor, pass it over, and run away. Then further down the line, credit will either be taken for the contractor’s hard effort if successful. Regardless of the state of what is handed over, once handover is done, it’s yours. Whether you like it or not. How you choose to deal with it is another matter.

If you are going into contracting, especially in QA arena, be aware that things can/will happen that seem unfair. That’s life – and as a contractor, you are choosing to be more at risk of life seeming unfair. We have bills to pay, but that doesn’t mean I will stand for environment addicted to bad process in development management, or suspect project management. Because in the end, the project timeline fallout, can easily be landed at the QA door. And if you don’t push back, you will be liable to end up the scapegoat. So the skills you need are not only test planning, automation, etc … you need robustness to speak up and complain. it’s part of the role as far as I am concerned. There is little point maintaining great tests and automation frameworks, if the process that feeds into it is fundamentally flawed. That won’t stop people blaming QA though.

What I have come to value most in my skill-set, is my approach, which appears to now encompass not only what I know now, but what I will know. In order to keep up with the pace of tech (if you don’t want to be stuck on projects, where you want to scoop out your own eyeballs to alleviate the tedium), it is necessary to keep close eye on what is round the corner. And to learn fast but also efficiently. Some no doubt are born with these skills, but they also come from persistent experience. I say persistent, as that is exactly how it feels you have to be to stay in tech for any good length of time. In order to survive, you need decent softskills (emotional intelligence).

So in summary, if you feel something is wrong early in processes, voice it. You will not be popular for it, but do you really care what those people think? These are the people preparing (albeit maybe unintentionally) your slippery slide. So be ruthless when needed – but only when needed! The team spirit can be a fragile thing, so tread carefully but don’t pander too much to the way things work, if you feel they are flawed.

Firefox v32 issues with Selenium WebDriver (Linux)

Firefox 32 does not work with Selenium WebDriver, and if you use Ubuntu and have upgraded recently, this is version you will probably have.  You will have seen some kind of error message from selenium, complaining about being unable to bind to the port firefox driver uses. To get round this annoyance, and as Ubuntu dont make it easy to downgrade Firefox version, I used following steps:-

  • sudo apt-get remove firefox
  • Download binary version of your choice (I used version 31)
  • Extract to location of you choice
  • Create link: ln -s /path/to/your/firefox/folder/firefox /usr/bin/firefox

Now Selenium and Firefox will play nicely 🙂

Behat And Testing Design Errors/Changes

Comparing screenshots can prove effective way to verify design errors/changes, using CasperJS in conjunction with Resemblejs makes comparisons and reporting easy. PhantomCSS does exactly this, and the repo is available here. Or you can take my forked version here, in which I removed the PhantomJS junk, and altered scripts to just process the screenshots directory. It was only the comparison tools I was looking for .

The trick is now to generate the screenshots (the baseline, and the one for comparison).

As I use Behat/Mink, I didnt need most of the PhantomCSS repo, which assumes use of phantonJS are test driver.

I generate screnshots after certain steps to create baseline for comparison (best to do this in context of a test suite).

* @Then /^I take a screenshot of current page “([^”]*)”$/
public function takeAScreenshotOfCurrentPage($pagename) {
$image_data = $this->getSession()->getDriver()->getScreenshot();
file_put_contents(‘PhantomCSS/screenshots/behat_’.$pagename.’.diff.png’, $image_data);

Then I use PhantomCSS to do the screenhot comparison grunt work. There is a manual step, which which you establish the baseline screenshots. Then each subsequent test run, a new “diff” file is generated and comapred with baseline version. If differences, then an almalgamated image is generated to highlight difference (filename appended with “fail”).


  • brew install casperjs
  • (or) npm install -g casperjs
  • Clone repo
  • Assuming you follow my behat route ..
  • Run your test once to get baseline images for pages.
  • Rename files by removing the “.diff” part
  • Each time test runs, the newer comparison file will be removed and updated.
  • The command to do comparison is:- casperjs test demo/testsuite.js

 Rudimentary end to end process (todo: add verification step function, and call the casperjs command from within Behat function)

Testers should have waited

Interesting experience this week – I am sure the integration of development and testing worlds has been acheived elsewhere, but I doubt to the same mutually beneficial level. Usually development subsumes testing (i.e. no acceptance testing). The merging of development and testing worlds, can actually happen in a good way, with the right combination of skills, people and … process. A word unfairly despised, but simply a word describing how you would approach something. Sure, a bad process is not good, and a bad process not recognised, even worse. But no reason to avoid a word, because of bad application by inidviduals and companies.
Continue reading

Nothing good was ever fashionable

When the fashion becomes bigger than the substance in tech world, I naturally resist its pull. The substance gets diluted, re-branded, and owned after lengthy patent suits. The same goes for electronic music, for me. After 1994, when the Criminal Justice Bill pushed parties back into commercial clubs, business worked out ways to clone and market it. Much of dance music in underground scene, provided the drum sounds for the drum machines still used today. Music and tech – standing on shoulders of giants, always.

Take the wonderful world of the web. The first online ad appeared in 1994.
1994 first online banner adThe first tv advertisement appeared for the internet in 1994 …

Continue reading

Behat, Mink and DOM elements

DOM elementsThere is a constriction around how mink selects DOM elements, but you can customise the mink selectors easily. For instance, what if you have an image link that has no id or title? By default, mink will look for dom elements of id,title,alt or text for links, but this is not always relevant.

To add other DOM elements ….

$ sudo nano vendor/behat/mink/src/Behat/Mink/Selector/NamedSelector.php

You will find sections in this file for each type of selector – in this example, I am adding a dom element called data-id to the link type, which Mink will now look for in any UI link reference (text or image).

,’link’ => <<<XPATH
.//a[./@href][(((./@id = %locator% or contains(normalize-space(string(.)), %locator%)) or contains(./@title, %locator%) or contains(./@data-id, %locator%) or contains(./@rel, %locator%)) or .//img[contains(./@alt, %locator%)])] | .//*[./@role = ‘link’][((./@id = %locator% or contains(./@value, %locator%)) or contains(./@title, %locator%) or contains(./@data-id, %locator%) or contains(normalize-space(string(.)), %locator%))]