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
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.
If you dream of a
Software Quality Assurance,
you will have to choose the right things to learn. Learn the
learn the fundamentals and
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
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!
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.
Common software weak points:
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:
Radio buttons, Drop-down menus, or any other selection mechanism should be toyed with as though you were a halfway intelligent monkey.
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?
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.
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.
Create an interrupt while the program is not “expecting” one:
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?
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.