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.
It was good to meet all the regulars (you know who you are :-)) and many new people. It’s always nice to hear experiences of fellow testers. Incidentally, John from Sauce Labs was also there. Sauce Labs is a special company for our community because of Jason and so it was nice to hear from John how Sauce Labs is progressing.
We invited Costin to share his experience. It was great to get insight on the challenges of testing analytics in mobile world. Unfortunately this talk was not recorded - I will check with him and see if his slide-deck is available somewhere.
One of the main reason for me to go to meet-ups is to learn something new and Costin’s talk gave me plenty of things to learn ...
Selenium Webdriver has become one of the most important tool for testers around the world. Demand for Selenium WebDriver has been increasing over the years and will continue for the foreseeable future. Demand for the Selenium is evident from the increasing number of jobs which require knowledge of Selenium WebDriver (Graph generated from Indeed)
Selenium is an open source project, it has progressed so far because of the monumental efforts of Selenium community. Many people are actively involved in Selenium community and there are many ways to get involved. If you have right skills, you can contribute code, write documentation, help with bugs and so on.
It is also possible to support Selenium community indirectly - by sharing your knowledge, by making it easier for people to use Selenium, by participating in local selenium meet-ups ...
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 ...
One of the project I am currently working on had a formal end-to-end testing phase. There are many interrelated systems and end-to-end testing is a good exercise to ensure that system works as expected.
However, it’s important to remember that executing more tests, specially during end-to-end testing phase could be counter productive. In general, I prefer less because constraints make me focus on right and important things.
So for end-to-end testing, let’s assume that product in question is a web-based e-commerce product such as Amazon. A typical end-to-end test for such a product could be on the lines of
- User purchase an item
- An order is generated
- User gets order confirmation
- Inventory is adjusted
- Dispatch system gets order information
- Dispatch is scheduled
- Order status is updated
- User gets notification about dispatch
- Item is dispatched ...
On Friday, I went to Brighton for the TestBash. If you have never been to TestBash before, make it a point to attend this conference next year. It's a great event.
This event was in Brighton and I was banking on my train ride from Clapham Junction to Brighton to prepare 99 seconds talk. Not sure whether it was the rhythm of train or my excessive exposure to children's rhymes (I have a three year old boy :-)) - I converted my software testing experience in a rhyme. Hope you find it amusing :-)
From the corner in an office, where I was sitting alone
I looked at the defects and thought, how do they born!
I started writing code, To find those tricky defects
That made devs confused, testers were scared.
It took us some time, to realise we are a team
Testing is the goal, automation is ...
I recently published this article on linked-in and thought it will be a good idea to re-publish it here as well - hope you like it.
Software testing is challenging and working as a tester in agile team can often be very challenging. I have been working with agile teams for a while now. In my experience, irrespective of the maturity and size of the team, as a tester, I have always faced following challenges
1. Sprint becomes mini waterfall
In many teams, sprint often becomes mini waterfall. It does not matter whether sprint is a one week, two week or three week sprint - sprint can always become mini waterfall. In my early days as agile tester, I used to wait for the stories to come my way and somehow all the stories would become available towards the end of the sprint. I struggled with it and tried to solve it ...
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 ...