testing (447)


What do you mean?

  • October 2, 2016
  • Agile, BDD, ...

After working on several BDD (Behaviour Driven Development) projects, I was struck firstly by what a great development approach it is, if only from a test engineering viewpoint. While on the tech side, BDD is more clearly understood, clients may find the style of writing requirement commonly expected with this approach, more involved than they are used to.

There is still value in defining user stories only, if you are happy with trusting team to take care of implementation, and ask relevant questions. But perhaps you want to be more involved … So here is a guide aimed largely at Product Owners, on how to write requirements for not only BDD projects, but as alternative style to more traditional Agile user stories.




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 🙂