Do software testers need to code?

I am sure you have seen this debate many times online. You may also have strong views on whether testers should be able to code or not.

Well, In my opinion - testers should be able to write code.

I have just published my views on this here .

Please have a look - would be nice to hear your views on this.

Let’s Test party is over - see you next year?

Let’s Test party is over. I am back in London and still trying to absorb everything. I will need to write few blog posts to cover my experience @ Lets Test - this is just start :-)

Let’s Test was on top of my must-attend list from past two years and I am glad I could attend this year. In my opinion, one of the biggest advantage of attending a conferences is being able to confer and Let’s Test provides perfect environment for that.

I reached Stockholm on Sunday and thanks to the power of twitter - I met Richard , Christopher , Geir and Amy at the airport. See the usefulness of this medium? If you are still not on the twitter, come and join us :-)

After checking-in, I headed straight to the lobby and got few tips about the area and nature walk from Carsten . In the next half an hour ...

Automated testing of emails

Testing emails is a challenging task and automated testing of emails is even more challenging. A while back I wrote about one of the way to automate email testing using GMail and IMAP. This solution works, but has a huge dependency on the network and Gmail. If there is any problem in the network or if GMail is down because of any reason - test would fail.

Also, this end-to-end flow is important to test, but as far as functional testing of application is concern - it is not application's responsibility to deliver emails to the client. Application will send emails to the SMTP server and it’s the responsibility of SMTP server to ensure that emails are delivered. As long as application can send appropriate emails / messages to the SMTP server, it’s fine and that’s all we need to test.

If application is configured to use real SMTP ...

Best of TestingGeek - Blog posts I like about software testing

For quite some time I was thinking of improving blogs / articles I have written on TestingGeek in past. Many articles I have written in past do not reflect my current thinking. However I decided to leave that exercise. May be it's better to show that my thinking ( and writing) has changed. I might re-write some of the articles and link them from the old articles to ensure that folks landing on my old pages have opportunity to see what I am thinking now.

However, this thought process was useful because I ended up thinking about the opposite - which blog posts do I like?

So here is the list of blog posts (In no particular order) I like on TestingGeek. You may have read some of them earlier, if not it would be nice to know your thoughts on them.

Testers journey from Manual to Political

This post was story ...

Testing Restful Webservices or API Testing - Remember PAPAS BE SFO, DEED HELP GC and DVLA PC

I have been working on API testing for sometime now. To be specific, I have been testing RESTful web services. I like the idea of REST and from what I have seen, many projects will move in this direction. In few projects I have been working on, RESTful web services are becoming backbone for mobile apps and web clients. If RESTful web services is a new concept for you, you can either dive deep down in the original thesis by Roy Fielding or get a quick overview here.

I like testing applications with RESTful interfaces as their backbone. Often these applications are more testable than tightly integrated applications because interfaces (web services or APIs) used by clients (Web, mobile apps, support or public) are available to testers as well.

In this post, I will explain the model / checklist I follow to test RESTful Web Services.

I usually test APIs for ...

How to start using random data in manual and automated testing using TestSpicer?

Many people asked me to explain how TestSpicer works. This post will explain how TestSpicer can be used for manual or automated testing.

Let me start with manual testing.

TestSpicer for manual testing could be extremely useful for doing experiments with data. For example, if you are testing username and run out of ideas, you can quickly use TestSpicer to generate a random username. On the same lines, If you need currency, few paragraphs of text or need a big unicode string - you can get all of them @ TestSpicer. It is free and you do not need to sign up or create an account for generating random data manually. You can follow these steps

  1. Go to TestSpicer.com/docs
  2. Click on the appropriate GET.
  3. Specify parameters if required
  4. Get the data and off you go

This will ensure that you are not using static data, even subconsciously.

Let’s see ...

TestSpicer is live now - Embrace randomness for improved effectiveness

Some of you might know that I have been working on my pet project TestSpicer for some time. TestSpicer has a long way to go, however I am happy to announce that it is live now.

So what is TestSpicer?

TestSpicer is a collection of RESTful web services which can be used to make test automation more efficient and effective.

Please have a look at this (around 4 minute long) video to understand TestSpicer.

TestSpicer is in beta and is free to use. It would be great if you can sign up, give it a spin and let me know what you think about it.

With TestSpicer , I hope to make randomisation mainstream - as it will take the pain out of data generation, logging, reporting and will provide invaluable insight on the data used by test automation. Right now I have focussed on data generation, but reporting, logging and visualisation ...

How to make test automation more effective?

How can I make test automation more effective? This simple question can lead to many interesting things.

According to dictionary, effective can be defined as - capable of accomplishing a purpose or capable of producing intended or expected results.

In order to understand effectiveness in the context of test automation, we need to answer following questions -

  • What do we want to accomplish with test automation?
  • What do we expect test automation to produce?

For me, automation should yield following two things -

  • It should give confidence
  • It should find defects

We strive to get confidence and we hope to find defects with test automation. However, most of the time test automation becomes repetition - execution with the same data and steps. There is immense value in this repetition - but should we stop there? What can we do to make test automation more effective?

In my opinion, testing is a sampling exercise. If we ...