Testing for SEO
If you ever find yourself testing a publicly available website then you should be considering Search Engine Optimisation (SEO). Basically this means ‘How easily can the website be found and indexed by search engines such as Google?’. Many users, maybe the majority of users, will go to somewhere like Google and search for a website name rather than entering the URL in the address bar. How far down the search results you appear can have a dramatic impact on the amount of traffic your website receives.
Websites with good SEO will usually have a clear site hierarchy and contain text links which provide access to all pages. Websites are indexed by bots which spider the site. Pages with no links leading to them are unlikely to be indexed simply because the bot cannot discover them. Bots do not behave like a real user so you should take care to actively consider SEO during testing.
Site structure is important for SEO, although possibly not something you can influence by testing. Do check that your site has a Robots.txt file to help Bots understand the site structure.
Search engines reward visitor satisfaction (likely a combination of visit duration and return visits), and site performance so make sure you thoroughly test the website in all supported web browsers and monitor page load times at the very least. If you have the opportunity to carry out more detailed performance monitoring or testing then take it.
When testing a website for SEO consider using the Lynx browser, a text only browser, to see the site as a bot would. If you can’t access any of the content when viewed text-only then neither will the indexing bot. All non-text content such as Flash videos or images which portray information, should have a descriptive html tag to provide the same information in a text form. Descriptive ALT tags will help your site’s accessibility as well as your SEO.
The search result link that you see in a search engine is the page title so it makes sense that page titles should be descriptive and unique. Either check the <TITLE> html tag or simply raise your eyes and read the top of your browser for every page you view. Search engines take the first terms to be the most important so it is usual to display relevant page keywords before the site name. Make sure the keywords are relevant to the page you are viewing.
Use scripts or test tools to make sure your website doesn’t contain any broken links and to check for invalid HTML.
Webpages requiring session ids or other arguments in their path are unlikely to be accessible to the bot. Depending on how your website works this may or may not be a good thing. For example I’m fairly sure you wouldn’t want users dropping in part way through a checkout flow simply because they clicked a link on Google.
A quick post-release check in Google to see exactly what has been indexed and how highly is also worth carrying out. Remember that the results you see will often be personalised to you so a website you view frequently should rank higher when you search for it.

Finally, although you want search engines to index the site, they can cause you issues with load. Use a tool such as Firebug for Firefox or the Chrome browser developer tools to check for the If-Modified-Since HTTP header, it probably won’t help in every case but in general this should allow your web servers to tell Google whether content has changed since the page was last crawled.

Benefits Me vs. Benefits the Project
New Year resolutions are usually a time to drop some bad habits, pick up some good habits, and generally try to make yourself a better human being. As well as personal goals for the year I like to set myself a quarterly work-related goal. Usually the goal focuses on solving a particular problem and consists of mini goals to keep me motivated. Previous goals have led to us adopting Continuous Delivery, tackling load testing, and introducing a bug tracking system. When I started to think about a suitable goal for the start of 2014 I realised that achieving the potential goals would have differing levels of value for me and for my current project(s). 
 
On my current project we use checklists and sometimes even test plans to give the product managers confidence that the developers have checked the important aspects of the feature. Yes, the developers are testing, ask me about it if you want to know more. I come along later and carry out some testing to make sure we’re not losing the plot. I have a personal goal to get rid of the test plans and to hugely simplify the checklists because I want to spend more of my time doing things that I enjoy and that I feel are of greater value. Things like exploratory testing for example. 
 
It would be easy to set this as my Q1 goal for 2014. I’m motivated to make some changes and I have plenty of ideas about how we could go about making these changes. But I realised that this is my goal not my project’s. The product managers and developers like the current process; they find it reassuring to have a finite list of things to check. Although I think we would be in a better place if we change this I have come to realise that you should always fix the problem that people feel is currently the biggest problem. With this in mind it looks like solving the flaky Facebook tests and finding a way to monitor CSS quality will be of far greater value to the project as a whole. 
 
Do you set quarterly goals? If so how do you decide on them?

Asking “Why?”
I once worked on a large project that required us to hire lots of new people. New people are fantastic. As well as having more hands to help with the work you get a fresh pair of eyes and a new set of experiences and opinions. I loved the moment when a new person would ask ‘Why?’ after hearing how some part of the process worked. “What do you mean ‘Why’?” I would ask. “Why do you do it that way?” Many a process was refined or completely changed as a result of those early conversations.
Asking ‘Why’ is nothing new. Children are famous for their never-ending ‘Why’ questions. Rather than just trying to annoy you recent studies indicate that they are actively learning when they do it .
The ‘5-Why’s’ analysis method is a popular method for understanding why problems happen. If you manage to avoid the endless loop and dig down deeper to the actual cause of the problem then you have a powerful method for identifying improvements.
As useful as the 5-Whys method is I still feel something is missing. A 5-Why’s analysis session is common when trying to understand and resolve an issue. But why are we waiting for the problems to happen before we start asking ‘Why’? New people joining projects and children learning are missing the familiarity that makes the rest of us complacent. As you follow your process, log a bug, or join a meeting about a new feature ask yourself ‘Why?’
Millions saw the apple fall, but Newton was the one who asked why. – Bernard Baruch

Choosing Continuous Delivery
Continuous Delivery (CD) is looking like it’s the new Agile. Teams hear about the wonderful things that happen with you implement CD and rush to get on-board. In reality CD is the same as any process, there are pros and cons to adopting the approach. Not every team could. or even should want to change their culture and process to allow CD to work. However if you have a team, including business people, who are willing to take the steps required then CD can have a huge impact on team morale.
 
Process change is hard. You are asking a group of people to change the way they do things. Not all of these people will agree that you’re moving to a better approach and so at least some resistance is normal. CD requires everyone on the team to trust each other. You need to work together to agree on a process that allows you to move fast and deploy code to production far more frequently that you are used to. You need to understand and agree on risk levels and technical changes. How will you test the builds and who gets to make the decision as to what gets deployed? Most important of all you need to agree on what will happen when things go wrong.
 
Despite the obvious difficulties of making these changes I still believe CD is a positive process change to make. Full team conversations around acceptable risk are always going to be a useful thing. Actually sitting down and defining a process which can then be completely managed by a tool such as Jenkins will make life easier for everyone. Most significant of all are the benefits of creating a culture where developers are trusted to release code as and when they need to.
 
If you would like to hear more about how Songkick moved to CD then join me for the EuroSTAR Webinar Wednesday 11th December 2pm GMT

Next time will be better
Sometimes you don’t manage to do your best testing. Even as you frantically try to test more, to test better, you know that on this occasion you’re not going to walk away feeling like you did a great job. 
 
This was me last week. We were facing down an exciting deadline. Time was short. I had started on the back foot by missing the earliest project conversations. From then on I felt that I was chasing but never quite catching the conversations and decisions. It didn’t help that things were changing, nothing major but just a constant state of flux around the copy, the design, and some confusion over what was going to be changed before the launch and what could wait until afterwards. 
 
The tight timescales meant we couldn’t follow our usual processes, developers were focused on writing code but we couldn’t test as we went. Code was ‘deployed to production but the launch would be a ‘flip of a switch’ at an agreed time. End to end testing gained an unfamiliar significance and obviously exposed a raft of bugs. 
 
Tight deadlines often end up with a tester co-ordinating testing meaning valuable testing time is wasted telling non-testers how to raise bugs or showing them which area of the system to test. 
 
Was the project a success? Yes. We hit the deadline. There were no unexpected reports from users. Everyone was happy. But I knew I could, and should, have done more. Getting bogged down by a project prevents you from thinking clearly. When you don’t think clearly you miss silly, obvious bugs. 
 
So what can I do? I’m going to go away and come up with a plan. A plan to guide me through these short, frantic projects. A blueprint to co-ordinate end-to-end testing with non-testers. A checklist to remind me of the silly bugs that mobile browsers can introduce, or the need to check plain copy emails. Most important of all I’m going to come up with a plan for gathering project information and finding a way to think even when imd is tight. 
 
Next time will be better. 

Step away from the book

Do you ever feel like you’re overwhelmed by all the things that you need to learn? Everyday you hear of a great new technique or receive a new book recommendation. What do you mean you haven’t read “Thinking Fast, Thinking Slow”? Next you’ll be saying you haven’t read Milton, or Proust.

Years ago most people were taught by rote. The system appeared to work well, certainly at least some people did come away with a broad bed of knowledge. More recently it seems that a shift has taken place. Some, but probably not enough, kids are learning for themselves. This approach isn’t entirely new, in 1907 the first Montessori school opened, allowing children to learn through play. More recently unschooling has gained popularity, allowing kids to have the space to think for themselves and guide their own learning. These kids are likely to be far better equipped for the world around them because they are curious and used to working out what the answer is, and why.

Now consider your own education. Why do you read all those books? Are you genuinely interested in what they have to say? Do they provide a particular answer that you have been seeking? Or are you reading them simply because you feel you should? If it’s the latter then step away from the book. Learn because you are genuinely curious and you will remember the lesson for far longer than if you plug away at a book just to be able to say you’ve read it.

James Bach does a great job of explaining how he learns in his book “The Secrets of a Buccaneer Scholar“. Actively seeking connections between your knowledge can be an effective way to build understanding, and seems to be a method that ties in with this article which explores the physical side of how we learn. Successful learners are people who find a passion and then chase it. Don’t allow yourself to be overwhelmed, or constrained by what other people are saying and doing.

Ask your own questions and seek your own answers.

Why Every Tester Should Have a Blog

Testing is a journey. Each testing session forces you to ask new questions, review assumptions and hopefully learn something along the way. Like all journeys there will be problems, missed bugs or unexpected delays that force you to adapt your approach.

Sometimes it’s the difficult times that actually teach you how to become a better person. I am far more likely to recall the time I failed in the diplomacy stakes or remember every little detail about the critical bug that somehow made it to production. Digging in to the reason for these failures and finding something positive to take away can make mistakes a worthwhile pastime. Recording these lessons will help you apply them next time.

So much of testing relies on the tester having strong communication skills. Being able to write clearly and concisely is half the challenge when reporting bugs or reporting on testing. Writing a personal blog is the perfect place to practice your writing, as a useful aside it also helps you explore your own ideas about testing and record all those great, and not so great ideas that you have.

Many potential bloggers are deterred by the amount of time that they think a blog will require. Obviously the most successful blogs are updated frequently and I certainly find it easier to complete a post if I maintain a reasonably regular writing schedule. However it is your personal blog, no one will die if you don’t post for 6 months. Write when you have time and write when you have something to explore and enjoy the journey.

Do you have blog? If not, why not?

Book Recommendations

On Friday I asked the Twitterverse to recommend books about process change. I was hoping to find 2-3 good titles which I could give away during my Agile Cambridge Tutorial. As always the great mix of people on Twitter didn’t disappoint. Here is the full list of recommendations:

Fish, and Fish! Sticks were recommended by Erik Brickarp

Understanding Organisations was recommended by Graham Bleach

Quality Software Management: Vol 4: Anticipating Change was recommended by Michael Bolton

Peopleware: Productive Projects and Teams was recommended by Helena Jeret-Mäe

Bob Marshall linked to his fascinating blog post on Homogeneous Mindsets.

Have you read any of the recommended books? Would you recommend any others?

It’s All in the Mindset

I recently started reading ‘Proust was a Neuroscientist’ by Jonah Lehrer, so far it has been an extremely interesting and thought provoking book, I’ll probably write a proper review once I finish it but in the meantime I wanted to explore one particular thought.

In the chapter where he writes about how Auguste Escoffier invented veal stock they come across an interesting phenomena. Your mindset determines what you taste. Serve identical wines in a cheap bottle and in an expensive bottle and nearly all tasters will think that the wine in the expensive bottle tastes better. The tasters are not lying. The brain expects the wine to taste better and so when the tastes are interpreted by the subjective brain they are judged to be better.

I started thinking about how mindset affects testing. We all know that developers tend not to make good testers because they expect the system to work. They either subconsciously don’t stress the system or in some cases become blind to the errors.  It seems that testers can be caught out in the same way. Everything from past experiences to your current happiness will affect what you see and how you judge something.

It’s normal to expect that experienced testers who have a wealth of previous bug discoveries will carry out the best testing. In fact I often find that totally new testers, with their entirely fresh mindset, can uncover some incredible bugs.

Perhaps the only way to deal with this is to embrace it. Structure your testing sessions so that you deliberately set your mindset. In the first session go in expecting everything to work. Embrace your user and confirm the main user actions can be performed. Later adopt a negative mindset and expect everything to be broken. Try to see things from the point of view of a blind person, or a colour blind person. How about if you’re in a rush and need to complete a task quickly? Each time you set your mindset to something different your brain will start seeing, and interrupting things differently.

Choosing to be a Tester

Stephen Blower recently published this excellent post about proving your worth as a tester; If you haven’t read it then you should. As well as being struck by the excellent points he was making I was surprised to find that I am more unique that I realised – I actually did choose to go in to Software testing.

I was lucky and discovered that I enjoyed programming during my A-Levels. I went off to university to study Software Engineering. We did lots of programming but testing was never mentioned. Luckily I’m not such a great programmer so without realising it I was doing lots of debugging just to get my assignments to work.

One of the best aspects of my degree was that it was a Sandwich Course that required me to spend a year working in the IT industry. The European job market has a much better grasp of under-grads spending time in industry so I ended up  working in Germany. Unfortunately it was within an IT department that outsourced all their development work, they really didn’t really know what to do with a budding developer so I got dumped with the test contractor. Amazing! I had no idea that you could be paid for nit-picking someone else’s software.

After several months of testing I returned to university and used my final year to find out as much as I could about testing. As well as reading books and convincing Mercury to give me free access to their tools (Thanks, Mercury!) I decided to carry out a questionnaire on testing (ok so there were extra marks if you did this but still). By another very lucky chance one of the people I emailed about this survey ran a Testing Consultancy. As well as answering my survey he offered me the chance to do some work experience once I had completed my degree. When I contacted him 6 months later to take up this offer he lined me up for an interview and then offered me a permanent job as a graduate test consultant. I have never looked back.

As well as proving to Stephen that some people actually do choose to become testers (albeit with a lot of fortuitous circumstances) I thought it would be useful to highlight just how important that offer for some work experience turned out to be. If I had been rubbish the company could have easily fobbed me off with a week or two of safe project work. As it was they took a risk and launched my career.

The greatest challenge is identifying people who desperately want to break into testing. Hopefully Twitter and blogs make it easier for the interested tester to actually find out and follow testing but if you spot one then do whatever you can to help them. If you know of universities that teach aspects of testing contact them, maybe you could give a talk on testing or spread the word about tester meet up in the area.

Lets spread the word and open a few doors to the testing industry.