Yesterday I was thinking about the importance of having a pause button for the tester and wrote a post on the Linked-In. In my opinion, without understanding mission and identifying stakeholder, there is no point in focussing on scope and strategy. I have shared my experience to substantiate this claim where asking WHY made a difference in the project I was working on. Please read Remember Why before What and How on Linked-in and let me know your thoughts.
BTW, if you are on Linked-In - feel free to connect with me.
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 ...
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 ...
So what would be the ROI of reading this blogpost? It’s possible that you get an idea which helps you in your test automation effort or removes myths you may have about software testing or you find that you are in software testing field because of wrong reasons and you leave this field altogether.
There are many possibilities and all of them are difficult to quantify. In my opinion, it is difficult to quantify most of the activities we perform in our field - software testing.
I have never done ROI calculations for any testing activity. My take on most of the activities I perform is simple and based on the MoSCoW model
Things like exploratory testing, robust test automation, Continuous Integration, NFRs etc are more or less MUST for projects I get involved in. We discuss and get agreement on how to to implement / manage them but never ...
Test automation is an interesting activity. When teams start their journey, interesting things happen. Teams become more efficient, test coverage increases, communication between software testers and developers increases, fewer defects are reported by customers and so on, isn’t it? But does it happen every single time?
Let me tell you a story – BTW, all persons portrayed in this story are fictitious and any resemblance to living or dead, manual, automated or political tester is purely coincidental.
A small team of few developers and testers was working on a product at company X. Test team at company X wasn't experienced and lead tester of the team was Jim. Jim was a good tester. He was extremely good at finding defects - unfortunately he never got opportunity to work on the test automation projects. Management at company X had no interest in approach – they wanted results and they never pushed team ...
Last few days were awesome - My presentation at EuroSTAR was well received, builders are out and I had nice Diwail celebration with friends and family. Don’t worry, this post will not cover Diwali celebration or our home improvement project - I will stay on course and cover only EuroSTAR.
It was my first EuroSTAR and I truly enjoyed it. I attended EuroSTAR as a speaker and my presentation topic was - “Test Automation Framework, Don’t design it, let it evolve”. It was in-line with the theme of conference - Innovate and renovate. I will write about my presentation in detail - but for now - let’s focus on the overall conference.
On day 1, I reached early for the conference and spent around an hour in the exhibition hall. One of the vendor (Sorry forgot name :-() in the exhibition hall had few really nice puzzles to solve. I started by looking at ...
Continuous performance Monitoring
Performance testing is an important and integral part of most testing projects. This type of testing corresponds to Q4 of the Agile testing quadrant. You can find interesting insights on the agile testing quadrants in this post by Lisa Crispin.
Usually performance testing teams are different from functional testing teams and their reports / data etc are not easily available to to the entire team. I wanted to have more visibility, integration and feedback about the performance of application - essentially I was looking for Continuous Performance Monitoring.
In this post I will discuss what is continuous performance monitoring and how useful it is to report performance trends for every build.
In my current project, I am using TeamCity as the build server. TeamCity supports custom charts for any data. I thought, It should be possible to have performance data from all the teams in a particular format and ...
This post is a combination of two things - an advise and a request. In case you are wondering, it is not complicated advise and simple request, it's a simple advise and challenging request. If you like challenges of testing web applications, you may like this challenge as well.
So let's talk about the advise first. Find defects to find defects quicker - I am sure most of us already know this, isn't it? But sometime we do need to state and explain obvious. We do it all the time in testing - we state and explain obvious defects isn't it? Well, we need to that because obvious is obviously not obvious for everyone :-)
Software testing is a skilled profession and like all the skilled professions, you get better at it with practice. However, there is a difference between doing day-to-day testing in job for many years and practicing ...