Learn Software Testing

If you want to play computer games for a living...you you first better learn software testing.

If you want to land a job in the software industry...you better know How to Succeed

If you want to learn software testing so that you can have a long and lucrative career in the tech industry, you should start at the beginning with the basics. You should know what software testing entails, how it works, how it can be most effective, and why often it is not.

Software Testing Basics: Thing One

Thing One: Testing Is Simple! Period. End-of-story. S-I-M-P-L-E. Just so we are crystal clear: Testing Is Simple.

Anyone who tries to tell you differently doesn’t know what they are talking about and may just be in the wrong line of work. Testing is simple. Always remember that. Any testing that you perform that is NOT simple is at best potentially inaccurate – and at worst wrong.

When testing software, you main goal is to clearly establish whether or not the pre-defined behavior that is expected of the software occurs when and how it is supposed to. In short: Does the software do what it should? Does the software do anything that it shouldn’t? That’s it. That’s how it starts. And that…is simple.

Software Testing Basics: Thing Two

Thing Two: Learn and Adapt. Let’s face it, the reason that testers are always needed is that new technology continues to be developed. Do you actually think that’s going to stop? EVER?!? I don’t think so either. So, in order to keep up, you must always be learning and remain adaptable.

As the software changes, so do the specific demands on testing it. In order to keep up with these demands you must be able to learn the new technology as it is created and then adapt your techniques so that you can test it most effectively.

Software Testing Basics: Thing Three

Thing Three: You must be able to communicate clearly and accurately. When you are testing software and you find a bug (an issue, a defect, a bad result, etc.) you must be able to share your information in such a way that anyone can understand it.

When you do this, then the bug can be fixed and your project can move forward. If you don’t, then you create more work for others, waste time that people are paying you for, and are seen as a drain on the project.

You must know the fundamentals if you plan to be a QA Tester. If you want a software testing job, learn the fundamentals.

If you dream of a career in Software Quality Assurance, you will have to choose the right things to learn. Learn the terminology, learn the fundamentals and Choose Success!

Now that I’ve said all that, I will attempt to give you a primer on how to find bugs. Hopefully this will give you some solid ground to understand how to find weaknesses in any software you test. Think of this as your primer to learn software testing.

If after reading this, you think I know what I'm talking about, then do yourself a favor and take the training offered on this site seriously and learn software testing. Either sign up for a course (and get past the orientation courses into the meat of the training) or go get yourself a copy of my book.

If you want to learn software testing, if you want to control your future in the software testing industry, then take action and get yourself the training you need.

How to Find Bugs: A Primer

Always remember: Testing should be simple.

If you want to learn software testing, you must understand that testing can be very product-specific. Other than that, becoming a QA tester that understands his/her craft is an experiential journey that each professional really must take on their own.

Here are some techniques to get you started. Learn the principles behind each of these tests and you will be on your way understanding fundamentals.

Following the Script

As a tester, much of the time that you are testing you will have test cases to execute. Your job at first is just to follow the instructions in the test case and compare the outcome you witness with the expected outcome listed in the test suite. These two results should be the same.

The product design and technical specification documents establish a product’s requirements. To make sure that each and every requirement behaves as intended, test cases are written to cover each requirement. The outcome of the test cases is then tracked so that the QA team knows if and when all requirements have been tested.

Each test case you execute should give you exact steps to follow. By following the stated steps, you will be verifying the behavior of a feature requirement – or at least one piece of it.

That is why I say that testing is simple – all you have to do is follow directions. This is crucial if you want to learn software testing, you must be able to follow directions.

Unfortunately this assumes that the test cases you have are given have been written clearly. This is not always the case.

If the test cases you are trying to execute are not crystal clear, make sure you receive clarification as to what the intended testing is to cover. You can either update the test case yourself (so it is easier to follow in the future) or get it on the to-do list of whoever is responsible for that.

Until you learn software testing well enough to compensate for poor project set up, the test cases must be clear and accurate or your testing will suffer.

You may not test the right thing; you may miss requirements that need to be validated – in short, get your tests accurate or risk participating in bad QA.

While executing test cases, take each one a step at a time. Perform each step of each test with diligence and attention. Make sure you aware of the outcome of every move you make. Compare the results you witness with the expected results as stated in each test case. Anytime there is not a match, you have found a bug!

But what if you don’t have a test case in front of you? What if you have been tasked with performing exploratory/ad-hoc/real-world/end-user testing? How will you be able to find bugs?

Follow me…to learn software testing!

Low-Hanging Fruit

Whenever you have an opportunity to freelance, you should jump at the chance! This is a fantastic opportunity to further learn software testing.

There are many reasons that you would have this opportunity. The reason you have this option, however, is not what important. What is important is what you do with it. You should see it as what it is - your best chance to hone your skills. This is where you really learn software testing.

Where should you begin your exploratory testing? How can you make an impression on your boss and show that you have a knack for finding weaknesses in software? Being able to quickly and effectively identify where a product is weak, is really the art of QA testing.

Improving your skill and developing your craft take time. But when you become adept at the art of testing, software you have never touched before will bend to your will. Programs will stand in line to spring open and share their secrets with you. You will have more bugs than you can possibly log in a single day. You will be a known assassin and you will be in demand.

But, until you develop the feel yourself, here are some ideas of where to look.

Common software weak points:

  • Data Capture
  • Selectors
  • ReadMe.txt
  • Transitions
  • Interrrupts
  • Defaults
  • Un-Install

Data Capture
Any time a program or web page have data capture fields, you have a chance to exploit them. Data captured goes into databases for future use so if you can affect the data capture field, you may be able to affect the database.

Most data entry fields allow you to enter whatever you want. Their rule checking happens upon submission. Anytime you can get around the rules that the database on the back end needs enforced so that it can do its job, you can put the whole system in jeopardy. So here are some things to try:

  • How many characters can you type in a field?
    • This is usually limited to 256 or less. So, if they limit the amount you can type in, then go find a copy of War and Peace and see if you can Copy and Paste. Often you can paste more into a field than you can type
  • Which characters can you enter by typing?
    • Again this is often limited, so go back to Copy and Paste. Now which characters can you enter into the field?
  • If there are any rules stated next to the field (minimum number of characters, etc.) see if they are being enforced
  • If there are multiple data capture/entry fields, use the [Tab] key to navigate from one to the next. See if they go from one to the next in a logical order

Much like data capture/entry fields, selectors can be very weak in the early stages of development. This is often due to the development team using non-standard, basic “rules” that they expect to work. It is thought to be such mundane work, that this is often a rich area for bugs.

Radio buttons, Drop-down menus, or any other selection mechanism should be toyed with as though you were a halfway intelligent monkey.

  • Left and right mouse click very quickly on a selection
  • Double-click a selection
  • Quickly one and then another selection
  • Click and drag prior to selection
  • Select any blank line item option

The other thing to check is what happens if you don’t select any of the available options. Are there defaults selected already? Are the defaults functional even if you don’t select them?

R.T.F.M. = Read the Manual (Don’t ask what the “F” stands for)

Part of your job as a QA tester is to ensure that the information made available to the user is accurate. It is very common to use an old ReadMe.txt file on a new product or updated product version. Often the ReadMe is updated very late in the project, but it will have to be (or should be) updated prior to launch.

The ReadMe is often a great place to continue to learn software testing. You will find information about the product that you may not have known!

Get into the ReadMe immediately and see if it is accurate. You can often find several bugs to log just in outdated information, information that wasn’t updated prior to the previous release, or even copyrights. In the real world, not many users actually R.T.F.M., but if you have a ReadMe that is shipping with your product, then it had better be accurate.

Programs are often very weak during any and all transitions. Transitions from one screen to another, from one scene to another, from one user state to another, or from one game level or state to another. Make selections that can engage the program during a transition.

This means, make a selection (whether or not you can see it onscreen) while a transition is occurring. Even if you can’t see the selection you are making, click on the location of where selector would be normally.

This is a classic step in your ability to learn software testing. Just as stated above with transitions, interrupting the program while it is trying to do something can often give it problems. This is especially true in the earlier stages of development (hopefully this becomes less common later in the project).

Create an interrupt while the program is not “expecting” one:

  • While it is loading
  • While reading information
  • While writing information
    • One example would be to unplug a memory stick (flash drive, USB drive) from a computer while it is reading/writing – bad things happen. Apply this test to devices and memory reads/writes other than external USB, that is only an example so you understand the principle

Verify that a program’s default selections function properly if you don’t select anything. If you really want to learn software testing, play with default/non-default settings. You will learn more about testing and about software and traditionally standard weaknesses all at the same time.

Another issue is to install to a non-default location. There are thousands of programs on the market right now that do not function properly if they are installed anywhere other than the default (sad, but true).

Even if the main body of the program works, check the peripherals. Do the installed shortcuts recognize that the program was installed to a non-default location or is the shortcut path hard-coded? Does the program save information to a non-default location?

UnInstall the program and see if it really does “Un-Install”. Upon completion of the Un-Installation, does the program inform the user that everything has been uninstalled (or does the program imply it)? Another major area of knowledge if you want to learn software testing is to master the ins-and-outs of Installation/Un-Installation.

If, upon completion, the program tells the user what was not removed – OR – that not everything was removed and perhaps tells the user what was left and/or where, then that is ok (technically – although it is always feels like amateur hour to me). But if the user is led to believe that everything has been uninstalled, this should be true.

Often, however, a program will tell the user (or strongly imply) that everything has been removed when this is simply not the case. This can get the company a great deal of bad press depending on what is left behind. News travels fast on the internet.

Run a standard search on all hard drives for the name of the program, shortcuts, etc., See what is left. Search for directories that the program installs; save information, preferences, etc.

If you are on a PC you can also run “regedit” and search the registry for program remnants (from the [Start] menu, select “Run” – and then type “regedit” without the quotes, then select [Ok] or press [Enter] – your registry will open. F3 will launch search function). If a program tells the user all has been removed, then all really should be removed.

And don’t forget to combine Non-Default installation and full Un-Installation. Make sure a program can remove itself after installing somewhere it is not expected to. Until you can perform Install/Uninstall tests in your sleep, you still have much work to do to learn software testing.

And You’re Off!

Each of the tests listed above embodies one (or more) principles of software quality assurance testing. Your task is to learn the tests to perform. Execute each one and get a feel for what they affect and for the outcome. When you do this, you will learn software testing.

By practicing tests that are known to reveal bugs is a very quick way to get a feel for and learn software testing. Execute effective tests and learn what they do. This is your shortcut to understanding the art of QA testing.

I'd take the awe of understanding over the awe of ignorance any day.
~Douglas Adams

Return from Learn Software Testing to Successful Quality Assurance Home

E-mail Address
First Name (optional)

Don't worry — your e-mail address is totally secure.
I promise to use it only to send you SQA the Right Way!.