Form filling using tables (Cucumber/AngularJS/Chai/Protractor)

Rather than pollute your Gherkin with “I fill in …” lines, you can create your own Gherkin and code, using table format. Many make mistaken assumption that Gherkin is somehow fixed format. Yes, the Regex trigger is the “Given”, “When”, “Then”, “And”. But Gherkin is supposed to be based on natural language, so as long as you observe some programming principles to creating new Gherkin, create your own. It’s encouraged as there is no way the out-of-the-box Gherkin provided by BDD products will completely accommodate your project requirements.

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.

How I stopped hating QA

  • September 25, 2015
  • Agile, BDD, ...

Guerilla test management – it became my accidental niche area.  From 2000-2011, I was working in primarily creative, publishing, mobile and media companies in QA/Test Management capacity – usually hands-on (asides pure strategy/management based contracts).  Either welcome or not, I was hired for my pragmatism and multi-disciplined QA skills.  I have built test environments on the sly (not kidding), experienced sabotage, back-stabbing, blame-game defences.  I have managed distributed teams, and have been a lone QA  on multiple projects.  I often had to learn new things, at speed.  What never changes (rarely) is my good-natured optimism, and refusal to allow others negativity to affect me.  But, a few years ago, I had grown tired of my management direction and tired of unhealthy chaotic projects I was hired to improve QA within.  On a personal level, the work felt vague with no focus, and increasing dissatisfaction.

BDD debugger

So what are we really building when we develop in test on a BDD project? A test framework, a test application? Well, both of these, but most importantly it is a debugging application, ideally integrated into CI and/or whatever the code build/deploy process the code goes through. Sometimes the debugging application is part of the application under test, and all for the better.