Software Testing Blog

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. He’s also a former Bug Battle winner, a guest judge, a Tester of the Year, a Forums junkie, a crash course author and he’s here today to discuss how interpersonal skills can make or break a tester’s career. Enjoy!

*******

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.

Read more…

Our guest blogger this month is Travis Howell. A member of the uTest community, Travis has over 15 years of project management/analyst experience, including one year at NASA where he served as Deputy Manager of Human Spaceflight for the International Space Station. A father of three (or seven if you include dogs), Travis is an employee by day, a father by night and a uTester by early morning. Sleep would be nice, he said, but he’s adjusted to living on a couple hours.

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.

Read more…

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.

Read more…

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. ”

Read more…

As a way to extract the collective wisdom of the uTest community, we decided to experiment with a Guest Blogger program beginning in April. To say that it’s been a success would be an understatement, but we’ll say it anyway (the number of page views don’t lie!). Having covered a wide range of topics – including mobile app testing, tester overconfidence, security testing and more – the series has become a big hit within the community — and a great way for testers to get published in front of a large audience.

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.

User login failures – why do they occur and how can testers spot them beforehand? That’s the latest subject of our Guest Blogger series. Addressing the topic is veteran uTester Sherry Chukpa of Pittsburgh, Pennsylvania. A married mother of three teenage sons, Sherry began her software testing career back in 1998 after obtaining a degree in Applied Science. Aside from being a full-time tester, and an active member of the uTest community, Sherry is also a prolific testing blogger. You can read her blog or you can follow her on Twitter. Either way, testers should be listening carefully to her advice. Enjoy!

This article lists some of the scenarios that cause user login failures. It is my hope that this will give you some new ideas when building future test cases.

What happens if the ODBC Data Source is configured using the incorrect driver version? For instance, I tested an application that was an add-on module to a web application. The add-on module required the Native SQL Server driver. The web application had its own ODBC Driver. The add-on module did not handle names containing spaces if it connected using the web application’s ODBC Driver instead of the Native SQL Server Driver.

What if there is more than one ODBC Data Sources configured to use the same name (one under System DSN and one under File DSN)? I once saw an application that displayed the ODBC Data Source names in a drop down list. The program would only show one of the Data Sources if there was more than one DSN using the same name. You could not be sure which database the program was connecting to.

Does the software handles DSN names containing special characters? The data source name may accept special characters that the application does not handle correctly. Some languages use the ampersand (&) symbol to underline the accelerator key or keyboard shortcut in a menu. The ampersand symbol might be displayed as an underline.

Read more…

Our guest blogger this month is Joseph Ours, a recent Bug Battle winner with more than 12 years of IT experience, including software testing and quality assurance. In this post, Joseph advises testers to re-examine the way they report defects in software applications.

Testers and testing are viewed as a cost center in many organizations. If you look at the roles of other “main” players, you quickly see that testers face what I call an issue of intangibles. Here’s what I mean:

• Project managers – They are task masters driving a product to completion. Businesses absolutely want products created on time and under budget – which is why they are (correctly) viewed as an absolute necessity.

• Analysts – These guys get the great job of descriptively conceptualizing the idea. This is akin to a paper prototype, and gives the business the first real glimpse of how it might look and work.

• Developers – They are the cream of the crop. They get to create an actual product that businesses can see and feel.

• Testers – Well, we say if it works or not.

Read more…

In the second installment of our guest blogger series,  Bug Battle winner and expert tester Bernard Lelchuk examines the basics of security testing:

Although it’s a broad term, security testing can be broken down into six basic concepts:  Availability, Authentication, Authorization, Confidentiality, Integrity and Non-repudiation. I’ll define each concept briefly, however, I encourage you to research each concept for a better understanding.

• Availability: Assuring that information & communications services are available and maintained for authorized persons when needed.
• Authentication: Assuring the validity of any type of originator, transmission or message.  This also gives confidence that information is received by a known and validated source.
• Authorization: Assuring that an individual can allow/deny access to a system/service/operation (e.g. Access control).
• Confidentiality: Ensuring information is accessible only for those with authorized access and to prevent information disclosure to any party other than the intended recipients. Often ensured by encoding information using algorithms (cryptography).
• Integrity: Ensuring received information is preserved successfully with no alteration.
• Non-repudiation: Ensuring action/communication cannot later be denied (usually used by form of authentication and time stamping). Read more…