Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Friday, September 13, 2013

A Look at the Relationship Between Testers and Developers

I believe that one of the important things in the work life of a tester is to have a good working relationship with developers. This will not only make a tester's job and bug advocacy process easier but will also give him the ability to exert influence on quality, promote positive collaboration and learning opportunities.

Roy Osherove interviewed James Bach on “The Role of the Tester” where Bach talks about this. He says that:

‘…developers are the people who create quality; they make the quality happen. Without the developers, nothing would be there; you’d have zero quality.’

After all without developers on the project us – testers – will not have a job!

In the last few years I have worked thoroughly integrated into Agile development teams as a lone tester. I tend to gravitate more towards developers as opposed to testers as I feel that it helps me expand my domain knowledge and technical skills and…be a better tester. Plus programmers are WYSIWYG. I prefer it when people do not beat around the bush when working together.

http://qa-india.blogspot.com/2010/12/testers-vs-developers.html

On occasion I hear and read stories about the challenges and conflicts both sides have experienced in the workplace, as well as tips and recommendations on how to handle difficult situations and work on improvements from the tester’s viewpoint.

I thought it would be interesting to find out from developers what they thought about testers and their skills. I conducted a very unscientific survey of some developers that I have worked with and whom I also consider professional mentors and good friends.

The replies were pretty refreshing. I hope testers find them useful and take them into consideration in how they go about their work.

Here are the results:

Tuesday, October 12, 2010

Selenium RC Experience

So I have decided to give Selenium RC a shot and try to automate some of our web app GUI tests. I worked with WinRunner in the past on a waterfall government project and was familiar with ‘record and playback’ features and editing TSL scripts. On that project we abandoned automated tools as scripts updating became too time-consuming and labor-intensive due to the fact that our test environment was never stable enough for automated regression testing. We successfully ran a few automated tests to validate URL links that we had a ton of and for navigation mapping. I both loved and hated using automated tools at the time. Execution time was fast when scripts worked. Debugging and re-writing scripts was not fun however.
In the case with Selenium RC I ran into a 1) lack of programming experience in Java and 2) lack of knowledge of the current application code issues.

Friday, September 24, 2010

When the student is ready, the teacher will appear

When the student is ready, the teacher will appear. Buddhist Proverb

And he did. I met James Bach, a teacher, consultant and guru in the software testing field this week.

Here is how it happened. I am a recent involuntary Agile convert after 5-6 years of a solid waterfall testing career. In the course of the last Sprint, while continuously running exploratory tests to no end, I realized that crucial changes need to be made to my testing approaches or I would go crazy. I felt that I could not keep up with the pace of the project cycle. I tried to follow the old patterns of designing elaborate test cases based on high level user stories specs, but I was unable to as the requirements kept changing. My test cases kept getting obsolete, updating the cases slowed down my testing, and I was losing track of time and direction. Plus the whole team was under a lot of pressure. We needed to deliver a product every 3 weeks and we were at the end of the release. I felt anxious and frustrated. I blamed it on the Agile Scrum that I was forced to embrace a few months ago and on the overwhelming number of epic user stories that frequently made no sense. All of this helped move me out of my introverted comfort zone – I now had to talk to developers daily and IN PERSON.

I blamed myself most of all for not being to cope with all this better. I looked through my testing textbooks, I Googled for information on rapid and Agile testing and I read other people’s testing blogs and forums. Soon the realization hit me that what I am going through – growing pains – is not an uncommon phenomenon. Many colleagues of mine also started their quests for answers on how to better themselves and there is a growing ‘army’ of non-conformist testing professionals that consider agile, rapid testing and context-driven testing as a golden opportunity to learn, test effectively and make clients happy.

Somehow I landed on James Bach’s blog site – http://www.satisfice.com/blog/. It felt as if someone directed me right to the site. I noticed that he would be in Virginia within a week to teach his seminars on Rapid Software Testing. Wow! The timing could not have been better for me.