I really hate it when a software program I'm using crashes. It seems to always happen just before I'm about to save my work. I'll usually forgive the occasional crash, because it's hard to test for every scenario. Constant crashes, however, represent a lack of thorough testing on the part of the application's development team. It's inexcusable, especially considering the plethora of automated testing tools available on the market today.
Why We Test
Why test an application? After all, isn't that what users are for? I've actually heard that one before. We test your application before you see it for totally selfish reasons. You see, I don't want to look bad. We've all been in a demo session and witnessed a program crash. Talk about being on the hot seat. It's also unprofessional to provide a version of a program that is untested. It shows you really don't care what they think about you. It's insulting, to be frank.
What We Test
There are quite a few things to test for while developing software applications. Let me list a few of them below:
Unit Testing
Unit tests are designed to test specific portions of the source code. It's a way to validate and verify that the source code is fit for use. We run code scanners that actually tell us what percentage of the source code is covered by unit tests. If the number is too low the source code must be reworked.
Black Box Testing
Black Box testing occurs without knowledge of the internal structure of the system. The system is a black box. This can be helpful because the tester has no understanding of the system can and cannot do, so they are more likely to break it.
White Box Testing
As you may have guessed White Box testing is the exact opposite of Black Box testing. In this scenario, the tester has access to the internal structure of the system. This knowledge allows him or her to test for specific scenarios. For example, if the database field "DOB" is a date field, they may test to see what happens when a numeric value is entered.
Regression Testing
It's easy to fix one problem and cause another. That's where Regression testing comes in. Every time a change is made to the source code, we want to run a suite of tests against the system to guarantee we didn't break something by mistake. This happens within our system automatically each time a commit is made to the source code repository.
Functional Testing
With Functional Testing we want to test the application the same way it is experienced by the users. Using something like Selenium or QuickTest Professional, we can record a series of actions (i.e. inserting and deleting records, for example) and then have these tests run automatically (usually overnight). This way when the tester starts their day they can see exactly what problems occurred the day before.
As I hope you can see by now, software testing isn't a linear task to be performed once the coding is completed. We employ a test-driven approach. This means we test your application through the entire development process. Problems within the code have a way of cascading, meaning that one problem impacts another, which impacts yet another. The easiest, and least expensive time to deal with a problem is immediately after it is coded. It gets harder and more expensive as time elapses.
By the time the coding portion of your software project is completed, your application is 90% tested. And that saves us all a lot of stress. I don't like that kind of stress, and I doubt you do either.