Software testing is a critical component of the software engineering process. It is an element of software quality assurance and can be described as a process of running a program in such a manner as to uncover as many errors as possible.

The process of software testing involves creating test cases to break "the system" but before this a software engineer must understand the basic principles that guide software testing.

Experts of the software testing industry have prescribed guidelines that form an excellent starting point for any tester may be a novice or an expert. Testers can keep them in mind while attempting any testing exercise.

1) Test according to the user requirements: Testing should be based on user requirements. This is to ensure that we uncover all defects that might cause the program or system to fail to meet the client's requirements.

2) Avoid redundant tests: Remember that our testing time and resources are limited.

3) Don’t try to test everything: It is virtually impossible to test everything. Reasons being exhaustive testing of all possible scenarios are just not feasible. This happens due to extremely large number of variables affecting the system and equally large number of paths a program flow can take.

4) Deploy effective resources for testing: This represents use of the most suitable tools, procedures and individuals to conduct the tests. The test team should use tools that they are confident and familiar with. Testing procedures should be clearly defined. Testing personnel may be a technical group of people independent of the developers.

5) Plan the tests early: Test planning should be done earlier during SDLC. This is because test planning can begin independently of the coding and as soon as the client requirements are set.

6) Begin the testing early: Try to begin the testing right from the moment, requirements analysis phase gets over to avoid defect migration.

7) Plan the tests for extreme conditions: Testing effort must be directed towards unexpected and invalid input along with valid inputs as well. Our endeavour is to ensure that our program produces correct messages when an invalid test is encountered and should generate correct results when the test is valid.

8) Identify & Isolate the problem areas: Remember that the chances of large number of defects in a module or group of modules are directly proportional to the number of errors already found.

9) Begin testing from the module level: The focus of testing should be concentrated on the smallest programming units first and then expand to other parts of the system.

10) Entrust the testing jobs to an independent agency: The individuals involved in the software development should not perform Testing. This is due to the simple reason that developers could psychologically tend to overlook weaknesses in their own creation. Generally the third party testing or dedicated test engineers prove to be more effective.

11) Assign testing to the best personnel: Remember that testing requires great deal of creativity and responsibility. Hence personnel with best track record must be entrusted the job of designing, implementing, and analysis of test cases, test data & the test results.

12) Don’t test with pessimism: Never begin your testing effort with an assumption that everything is in order & you are not likely to find any error in it.

13) Test with sole objective of finding maximum errors: Remember that the intent of testing is to execute the software application with a motive of uncovering errors & that too maximum in numbers.

14) Try not to change the software during test: While you are implementing the set of test cases designed for the purpose, try not to make changes during such period.

15) Importance of proper documentation: Document all the test cases & the results of testing as per software test standards & preferably it must be controlled by some configuration management system. We must document all our expectations of the test results even if such expectations are difficult to achieve.

16) Test with a destructive attitude: Testing is effective when done with a destructive attitude or an assumption that everything is wrong.

17) Try to test maximum possible requirements: Try to cover functional & non functional requirements of the software application under the scope of your testing.

18) Try to use Automation Tools: Try to support your testing by automated testing tools to the maximum possible extent.

19) Special care for testing critical Software: Full testing right from requirements phase till acceptance testing must be done for critical software applications.

20) Test Analysis: Quantitative assessment of tests & their results must be done thoroughly.

If you are looking for a job, it can often be difficult to understand what the heck they mean by some of the terms used in a Job Description.

From http://fun.varadinum.com/what-job-ads-really-mean.html, here's one take on what they say, and what they mean.

“Competitive Salary”

We remain competitive by paying you less than our competition.

“Join our fast-paced company”

We have no time to train you.

“Casual work atmosphere”

We don’t pay enough to expect that you will dress up; a couple of the real daring guys wear earrings.

“Some overtime required”

Some every night and some every weekend.

“Duties will vary”

Anyone in the office can boss you around.

“Must have an eye for detail”

We have no quality assurance.

“Career-minded”

Female applicants must be childless (and remain that way).

“Apply in person”

If you’re old, fat or ugly you’ll be told that the position has been filled.

“Seeking candidates with a wide variety of experience”

You’ll need it to replace the three people who just quit.

“Problem-solving skills a must”

You’re walking into perpetual chaos.

“Requires team leadership skills”

You’ll have the responsibilities of a manager, without the pay or respect.

“Good communication skills”

Management communicates, you listen, figure out what they want and do it.

While waiting on hold the with my satellite service provider to complain about the quality of the service I received I had to laugh at the recorded message that was repeated over and over. A friendly computerized voice would interrupt my elevator hold music every couple minutes to say “To ensure quality, this call may be recorded”. Each time I heard it, I laughed.

If only it were that easy! If only a simple recording about my complaints could ensure that the quality I received was improved. If only my recorded call about my satellite no longer working and the terrible service I received as a result, complete with a INR 400.00 charge for something the company didn’t do correctly the first time could ensure greater quality. And perhaps the recording of my call could ensure quality for everyone else in any other situation as well! Wow, that’s pretty powerful.
This message got me thinking about a statement saying that a person, process, action, or thing can ‘ensure quality’ is a lofty statement to make. Those are some big shoes to fill! Ensuring quality isn’t something that should be taken on lightly. For starters quality is a difficult thing to define and it is probably different for every person. Quality for me, may not cut it for you and vice versa. Second, unless we have control over every aspect of the thing we are trying to ensure quality for, if we can manipulate it and change it where it needs to at any point in time we really cannot ensure anything.
So when my satellite provider says that are going to use my recorded call to “ensure quality” they really aren’t. What they really mean is, they are going to review the tape of the conversation I had with one of their employees . They may listen for ways they can improve, listen for mistakes that were made, and listen for ways to change what they do. They may listen because they care about improving their customer satisfaction. They may listen because they want to use my recorded call as a training example, good or bad, for new employees. They may listen because they want to find ways to make more (or spend less) money. They are listening to my recorded call for many of the same reasons we test software.

We test to find ways we can improve, look for mistakes we have made, find ways to change what we do, find ways to improve our customers satisfaction, use what we find as training examples, good or bad, and find ways to make more (or spend less) money. We test to gather information about our product, about what we are doing, about how we are doing it, etc. We don’t test to ensure quality.

So the next time I have trouble again and call for support, I will once again laugh when I hear the recorded message. Although ‘ensuring quality’ isn’t the real reason why they are recording my call, I do get the point. To repeat “To ensure we improve, get better at what we do, make more money, train our employees, and keep you happy when we care to, this call may be recorded” is certainly wordy.  However, I hope when they say they are “ensuring quality”, they also understand they really aren’t.

Congratulations, you just found a bug in an office supply commerce application!  It appears that any time you submit an order with more than one line item; an “object reference not found” error is thrown.  Cool!  Here are the repro steps you logged in the bug report:

1. Create a new order.
2. Add Pencils to the new order.
3. Add Pens to the new order.
4. Select UPS for shipping method.
5. Select Credit Card for payment method.
6. Submit the new order.

Expected Result: No errors are thrown.

Actual Results: “Object reference not found” error is thrown.

Those are pretty solid repro steps.  Every time one performs them, the Actual Results occur.  Nevertheless, do you see any problems with the above repro steps?

Hmmmmm….

What if you depend on just the repro steps to understand the bug?

Does this bug only repro if pens and pencils are ordered, if the UPS shipping method is selected, if the Credit Card payment method is selected?

Those details capture what the tester did, but might they mislead?  Anytime you add specific data to your repro steps, you may be implying, to someone, that said data is required to repro the bug (e.g., perhaps the “pens” data in our DB is bad).  A more skilled tester may log the bug like this:

1. Create a new order.
2. Add at least two line items to the new order.
3. Select a shipping method.
4. Select a payment method.
5. Submit the new order.

Okay, that seems considerably better to me.  However, we can still improve it.  Is it reasonable to assume the programmers, testers, and business analysts on our project team know how to submit an order?  Do they already understand that in order to submit an order, one must specify shipping and payment methods?  Yes!

Thus, an even more skilled tester may end up with these repro steps:

1. Create a new order.
2. Add at least two line items to the new order.
3. Submit the new order.

There is nothing extra to cloud our interpretation.  The steps look so minimal and easy, anyone could do them!  Now that’s a set of repro steps we can be proud of.