So this image triggered some discussion on twitter and I think it's worth explaining it a bit more.
With this image, I wanted to highlight two main things
- Shortage of skilled / inspiring testers
- Need to move up and become skilled and inspiring tester.
There is no scientific basis for this image. This image is purely based on what I have observed or experienced. I have met people who would be a perfect fit for the categories I have created. Also, this pyramid has nothing to do with the experience - It's possible to spend entire lifetime as a lazy tester and newbies can be truly inspiring. Also, it's not a progression as such - skilled testers doesn't mean that they'll have to be community builders, domain experts or decent coders. I have used pyramid to show only one thing - size of the pool.
I have seen fewer ...
This is the first time I am publishing my goals for next year public. This will probably put some pressure on me and might give some ideas to you as well.. So here is my list
Things I need to learn to remain a relevant technical tester
- Functional programming languages and NoSQL / Non-relational databases
- Tools available for testing native and hybrid Chrome and iOS apps
- Ops tools such as Kibana, Splunk and deployment tools such as puppet
- Mocking frameworks & tools which give insight on automation coverage.
Things I need to do to contribute meaningfully in the software testing community
- Make London Selenium Meetup Group more effective and organise quarterly meetups
- Active participation in discussions on twitter, blogsphere and software testing club
- Start writing reviews of the books I have read / reading
- Submit articles for StickyMinds, Testing Planet, Testing Circus and TeaTime With Testers
- Share automation code and examples with the ...
Better late than never :-)
I attended Agile Testing Days 2013 and went to India for holidays. I am back in UK now and it’s time to reflect on the conference and share my experience.
Agile Testing Days started with a great note - some of us went for dinner and many people stayed in the bar till morning. I was relaxed because I didn’t sign up for any tutorial for the next day. I decided to take a day off from testing and explored Berlin before joining others for dinner.
Opening keynote of the conference was from Andrea Tomasini. I found it extremely fast paced and packed with.. well a lot of information on what agile is. You can find my notes from the session here . Key takeaway from the session for me were the notion of social, technical and business risk in agile projects and reasons of dysfunction ...
Someone has rightly said - conferences are what you make of them. It is possible to hear completely different accounts of what people experienced at the same conference. It could be great learning experience for some and complete waste of time for others.
Going to a conference is a huge commitment in terms of time, cost and efforts. I am an independent consultant so do not have to give a business case or take permission - but still I do need to justify this investment of time and money to myself.
My main objective to go to the conferences is - to learn more. I learn by attending sessions and I learn by talking to people between the sessions. It’s always nice to share problems, solutions, constraints to understand what works in a given context and why. It’s also nice to challenge (with the intention to learn more or clarify) and ...
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 ...
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 ...
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 ...
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
- Go to TestSpicer.com/docs
- Click on the appropriate GET.
- Specify parameters if required
- Get the data and off you go
This will ensure that you are not using static data, even subconsciously.
Let’s see ...