Mobile

Mobile Testing: Out of the Darkness

“Hang on a second… how do we test mobile?”

Blank. Other testers stop their tasks and raise their heads up, staring at each other and frowning, as if they were trying to find the solution to a 3,000-year old history problem, like trying to discover the origins of the Pyramids. The Great Mobile Lord has cast his confusion.

This confusion is a major risk to software quality, and this is why it is time to cast some light over these mysteries and show you how easy and accessible mobile testing is. So please join me in diving into the darkness of mobile testing.

Continue reading

Agile

Manual Testing and Automated Testing – the myths, the misconceptions and the reality…

There are many misconceptions in the software industry regarding both Manual Testing and Automated Testing. Some people believe that Automated Testing is the bee’s knees and exists as a replacement for Manual Testing. Others believe that Manual Testing is a simple set of step by step tasks that anyone can run through to check an expected output, and that it’s dying out.

The truth is that both are very important and necessary; they go hand in hand and complement each other. The bottom line is that in order to produce the highest quality app, you should have a strong manual testing element in place alongside utilising an automated framework.

So let us start by explaining a little bit about Automated Testing…
Continue reading

Architecture

Isolate and Test

Diving into a new technology, language, tool or architecture is always fun. At least for the first day or so of playing around with it.

Fairly soon, you and your fellow pioneers will decide on building this amazing new thing with this even more awesome new technology that will provide the business with so many cool features that you really think a plaque with your name at the entrance of the office is the minimum they can do to thank you.

Continue reading

Testing

Go Headless, be vulnerable

During some routine network security testing recently, it was pointed out to me that my laptop had X running an open network port — anyone could connect to it and control my desktop as if they were me.

Being that I’m fairly conscious of network security, and particularly when you are surrounded by some very technical people with a mischievous sense of humour, this is something that I would never have manually configured.

Continue reading

Testing

Using an “Exploratory Testing” Approach in Net-A-Porter…

What is Exploratory Testing?

Exploratory testing is an approach to testing. Traditionally, testing has always had a “scripted” approach, where tests are planned based on a list of requirements supplied by the business stakeholders, and these scripted tests are written long before any software is even written. Although this might be useful in some circumstances, and scripted tests are still used in some circumstances within Net-A-Porter (in the regression team for example), it can be painful to use a scripted testing approach in other situations (like when testing new functionality in the streams). Continue reading

Testing

IRB, and when automation is easier than testing it manually

I spend a lot of time thinking about test automation.  We all know that, when it’s done right, it can save everyone time, increase test coverage, and eliminate a lot of tedious, repetitive grunt work.  The trouble is, when it’s done wrong, it becomes just as much of a millstone as the manual testing it replaces.  Witness:

  • The massive maintenance burden of keeping automated tests working when the products they are hard-coded to look for suddenly disappear from the site under test because they’re sold out.
  • The pain of debugging a test that’s given you an incomprehensible stack trace instead of a sensible error message.
  • The constant fine-tuning of automated tests to cope with slight changes to the user interface that prevent them from “seeing” the objects they are looking for.

…and so on.  I’m sure you can think of some more examples.  So, to sum up, if you’re going for test automation in a big way, you’ve got to plan carefully.  And you have to employ the same kind of programming best-practices as the developers do.  And, of course, you must be prepared to spend significant time on maintenance.  This is daunting, and, if you’re just dabbling in automation rather than being a full-time Test Automator, you probably aren’t prepared to make that kind of commitment for fear that it won’t deliver enough value to justify the time invested.  Game over.

Continue reading