Do you get the feeling the British government isn’t doing us any good?

  • The banned psychoactive substances, but not tobacco.
  • They make shops cover up the cigarettes shelves, but alcohol is on full display (and in reach of kids).
  • They claim to be working for greener future, yet pollution in London is rising (and killing).
  • They nod head to towards war on drugs, but remain impotent as corruption/collusion exists at high-level.
  • They push for private healthcare but still trade off the public’s emotional attachment to nhs.
  • They implement tax laws that crush 1000’s of small businesses, but help large corporates.
  • They claim to get tough on crime, yet some gangs exist with no challenge to their activities.
  • They sell off revenue departments to private companies.
  • They allow property development companies to dictate planning.
  • They have allowed massive investment in London, from highly dubious sources.
  • They have somehow managed to make education system worse since than the 1980’s.
  • They created departments/hotlines for reporting public fraud to councils, though still no accountability of the more worrying fraud/corruption inside councils.
  • They (all parties) constantly and incessantly lie.
Advertisements

Test engineering

OK, let’s cut to the chase. Testers are part of your team, not an anonymised bolt-on. This was an attitude prevalent 20 years ago, but at least then, testers were taken seriously. What we have now is too many making evaluations of what testing is and where it should fit in. Testing is a free-for-all area that many self-appointed experts reside in. And the more testing becomes test engineering, the more foolish those people look.

Who (as a tester) has not heard the response to you job “what, you just sit around surfing website all day?”. Well, these people are not worth correcting, but it illustrates a point – even with 20 years QA experience, it amazes me how many feel need to tell me what I do, and why I do it. My twitter feed gauge my annoyance levels, full as it is, of strongly-worded diatribes on this subject. It is bad enough that in contracting, I am generally following in wake of amateur balls-ups. And balls-ups that went on for too long, as no-one took interest or monitoring the ongoing development of tests.

Part of problem is that testing world is full of enthusiasm, but few with real test engineering skills. Want to impress your average company? Create hundreds of brittle UI automated tests, built on latest “funky framework”, then bask in the multiple “oooooooh!”, then time exit before anyone notices that:

  • No-one is using the test framework repo, apart from the tester.
  • No-one else is checking out the repo.
  • The tester becomes “Manuel Jenkins”, as the test framework only ever running on their pc.
  • The hundreds of tests are pointless, useless and throwaway

Then I come in to mop up the mess, and deal with bad perceptions/understanding about test engineering. There is a problem around the decision-making process, usually made by project members who view a project like this:

Airplane

Generally, process and products are selected based on personal taste or even fashion (the worst). These are always sold with over-optimistic promises of improving things, simply by their existence on project. These helpful individuals may not even be connected with tech – maybe they just enjoyed a pretentious demonstration at a conference. And react like they have never heard the time-honoured sales line “All you problems are solved with this product!”. The people that decide test framework are the team, because they are the saps that have to use and maintain it.

Though a broad statement, test engineering is very effective bridge between development and devops. Yes, developers can factor in test framework maintenance and coding tests, into their workload. But why? It’s far better to have a well-maintained test framework they can use as necessary, rather than being concerned with it’s mechanics. Calling test engineering “developing in test” provided more confusion, as many role descriptions were essentially for a developer who was also prepared to write acceptance tests. By that, I mean tests that directly map to requirements, not unit tests.

If the test engineer is charged with creating and maintaining UI and API tests, this can save the developers a lot of unit test work, and if test framework set running on the build server, an excellent sanity check for every build. And based of real-life scenarios. The common whine when trying to get is that it gets in the way. Really? A failing test is an obstruction, and should be (whatever the reason it fails). Acceptance tests should be part of the build pipeline. Tests don’t obstruct, they inform.

I am generally following in wake of amateur balls-ups. And balls-ups that went on for too long, as noone took interest or monitoring the ongoing development of tests. Want to impress your average company? Create hundreds of brittle UI automated tests, bask on the multiple “oooooooh!”, then time exit before anyone notices that:

  • No-one is using the test framework repo, apart from the tester.
  • No-one else is checking out the repo.
  • The tester becomes “Manuel Jenkins”, as the test framework only ever running on their pc.
  • The hundreds of tests are pointless, useless and throwaway

Then I come in to mop up the mess, and deal with bad perceptions/understanding about test engineering. There is a problem around the decision-making process, usually made by project members who view a project like this:

Airplane

So process and products are selected based on personal taste, fashion (the worst). These are always sold with over-optimistic promises of improving things, simply by their existence on project.

Though a broad statement, test engineering is very effective bridge between development and devops. Yes, developers can factor in test framework maintenance and coding tests, into their workload. But why? It’s far wetter to have a well-maintained test framework they can use as necessary, rather than being concerned with it’s mechanics. Calling test engineering “developing in test” provided more confusion, as many role descriptions were essentially for a developer who was also prepared to write acceptance tests. By that, I mean tests that directly map to requirements, not unit tests.

If the test engineer is charged with creating and maintaining UI and API tests, this can save the developers a lot of unit test work, and if test framework set running on the build server, an excellent sanity check for every build. And based of real-life scenarios. The common whine when trying to get is that it gets in the way. Really? A failing test is an obstruction, and should be (whatever the reason it fails). Acceptance tests should be part of the build pipeline. Tests don’t obstruct, they inform.

What is the point of test automation?

Easily very little.  Whether it the most heinous and popular of crimes, the throwaway UI tests or (closely followed by) tests with test data and/or inter-test dependencies.  But even if all this is perfect, if it’s running on one machine, for one person, it’s just a good college project.  Or might as well be, for all the real use you get out of it.

The first step, after avoiding the perils of what’s outlined above, is to make it bigger. Drive tests using a specification language (i.e. natural language), but don’t forget to approach that as code, or too easily becomes a tangled library of accidental repetition.  The advantage here is quickly identifying common steps.  Everyone thinks their website UX is unique, but there is a lot that is common. Generating a good html report (with screenshots of failures), and a junit one for easy processing on systems such as Travis or Jenkins. Which brings me to important point – running tests on CI.

Integrating acceptance tests (which I what I generally call tester-generated automated tests).  It’s imperative to get maximum benefit from test automation.  The advantage of this approach, is it keeps tests lean and relevant and unique.  With no constrictions, you will no doubt have experienced testers or consultancies, who can generate hundreds of automated tests that provide “wow” factor, simply by quantity.  But run those same tests again and again, and the cracks will soon start to show.  Data dependencies, too many tests need updating with a code change, dependencies on other tests that start a cascade fail.  This is programming, remember, and same risks apply 🙂

While UI and API acceptance testing doesn’t replace unit testing, developers find the test framework useful in developing reusable tests (especially flexible API ones). Keeping in mind what is useful, and to who, help focus the mind.  My mind is very prone to veering off rapidly on tangents, so this was simple part of the way I learnt to avoid scatterbrained development.

Above all don’t play at it, do it. I have little patience for wasting time developing acceptance test frameworks that are unused.  Too many just “want it”, but don’t actually understand why, they just know it’s a “good thing”.  Which is why so many go through some consultancies pain before realising it can be a one-person job, well at least to kick-start it.

Manual tester are fast becoming a role that has become redundant in many ways, but others do not want to take it on. Hello to some PO’s and Stakeholders out there 😉 However, test frameworks and automation requires programming skills.  The best way to think about it is that’s it’s another developer on the team. (or more relevant test frameworks) can help bridge the old requirements to code gap.

How I stopped hating QA

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.

Continue reading

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.

Continue reading

Test a tester

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).
Continue reading

Out with the old, in with something … different

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.