It feels like we've got another "I know too much so I'll throw around buzzwords because I don't know how to test" message.
There's nothing about an application that makes it "special" to test. As Yoda says, "Do or do not. There is no try."
In general "Domain" is often a B.S. term - a throwaway to try to make ignorant people look smart or to turn away a manager that wouldn't understand it if you explained it to them three times.
An application/module is simply an object to be tested. It has inputs and outputs and as a tester we exercise it. It doesn't matter if it's an account balance or a temperature, it's just a number.
The only thing that a "Domain" concept gets you are implicit rules as to reasonable values and response. "Implicit" is bad in testing. Document assumptions and test that those assumptions are met. It may be reasonable when testing a temperature that the range be between 140.0 Fahrenheit and -100.0 if you're measuring external air temperature on the earth but an account balance has a different range. Part of the specification of any module is "valid data" and this should be EXPLICITLY written rather than just being an "accepted value" as part of a "domain".
It's not up to test to decide what the values are, just to test that the component works in the documented ranges.
Now - it *IS* in testing's world to ask if a documented range is reasonable after understanding the domain. The temperature range I gave earlier was for earth - what if that component were being used on Mars? Different values and another round of testing.
I hope this helps a little. As you can see from KBMu and Rich W., your question seems WAY too vauge for us to have any meaningful conversation about it.
K.I.S.S. - Simple. Documented. Delivered. Assume nothing works, test and measure everything.
You need to understand the requirements, interpret any business jargon properly and then be able to write scenarios which "act like a customer". Well, little bit of Domain Knowledge will help but if you are a good tester that should not be an obstacle really.
<ul type="square">[*]www.testersdesk.com- The Online Tool Platform for Software Testers.[*]Building test engineering tools & training test engineers is what value-creation means to me in the race of Deterministic Technology.[/list]
Test specialist, it is my feeling this is an interview question; is that true?
I have tested both balance transfer and line of credit; neither is trivial and to understand them your place of business should be giving you training and providing you with the specifications for the applications to be tested. These forums would not be able to give you all of the information you would need in order to do your job. What some of our posters above are trying to tell you is that you can use basic test technique for these functions in the same way you would use them for any other function.
By the way, it is unusual to have both balance transfer and line of credit handled within one module.
You can check this with Test Credit Card No's. We have a similar approach where if there are some payment Gateway implemented for which you can get some Test credit card no's. On using this Test Credit Card No's you can test the application.