Posts Tagged ‘Manual testing’

Software Testing has lot of challenges both in manual as well as in automation.Generally in manual testing scenario developers through the build to test team assuming the responsible test team or tester will pick the build and will come to ask what the build is about? This is the case in organizations not following so-called ‘processes’. Tester is the middleman between developing team and the customers, handling the pressure from both the sides. And I assume most of our readers are smart enough to handle this pressure. Aren’t you?

This is not the case always. Some times testers may add complications in testing process due to their unskilled way of working.In this post I have added most of the testing challenges created due to testing staff, developing staff, testing processes and wrong management decisions.

So here we go with the top challenges:

1) Testing the complete application: 
Is it possible? I think impossible. There are millions of test combinations. It’s not possible to test each and every combination both in manual as well as in automation testing. If you try all these combinations you will never ship the product ;-)

2) Misunderstanding of company processes:
Some times you just don’t pay proper attention what the company-defined processes are and these are for what purposes. There are some myths in testers that they should only go with company processes even these processes are not applicable for their current testing scenario. This results in incomplete and inappropriate application testing.

3) Relationship with developers:
Big challenge. Requires very skilled tester to handle this relation positively and even by completing the work in testers way. There are simply hundreds of excuses developers or testers can make when they are not agree with some points. For this tester also requiresgood communication, troubleshooting and analyzing skill.

4) Regression testing:
When project goes on expanding the regression testing work simply becomes uncontrolled. Pressure to handle the current functionality changes, previous working functionality checks and bug tracking.

5) Lack of skilled testers:
I will call this as ‘wrong management decision’ while selecting or training testers for their project task in hand. These unskilled fellows may add more chaos than simplifying the testing work. This results into incomplete, insufficient and ad-hoc testing throughout thetesting life cycle.

6) Testing always under time constraint:
Hey tester, we want to ship this product by this weekend, are you ready for completion? When this order comes from boss, tester simply focuses on task completion and not on the test coverage and quality of work. There is huge list of tasks that you need to complete within specified time. This includes writing, executing, automating and reviewing the test cases.

7) Which tests to execute first?
If you are facing the challenge stated in point no 6, then how will you take decision which test cases should be executed and with what priority? Which tests are important over others? This requires good experience to work under pressure.

8 ) Understanding the requirements:
Some times testers are responsible for communicating with customers for understanding the requirements. What if tester fails to understand the requirements? Will he be able to test the application properly? Definitely No! Testers require good listening and understanding capabilities.

9) Automation testing:
Many sub challenges – Should automate the testing work? Till what level automation should be done? Do you have sufficient and skilled resources for automation? Is time permissible for automating the test cases? Decision of automation or manual testing will need to address the pros and cons of each process.

10) Decision to stop the testing:
When to stop testing? Very difficult decision. Requires core judgment of testing processes and importance of each process. Also requires ‘on the fly’ decision ability.

11) One test team under multiple projects:
Challenging to keep track of each task. Communication challenges. Many times results in failure of one or both the projects.

12) Reuse of Test scripts:
Application development methods are changing rapidly, making it difficult to manage the test tools and test scripts. Test script migration or reuse is very essential but difficult task.

13) Testers focusing on finding easy bugs:
If organization is rewarding testers based on number of bugs (very bad approach to judge testers performance) then some testers only concentrate on finding easy bugs those don’t require deep understanding and testing. A hard or subtle bug remains unnoticed in such testing approach.



They just found out that the third-party consulting firm you hired tested their code in production and sent 14,000 form letters out to your customers with a return address of “Bertha Big Butt.” While the CEO and executive management team are sweating bullets and preparing mitigation strategies, your testing team is trying (without success) to stifle their guffaws.

Testers think differently than the rest of the IT team.

It’s not that they don’t appreciate the seriousness of the situation. They do.

It’s just that it’s…well…it’s FUNNY.

If you’re going to manage or work with testers, it stands to reason you have to understand testers. They march to the beat of a different drummer when compared to the rest of the IT staff.

Testers are trained to find and report problems. They view their contribution as helping the company, the development organization, and the customer or end user by exposing risks. They do that by finding and reporting software anomalies, often contributing information about the consequences of those errors.

Software testers know they’re the “dark side of the force.” They often joke about it (“Come to the Dark Side—We Have Cookies”). They view themselves as rebels, as the Bad Guys in the Black Hats, as Indiana Jones, Captain Jack Sparrow, and Sherlock Holmes all rolled into one.

You never knew testing groups view themselves as the original Bad Asses, did you? Well, they’re about to kick down your pretty house of cards. And they’re going to enjoy it. Good testers almost always have an “attitude” of sorts. It can make them kind of irritating at times. After all, they never would have tested in production. They would have tried scenario X before shipping. They told you something was wrong and you didn’t listen, did you? Sometimes it’s enough to make you want to hit them with a stick. Especially when they’re right.

So what is a tester, exactly? If you were to pick just a few key qualities, one of the first would be that a tester is curious. They want to know how things work. They are experimental. They want to see what happens when they try different scenarios or experiments against what has been presented to them. A good tester is also relatively fearless. They aren’t afraid they’ll break something. They aren’t afraid to tell you the truth about what they’ve found, regardless of your position. And they aren’t afraid to stand their ground and fight to get it fixed if they believe it negatively impacts the potential success of the product. A tester is intelligent, analytical, and learns fast. They are, in fact, always learning. Their jobs require it. Technology changes on a constant basis, and every project they receive is different in some way from the last. Sometimes they have great specifications. Sometimes not. Sometimes they have no written documentation at all. They need the ability to ask the right questions, investigate the right issues, put together the pieces of the puzzle, and draw the right conclusions.

Testers are also generally apolitical. If you find a tester who is particularly good at politics, chances are pretty good they aren’t especially great at their jobs. It is very difficult to play political games successfully when your job involves discovering and reporting issues. Testers are often accused of being blunt, rude, not team players, and the like. That’s rarely true. Chances are good that anyone making such accusations does not understand or appreciate the role of the tester on a project team. Their jobs do not allow them to sweep any information that is “inconvenient” under the carpet.

Those are the good qualities of testers. There are other qualities that are less desirable, but still part and parcel of the overall persona of most testers, particularly those with a lot of experience.

A tester tends to be distrustful. This is a learned behavior. They’ve been told over and over again that X doesn’t need to be tested or Y code “hasn’t been touched.” That information has been wrong more times than they can count. So you can tell a tester the grass is green and they’re still going to go check for themselves. A tester is critical, and it bleeds into other areas of their lives. They’ve been trained to find and report problems. That means if you send them an email with a misspelling, the entire team is going to helpfully point that out, or any other mistakes you (or anyone else) makes. Testers question everything, and that includes authority. It’s generally a bad idea to try to lie to or finesse a test team with whatever politically correct propaganda that would be successful with some other group of people. You’ll get far better results telling them the bitter truth. It’s the only way to earn their respect and trust.