Layer testing - How should I test data replication/update?

Question

I have a development background and now I'm starting with software QA. While building a solution developers often create code which is shared among different platforms/applications. One example is the popular create-update-delete funcionality which is used accross the system for everything.

While developing the developer makes sure that when the funcion/method "save" is called, data is really saved in the database. This I'd call a lower testing layer in this question.

While testing the application (for example in the browser or a mobile app), I particularly don't think that the tester should test if data is saved when selecting "Save" options. Instead, the tester should test if "save" funcion/method is called. This I'd call a higher testing layer.

The question(s) is(are): How is it possible to test these different layers?

Answer 1

First of all, it is understandable that a former developer might approach testing in terms of individually testable layers or sub-components. However, as a tester, if you do nothing else, you must verify that the finished product behaves correctly when exercised using whatever interfaces the end-user will use. Everything else is secondary to that -- perhaps important, but secondary. It is entirely possible to have perfectly functioning sub-components but a broken, buggy finished product. That is why people do integration testing.

There are different schools of thought on how to approach testing a layer in isolation. One approach is to use lots of debug-level logging to verify that things are called when they should be called. This can work well for initial development/debugging but is not ideal for automated or repetitive testing. Another approach is to use mocking: you write fake, hollowed-out versions of the lower-level components that allow you to test your layer without worrying about bugs in the underlying components. If you have been a developer for five years, you probably know about mocking, and if not, a Google search will lead you to as much detail as you need. Depending on the language, yet another approach might be to use Aspects, as in Aspect-Oriented Programming. Again, a Google search will give you lots of details about Aspects.

You will have to decide for yourself which approach is best suited to your circumstances.

Do not be surprised if you find that testing the UI in isolation, as you described in your question, is more awkward than testing lower-level layers.

Answer 2

As user246 says, your principal concern is the functionality of the user facing system. You need to consider the product as a whole, a tool to deliver some value to its users. Given your example of some 'save' function, ask yourself why am I able to save this information; does it update my public profile, impact the way an email is delivered, or change the behaviour of some other system. When you start thinking about the value, (the Why), the focus of your test becomes more clear. Ie, to test the save function, check the users profile has updated. If the save has no visible effect, why save at all?

Alternatively, I often find that developers need to add behaviour to apps to support effective testing. For instance, I have a function that adds users, but I am limited to one account, so I got the team to build a quick delete function to help test the app without needing to reset databases.