Our guest blogger this month is Atul Angra. A resident of India, Atul is one of our more accomplished testers (a Gold Tester in fact), with over six years of professional experience. He’s a photographer at heart, but a tester by trade, with domain expertise in healthcare and finance.

*******

Let’s take a scenario where a tester follows the rules and reports 100 bugs. Some of these bugs were traced to non-documented requirements that are implicit in nature, such as a drop-down list not populating alphabetically and things of that nature. These bugs are quite common and usually end up in conflict, as development teams reject them based on the argument that it’s not a defined requirement.

Here, both the developer and tester are not ready to close this issue – and they are both correct. The traditional way these issues are resolved is by involving someone from management to intervene and make a decision. The time spent in escalation and argument is much greater than what it would have taken to actually fix the issue.

At a high level, we could blame the team which collected requirement, but this may not be the case when it comes to implicit requirements. Many of these situations could be resolved if the tester demonstrates interpersonal skills.

Testers play a challenging and critical role in the organization. They dare their developer counterparts and are constantly challenged by release managers, as they pose significant risk in delaying the release. This may even stop the organization from achieving a financial target on time. In other words, testers play the role of Devil’s advocate when it comes to improving quality of a deliverable.

As such, good testing skills and good interpersonal skills make the KILLER COMBO that suits this role. Critics are rarely appreciated for their work, but coaches are. Yet coaches and critics do the same thing: they point out your mistakes and give you a chance to perform better the next time around.

The difference is in their approach. An ideal tester should become a coach instead of a critic. Developers turn defensive when testers approach them with a statement such as “This is not working as intended.”

With good interpersonal skills, these discussions can become more effective. A good tester will put forth a scenario that makes the developer consider the impact if the bug is not fixed.

A tester who reports the maximum number of critical bugs with a low rejection ratio is considered efficient. Other expectations from testers are to meet deadlines, ensure process compliance, and practice good documentation with complete functional testing. They ignore a very important attribute here:  interpersonal skills.

Conclusion:

A tester might have all the required technical skills, but may still fail because of his/her interpersonal skills. A bug that could have been amicably solved turns into a management issue with leads to a lot of wasted time.

Testers should spend time in enhancing their interpersonal skills. People always like to have colleagues who are a good listeners and who love to share knowledge. One who shares information and resources, and is helpful by bringing conflicts to the surface and getting them resolved in an ethical and professional manner.

Editor’s note: If you would like to write for our Guest Blogger series, send your posts and ideas to me at mikeb@utest.com

Wondering how you can stand out from the crowd in this quarter’s Bug Battle? Santhosh Tuppad – a “Gold” tester and three-time Bug Battle winner – has some tips to help you claim your share of the prize money, including advice on logging bugs, bug-hunting strategies, submitting positive feedback and more.

For more on Santhosh, read his Tester Spotlight or his recent guest blog post. For more on the current Bug Battle, start here.

*******

I have participated in three uTest Bug Battles so far. In this blog post, I will share with you my experiences from the Q2 competition this past May, and how I was able to win first place. This will include the types of things I concentrated on, my strategy, and how others can give themselves a better chance to succeed in the Bug Battle, as well as in the greater uTest community. Let’s get started!

Different quality criteria bugs

Bug Battles are organized to help uTest understand who is skilled and to whom they can assign more projects or invite to the projects. So, this is a good opportunity for those testers who are new, as well as who are old. Unfortunately, most of them do not understand what the Bug Battle is about – they just understand that “Hunting bugs and reporting them would make them win.”

So, in Bug Battles I report bugs on different quality criteria like:

1. Usability
2. Functionality
3. Severity
4. Performance [ Out of scope for Bug Battle ]

The above list goes on. I do not report 20 usability issues but 20 issues across different quality criteria. By doing this, it gives a good visibility to the Project Managers of uTest and helps them in understanding the credibility of a uTester. So, Project Managers add them to their list to invite these testers to projects.

Bug Reporting

uTester says: I found a bug

Project Manager: What is it?

uTester: There is a ‘Password’ tab after logging in, but there is no current password that is being asked for but only new password to set is being asked for.

Project Manager: Ah, we will fix that in the next release or next version

uTester: Cool

From the above conversation, both the ‘uTester’ and ‘Project Manager’ do not understand the impact of not having “Current password” field in the password tab while changing the password or setting a new password. If a uTester would have helped the Project Manager understand the risk by doing analysis of the issue, then the Project Manager would have stopped the release and asked the development team to fix it as soon as possible, since it is a high risk issue which falls under security quality criteria.

So, you might include the following things in your Bug Battle bug report:

1. Overview
2. Story (this helps in understanding the issue in a better way)
3. Investigation report
4. Impact on end-user
5. Impact on product owner or his / her business
6. Steps to reproduce
7. Expected result
8. Actual result
9. Screenshots
10. Video report (If reproducing the bug will take many steps or is difficult to write properly, you might want to consider attaching a video report which would be easy for reader to understand)

Strategy for Winning Best Bug

How do I win the Best Bug award? How do I find a bug that is more unique than that submitted by other uTesters? Without having this type of mindset, it is hard to get Best Bug award. It’s like traveling in a bus without knowing your destination.

I have a habit of going through other bugs reported by other uTesters. I do this because I get test ideas from the bugs which they would have reported. I attack the depth of that bug and I find a BIG bug which was hiding safely under the small bug. When I say BIG bug what I mean is,

1. Very high risk impact on end-user
2. Money loss involved
3. Threat to product – feature block, server crash, dDoS attack vulnerability, Botnet attack vulnerability and many more things
4. Access to confidential data

Again, the above list goes on. I do analyze the bug reports submitted by other uTesters before I log the bug which would be a nomination for Best Bug award. If the bug is already logged then I see how good the bug report is. If the bug report just has steps to reproduce then I showcase the same bug with detailed information which would help the customer or Project Manager in understanding the risk factor.

Winning Top Tester strategy

19 non-important bugs versus 9 important bugs = 9 important bugs is the winner.

But, you can still report 19 important bugs and be the Top Tester. You might want to ask yourself why you should be the top tester?

1. Have you reported more bugs ( Not crossing 20 ) which are important?
2. Have you followed the guidelines provided in the instructions?
3. Has any other uTester reported more important bugs?

There might be many questions you want to ask yourself before you get into the battle to win Top Tester award.

I reported 18 issues in the Q2 Bug Battle (Best Bug), in Q1 I had reported 16 ( Top Tester ) and in the Q4 2009 I had reported 6 (Honorable Mention) out of 10.

Winning Best Feedback Award

Until now, I haven’t won a best feedback award. However, I suspect that a few points would help you. These points have been consolidated on the experiment I did in the past 3 Bug Battles for Best Feedback award.

1. Feedback is not always negative – they are POSITIVE too. You find bugs on all the products in Bug Battle but doesn’t mean you should critique everything in feedback.
2. Go through the past reports published by uTest and you can find feedback showcased of a winner in PDF document. You can learn something from it.
3. Be honest in answering the multiple choice questions. You might have not tested something or not aware of something. Be honest in choosing appropriate answer. They are not mandatory which would force you to lie

So what is your strategy for the upcoming Bug Battle? I would be happy to read your answers, either in this comments section of this post, or in the uTest Forums. Thanks for taking the time to read this blog post – I hope it helps you to rock in next Bug Battle!

In this post, Travis (a Gold Tester) outlines the mindset needed for success in the uTest community – including advice on logging bugs, preparation, knowing your limitations and more. Enjoy!

*************

How fitting to the time of year. It’s summer, it’s hot – for some of us it’s very hot – and a pool looks so inviting. Tell me this: Would you jump into a pool if you didn’t first know how to swim?  My guess is that your answer is NO. This world presents a lot of open invitations – invitations that appeal to our wants and desires and make it easy for us to just jump right in. I have to admit, sometimes it’s nice to be first. After all, we live in a generation that rewards the person that comes in first. 

Testing Is NOT About Being First
It’s not about the first person to find bugs or the first person to complete their work. To test is: to be informed, to understand, to question, to investigate, to identify, and to communicate. In the end, it’s about providing the customer with the ability to deliver a superior product. And once they bring that product to market, who is ultimately the winner?  You, the consumer.

What’s This — A New Test Cycle In My Inbox?
A new test cycle is an open invitation for everyone to jump in the pool. I know how inviting that test cycle invitation is, and I can guess what’s going through your mind. “What do I have here, a new test cycle. Looks like I’m the first participant, the world is my oyster. I’ll get in, look around, get a jump on everyone, score a few bugs, rack up some dollars, and out I go.”  Easy money right?  Maybe, maybe not.

Let me take you back to my first question, would you jump into a pool if you didn’t first know how to swim? Now, let me re-phrase it as it relates to testing. Would you enter a new test cycle without first knowing what the expectation of the customer is and what is expected of you to test? The correct answer is NO, but the lure of ‘easy money’ is there and provides the temptation to push a few in the pool. As an example, I have seen a large number of bugs logged to a test cycle where it is clearly identified within the objectives that testing is not to begin until a future date. We’re all guilty of moving too quickly sometimes. But don’t forget one thing, what you don’t know could come back to bite you.

Preparation Is Key – Know Your Release!
Read the objectives of the test cycles, understand what the requirements are. It hurts when you enter a bug on a browser that was not listed as a requirement. Documentation attached to the test cycle is not just there to look pretty.  These are valuable resources provided to eliminate questions and eliminate entering bad bugs. Take advantage of the open invitation to ask questions of the project manager. If anything within the objective is unclear, ask the question. A question is learning experience, and if you have a question I guarantee that there are others who are in need of the same answer. Embrace the discussion thread, it’s there for a purpose and serves that purpose nicely.

Know Your Limitations
Before you commit to a test cycle, understand what is expected of you. There are all kinds test cycles, some large, some small, some public, some private. If you happen upon a test cycle where there are a limited number of participants, before you commit be sure you are able to meet the expectations. Do you have the time, can you meet the deadline, do you have the experience, and do you have the right technology? If you second guess any of these questions, the right approach may be to let this one go. Also, ensure that you can handle the workload. Never bite off more than you can chew.  We are the devoted few and that’s what makes us special.

The Database Is Your Friend
Defects are logged to provide a comprehensive picture of issues that have already been identified.  We are a community of testers working together, sharing information. As such, we should understand what other testers have already uncovered and embrace the discussion threads as a viable resource to communicate with each other and assist each other in overcoming hurdles. Before you enter that defect, ensure that it hasn’t already been discovered by another. If, within the objectives it is stated that tester feedback should be logged, take advantage of the opportunity.

Speaking from experience, a tester is not just someone who tests. They are someone who has become an expert on the product.  If something doesn’t fit the product and there’s an alternative which may add value, voice yourself.  The design phase can sometimes run down a ‘one-way street’.  On a one-way street there is no option other than going in the direction you are forced to drive.  Being familiar with the product, we have the ability to see a two way street.  You know the saying there’s more than one way to skin a cat.  Sometimes it takes another set of eyes to see that their may be a better direction to take than the one that was chosen.

Wow, That’s A Lot Of Bugs!
Sorry, I was just watching that Wow! That’s a low price commercial and got a little carried away.  Sometimes the number of bugs found deters us from working on a test cycle.  Nothing is more disheartening than entering a test cycle and seeing that 95 bugs have already been entered.  And what do we say to ourselves, obviously there can’t possibly be any more bugs left to find.  Let me tell you, where there’s one bug, he’s usually got a friend and where there’s a 100 bugs well, that’s a party. The goal of a test cycle is not to reach a particular number of bugs (xx) and call it a day. The goal is to ensure that we have done all we can, that we’ve tested each area of the application enough to feel good about the end product.  If there’s been 100 bugs found, great, make it a challenge to find those next five

Once You’re In The Pool….
We are the lucky few. We have the ability to see the future, to touch it, test it, learn it. We are ahead of the curve. We have all been given a great opportunity to explore technology that has yet to come to market. Embrace the future!

***********

[Editor's note: Want to get published?  If YOU would like to participate in our Guest Blogger series, send your posts or ideas to marketing@utest.com.]

Software testing doesn’t have to suck, says Ben Kelly, the latest contributor to our guest blogger series. A resident of Tokyo, Japan, Ben has over seven years of software testing experience – including his time as a member of the uTest community. In his spare time, he practices Kendo and has represented Australia twice at the World Kendo Championships. He was a Jedi knight for approximately 1.5 seconds and sometimes writes about himself in the third person.

For more of Ben’s writings, you should go read his blog or follow him on Twitter.

***

A good friend and fellow tester, Jared Quinert said to me recently, “It’s important for testers to know their job doesn’t have to suck.” I’d never really looked at it from that angle before, but really I think it’s an important point to make. I think many people are sold a story about how testing is boring, repetitive drudgery that requires little skill. It’s bad enough that many of the people we interact with – programmers, project managers, BA’s – tend to believe this. The really sad thing is this line seems to be bought by so many people that would call themselves testers.

Receive spec, create traceability matrix, write scripts, execute scripts. Repeat. Apologize for not finding all the bugs. Promise to do better. Repeat. Orwell himself could not have written a bleaker, more dystopian view of the future.

No thanks.

I want to work in a place where the developers are up in arms if a project manager suggests shaving time off testing to meet a deadline. I want to work in a place where the BA’s demand that the testers help analyze risk during design. I want to work in a place where project managers and stakeholders listen intently when a tester says ‘I think there might be a problem here’…

Here’s the thing though – it’s up to you and me to build that environment. It takes constant effort. It’s hard work. It’s challenging and sometimes it’s disheartening. You’ll make mistakes. People will misunderstand you, doubt you, sometimes oppose you. If you have a mind to try though, it can be one of the most rewarding things you ever do. Having a developer say to you ‘wow, thanks man. If that had gone to production, it would have been my neck on the block’ – that’s a massive win right there.

It starts with you – with your decision to hold yourself to a higher standard. That’s easy to say, but what does it mean? The specifics will be different for each person, but the gist is this: constantly develop your own skill as a tester and find ways to impress upon others the value of what you can do for them.

Start small. Do something every day to make yourself a better tester. Read testing blogs. Test something in your spare time. Understand that you’re not alone. Reach out. There is a world full of passionate, brilliant, experienced testers out there only too happy to share their knowledge with you. Words cannot express the value of such a community. You need but ask.

At work, build relationships with the people you work with. Speak to developers about what information helps them troubleshoot bugs. If you don’t know how to get it for them, ask if they can show you. Speak with project managers about how they process information so that when you’re writing your test reports, you can make it digestible. Talk to your fellow testers. What are they good at? What do they want to get better at? How can you help them get there? Do you have a customer support team? Spend time with them. What are users frustrated about? What patterns are there in the calls they get?

You may need to have some challenging conversations, resolve some misconceptions and set some boundaries. For example, by calling your team ‘Quality Assurance’ is management expecting you to somehow ensure that the product is bug free? Are they tracking tester effectiveness by counting bug numbers or some other bogus statistic? What can you find that is a better measure?

Possibly the most important thing in creating a brighter testing future is the ability to work with other passionate people – people who love testing. If the people making hiring/firing responsibilities aren’t hiring these people, ask to have input into the process. Help educate them as to what it is you need. Ask to be included in the interview process. If you can’t find motivated people with the skills you need, hire someone with a passion for learning and teach them, but I’ll tell you this for free, I value an empty seat much more highly than a seat filled with a muppet.

Let us, you and I, find ways to improve the things around us. You as testers probably have more influence over your fellow testers than your manager does. What can you do to inspire them to be better? It might be as simple as asking them to show you how they test something and offering your suggestions. It might be pointing them in the direction of a blog you found interesting. Small things can make such a big difference. Even if you’re not in a leadership position, lead from the front. Keep searching for ways to show people how it can be. Find ways to add value and make a difference. It doesn’t have to be a massive difference. Small differences over time. You’d be surprised how quickly these things can gain momentum.

It is time to find the courage to hold ourselves and each other to a higher standard.

If you don’t want to be a part of that, that’s okay. You can still do the entire craft of testing a favor. Just quit your job and make way for someone that deserves your place a lot more than you do. If you choose to be part of something bigger, then welcome.

Editor’s Note: If you would like to contribute to our guest blogger series, please email your ideas to marketing@utest.com.

Santhosh Tuppad has high hopes for the software testing industry – and he’s here to tell you all about them as this month’s featured

Aside from uTest, Santhosh is a member of the Weekend Testing, and received his formal training from fellow guest blogger Pradeep Soundararajan. For more on his background, go check out his blog or follow him on Twitter.

As you could have guessed from the title, this post is about my wishful thinking of software testing. Of course, I can’t be expected to cover all of my wishes in a single blog post, but I have done my best to highlight a few areas of great potential – and here they are:

More active software testing communities
As many of you know from being a member of uTest, software communities will play a big part in the future of testing. Although uTest is a global community, I envision similar communities popping up in every city, state and country. The Weekend Testing group, of which I’m also a member, is another great example of this.

Software testing in schools and colleges

Pradeep Soundararajan – my testing coach – said that kids sometimes ask better questions about a product than what many so-called experienced testers ask. He talked to me about how questions from school kids would lead them to solutions in their own software and products. They asked some very intelligent questions and I was amazed by the perspective they showed. It made me wonder, “Why are students  not taught about thinking (example: lateral thinking) as a skill in most schools and colleges?”

In the future, I wish there will be schools dedicated only for software testing. We will see a great amount of value if an individual is taught about software testing from a much earlier age than college. That kind of expertise would be great for our craft.

Better testing approaches
Most of the organizations use traditional approaches to executing test cases and doing testing. In the future, I wish organizations will understand the problems with the ‘test case approach’ and adopt better testing approaches like Exploratory Testing, Session Based Test Management and others.

Kids as security testers
“Some kids generally explore cracking / hacking tools because they are keen into looking into their girlfriend’s account to keep them updated about the happening.”

“Some kids out of their interest want to crack their friend’s account and get confidential information.”

“Some kids want to show that they are smart enough when compared to their friends.”

So what’s happening here? Clearly, younger kids want to hack everything from the smallest application on up. They practice in coffee shops and shopping malls, trying to crack passwords and getting into the networks of other organizations. I see a group of ethical hackers (can’t stress that last point enough) who are enthusiastic about testing – and who share their knowledge with their peers – will help advance the knowledge base immensely. Today’s harmless hacker is tomorrow’s security tester.

Testing shops
I also wish we could see ” Testing Shops” in future, where testers test any product the customer purchases (for a nominal fee) and then provides them with the issues. This would enable the end-user to evaluate the product and decide “to buy or not to buy.”

Charges might be different:

• Depending on quality criteria
• Depending on the product
• Depending on the number of users using the specific product

Many more points to be considered…

Software Testing TV Channel
A TV channel dedicated to Software Testing. It could include programs like:

1. Effects of Poor Testing
2. Testing stories
3. Testing news
4. Testing jobs
5. Tutorials

The list goes on as the ideas go on.

More Testing Competitions
Talent Hunt – There are a lot of talented testers out there, but not all of them get recognized for their skills. Testing competitions – like the uTest Bug Battle – are a great way to expose their talent and bring them forward for more active roles. I hope to see this trend of increased competition and collaboration keep up for years to come. If the last few years in the testing industry are any indication, I think it will.

Those are just a few of my hopes and wishes for the software testing industry. What are  yours?

Editor’s note: If you would like to participate in our Guest Blogger series, please email your ideas to us at marketing@utest.com.

In this post, Ajay takes a stroll down memory lane…

This is an article on my experiences with software testing, the traps I fell into, and the lessons I learned in the process. Before I share my story, let me make one thing clear: I’m no software testing expert. I make mistakes, learn, practice and apply my learning to improve my skills as a tester. To illustrate, I’ve split the journey into five simple stages.

Stage 1: Testing = Find Bugs

I am hired as an Associate QA Engineer at my first job. I was called upon to help remove all bugs in the product before it reached the customer – simple enough. As an obedient student, I did what was expected of me. The execution percentage never reached 100%. I could not complete a cycle of execution in the stipulated time. I did not know that I was checking and not testing. Whenever I tested, I could not achieve 100% execution. Some of the bugs I logged were termed as ‘Deferred – Will not be fixed’. I was bombarded with questions like: “Which user would do that? Good bug, but why did you find it now? Why did you miss it? ”

I did not have an answer for the questions. I myself had more questions than answers.

Stage 2: Testing = Certification

Everyone I met was a certified tester. I thought I too must take up a certification. Which one should I apply for? ISTQB seemed to be the first step. I downloaded the syllabus and started preparation for the certification. My definition of testing changed from ‘finding bugs’ to ‘get certified, hunt for bugs’. I felt I was not sufficiently prepared for the certification, thereby postponed my attempt to clear the certification exam.

Stage 3: Testing = Rapid Software Testing

I don’t remember the search term which led me to the Tester Tested blog, but it literally set off a chain reaction. Tester Tested led me to James‘ video. This led me to even more testing blogs, which finally led me to the RST workshop by Pradeep Soundararajan.

The workshop literally changed my life, as I’m sure it did for others as well. At last, I started adding VALUE to my team. My manager was happy. I was happy, as I was then given freedom and responsibility to demonstrate value. I started participating in Test Republic, Software Testing Club, SourceForge, uTest and other activities. I started my blog.

I broke some records in terms of number of bugs logged, and became an overnight hero in the project. I was happy, even though I was not aware of the traps I was falling into. The thought of certification was replaced by ‘Cost Vs Value’ and skills in testing like questioning, observation, critical thinking, bug hunting, bug investigation and so on.

Stage 4:  Achievements and Mistakes

I fell into the trap of equating credibility with bug counts, missing the mission of testing and just finding bugs. I was lucky to have someone of Pradeep’s caliber to help me realize these pitfalls. Interactions with testers  and programmers from across the globe helped me immensely in my journey of learning.

I would highlight the credit by the programmer for testing D2D Map Editor as my first achievement.

Frequent meetings with passionate testers like Sharath Byregowda, Santhosh Tuppad, Manoj Nair, Parimala Shankaraiah, Ravisuriya and coaching by Pradeep Soundararajan helped me sharpen my testing skills.

While RST workshop by Pradeep acted as an eye-opener, RST workshop by Michael Bolton could be termed as the cherry on the cake.

My biggest achievement is being appreciated and encouraged by leading software testing experts like Matt Heusser, Michael Bolton, James Bach and Shrini Kulkarni.

If you ask me, Test Republic, BWST, Zappers, Miagi-Do School, Software Testing Club, uTest, blogs and tweets are good sources to network, learn and contribute to the greater software community.

Stage 5: Testing = Passion

It all boils down to one word: PASSION. I’m learning every day. I now realize that there is so much to learn and so little time left. I’ve overcome my fear of failure and take every experience as a learning opportunity. The passion to test and contribute resulted in Weekend Testing. I’m happy that a single idea between tester friends has resulted in a safe platform to ‘Test, Learn and Contribute’ to the software community.

My special thanks to all the experts who have helped this generation of software testers by sharing their knowledge with us. From executing test cases to reporting bugs, I’ve come a long way to realize that it’s a long journey ahead. I would like to conclude with this quote:

“The important thing is not to stop questioning. Curiosity has its own reason for existing.”

-Albert Einstein

Here to address this topic is Bill Ricardi of Northern Ireland, this month’s guest blogger. An active member of the uTest community (especially in the uTest forums), Bill describes himself as a “huge nature fiend, with professional ties to advertising, real estate, gambling, and writing.” For more on Bill – including the upcoming publication of his first book – check out his Google Knol page.

In the field of contract software testing, you won’t always see eye to eye with the client. What you consider a critical bug, they might see as a non-issue (or worse, a ‘feature’). What you call a major security flaw, they might consider such a remote possibility that it doesn’t even deserve a mention.

You might ask how you bridge such a gap between your level of testing and the client’s level of acceptance and understanding of product integrity and the testing process in general. The answer is simple:

You don’t.

It isn’t your job to convert the client to your way of thinking. Yes, you can contest a bug that they reject out of hand if you were technically correct to report it. Sometimes they’ll accept it as valuable feedback, but most of the time they’ll just ignore any contested bugs. This is something that you have to live with.

You cannot impose your standards upon a client. No matter how passionate you are about the quality of your work and your understanding of their product, no matter how much you study the test parameters and the client’s requirements… only they know what they really want out of the test cycle. They WILL usually refuse bugs that they don’t consider ‘real’ bugs, because they’ve probably had meetings about what their programming philosophy should be, and they probably have a preconceived notion of what they have time and budget to fix.

So you’ll get hit with the dreaded duo of rejection reasons: ‘not a bug’ or ‘out of scope’.

My advice: Once you’ve made your case, and made it again if you contested their bug rejection, MOVE ON! As an independent tester, you only have 2 options; you can continue to look for bugs on their project, or you can move on to a new project. Don’t attempt to control the client, they won’t appreciate it. Instead, focus on your self control and keeping your personal standards high.

In this post, David offers us his “notes from the field”, where he’ll be addressing the role of  software testers; criteria for hiring testers; the experts he follows and more. We’re confident that you’ll like it. Enjoy!

I am thrilled to be invited to share my testing experiences with the uTest community. I hope my account will encourage more organizations to adopt the agile way and more testers to find fun and fulfilling jobs.

I joined Guidewire Software about seven months ago as an Agile Tester. We make core software for the Property and Casualty insurance carriers. If you have car or homeowners insurance, you may be serviced using our software. Right from the start, Guidewire has used agile development methods and credits a good part of its success to this philosophy.

Our applications are complex. It typically takes several months for a tester to become fully productive because there is so much domain knowledge and in-house tooling to learn. Our applications are enviably flexible, and each installation is customized to fit the specific needs of the insurance company. In order to empower the customization process, we provide a number of development tools including a custom java-compatible scripting language, an IDE, a GUI framework, and a screen painter.

For testing purposes, we ship a testing framework and have developed many internal tools such as a distributed continuous integration server consisting of several hundred hosts running various permutations of the operating systems, databases, and web servers that we support. We have an advanced UI testing framework that integrates with Selenium and a set of domain ‘builder’ classes that help with rapid test data creation.

Perhaps the biggest difference from other places where I have worked is the way testers are treated here. We sit together with developers grouped by functional areas. There is no dedicated QA space with the proverbial wall to throw releases over. We attend all product requirement meetings and participate in the product demos. Testers are truly first-class citizens of the development team.

Everyone does testing at Guidewire. Developer interviews include a large testing component, and the test-driven nature of our development is emphasized to make sure that new developers are on board with testing practices from the beginning. We have started a weekly Agile Testers brown bag lunch, which is well attended by testers and developers, as well as development and program managers. During this lunch, everyone is encouraged to demonstrate techniques that worked well or share war stories of challenging bugs. We discuss the latest books on testing and upcoming conferences, but no business decisions are made.

At this point you are probably wondering who writes the automated tests, developers or testers? On my team we have agreed to the following: both developers and testers write automated tests, but developers own and maintain the tests that run on the continuous integration server. Testers are focused on exploratory testing and use automation when appropriate to speed up the process. The advantage of this approach is that we recognize testers’ testing skills over their programming skills. It takes programming skills to maintain a large body of tests over a long period of time in an object-oriented language, and developers are typically better and quicker at this, whereas testers excel at domain knowledge, analytical skills, and the testing heuristics necessary for effective testing on tight schedules.

We work in two-week sprints and test continuously. Because developers practice test-driven development and the continuous integration server constantly reports test failures, the system is almost always runnable from the main branch in the source control system. We never have to wait for an official release to start testing. Both developers and testers work from story cards posted on the project board. If a requirement is unclear, the product managers sit next to us and provide instant clarification.

When we write test scripts that drive exploratory testing, we meet with developers from time to time to discuss which tests are good candidates for automated regression functional tests and turn them over to developers. Both developer-owned and tester-owned tests can coexist in the same source file by using the @ManualTest annotation. Because our application runs inside a web server, it’s important that our exploratory tests run inside a live application, not just in a testing harness. To accomplish this, one of our engineers wrote a tool called QuickTest that can load and run tests inside a live server. We recognize that tight engineer-tester collaboration is one of the most important aspects of our process.

But what if you are a tester with significant programming experience—is there a place for you at Guidewire? Absolutely! What I have described thus far is the testing approach we use on my application team. We also have testers on the platform team that possess significantly higher programming proficiency because they are testing our scripting language, IDE, and related frameworks. And last, but not least, we have our ‘testing labs’ projects such as the distributed, pseudo-random, model-based testing system I work on during my slack time.

If by now you are suspicious that all this sounds too good to be true, let me confess some of the challenges that remain with us. Due to the inherent complexity of our platform, unit tests incur a significant start-up time. We are fighting this by finding ways to tune our core code and by buying faster workstations with solid state drives. Over the years, we have accumulated a very large number of tests, and test maintenance is taking a noticeable chunk of engineering time. We are looking for ways to reduce test fragility and triage the regression test suites based on their relative value. Lastly, we have our share of non-deterministic tests—these are always ‘fun’ to diagnose and fix—they are often a symptom of concurrency or data locking problems and thus may be some of the more valuable tests in our arsenal. Unlike some smaller agile projects that boast their systems are always in a shippable state, we acknowledge the existence of “dark matter” – the stuff that is invariably found and must be fixed prior to a release – even as we are working hard to reduce its volume.

I would like to conclude with a short treatise on hiring testers. Too many development organizations are enamored with building out test automation at the expense of useful, efficient testing and have favored hiring programmers into testing jobs regardless of their true interest and talent for testing or their actual testing skills. This is a mistake. Some of the best testers I have worked with studied math, physics, philosophy, and psychology. Testing, like programming, is a performance art. When hiring testers, it’s important to have them test something during the interviews. It can also be very helpful to look at the testing they have done previously. This is typically impossible when someone has worked for a private company, but it is possible on the public projects on uTest.com. “Wow! How did you find that bug?” is a great question to get from the hiring manager during an interview. I value uTest as a fantastic resource for learning testing skills from peers all around the world, and I visit the site often.

I owe a debt of gratitude to the following individuals who have nurtured and supported me in my studies of testing. I encourage you to seek out their writing on the topic:

• Cem Kaner
• Elisabeth Hendrickson
• James Bach
• Paul Carvalho
• Michael Bolton
• Brian Marick
• Bret Pettichord

Special thanks to my peer and mentor at Guidewire, Dave Liebreich.

We’re excited to kick-off the new year with Yvette Francino as the latest contributor to our Guest Blogger series. Before joining the uTest community, Yvette  spent the bulk of her career as a developer for companies like IBM, and most recently, as an IT manager at Sun Microsystems. An aspiring novelist, she also publishes “New World Software Quality Assurance”, a blog covering all sorts of testing-related subjects.

In this post, Yvette offers advice for testers who hope to engage in ‘civilized’ dialogue with their developer counterparts. A touchy subject, to be sure!

Software testing is one of the few professions where an unfortunate task is to tell someone else what is wrong with their product!  This, of course, can make the recipient of such news – the developers – a bit defensive. Imagine hearing that your baby is defective! It’s therefore important to employ a bit of diplomacy when delivering such news.  Being a tester is comparable to being a doctor. Let’s listen in on couple of hypothetical conversations. Young Susie (i.e. the software) has been examined to see if she’s ready to enter Kindergarten (i.e. the market).

Conversation with Dr. Tactless

“I have found quite a few problems with Susie,” Dr. Tactless reports to Susie’s parents, looking quite satisfied with his report. “I found 20 problems on her hands and feet. Each toe on each foot has a rash on it. And each of her five fingers on her two hands also has a rash.  What have you been feeding this child? When a child has 20 problems, we can’t let her go to school.  Not only that, but her head is weak. She certainly will die if you let her go to school now.”

“Die? NOOO!”

“When I pushed her down, she knocked her head on the floor, and then she wasn’t able to think. Had I pushed her any harder, she certainly would have died.”

“Why did you push her down?” the parents ask in horror.

“I had to simulate what the kids at school will do.  She is really ugly – uglier than any kid I’ve ever seen. She’s going to be pushed down a lot. She’s going to need major surgery to put a protective layer on her head before I can sign off that she’s ready to go to school. ”

It’s a shame the doctor didn’t have a protective layer on his head to protect him from Susie’s parents.

Once they recovered from their anger, they took Susie to get a second opinion.

Conversation with Dr. Diplomacy

“What a great kid your Susie is. She’s a whiz with numbers.”

Susie’s parents beam.  “But is she ready for school, doctor?”

“Well, she passed most of the tests, but there are a couple of things I’m concerned about. We need to figure out what’s causing this rash on her fingers and toes before letting her go to school. This looks like an allergy, so with some additional tests we should be able to narrow down the culprit. Usually, with a simple change in diet, we can get it all cleared up.”

“And her head? Is it true she needs major surgery?”

“We can weigh the pros and cons of surgery, but there is a less intrusive alternative. She can wear a helmet whenever she’s riding her bike or engaging in activities that might put her at risk for a head injury.”

“Thank you SO much Dr. Diplomacy! We trust you and will send all of our friends to you.”

~~

It’s not always going to be so easy to solve each problem. And there are times when a product is not ready to be released. The tester does need to stand firm about his findings. However, here are some lessons in communication that will be beneficial in ensuring effective communication between the tester and the developer:

1. Don’t report the same bug multiple times.

Know the code and application well enough to be able to determine if different scenarios are uncovering the same bug.  If you suspect that one fix will address multiple symptoms, report the symptoms as a single bug, rather than multiple bugs.

2. Don’t inflate the seriousness of the problem.

It’s common for a tester to be proud of finding a serious bug. However, until the specifics are known it’s better to simply state the facts and not jump to conclusions that haven’t been proven.  Avoid dramatics.

3. Find some positive things to report.

Though it’s important to report on the bugs and issues, the developers have worked hard at creating a product. Take some time to let them know of the tests that passed and appreciate the positive findings.

4. Brainstorm alternatives.

Don’t assume there is only one fix. Look for work-arounds and solutions that might allow for a product to be released, while still minimizing the risk of product failure.

5. Refrain from offering negative opinions that can’t be validated.

Stick to reports that will give factual information and be traceable back to the requirements.  Don’t report that an application has an “ugly” user interface.  Test against what the customer requirements were, even if those differ from your own opinions. If you have concerns, use sensitivity when discussing them.

6. Take pride in the application.

Ideally, you and the developer are partners; working together to ensure the product is delivered on time and with high quality.  Think of the application as your baby, too!

Here are a some of the highlights from our 2009 guest blogger program.  Stay tuned for an even bigger 2010!

Who is the User? – by Lucia Maldonado:  In what ways is software similar to architecture? And how can this help steer testers in the right direction? In this post, Lucia Maldonado takes an in-depth look at user accessibility standards, and offers a number of essential tips for testers in this field.

Security Testing Tips (from a Bug Battle Winner) – by Bernard Shai Lelchuck:  When it comes to security testing, few can match the expertise of Bernard Shai Lelchuck – one of uTest’s first (and finest) QA professionals. In this post, Bernard covers the basics methods of security testing, including tips for  information gathering, logical attacks and injection attacks. Oh, and here’s Part II.

Respect the Defect: Advice That Will Change the Perception of  Testing – by Joseph Ours:  Testers need to reconsider they way they report bugs – this was the position taken by Joseph Ours in his first (and hopefully not last) uTest blog post. Challenging testers to demonstrate their value by writing more clearly about the bugs they uncover (among other tactics), Joesph has sparked an interesting debate among our community. Visit the comments section to see for yourself.

Step Away from the Simulator: Putting Mobile Applications Into a Tester’s Hands – by Brad Sellick:  What makes mobile testing different from conventional software testing? For one, the simulators and emulators are far less reliable. In this post, uTester Brad Sellick – a self-made expert on mobile app testing and development – explains the dangers of relying on these tools while performing mobile app testing.

What You Need to Know About Writing Effective Test Cases – by Valerie Dale:  Despite all evidence to the contrary, test case design is often seen as work with no real value – a remedial task with no significant ROI. One would think that with the added pressures to launch a quality product on schedule, test case design and planning would be a top priority. It’s not. At best, there is minimal attention paid to the practice. At worst, it’s non-existent. In this post, Valerie Dale makes a great defense of  this beleaguered practice.

Your Overconfidence is Your Weakness: Lessons from a “Crash Specialist” – by Pradeep Soundararajan:  In our most-popular guest post to date, noted blogger Pradeep Soundararajan explains why finding lots and lots of bugs isn’t necessarily a good thing. Reliving his days as a “crash specialist” Pradeep examines how a tester’s ego can get in the way of their objective. His advice is as funny as it is useful. Simply put: a must read.

Software Testers: The “Eyes of the Battlefield” – by Brian Rock:  Our testers come from all sorts of backgrounds, including the armed forces. Brian Rock – a former Sgt. for Combat Arms Forward Recon Team in the U.S Army – is a great example. In this post, Brian makes analogizes testers with cavalry scouts. That is, they are the “eyes of the battlefield.”  Advocating exploratory software testing (especially for those in the uTest community) this post will make you rethink the role of testers.

You’re a Professional Mobile Tester (you just don’t know it yet) – by Bernard Shai Lelchuck:  As the title would imply, this post makes the case that anyone with a mobile phone and an inquisitive mind can become a successful mobile tester. It worked for Bernard Shai Lelchuck! Here Beranrd explains the rise in mobile applications, how he himself broke into the field and some basic tips for those who would like to get started in this growing (and highly lucrative) field.

Question the Connection: Tips for Diagnosing User Login Failures – by Sherry Chukpa:  Forget the sweeping generalizations about software testing “best practices.” This post by uTester Sherry Chupka gets right to the point on a very specific issue: user login failures. If you’ve ever been pitted against this problem in the testing lab, Sherry feels your pains, and has some invaluable advice for you as you move forward.

It’s been a great year, with some terrific insights into the world of testing, but our Guest Blogger program is just getting started. So if you have an opinion to express, a tip to share or a bone to pick, we’re always eager to share the thoughts of our tester community. Email us your ideas at marketing@utest.com.