You might be an application tester, and they might have asked you on occasion to "test security". But, are you really an application security tester?
The following three questions will help you to answer that question. For each question, the preferred answer is "yes".
1 Have you read the application's source code? You can do normal testing of an application without really knowing how the application is constructed or how it works, although if it is written badly enough, certain bugs may only be discoverable by someone who has read the source code. But with security testing, you are looking for things that are not meant to happen, and it is difficult to guess, a apriori, what those things might be, without a bit of help. Which is why you need to read the source code.
3 Do your test scripts have gaps in them? Normal testing is for positive functionality, i.e. things that are meant to happen. Security testing is for negative functionality, i.e. things that are not meant to happen. Here is an example of a normal test script (abbreviated somewhat):
It seems that if you want to be an application security tester, then you have to know as much as the developers do, if not more, about how the application has been developed. You have to be able to read source code. You have to understand how the client parts of the application communicate with the server parts of the application.
And given that developers generally get paid more than testers, it follows that application security testers will also get paid more.
If you are in charge of the application development budget, it may seem like madness to pay developer's rates for a testing role. But if you don't, then you won't really be testing application security. You'll just be pretending to test application security. (For some applications, "pretend security" might be enough. But if that's really the case for your application, have you documented that?)