Test a tester

  • June 23, 2015
  • Agile

How to interview for a good tester is not as straightforward as imagined. Those using the ISTQB/ISEB Foundation Certificate in Software Testing certification, to measure competence, should be aware the exam can be taken as many times as you want, and there are numerous forums sharing tip and tricks. These are not what I would called tester forums, more like exam-scamming forums. This is not the fault of the certification itself, more down to the lack of formal testing qualifications. So it became a default. People appear to struggle with other ways to demonstrate competence quickly, other than certification (which are rarely fully checked on submission).

Out with the old, in with something … different

  • June 16, 2015
  • Agile

Part of human nature, in fact all animals, is the young usurping the older generation. That is natural. What is important in tech context, is how we make that healthy natural process less “primitive”, as it is ultimately to our advantages to have new thinking. The younger generation, in their more clunky fashion, will use emotive language, to force points: “Old is bad, new is good!”. Fresh young thinking is good, when tempered with older experience, i.e. it doesn’t have to be war. Also, there is no rulebook that says older generations can’t have new ideas.

#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.

Failure … is an option

  • June 5, 2015
  • Agile

I don’t judge failure harshly – if you are experimenting/aspiring then the route is paved with potential pitfalls.  BDD is based on principle of failing first.  Sometimes I repeat that fact many times, to guage how many whinces I see from senior management. If you have a team and environment that accepts that failure, then stress is lower, as all know that support is there.  Failures should not be hidden, and certianly not go unaddressed.

So why is appraoch not more common on IT projects? Do people still want to be told what they want to hear?  It strikes me (and it may be a particular British issue) that most are still stuck in an era when answering questions with giving a real answer, is considered an asset. How tiresome. The era of the self-serving manager is still definitely evident.   In this work environment, making a mistake is considered a weakness to exploit.

After 18 years, and 46 companies, I would like to see the back of tired old business ways.  If anything has held back IT evolution in UK, it’s business and self-serving management layers.

Natural Language Programming

  • June 4, 2015
  • Agile

This was from an article 5 years ago, and currently, BDD is contributing most to this end. it still feels like we are making our way in the part-dark, and it feels like the right path to take.

After so many years, the science-fiction concept of being able to tell a computer what to do by using plain human language is gradually going to become reality—in a way that fascinatingly coexists with what’s been achieved in high-level computer languages.
Stephen Wolfram