Narasimhan,
Take a closer look at Yves KERVADEC's approach. The issue here is that typically SCC1 is used to move transports which have not yet been closed. You can see the details of any transport via se01/se09/se10, whether open or closed, but my interpretation of your question is that the customer wants to know which transports have been imported into the unit test client (400) via SCC1, which transports have been brought in by the transport system (after they were closed), and which transports have not yet been sent to either the unit test or QA system (i.e. are still open).
My guess is that you are trying to track down why things work in the unit test client and not in the QA client. That is actually a different question with a different approach, but if that's what you really want to answer, go ahead and ask that question in a separate thread and you'll get a ton of techniques.
Back to the question you actually asked: By writing a query, you can get a list of transports which have been brought in to the unit test client via SCC1. You can also get this information from SCC1 --> Goto --> Log Display. Then click All Transport Requests and doubleclick on the client. This will give you the import log of your unit test client with date/time stamp. Analysis of that data indicates to me that perhaps you may want to look at CC0_RSCCPROT03_ALV, but I'm not an ABAPer so the previously mentioned tables are probably better.
Anyway, once you have a list of transports which have been imported, you can subtract out the ones that have been closed and transported downstream (and back into the unit test client.. your transport path does re-import the final version of the transports into the unit test client... right?). You can get that information from another query or you can get the list from STMS as suggested by Aparajit Banik.Then you'll have a list of transports which have been imported into the unit test client via SCC1 but have not yet been released and made it downstream. This will give you a "hit list" of transports which might be causing a mismatch between your unit test and QAS clients. You would then inspect them more closely with SE09/SE10/SE01 (I prefer se01, but different folks prefer different version of the transaction).
Again, there are better ways to deal with client mismatches, but I'm answering the question you asked in case I misunderstood the underlying subtext.
I hope this helps!
Best regards,
--Tom