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?

  • Why do you think that tester should not test if data is saved when selecting "Save" option?
    – dzieciou
    Commented Sep 15, 2012 at 4:48
  • Taking an automated test done using Selenium for example. I'd be testing UI and page flow basically. Suppose I go to the registration page and save some data. Then for me sounds reasonable to go to the "search" page and search for the information entered. If I have to test database (if the data was really saved), I'd mix code which tests UI with code to test database. Consider now a change on the database (different DBMS, different table relationships, etc). As a consequence I have to change my UI test to adapt a lower layer change in my solution. For me this is a good reason or am I wrong? Commented Sep 15, 2012 at 4:57
  • @fabiopagoti, does "I'm starting with software QA" mean that you switched from a development job to a QA job, or does it mean that you are still a developer but are trying to pay more attention to how you test your own code? Also, is "the popular create-update-delete functionality" a body of code shared across multiple products, or are you just describing a functionality that every application implements on its own?
    – user246
    Commented Sep 15, 2012 at 16:30
  • @user246 I switched to a QA job after working 5 years with development. I meant that the create-update-delete is shared across multiple products but even if it was not shared, I'd still defend the concept of layer testing. Commented Sep 15, 2012 at 18:15

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.