issue (18)


WordPress DB Tidy

As all WordPress developers know, it doesn’t take too long for the database to get clunky, especially with the wp_options table.




Exploratory testing was always in scope

Exploratory testing – I found it intriguing how it became so big a subject of it’s own, but also unsurprised given the damage done by an army of poorly qualified testers and testing demotion, starting around 10 years ago. And at a time when (pointless) reinvention of the wheel became IT industry pastime. Testers who test to the letter of requirement, and/or anything else they were told (Ad-hoc), are ineffective. Testing was a skill long before Agile – in fact since software was first conceived, testing was assumed necessity. So where did the term “Exploratory testing” come from?

I coined the phrase “exploratory testing” 23 years ago to describe the practice of some of the best testers in Silicon Valley. The fundamental distinction between scripted and exploratory testing lies in the cognition of the tester. The script-driven tester executes and interprets the results of tests that were previously designed and documented. In contrast, the explorer treats reuse of tests and test data as a tactical choice. The explorer is always learning and always accountable for using new knowledge to optimize the value of her work, changing focus and techniques whenever this seems most useful.
http://www.kaner.com/pdfs/ETatQAI.pdf

This is a more useful explanation, as recent attempts seem to have confused the issue somewhat. A pure script-driven tester has very little place in modern development, as the demand is for a much more skilled testers who, as well as working closesly to requirements, is also expected to contribute to process and make intelligent decisions around testing and reporting. You want a tester who will question, not blindly follow scripts. Over time, the expectation of testers was to adhere to a “do as you are told” mentality. A mentality, I should add, that quickly disappeared when a QA-related issue needed a scapegoat! So why is exploratory testing even necessary, if you have been provided with scope defintions?

When you test a registration form (always a good example), people rarely specify things such a field lengths, legal characters, security, etc.  I guess because a client is paying the bill, they expect some kind of expertise in return.  For example, to expect a client to have understanding of performance issues associated with AJAX, is plain naive.  So in that circumstance, a good tester would be immediately thinking about including security and performance in the testing roadmap.  Is it exploratory testing?  Well, we are being told, apparently so – it’s not immediate scope, or what the business is expecting (briefly taking their heads out the sand).  Exploratory testing can (and should) occur in any type of testing – be it functional or performance related. The majority of ET causes very little testing overhead, but there are many benefits to the project.

I have found the recent debates frankly tiresome, and lead me to suspect ET is being used as a springboard for people rush to define and “own” the term.  Offering Exploratory Testing as separate service is a nonsense, and it pointlessly separates out common sense from testing, and does us no favours.  If you lift the hood on Exploratory Testing services, you will discover nothing new, except a statement that we in testing, have decided to apply some common sense, all of a sudden. What, I am only supposed to think outside the box, when I am actually asked to? No wonder testing became a task, not a role – open to as much misinterpretation as Agile itself.

Education needed at requirements level – ask the right questions.  Testers with a few brain cells realise that in situation when all the right questions are not being asked, they can still be covered in testing, and fed back into the requirements review/improve process.  This would work great, except the client generally isn’t so available to consult about requirements, and project management may be a bit over-sensitive to issue reports made about requirements. One way of ensuring important technical considerations when testing, is querying client on key points – such as the volume of users it expects a website to concurrently support. That requirement will cascade down through to development approach, and so through to testing scope. And it won’t be called exploratory testing either – it will be a requirement. In fact, you can trace that problem to point of initial analysis. If someone isn’t asking the right questions, how can development accommodate all possibilities?

Exploratory testing did fill a gap, that is naturally left by the those making higher-level decisions.  Agile, if nothing else, made people acknowledge that requirement should be in the same constant review/improve process as with the SDLC.

Pinocchio by Cartoon Tester

Pinocchio by Cartoon Tester




HTMLUnit and Proxies

Proxies are bain of automated testing, but there is simple way to both create a profile add proxy details, along with username and password (often forgotten in proxy tutorials). Here is the Java code that solves issue, when using Selenium Web Driver and HTMLUnit.




Code bloat

Every web application developer should learn html, css and javascript coding standards – given how frequently they are also charged with resultant front-end output. The forgiving nature of modern browsers can mask a whole heap of problems, that will cause performance issue, and on more extreme level, applications errors. Sloppy html coding can result in passwords being exposed, session tokens visible in URL’s – so security can be an issue also.




$HIDDEN1.*

This is a start to pepper my opinionated Agile rants with some useful test automation tips. Although used to other test tools, I am finding Visual Studio Team Test surprising, challenging … and sometimes leaving me with feeling I want to rip it’s head off. Here’s the first anyway.