Many software developers have no clue about how testing is actually done. They write the code, make sure it builds, and hand it over to testers or QA (Quality Assurance). The testers put the application through a series of test and give the developers a report on the issues and bugs found.

Wouldn’t it be much better if you, the developer, can also test your own code? Think about how much time you can save. Being able to test your own code means you are delivering more robust and quality code. Having experience in testing also helps you look at and write code in a different way. In a good way, like not just implementing features and fixing bugs, but to make sure the software you write is working correctly and as intended.

Why We Do Testing

The purpose of testing is about reducing risk. The goal is to reduce risk by actively finding and eliminating problems, which would greatly impact the customer’s experience in using the software. It is not about finding bugs or to make the software better, but that is a secondary bonus from the testing process — in most cases.

Why is testing not about finding defects and bugs you might be wondering. That’s because it is not possible for you to find all the bugs or defects in a piece of software. It is also not possible to test for every possible input into the software. This applies to non-trivial applications and most software do end up in this category.

How to Achieve Risk Reduction

Usually, risk reduction is achieved by first prioritizing what parts of the software are likely to have the biggest impact (risk) on the customers. Once you determined those parts, you decide on a set of tests to run, which verifies the desired functionality in that part. Whenever the actual functionality differs from the desired functionality it is log as a defect. The list of defects will then be prioritized based on severity (relative to risk).

Common Types of Testing

The development world has many concepts and methodologies for creating software. Similarly, there are many ways to think about testing and it is changing all the time. There are many kinds of testing, but as a developer, you don’t need to know them all. You should know some of the more common ones, so you know what someone is talking about. Here is a non-exhaustive list of different testing methods.

Black Box Testing

Black box testing is testing as if the software itself was a black box. Your only concern is the inputs and outputs. You don’t care about the process that happens in between.

You don’t know how things are implemented, except that for a given set of inputs to the software, a given set of outputs are expected.

Black box testing is a common way of testing because it is unbiased. It either passes or fail.

White Box Testing

White box testing is the opposite of black box testing. You have some idea of what is going on in the software. You might have some understanding of the internals of the system and might even have access to the source code.

For example, consider a piece of software that does some complex computation. In the source code, there are two cases. For values larger than a certain amount a different algorithm runs. Seeing this you can create tests that target both scenarios. In black box testing, you would not know that there are different cases.

Acceptance Testing

Acceptance testing is when you have tests to test the actual requirements or expectations of the customer, and another set of tests that run against the entire system. You are not testing one part of the system. This type of testing is usually for testing the functionality of the entire system or the usability, or both.

Functional Testing

Functional testing refers to testing activities where what is being tested is the actual functionality of the system. This might seem obvious, but there are all kinds of things you can test that is not related to functionality, like performance, security, scalability, usability, and etcetera.

So, functional testing is where you are really concerned with the system doing what it is supposed to do from a functional perspective only. For example, if I push this button, do I get the expected output? I don’t care how long it takes to complete. I don’t care if some graphical glitches happen. All I care about is if I get the result I expected.

Automated Testing

Automated testing is a broad term that takes on many forms and has many definitions. So, a general definition for automated testing is any testing where the execution of the test and the verification of the results is automated.

For example, you can automate the testing of an API by writing scripts to call the API with various data as input and then check the output. Automate testing for a web application might include running multiple scripts which open a web page, input some values, clicking some buttons, and then checking the results.

Regression Testing

Regression testing is testing done to verify that the system still works the way it did before. This form of testing is important because it ensures that adding a new feature does not break existing ones. In an Agile development environment, which is common nowadays, new features are constantly being added in short time span and each has a chance to break existing features.

So, you might think, “Wouldn’t automated tests be considered regression tests?”. Well, for the most part, most automated tests are regression tests. After all, the purpose of automating a test is so it can run more than once without manually repeating it.

The Developer’s Role in Testing

So where do you, the developer, fit in with all this testing? As the one writing code, you should be more concerned with quality than anyone else. You can’t have a mindset that testers will find all the bugs in your code. In smaller companies, there might not even be a tester — oh the horror!

Instead, you should make it your responsibility to find and fix the bugs before your code goes into the testing phase. The further along in development a bug is found, the more expensive it is to fix. If you test your own code and find a bug, it may take you an extra hour to fix. Now, if you didn’t test your code and that bug made it to QA, that bug will get log and probably get assign to you to fix anyways. In either case, you will end up fixing that bug, except one has a longer turnaround time — could take days.

You won’t catch every problem, but if you can catch some problems that would otherwise make it to QA, it will save everyone a lot of time in the long run.

I hope you found this post helpful. If you found this post helpful, share it with others so they can benefit too.

What are your experiences with testing? Did any of the scenarios described in this post happen to you?

To stay in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.