Bloggo back to the blog
Testers versus developers, fire and water…-->
What a load of crap!
I’m a software testing professional for over 16 years now and sure, I played the game ‘blame the developers’. I too once kept a log of statements and replies to bugs; ‘That’s by design’, ‘It doesn’t do that on my system’, ‘No user would ever do that!’.
It took me long enough, but I finally found a place where it all comes together. And to be honest, I always suspected, but saw it as Utopia, the unreachable.
It’s all about the environment we work in, corporate culture, open communication and equal respect for the entire team regardless of their role.
About a year and a half ago now, I joined Nascom to help them streamline and improve their quality procedures and build a test approach to cover the entire development life cycle.
Testing before that time was handled by the ‘Nascow’! The Nascow is a plush cow that moved to a different desk every day and whoever found the Nascow on his desk in the morning took the role of tester for that day. Not a bad idea and already a good indication that quality and testing was regarded as an important integral part of development.
But what can you expect from developers, designers, themers without any training or background in software testing. They all tried to make the best of it but missed structure and someone to create and maintain guidelines, plans, templates.
So there lies part of the job of a tester, besides testing, finding bugs, a tester needs organisational skills and an analytic mind to bring some order and structure. It’s such a waste of time to repeat actions because you just forgot you already performed them or simply forgot to keep record of things already done and the result of those actions.
So now I’m ‘The Lone Tester’… but it doesn’t feel that way because I’m part of a team that has the same goal, build great software applications that meet high quality standards.
Being a team player, in my opinion is another indispensable characteristic of a good tester. Just as developers can’t deliver quality software when code is thrown over the wall, a tester also needs to communicate about his work, his findings. Why he does the things he do, the way he does them.
Being part of a team means being valued as an equally important link in the chain and vice versa.
Developers often just don’t know that there are also active testing communities, work groups, conferences just as they exist for developers. Showing your team that you are passionate about your profession as a software tester (just as they are about their profession) and want to stay on top of things by actively participating in the community, attending conferences and events will build mutual respect for each other’s role in the team. If you don’t build walls around you, there is no need to tear them down and there certainly isn’t any need to throw anything over. It takes less energy handing things over including context and information than playing ping pong with a dozen balls over a brick wall, never knowing what colour the next ball will have. However exciting it might be as a game… we’re not playing games when it comes to delivering great products.
Yes, we do have an awesome team but we also live in the real world and that means that not every team member has the same skills and experience. However, over time I learned to recognise the really good developers or those who want to become really good developers. And actually, it’s pretty simple, the good ones want you to test their work and will strive to find solutions for every bug or finding. They make it their mission to make it as hard as possible for you, the tester, to find bugs. Not by hiding them better but by learning from the past and avoid making the same mistakes again.
Some of them have that sparkle in their eyes when they deliver a release for testing. They hope you don’t, but at the same time are eager for you to find bugs so they can fix them and keep improving.
The (excuse my language) ‘bad’ developers are the ones who always find excuses. ‘It doesn’t do that on my system’, ‘No user would ever do that!’ remember?
So yes, I found a great place to work where every individual is valued for his specific skills and talents but the work is never finished. We’re not there yet, there is still a lot of room for improvement both in terms of testing as in terms of development. But that is what makes it exciting and challenging, working as a team to keep improving and ultimately being proud of the products you deliver.
And you know what? I still blame the developers!
Not really, but I like to tease, and so do they.
Bio: David Vandervoort is a software testing enthusiast with more than 16 years of experience as a tester, test coordinator and test manager. His passion lies in helping developers provide the best possible end user experience and as such the end user will always be his starting point of view in any test project. Although a great believer in exploratory and session based testing, he feels that techniques or approaches used are subordinate to reaching the goal, delivering great software that is fun to use!