Diary of a user tester

by Carsten Wium & Lucas Hansen

Dear diary

Good news! Today my boss told me that he would be sending me out to test our new software solution. He told me how quality minded and thorough I am. He said that the guys at the IT department had been working for a good while on this piece of shiny new software, and he wanted me to take it for a trial run. Feeling like my dad had just given me the keys to his new car, I promptly cleared my early summer schedule for the “User Test”. I also readied a speech for my wife about how we would have to wait another season before going to France.This is going to be great!

Dear diary

I was at the IT department today for my first planning meeting. I must admit my first impressions were met in full. There were computer geeks all over the place, coffee machines to feed them all and not a customer in sight! When I got to the meeting room, I met with the Test Manager – a bright one with a nice tie and the good manners too. He kicked off the meeting by letting us all know how important we are, and I must admit, it felt nice. We were all from different branches and we all felt much appreciated for taking time out of our calendars to be here. Some had been testers before, while others like me were here for the first time.Using several complicated terms, the test manager told us all of the plans for the test. I’m not really sure what they were, but the power points looked good. Tomorrow, everything is going to make much more sense.

Dear diary

Day three and we are almost done with the preparations for the test. Surprisingly enough, today wasn’t at all the best of days, after the first day’s confusion. The test manager showed up with a “business developer” who had a few moments to talk about the new software. It sounded good, but she had to run shortly after the presentation. Then the test manager started talking about another test which was making our test more difficult. Apparently someone was doing a system test. I’m not sure why that would be necessary since we are all here to do the testing, but in any event, that test was more important than the remaining introduction and we were sent home early.

Dear diary

It has been two weeks since we finished our planning and preparation and there are now three days to the beginning of the test! Here in our department, everybody is feeling tired of the old software and they are looking forward to my stories when they return from their holidays. Anyway, at the end of the day, I got a mail saying that the test is postponed for two weeks. The new software is having some bugs fixed (which, incidentally my cat also had this spring) and the developers needs a bit more time.

Dear diary

Today is the first day of the test, and I learned a valuable lesson. Showing up early has its rewards. Apparently someone else had made a miscount of how many testers were coming, and the last four testers that came through the door were divided onto only two computers. My first test case was a bit difficult to find. Our training with the test software had been much simpler than it really was. Apparently there was a bit of difference between how the developers sorted these “test cases” and how we practiced it during the training. When I finally found what I needed, I was good and ready to get to work like the thorough and quality minded tester that I supposedly was.There was plenty of work cut out for all of us. I tested many of the work processes that go on in my branch. A few I’ve had much experience with and some I got to know a lot better. Today, I also found a defect in the approval of invoices. Apparently the system allowed for all users to approve invoices, regardless of their position, and I am not sure that my boss would like for the canteen to approve his orderings of new hardware. This was my first actual defect and it felt good to catch that one before the software was released.

 

Quality Software Project Management

Quality Software Project Management.

 

An article on Exploratory Testing

by James Bach

Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven’t found a tester yet who didn’t, at least unconsciously, perform exploratory testing at one time or another. Yet few of us study this approach, and it doesn’t get much respect in our field. It’s high time we stop the denial, and publicly recognize the exploratory approach for what it is: scientific thinking in real-time. Friends, that’s a good thing.

Concurrent Test Design and Execution

The plainest definition of exploratory testing is test design and test execution at the same time. This is the opposite of scripted testing (predefined test procedures, whether manual or automated). Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan. This may sound like a straightforward distinction, but in practice it’s murky. That’s because “defined” is a spectrum. Even an otherwise elaborately defined test procedure will leave many interesting details (such as how quickly to type on the keyboard, or what kinds of behavior to recognize as a failure) to the discretion of the tester. Likewise, even a free-form exploratory test session will involve tacit constraints or mandates about what parts of the product to test, or what strategies to use. A good exploratory tester will write down test ideas and use them in later test cycles. Such notes sometimes look a lot like test scripts, even if they aren’t. Exploratory testing is sometimes confused with “ad hoc” testing. Ad hoc testing normally refers to a process of improvised, impromptu bug searching. By definition, anyone can do ad hoc testing. The term “exploratory testing”–coined by Cem Kaner, in Testing Computer Software– refers to a sophisticated, thoughtful approach to ad hoc testing. In the last decade, James Whittaker (at Florida Tech), Cem Kaner and I have worked to identify the skills and techniques of excellent exploratory testing. For one example of a fully defined and articulated process of exploratory testing, see the General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program. This document is publicly available on Microsoft’s web site, or on my site at http://www.satisfice.com/tools/procedure.pdf.

Balancing Exploratory Testing With Scripted Testing

To the extent that the next test we do is influenced by the result of the last test we did, we are doing exploratory testing. We become more exploratory when we can’t tell what tests should be run, in advance of the test cycle, or when we haven’t yet had the opportunity to create those tests. If we are running scripted tests, and new information comes to light that suggests a better test strategy, we may switch to an exploratory mode (as in the case of discovering a new failure that requires investigation). Conversely, we take a more scripted approach when there is little uncertainty about how we want to test, new tests are relatively unimportant, the need for efficiency and reliability in executing those tests is worth the effort of scripting, and when we are prepared to pay the cost of documenting and maintaining tests.

The results of exploratory testing aren’t necessarily radically different than those of scripted testing, and the two approaches to testing are fully compatible. Companies such as Nortel and Microsoft commonly use both approaches on the same project. Still there are many important differences between the two approaches.

Why Do Exploratory Testing?

Recurring themes in the management of an effective exploratory test cycle are tester, test strategy, test reporting and test mission. The scripted approach to testing attempts to mechanize the test process by taking test ideas out of a test designer’s head and putting them on paper. There’s a lot of value in that way of testing. But exploratory testers take the view that writing down test scripts and following them tends to disrupt the intellectual processes that make testers able to find important problems quickly. The more we can make testing intellectually rich and fluid, the more likely we will hit upon the right tests at the right time. That’s where the power of exploratory testing comes in: the richness of this process is only limited by the breadth and depth of our imagination and our emerging insights into the nature of the product under test. In the rapid testing classes at Satisfice, Inc., we have equipment that watches testers invent tests in real-time. When the instructor makes a new suggestion for what to test, or provides new information to the testers about the product, we observe and measure how a roomful of exploratory testers reacts to that information. Free from the encumbrance of pre-documentation, they immediately incorporate new ideas into their tests.

Scripting has its place. I can imagine testing situations where efficiency and repeatability are so important that we should script or automate them. For example, in the case where a test platform is only intermittently available, such as a client-server project where there are only a few configured servers available and they must be shared by testing and development. The logistics of such a situation may dictate that we script tests carefully in advance to get the most out of every second of limited test execution time. Exploratory testing is especially useful in complex testing situations, when little is known about the product, or as part of preparing a set of scripted tests. The basic rule is this: exploratory testing is called for any time the next test you should perform is not obvious, or when you want to go beyond the obvious. In my experience, that’s most of the time.

 

Hearing “No”

You’ve been working with a group of stakeholders to forge consensus on a project issue. Some want exactly what others don’t want, some refuse to reveal their private agendas, and some seem to change their goals almost at random. At times, you’ve felt that the group was close to agreement, only to be disrupted when someone on high changed the external constraints.

It’s been a little frustrating.

Work life sometimes delivers disappointments, often in the form of No. Some of us have difficulty hearing No or dealing with it once we do hear it. And, sometimes, No arrives so frequently that we exhaust our ability to cope with it.

In the tips that follow, I’ll use the term No-giver to refer to the person or people who said No and recipient to refer to the person or people receiving the No.

To understand the full range of choices recipients have, it’s useful to analyze the situation from three perspectives: within, between, and among.

Within describes the recipient’s internal response. Some of us conceal our internal responses from others and even from ourselves.

Between pertains to relationships. There are tight connections between the method of delivery, how it’s received, and past experiences shared by the No-giver and recipient.

Among includes connections in the larger context—the organization, its people, and their perceptions. When we consider stakeholders as a whole, we’re usually considering the larger context.

Suppose that you’re presenting to a general manager’s staff a plan proposed by IT. The plan doesn’t provide everything the general manager wanted by the desired dates, but it does deliver everything eventually. IT has explained why this is necessary, and it’s your task to present their case as a starting point for further negotiation. After you’ve clarified general management’s objections, you go back to IT to help them understand why adjustments to their proposal are needed. At times, you feel a lot like a high-level diplomat shuttling back and forth between the leaders of two warring countries who speak entirely different languages. (Throughout the article, you’ll find references to examples that are available in the StickyNotes.)

Within: The Self
No can arrive with a thud: “No can do” or “When pigs fly.” Or, it can land gently: “Not at this time”or “We’ve decided to go in a different direction.”

No can rock our world, or it can be a useful prod to make alternative plans. How we respond can make the difference between success and decades of pointless wandering.

Here are four techniques for enhancing your inner response to No.

Remove time pressure: While formulating a response, time pressure limits clear thinking. Even if an immediate Yes is needed, taking time to think does little harm. We usually do much better if we know in advance how much time we can spare before we must act.

If we enter the conversation knowing that we do have a little time to think, we’re more likely to respond creatively to No. (See Example 1)

Question your own analysis of the consequences: Failing to consider the consequences of No carefully enough makes receiving No difficult, and we’re more likely to respond to No emotionally or to reject it. Usually, that leads to trouble.

The pathway opened by No can sometimes be more desirable than the pathway opened by Yes. Examine it courageously. (Example 2)

Distinguish your request from your Self: Sometimes we experience No as the answer to the question “Am I a good person?” Rarely is this the issue. Usually, No is related more directly to what was requested.

Distinguishing your request from your Self provides protection from imagined attacks or criticism and helps you recognize them when they’re real. (Example 3)

Be prepared for No: When No comes as a total shock, hearing it is truly challenging. To avoid the shock, prepare by asking four simple questions: What if the answer is No? How long will it take us to find another approach? Is another approach actually impossible, or is the search for it simply distasteful? Is the organization harmed by No, or is it mostly my personal problem?

Answering such questions in advance helps you control emotional responses. (Example 4)

Between: Relationships
Relationships matter. If the recipient has long been a target of abuse by the No-giver, fear might be a likely response. If the No-giver and recipient have a history of constructive collaboration, honest discussion is likely to ensue. Here are five practices that help build or maintain constructive relationships with No-givers.

Seek to understand why: Our first response to No might be emotional: hurt, consternation, or anger. To recover a more serene state and move toward alternatives, seek to understand the No-giver’s view. Even though the No-giver might be unable or unwilling to be candid, our response to No is more effective if we understand the reasons for the No. (Example 5)

Take the broad view: To understand what led to No, apply the Johari Window. [1] The Open factors alone might not explain it, because some factors might be Hidden from the recipient, the No-giver might be Blind to other factors, or critical information might be Unknown to both. The Blind and Unknown quadrants of the window are most likely to produce convergence.

In responding, avoid the fundamental attribution error. Don’t attribute the No to the No-giver’s character defects without solid evidence. (Example 6)

Never threaten: One popular, threatening response to a subordinate’s No is “If you can’t do it, we’ll find someone who can.” A threatening response to a superior’s No is “Just remember I warned you.” Threats rarely produce conversions. At most, they produce compliance, and they almost always damage relationships.

Anger, fear, and feelings of powerlessness can lead to threats. When you feel the urge, clear thinking may be difficult. Recover control or suspend the conversation. (Example 7)

Prevent, rather than respond: Hearing No when it arrives is useful, but preventing it is even better. Here are four effective strategies:

• Yes is more likely if the relationship is strong. Keep it strong.
• Ask only for what’s likely to be granted.
• Prepare the decision-maker by providing whatever is needed for Yes.
• Create in the decision-maker an aversion to the consequences of No.

By working toward Yes in advance, you’ll learn more about why Yes might be appealing to the decider, and that can help you craft your request. (Example 8)

Ask whether the No-giver is empowered to say Yes: If we know the No-giver lacks the authority to say Yes, we can prepare our response to the No. If the No-giver has no choice, investing in prevention might be pointless. In determining whether No-givers have real choices, remember that their constraints might include factors external to the organization. (Example 9)

Among: The Larger Context
The larger context includes everything beyond yourself and your relationships: laws, regulations, procedures, and organizational politics.

Know whether there is an appeal path: Knowing that recourse is possible can help you remain centered when No arrives. Familiarity with the appeal path can help you frame the original request.

No-givers dislike being overruled. Construct your request so as to enhance the likelihood of a successful appeal. (Example 10)

Know whose No it is: Sometimes the No is directed at denying something to someone else or to another effort. In such cases, responses that leave the true target untouched may be ineffective. Seek alliance with the true target, or adjust your request to minimize entanglement with the target. (Example 11)

Understand reality: Sometimes the No is determined by the laws of nature, legal requirements, or financial constraints. Financial constraints are the least objective, but there are limits even there. A realistic perspective can help you to avoid asking for the impossible and to accept No when Yes is impossible. (Example 12)

Does No really break my world?: No might be the end of any plans that assumed Yes, but it usually isn’t the end of the world as we know it. To examine the No version of the world objectively, ask, “If I could still accomplish something I wanted, how would I do it now?” The essential question is “How can you re-point yourself toward something else you want?” (Example 13)

Final Words
Because reflection can facilitate learning, conduct a No retrospective after any especially difficult—or especially successful—incident. Reflect on what worked and what didn’t—within, between, and among—when you received a No. If you hesitate to reflect on this because such reflection might be a bit painful, that’s just your Self telling you No. But, you know how to deal with that, right?

About the Author
Rick Brenner, principal of Chaco Canyon Consulting, works with people needing state-of-the-art teamwork in problem-solving organizations producing complex products and with organizations that want stronger relationships among their people. His interests are personal and organizational effectiveness in abnormal situations, such as dramatic change, enterprise emergencies, and high-pressure projects. His articles and weekly newsletter are available at www.chacocanyon.com.

You’ve been working with a group of stakeholders to forge consensus on a project issue. Some want exactly what others don’t want, some refuse to reveal their private agendas, and some seem to change their goals almost at random. At times, you’ve felt that the group was close to agreement, only to be disrupted when someone on high changed the external constraints.

It’s been a little frustrating.

Work life sometimes delivers disappointments, often in the form of No. Some of us have difficulty hearing No or dealing with it once we do hear it. And, sometimes, No arrives so frequently that we exhaust our ability to cope with it.

In the tips that follow, I’ll use the term No-giver to refer to the person or people who said No and recipient to refer to the person or people receiving the No.

To understand the full range of choices recipients have, it’s useful to analyze the situation from three perspectives: within, between, and among.

Within describes the recipient’s internal response. Some of us conceal our internal responses from others and even from ourselves.

Between pertains to relationships. There are tight connections between the method of delivery, how it’s received, and past experiences shared by the No-giver and recipient.

Among includes connections in the larger context—the organization, its people, and their perceptions. When we consider stakeholders as a whole, we’re usually considering the larger context.

Suppose that you’re presenting to a general manager’s staff a plan proposed by IT. The plan doesn’t provide everything the general manager wanted by the desired dates, but it does deliver everything eventually. IT has explained why this is necessary, and it’s your task to present their case as a starting point for further negotiation. After you’ve clarified general management’s objections, you go back to IT to help them understand why adjustments to their proposal are needed. At times, you feel a lot like a high-level diplomat shuttling back and forth between the leaders of two warring countries who speak entirely different languages. (Throughout the article, you’ll find references to examples that are available in the StickyNotes.)

Within: The Self
No can arrive with a thud: “No can do” or “When pigs fly.” Or, it can land gently: “Not at this time”or “We’ve decided to go in a different direction.”

No can rock our world, or it can be a useful prod to make alternative plans. How we respond can make the difference between success and decades of pointless wandering.

Here are four techniques for enhancing your inner response to No.

Remove time pressure: While formulating a response, time pressure limits clear thinking. Even if an immediate Yes is needed, taking time to think does little harm. We usually do much better if we know in advance how much time we can spare before we must act.

If we enter the conversation knowing that we do have a little time to think, we’re more likely to respond creatively to No. (See Example 1)

Question your own analysis of the consequences: Failing to consider the consequences of No carefully enough makes receiving No difficult, and we’re more likely to respond to No emotionally or to reject it. Usually, that leads to trouble.

The pathway opened by No can sometimes be more desirable than the pathway opened by Yes. Examine it courageously. (Example 2)

Distinguish your request from your Self: Sometimes we experience No as the answer to the question “Am I a good person?” Rarely is this the issue. Usually, No is related more directly to what was requested.

Distinguishing your request from your Self provides protection from imagined attacks or criticism and helps you recognize them when they’re real. (Example 3)

Be prepared for No: When No comes as a total shock, hearing it is truly challenging. To avoid the shock, prepare by asking four simple questions: What if the answer is No? How long will it take us to find another approach? Is another approach actually impossible, or is the search for it simply distasteful? Is the organization harmed by No, or is it mostly my personal problem?

Answering such questions in advance helps you control emotional responses. (Example 4)

Between: Relationships
Relationships matter. If the recipient has long been a target of abuse by the No-giver, fear might be a likely response. If the No-giver and recipient have a history of constructive collaboration, honest discussion is likely to ensue. Here are five practices that help build or maintain constructive relationships with No-givers.

Seek to understand why: Our first response to No might be emotional: hurt, consternation, or anger. To recover a more serene state and move toward alternatives, seek to understand the No-giver’s view. Even though the No-giver might be unable or unwilling to be candid, our response to No is more effective if we understand the reasons for the No. (Example 5)

Take the broad view: To understand what led to No, apply the Johari Window. [1] The Open factors alone might not explain it, because some factors might be Hidden from the recipient, the No-giver might be Blind to other factors, or critical information might be Unknown to both. The Blind and Unknown quadrants of the window are most likely to produce convergence.

In responding, avoid the fundamental attribution error. Don’t attribute the No to the No-giver’s character defects without solid evidence. (Example 6)

Never threaten: One popular, threatening response to a subordinate’s No is “If you can’t do it, we’ll find someone who can.” A threatening response to a superior’s No is “Just remember I warned you.” Threats rarely produce conversions. At most, they produce compliance, and they almost always damage relationships.

Anger, fear, and feelings of powerlessness can lead to threats. When you feel the urge, clear thinking may be difficult. Recover control or suspend the conversation. (Example 7)

Prevent, rather than respond: Hearing No when it arrives is useful, but preventing it is even better. Here are four effective strategies:

• Yes is more likely if the relationship is strong. Keep it strong.
• Ask only for what’s likely to be granted.
• Prepare the decision-maker by providing whatever is needed for Yes.
• Create in the decision-maker an aversion to the consequences of No.

By working toward Yes in advance, you’ll learn more about why Yes might be appealing to the decider, and that can help you craft your request. (Example 8)

Ask whether the No-giver is empowered to say Yes: If we know the No-giver lacks the authority to say Yes, we can prepare our response to the No. If the No-giver has no choice, investing in prevention might be pointless. In determining whether No-givers have real choices, remember that their constraints might include factors external to the organization. (Example 9)

Among: The Larger Context
The larger context includes everything beyond yourself and your relationships: laws, regulations, procedures, and organizational politics.

Know whether there is an appeal path: Knowing that recourse is possible can help you remain centered when No arrives. Familiarity with the appeal path can help you frame the original request.

No-givers dislike being overruled. Construct your request so as to enhance the likelihood of a successful appeal. (Example 10)

Know whose No it is: Sometimes the No is directed at denying something to someone else or to another effort. In such cases, responses that leave the true target untouched may be ineffective. Seek alliance with the true target, or adjust your request to minimize entanglement with the target. (Example 11)

Understand reality: Sometimes the No is determined by the laws of nature, legal requirements, or financial constraints. Financial constraints are the least objective, but there are limits even there. A realistic perspective can help you to avoid asking for the impossible and to accept No when Yes is impossible. (Example 12)

Does No really break my world?: No might be the end of any plans that assumed Yes, but it usually isn’t the end of the world as we know it. To examine the No version of the world objectively, ask, “If I could still accomplish something I wanted, how would I do it now?” The essential question is “How can you re-point yourself toward something else you want?” (Example 13)

Final Words
Because reflection can facilitate learning, conduct a No retrospective after any especially difficult—or especially successful—incident. Reflect on what worked and what didn’t—within, between, and among—when you received a No. If you hesitate to reflect on this because such reflection might be a bit painful, that’s just your Self telling you No. But, you know how to deal with that, right?

About the Author
Rick Brenner, principal of Chaco Canyon Consulting, works with people needing state-of-the-art teamwork in problem-solving organizations producing complex products and with organizations that want stronger relationships among their people. His interests are personal and organizational effectiveness in abnormal situations, such as dramatic change, enterprise emergencies, and high-pressure projects.

 

AgitarOne

AgitarOne helps you work safer, better, and smarter as you develop and maintain Java applications. AgitarOne JUnit Generator creates thorough JUnit tests on your code, with 80% coverage out of the box! It helps find regressions and makes it safer and easier to improve code, reducing maintenance costs. AgitarOne Agitator helps you understand the behavior of your code as it is written, aiding the prevention of bugs and code complexity. AgitarOne is the best way to create, use, and manage the unit tests that you need to be truly agile.
 
Keywords: JUnit / JSF / Capture/Playback / Code Coverage / Dynamic Analysis / Process Management / Static Analysis / Unit Testing / Test Suite / Automated Test Generation / Integration Testing / Automatic Code Generation / Embedded Systems / Agile Development / Extreme Programming (XP) / Security Analysis / Eclipse / Continuous Integration / Code Rules / JavaServerFaces / Interactive Exploratory Testing
 
Target Platform : All

Language: Java

Hardware/Software Requirements: Not Listed
List Price: Not Listed
 
Tool URL: http://www.agitar.com/solutions/products/agitarone.html
Sales Contact Email: jpalmisano@agitar.com
Trial Available: Yes    Training Available: Yes
Vendor Information
Agitar Technologies, Inc.
41 Sharpe Drive
Cranston, RI  02920
USA
Phone: 401-572-3150    Fax: 401-572-3351
http://www.agitar.com

 

TestComplete (Automation testing tool)

TestComplete is an automated testing tool, developed by AutomatedQA which aims to allow testers to save time by creating software quality tests. Tests can be recorded, manually scripted or created manually with keyword operations and used for automated playback and error logging. TestComplete is used for testing many different application types including Web, Windows, WPF, Flash, .NET and Java. It automates front end UI/functional testing and back-end testing like database, and HTTP load testing.

 

Load Runner: System Resources Monitors Guidelines (Load test Tool)

The document provides the guidelines to access the Load Runner System Resources Monitors graphs and the required configuration on the testing machine. Over here, I am covering the two system resources for measurements.
1) Server Resources
2) Windows Resources

Server Resources Graph Access Guidelines:
To analyze the server resources monitors, you must have the HP sitescope software for loadrunner on your machine or server machine. Please follow the steps to have access server resources graphs:

1. Start the Load Runner Controller.
2. Define the load test scenario as per requirement in Design tab.
3. From the available graphs panel, add the windows or server resources graphs under system resources heading.
4. In Graphs View Panel, Right click with mouse and select ‘Add measurements’option.
5. Add the monitored machine server, platform, site scope server and platform information.
6. Logged on the application server machine.
7. Add the desired resources measurements to monitor.
8. Run the scenario in Run tab.
9. Analyze the results on Graph data.

Windows Resources Graph Access Guidelines:
Please follow the steps to have access to resources graphs:

1. Start the Load Runner Controller.
2. Define the load test scenario as per requirement in Design tab.
3. From the available graphs panel, add the windows resources under system resources graph heading.
4. In Graphs View Panel, Right click with mouse and select ‘Add measurements’option.
5. Add the machine and platform information.
6. Logged on the moniotred machine server.
7. Add the desired resources monitors to measure.
8. Run the scenario in Run tab.
9. Analyze the results on Graph data.

Configuration Requirements to access System Resources:
· Install the HP Sitescope on testing machine or server machine.
· Admin Rights on Application Server machine.
· Enable the system resources monitors on server machine to available remotely for performance test.

 

QA Wizard Pro 2009

Automated Functional and Regression Testing Tool 

Automated testing is a critical part of developing and deploying quality software applications. QA Wizard Pro automates the functional and regression testing of Web, Windows, and Java applications, helping your quality assurance team test more of an application in less time.

Test Multiple Technologies with One Tool

An automated testing tool is only useful if it can test the technologies you use to develop applications. Some automated testing tools exclusively test Web applications, while others are limited to Windows applications. Why spend twice the money and learn two tools when one can do the trick?

• Test Windows applications on Windows 2000, XP, 2003 Server, and Vista.
• Test Web applications through Internet Explorer (6.0, 7.0) and Firefox (2.x, 3.0) browsers.
• Use one application to automate the testing of applications implemented using popular languages and technologies like C#, VB.NET, C++, Win32, Qt, AJAX, ActiveX, JavaScript, HTML, Delphi, Java, and Infragistics Windows Forms controls.
• Test multilingual applications and Web sites from QA Wizard Pro’s Unicode-enabled environment.
• Ensure all application objects can be tested by using optical character recognition to read text embedded in graphics.

For having more knowledge on application, Please visit link: http://www.seapine.com/qawizard.html

For quick demo, please visit the link : http://www.seapine.com/flash/QAWPro2009GS/QAWPro2009GS.html

 

A worth reading Article on People Management

The Heart of the Argument
Getting Past Positions to the Sources of Disagreement

By Payson Hall

Abstract: “Arguments and conflicts are a normal part of working life, and good leaders must learn to handle professional disagreements diplomatically. In this week’s column, Payson Hall explains some productive approaches to negotiating among differing points of view.”

Let me begin with an unambiguous assertion: I’m not a therapist. I am a project manager and consultant who has served in a number of leadership and advisory capacities in the past thirty years. I cannot help you deal with crazy people, evil people, or family relationships—that’s beyond my pay grade and training. That said, I do have a lot of project experience dealing with reasonable people who had honest differences of opinion that escalated into serious conflict.

Differences of opinion are healthy and essential, but, beyond a point, conflict can get out of hand and be damaging to project morale and relationships among team members. This week, I hope to share a few insights and techniques I’ve picked up in my career that can improve your ability to work through disagreements or at least better uncover underlying issues.

Rule 1: Assume people are trying to do the best they can with the information they have available.
In my career I have run into only a handful of truly evil and selfish people who acted in their self-interest knowing that their actions were not in the best interests of their project, organization, or co-workers. In my experience, these people are extremely rare. If you think you are arguing with one, be careful. You are probably not dealing with an evil person. When someone appears to be acting maliciously or selfishly, there are several alternatives that may explain the behavior:

 

 

1. The person taking a seemingly destructive or oppositional position is unaware of some of the negative consequences of the course of action he is taking or advocating.
2. The people assigning negative consequences to a course of action are unaware of some of the positive aspects of the “negative” solution being proposed.

Suggested Action: Give the people advocating each alternative a chance to fully explain what they see as the advantages of their option. Don’t let the opposition interrupt. Write down the proposed advantages. When the advocates are finished, give the opposition and chance to ask clarifying questions. Repeat for each option. Insist that people treat each other with courtesy and respect.

Rule 2: When people disagree, it is often because they have different perspectives.
Kind of a “duh,” but this can also be profound insight if you give yourself permission to seek the basis of the different perspectives without prejudice. In my experience, the differences of perspective often come down to three key points:

1. Advocates of one position have different history than advocates of another. If your personal history is that converting to a relational database was a painful and error-prone experience, you will tend to think it is a bad idea. If my experience is that it was relatively easy and beneficial, I may advocate it. Someone else may have no personal experience but has heard good or bad stories from the media or other colleagues.
2. People may be working with different assumptions. People rarely have complete information about anything. In absence of complete information, people fill in the gaps by making assumptions. This isn’t bad as it is a natural process, but it can be a source of conflict when the assumptions are unspoken or unconscious and different from the assumptions of others. The challenge is that people are often unaware of the assumptions that they have made and treat them as if they are certain. If an organization has historically been extremely resistant to hiring consultants to address skill gaps, veterans of the organization may assume the same will be true in the future. They could possibly argue against a course of action that they know will require specialized skills because of concerns about the skill gaps, implicitly ruling out hiring specialized expertise without a second thought because of their assumptions.
3. People think they are talking about the same thing and disagreeing, but in fact they do not agree on some basic definitions and are talking past one another. This is a trap I have fallen into on more than one occasion.

Suggested Action: Take the time to talk about relevant differences in the history of people advocating different positions. This may help both explain the different positions and identify what was similar and what was unique among them. As you hear people disagreeing, be alert to assumptions that may underlie positions and try to identify and document them. A clever saying someone shared with me was “Everyone agreed, until we wrote it down.” If a certain word or phrase seems to be an important point of contention, it can be insightful to ask people what the word means to them and publicly document definitions.

Rule #3: Ask, don’t tell.
One of the best techniques I’ve learned for diffusing tensions when reasonable people are disagreeing is asking questions to understand why people believe what they believe. While this can open a can of worms if you are talking about religion or politics, most project issues should be less charged and not generate the same level of passion.

Suggested Actions:

1. Ask open-ended questions. Open-ended questions cannot be answered with a simple yes or no. Examples include:

• What were some of the negative consequences you have observed because of that action in your past?
• What might you have done to reduce the likelihood of that occurring?
• What might you have done to reduce the impact of that occurring?
• What might you have done to detect those problems sooner?

1. Listen to the answers. Sometimes it is tempting to argue with people while they try to explain. Argue later. As Stephen Covey says, “Seek first to understand, then to be understood.” Listen to what people say and how they say it, and try to identify the parts of their argument that seem to have the most energy. It’s OK to seek clarification, but don’t argue while you are in fact-finding mode.

Rule #4: Avoid framing decisions as one side “winning” and the other side “losing.”
No one likes to lose an argument. Most of us can think of times when we invested more energy in an argument than the outcome warranted because we were convinced we were right and didn’t want to lose—or didn’t want to give the opposition the satisfaction of winning. Leaders need to work toward the best decision for the project after careful deliberation and hope to get the team on board with the decision.

Suggested Actions:

1. Take the time to understand the different perspectives on the conflict and respect the different history that advocates of different positions bring. This can take a lot of the winning and losing out of decisions.
2. Sometimes the best decisions are informed by the reservations of the opposition, which might take the form of addressing their major concerns while going with another solution or acknowledging risks the opposition identifies and agreeing to monitor them as the solution is implemented.
3. When the final decision is made, ask everyone to explicitly agree to support the decision. This can help people consciously let go of some of the energy of the conflict and put it behind them.

Diplomacy is a critical and often ignored aspect of leadership. The ideas presented above won’t defuse or resolve every conflict, but they can help de-escalate and resolve some of them. When successful, these tactics can help unite rather than divide a team. Good luck, and happy arguing.

 

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!