Why I’m passionate about agile development

Agile continues to be a sought after development approach, team after team attempts to go agile and ask any job hunting tester what they’re looking for and more often than not you’ll hear agile being listed. Personally I love agile, done well you’ll end up working in a fast paced environment with a fantastic team but I am concerned how many people just wander into it blindly just because it’s the hip thing to do rather than because they, or their teams, are suited to it,

Agile is a full team approach, the best teams have managed to eliminate silos with everyone doing whatever is needed to get the job done. But that doesn’t mean we’re cowboys, instead you’ll find that just like every other team the people using agile have a wide range of skills and experiences, but unlike traditional approaches they are probably more likely to have diverse skills and will almost certainly be more ready to do what it takes to learn the skills they need to get things done.

In the past I have worked on a number of V-model testing projects and each time I would spend weeks, maybe months, writing detailed test strategies and test plans from hundred-paged requirement specs and each time I would be dying to get into the actual testing. Then the testing phase would begin and after completing the first 2-3 rounds of testing and doing the same mindless testing over and over for weeks at a time I would be dying to get back to test planning. For me agile works well, everything is on a short cycle, test planning is usually a few hours, maybe a day or two max, testing phases always involve exploratory testing and the emphasis on automation eliminates almost all the mindless, repetitive testing.

Unlike traditional approaches I can actually get involved early, agile has a great emphasis on the entire team working together to spec out user stories this is a perfect way to get developers thinking about testing before they even start coding. Add in Test Driven Development and you’ve suddenly got whole development teams caring about how testable a feature is.

Obviously like all software development projects things can go wrong, time pressures remain and there will always be times when things just do not go to plan. But if you enjoy arriving at work and not knowing quite how your day will look, being involved in projects right from the start and are good at dreaming up new and creative solutions to problems then agile might be the place for you.

So you’re a tester, but what’s your testing goal?

Everyone involved in software development spends some time testing software, maybe you’re a dedicated tester spending all day testing a product, maybe you’re a developer checking that the new thing you’ve built is working, or maybe you’re a product person making sure the feature does what you asked for it to do. Whatever your job title, at some time you’ll be evaluating the product and checking for bugs but what are you actually trying to achieve?

Your goal will drive the way that you approach software testing, a developer tends to look at something to see if it’s done, unsurprisingly they tend to be pretty bad at finding bugs. On the other side testers tend to focus on bugs, they’ll often have broken the software in 10 different ways before they even know if it can do what it’s supposed to do.

But what is the team’s goal? Are you aiming for a high quality product or are you aiming for a fast release time? Everyone developing and testing a product should be in agreement as to what this goal is and be using it to schedule and plan testing and maybe even more importantly to use it to prioritise bug fixing. If you really want to ship this feature today then you had better be prepared for some unexpected bugs to be around.

Testers are often forgotten in the early stages of the project but don’t be put you off, every time you write a test plan or add a test to your automated test suite make sure you know the team goal for this product and then use it. Learn to be honest with yourself, if you’re secretly trying to prove your value as a tester then you’ll probably be tempted to raise bugs about things that no-one cares about. You don’t need to tell anyone but admitting your real goal to yourself might be enough to switch to your team goal hat and assess your bugs before you hit that submit button.

Edward Bono has some great ideas about different modes of thinking in his book ‘Six Thinking Hats‘. I find it useful to ‘wear’ different hats at different stages of the project, it forces me not to get bogged down in nit-picking before the requirements are even agreed and reminds me of the end-to-end focus towards the end. So try switching to your team goal thinking hat next time you test something, you might find the new perspective uncovers some interesting bugs.

Testing an API

So you’re a tester right? So you can test this API for me? What? What on earth is n API?

Sounds familiar? Then read on for your quick start guide to testing an API.

An API is an Application Programming Interface used by developers to power apps, websites, widgets and other cool things. An API basically allows you to make requests for data and in return a website provides a response, usually in JSON format but XML is also common.

Before you get started the first and probably most important thing to know is that an API does NOT have a presentation layer, it will not look pretty, it will not have cute colours, and depending on which browser you are using it might look downright scary (thanks IE!). Never ever raise a bug about an API looking unstyled, well not unless you want to get laughed all the way into next week.

So how are you going to test this thing? Well the great thing about an API is it is intended to be used by someone who isn’t familiar with the internal workings of your website so they should have documentation and it should be easy to understand. Basically you use a URL and the available parameters to make up a request which you fire off in your browser address bar.

Your request will look something like the following. Be aware that API requests make of use of parameters in the URL, the first one will use a ? and all subsequent ones will use an &:

API request with one parameter:

http://api.songkick.com/api/3.0/users/{username}/events.json?apikey={your_api_key}

API request with multiple parameters:

http://api.songkick.com/api/3.0/users/{username}/calendar.json?reason=
attendance&apikey={your_api_key}

 

In return your browser will display something like:

{ "resultsPage": {
    "status": "ok",
    "page": 1,
    "totalEntries": 2,
    "perPage": 50,
    "results": {
        "event": [EVENT, EVENT]
    }
} }

So if you’re not testing how it looks then what are you testing? Probably the first thing to focus on is that the data being returned is actually correct, check that all the fields are filled in correctly and check that the data is accurate (you will probably be able to check this against the corresponding website). Domain knowledge will be key to finding bugs at this stage.

Next you’ll want to check that all the required requests are available, you should have some API documents to help you with this.  Read through them, check the examples work and then make sure everything they say can be done actually can be done.

Now we’re at the destructive stage. An API basically gives someone access to data from a website, therefore they are almost always restricted by an API key which allows the API owner to have control over who accesses the data and how frequently. Test that you can’t access anything without a valid key, make sure only the requests documented are actually available and if there is any way to post data back to the API make sure you give it a very thorough bashing.

Finally you should check for error handling. Just as a website has the ability to return a 404 page or maybe a 500 error when something goes wrong an API should be returning the correct error code for unavailable servers, invalid requests, empty data sets etc.

I’m a tester, why should I care about unit tests?

It always seems a missed opportunity when testers choose to ignore unit tests, yes they are usually hidden from sight (buried away with the code) and created and owned by developers, but the depth of information they can provide about the code and the developers themselves makes it well worth the effort of finding and deciphering them. Good unit test coverage will give you confidence in the product, you should be finding fewer problems with the basic workings of the system and can instead focus your time and skills on testing the complex business logic and integration of the software.

Unit tests are small tests written in code to check the basic functionality of a single block of code. They are not small tests (a selenium tests that checks a single field is absolutely not a unit test because it goes through all the layers of the system and is therefore an integration test). Developers tend to rely on them for fast feedback during coding but if you have unit tests running in your build process then finding out what gets tested by the build will give you a great start on sanity testing the product.

Unit tests alone won’t give you a quality system, just because a unit test passes doesn’t mean the user is going to see the right information. Always consider the layers of the system you are testing, even the simplest website is going to have some code and a frontend but it pretty common to find databases, web servers, load balancers amongst other things, you want to make sure each is working individually but you also want to make sure they work together. Maybe most importantly you want to make sure they don’t just work but are correct according to the business requirements. Just like any code product you’ll need to re-assure yourself that the tests are correct but after a few cycles of testing and building you should be in a position to trust the tests and start testing the real risks. Of course It is possible to test all of this with manual testing but you’ll find a lot of bugs so expect a fairly long bug-fix and retest period.

Unit tests will never be written by testers, and sometimes you’ll need some help to find and use them but testers shouldn’t ignore such a rich source of information about the system. Don’t duplicate testing, be smart and focus your efforts on things which are complex, risky or difficult to test with automation. If you have buggy builds, long build times or find developers showing a reluctance to re-visit old code then start voicing your support for unit tests, it’ll benefit quality for the users and the whole development team should benefit from faster build and release cycles.

100 hours of testing practice – getting started

At the end of last year I was inspired by this post on STC to spend 100 hours practising testing. Since the new year Mark Crowther has made an impressive start on his practising and I have umm well err mostly just been trying to survive the new year.

So, last week after a few nudges from Mark, I started my Codeacademy course, I’ll admit that learning Javascript was never exactly high on my list of things to learn but I can’t deny that I really need to improve my coding skills and the course itself is incredible. So far things are going well (I spent about 2 hours on it last week) so I hope to keep up the practice and start actually creating a test data generator to put the knowledge to the test.

The focus of this year is not going to be learning Javascript, it is going to be about learning automation, currently that is actually learning Selenium but I think this goal will adjust as the year progresses. To be truly successful with this goal, I’m going to need to understand Git, Jenkins and other things about creating and managing code, right now that looks decidedly impenetrable but that is really the point. Hopefully by focusing just a few hours each week I’ll slowly ship away at the opaque surface. I’ll try to keep you updated with my progress as I go.

So what are you planning to learn this year?

Help, there are too many web browsers to test

Over the past 4 or 5 years the web has become hugely advanced, and more and more users are accessing the web on mobile devices, all of this has led to new, more complex, web browsers and seemingly endless browser and operating system (OS) combinations. If you test a website or mobile site then you’ll need to consider where to focus your test effort, unless you have a very large budget (or a very simple site) then it is simply impossible to cover every combination in-depth so what should you do?

There are two things to consider when approaching browser/OS testing – the first is usage, what are your users using? Ideally you’ll have access to some user stats (analytics) to tell you which browsers and OSs your users are using. If not, then you’ll need to do some research, at the time of writing Internet Explorer (IE) 8 is the most widely used browser with IE9 in hot pursuit, but Safari (particular on mobile devices) and Chrome are both popular. Make sure you consider who your audience is, teenagers will be using different systems to tech savvy pensioners, which means that depending on your audience you either care deeply about Opera or you don’t care a cent, maybe most of your users are on Macs or maybe they’re on Windows,. Don’t forget to consider mobile devices, games consoles and TVs in your research and keep an eye on browser upgrade dates and OS launch dates to help you predict which combinations are relevant to you.

The second thing to consider is risk, based on your experience which browser/OS combinations will cause the most issues? This is very much an experience based metric, consider where you have previously found bugs and see if the risk applies here. If you’re new to the project then look through the bug tracking system to see what bugs have been previously fixed and consider if they could occur again, or maybe the architecture is similar to a previous project giving you an idea of how much you need to worry about cookies, cache and security settings. Some knowledge of how the website and app has been built will give you a huge help here so if you’re not sure then it could be time to have a chat with a developer.

So once you have your data you can start to put together a prioritised list of the browser and OS combinations that need testing. It is a very good idea to run through all your high priority test cases on all browser and OS combinations if possible, then you can run your medium and low priority tests on a reduced list of combinations, that way, if you run out of time you’ll at least have tested the site for the largest segment of your audience and for the riskiest combination of browsers.

A key web testing rule is to remember that Javascript and Ajax will be handled by the web browser, which makes them likely to functionally differ between browsers but anything handled by the web server should behave in the same way on all browsers although you still need to test for styling issues. So if the new feature is a server calculated pricing component you only need to fully test the calculating logic once but you’ll need to test the price input and output fields on each browser/OS combination that is important to you.

 

So, in summary you should not expect to test every browser and operating system combination but with a little effort you can work out which ones are important or high risk for your project and then focus the majority of your test effort there.

Tester required

Recruiting to fill a tester position is a difficult and time-consuming activity, each time I have posted a job ad I have mentally prepared myself for a flood of applications and a long and grueling hunt to find the perfect person. At the same time I hear endless reports on how hard it is to find a job, how many applications such and such has made, often without a single interview. So here are my thoughts on where the process is going wrong – each job is different but I believe most, if not all are relevant to any job application.

The cover letter; this is the first thing the recruiter will read, it is never ever optional. No matter how you have applied for the job, through a recruitment agent, online or via post you must always write a cover letter. In its simplest form this letter is a couple of paragraphs introducing yourself and explaining why you feel you are suitable for the job. The most important thing is to make this unique to the job you are applying for, generic cover letters will not cut it. You need to show you have read the job ad, plus any other company information that is available and you need to spell out exactly why you feel you will be perfect for this role.

The CV; Always keep this to a maximum of 2 pages, with a font size of at least point 10 (well you want them to be able to read it don’t you?). Keep in mind that the goal of your CV is to get an interview, keep it focused and avoid the long job history if it doesn’t add anything to this role. You don’t need to go into details about every job you have ever had, the last 2-3 will be more than enough if they’re relevant. Ideally you should be using your job history, education and experience to back up everything you said in your cover letter – if the job is looking for agile experience then write about the agile experience you have and how you came about it. Likewise if the job requires someone who is passionate about testing them make sure your CV screams passion!

Tailoring your application; If you’ve read the job ad and done a bit of research into the company then you should have a reasonable idea about the company culture, use this to your advantage. If you’re applying for a job at a bank then keep your language formal, if it’s a media company then you can afford to be a bit more informal. Either way, keep the language on your cover letter and CV consistent, nothing highlights document re-use more than the language suddenly changing style half-way through. Even though you might be applying to dozens or more companies you really want your application to look like it was specifically aimed at this company, show them how much you would like to join the company.

Finally, if you’re applying for a testing job then do whatever it takes to avoid any errors in your application (yes, get your mum to read it if you need to).

Good luck!

Embrace reviews

During my testing career I have attended a number of training courses and sat through more than my fair share of interviews; it is impressive how many times I have been struck that somehow ‘Waterfall’ has become a dirty word. Attend an ISTQB training course and tell the class you follow a ‘Waterfall’ approach and you’ll be surrounded by faces of sympathy. Worse, tell someone you work with that your team is following a waterfall approach and they’ll hit back with the classic ‘this is V-Model not Waterfall’ response. I have worked on many so-called ‘V-Model’ projects and each time we seem to drop all the evaluate and re-work stages that make V-Model so much more reliable than Waterfall.

So why, if we are really following a Waterfall approach can’t we say so? Maybe deep down we all know that our first attempt at doing something is never going to be the best way. Many projects are successful but I think if we were really honest then everybody would be able to identify something, or a certain time when things started to go wrong. Panic, long hours and compromise are all accepted parts of software projects but maybe it shouldn’t be that way. An essential part of an Agile approach is regular retrospectives, focusing as a team on what went badly and even more importantly, what went right will give you far more benefit than daily stand-ups and writing on story cards. Iteratively developing software whilst continually reviewing and improving is what makes agile such a powerful approach.

Time pressures, laziness and a million other things can get in the way of reflection and performing retrospective actions but take the time to schedule in half an hour a week to review your own work, attitude or approach and you will quickly identify positive patterns which can easily be repeated. You don’t need to change the whole project to change yourself so start small and reap the benefits of review.

The Start

So this is the start, not of my life in software testing, but of blogging about my thoughts and experiences. I intend to use this blog to lay out some of my ideas, lessons learnt and hopefully a few problems solved but these are just my thoughts so please do leave a comment to tell me why you disagree!

I, and you, owe thanks to Pradeep for making me get this blog started, his excellent post about why all testers should blog got me thinking, and having spent a few years consulting, a bit of time building and leading test teams and most importantly, 6 years of actually testing software I hope to have found a few best practices (for me at least).

Right now I’m loving Agile, the shared sense of ownership, the emphasis on communication and the fast pace make projects a fun place to be but of course there are challenges too. I’m looking forward to seeing where the future of testing lies and hopefully you’ll join me on the journey.

Take a look at my About page to find out more about me or visit some of the other testing blogs out there, they’re well worth a visit. Let me know if you have, or read, other blogs that should be on my list.