Oracle: How to show all column names from a table

What script language should a Test engineer grasp?

A list of software testing types

How to solve QTP “Object not visible” issue.

I found an issue “Object not visible” during using QTP automation: Browser(“Arris – Work Assure”).Page(“Arris – Work Assure”).Frame(“main”).WebButton(“Copy”).Click

The clause above is meant to click “Copy” button, however, when it comes to this clause, always pop up “Object not visible” error. By searching from online, I have done the following steps:

1)  Got to Object Repository and find WebButton(“Copy”) object, then set its Type into button + Regular expression (Check this option), and add into Description properties, but error still happens.

2)  Got to Object Repository and find WebButton(“Copy”) object, then set the value of “visible” to True, and add it into Description properties, but error still happens.

3)  Found the following objects: Browser(“Arris – Work Assure”) ，Page(“Arris – Work Assure”) and Frame(“main”). Set all of them “visible” to be True, and add into Description properties, but error still happens.

Note that, all three steps above uses the following clauses to verify the value of Visible is true: msgbox Browser(“Arris – Work Assure”).Page(“Arris – Work Assure”).Frame(“main”).WebButton(“Copy”).getroproperty(“visible”)

4)  Use the “Highlight in application” tool in “Object Repository” to highlight the objects mentioned above, but error still happens.

5)  By further searching online, found that dual screens of computer affect QTP. I am using two monitors on my PC. Then I put QTP and IE browser running on the same monitor, the issue is resolved. Note that: Not only QTP and IE browser need to be run on the same screen, also need to run on the same screen as the Windows Start menu.

Note: This article is from www.joehe.com

How to setup FTP server on Windows 2003

How to setup FTP server on Windows 2003

1) Go to Control Panel -> Add or Remove Programs -> Add/Remove Windows Components

2) Double click Application Server, you will find the following screenshot, make sure select File Transfer Protocol (FTP) service and click OK.

3) It may ask you providing Installation disk, follow the steps prompted and complete the installation.
4) Go to Administrative Tools -> Internet Information Services (IIS) Manager, extend FTP Sites.

5) Right click Default FTP Site, then click properties to open the following screenshot.

6) Make sure “Allow anonymous connections” is unchecked, otherwise, everyone can connect to FTP server.

7) Click the “Home Directory” tab, you will see the following screenshots:

8)  Set up the “FTP site directory -> local path” to the directory that you want to put your shared files in, for example, c:\inetput\ftproot, in this case.
9)  Open a browser, then type “ftp:\\ your server IP address”, it need you type the username and password for your server, then you can download the files from there.

Note: Copied from http://www.joehe.com

What Makes a Good Software Tester?

In the movie Star Trek II: The Wrath of Khan, Spock says, “As a matter of cosmic history, it has always been easier to destroy than to create.” At first glance, it may appear that a software tester’s job would be easier than a programmer’s. Breaking code and finding bugs must surely be easier than writing the code in the first place. Surprisingly, it’s not. The methodical and disciplined approach to software testing that you’ll learn in this book requires the same hard work and dedication that programming does. It involves very similar skills, and although a software tester doesn’t necessarily need to be a full-fledged programmer, having that knowledge is a great benefit.

Today, most mature companies treat software testing as a technical engineering profession. They recognize that having trained software testers on their project teams and allowing them to apply their trade early in the development process allows them to build better quality software. Unfortunately, there are still a few companies that don’t appreciate the challenge of software testing and the value of well-done testing effort. In a free market society, these companies usually aren’t around for long because the customers speak with their wallets and choose not to buy their buggy products. A good test organization (or the lack of one) can make or break a company.

Here’s a list of traits that most software testers should have:

• They are explorers. Software testers aren’t afraid to venture into unknown situations. They love to get a new piece of software, install it on their PC, and see what happens.

• They are troubleshooters. Software testers are good at figuring out why something doesn’t work. They love puzzles.

• They are relentless. Software testers keep trying. They may see a bug that quickly vanishes or is difficult to re-create. Rather than dismiss it as a fluke, they will try every way possible to find it.

• They are creative. Testing the obvious isn’t sufficient for software testers. Their job is to think up creative and even off-the-wall approaches to find bugs.

• They are (mellowed) perfectionists. They strive for perfection, but they know when it becomes unattainable and they’re okay with getting as close as they can.

• They exercise good judgment. Software testers need to make decisions about what they will test, how long it will take, and if the problem they’re looking at is really a bug.

• They are tactful and diplomatic. Software testers are always the bearers of bad news. They have to tell the programmers that their baby is ugly. Good software testers know how to do so tactfully and professionally and know how to work with programmers who aren’t always tactful and diplomatic.

• They are persuasive. Bugs that testers find won’t always be viewed as severe enough to be fixed. Testers need to be good at making their points clear, demonstrating why the bug does indeed need to be fixed, and following through on making it happen.

What metrics are used for bug tracking?

Metrics that can be used for bug tracking include the followings: the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and the number of fixes per week. Metrics for bug tracking can be used to determine when to stop testing, for example, when bug rate falls below a certain level.

What Exactly Does a Software Tester Do?

You’ve now seen examples of really nasty bugs, you know what the definition of a bug is, and you know how costly they can be. By now it should be pretty evident what a tester’s goal is:

The goal of a software tester is to find bugs.

You may run across product teams who want their testers to simply confirm that the software works, not to find bugs. Reread the case study about the Mars Polar Lander, and you’ll see why this is the wrong approach. If you’re only testing things that should work and setting up your tests so they’ll pass, you will miss the things that don’t work. You will miss the bugs.

If you’re missing bugs, you’re costing your project and your company money. As a software tester you shouldn’t be content at just finding bugsyou should think about how to find them sooner in the development process, thus making them cheaper to fix.

The goal of a software tester is to find bugs and find them as early as possible.

But, finding bugs, even finding them early, isn’t enough. Remember the definition of a bug. You, the software tester, are the customer’s eyes, the first one to see the software. You speak for the customer and must seek perfection.

The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.

This final definition is very important. Commit it to memory and refer back to it as you learn the testing techniques discussed throughout the rest of this book.

Defect Report Template

A good defect report might have following sections.

· Headline

One line description of the defect. Remember, A good headline will always be clear, related to the defect and give some hints on how critical defect could be.

· Product

In most cases defect tracking system is used for more than one product. So specifying appropriate product and version is very important

· Component

Products are normally very complex, and can be divided into components. A defect report containing proper information about component can help managers in assigning it to appropriate person.

· Defect Type

Defect type could be, functionality, specification, regression, UI etc. This classification can be used to analyze how defects are distributed in the system.

· Priority

Priority is the impact of defect on business. This field gives an indication of the impact of this defect on business. In some organizations, testers do not specify priority, It is defined my manager or triage team members.

· Severity

Severity is the impact of the defect on the product. For example if you hit five keys together and your product crashes, it is a very severe defect. But its  priority is probably low because normally people might not hit five keys together. Now consider that the  company logo is not proper on the splash screen. From severity point of view it is not severe as it is not crashing application or blocking user from using the application. However, it is hig priority as it is affecting organization’s image.

· Environment

Proper information about your test execution environment should be present. For example, information about platform, databases, run times everything should be included in your defect report. This information helps development team in reproducing the defects.

· Steps

All the steps should be specified clearly. You should not assume that programmer will understand this. Programmer might be looking at your defect report when are not  around to explain. Your steps should be clear enough for a novice user to follow and reproduce or verify the defect .

· Attachments

Whatever additional information is needed for the defect, should also be attached. This additional information could be logs generated by system, application etc. It could be screen shots or any other thing that might help developers in reproducing the defects.

· Comments

If you have any additional comments on the defect, you should specify it clearly. For example if you observe/think that defect is related to some other defects filed in the same component with little variation. You should specify that.

How Bugs Affect Us—Consequences

Bug consequences range from mild to catastrophic. Consequences should be measured in human rather than machine terms because it is ultimately for humans that we write programs. If you answer the question, “What are the consequences of this bug?” in machine terms by saying, for example, “Bit so-and-so will be set instead of reset,” you’re avoiding responsibility for the bug. Although it may be difficult to do in the scope of a subroutine, programmers should try to measure the consequences of their bugs in human terms. Here are some consequences on a scale of one to ten:

1. Mild—The symptoms of the bug offend us aesthetically; a misspelled output or a misaligned printout.

2. Moderate—Outputs are misleading or redundant. The bug impacts the system’s performance.

3. Annoying—The system’s behavior, because of the bug, is dehumanizing. Names are truncated or arbitrarily modified. Bills for $0.00 are sent. Operators must use unnatural command sequences and must trick the system into a proper response for unusual bug-related cases.

4. Disturbing—It refuses to handle legitimate transactions. The automatic teller machine won’t give you money. My credit card is declared invalid.

5. Serious—It loses track of transactions: not just the transaction itself (your paycheck), but the fact that the transaction occurred. Accountability is lost.

6. Very Serious—Instead of losing your paycheck, the system credits it to another account or converts deposits into withdrawals. The bug causes the system to do the wrong transaction.

7. Extreme—The problems aren’t limited to a few users or to a few transaction types. They are frequent and arbitrary instead of sporadic or for unusual cases.

8. Intolerable—Long-term, unrecoverable corruption of the data base occurs and the corruption is not easily discovered. Serious consideration is given to shutting the system down.

9. Catastrophic—The decision to shut down is taken out of our hands because the system fails.

10. Infectious—What can be worse than a failed system? One that corrupts other systems even though it does not fail in itself; that erodes the social or physical environment; that melts nuclear reactors or starts wars; whose influence, because of malfunction, is far greater than expected; a system that kills.

Any of these consequences could follow from that wrong bit. Programming is a serious business, and testing is more serious still. It pays to have nightmares about undiscovered bugs once in a while (SHED80). When was the last time one of your bugs violated someone’s human rights?

Source:  Coriolis - Software Testing Technique 2Nd