| || |
Client/Server vs. Mainframe Testing
I've done a lot of testing in the telecommunications industry - almost exclusively applications on mainframes. Now I'm looking for an IT testing job. So I'm interested to learn more about considerations when testing client/server applications - probably a basic question for most of you.
For example, if I were to write a test plan, what additional tests would need to be included to properly test a client/server application. I would think performance and load testing would be done differently, and fault recovery testing would be more involved (e.g., if fault occurs on client side, or on server side).
Am I on the right track?
Any help to steer me in the right direction and supply some details would be appreciated!
Re: Client/Server vs. Mainframe Testing
Mainframe applications run on the mainframe and clients access the mainframe through a terminal emulator. The terminal emulator is the only software that needs to sit on the client machine. Changes to the software (COBOL, JCL, etc) are made on the mainframe and you don't need to worry about migrating them to the client. If it works through one terminal emulator it should work on them all.
Client/server architecture allows some of the processing to be done by the client. However, since there is code to ship to the client, you have to worry about the code being installed properly, working on their OS, playing well with the other applications on the desktop, security, and performance. Inside a company, you probably know the number of users, types of environments (OS, RAM, connection speed), so it's not as extensive as web testing, but it has more variables than mainframe testing. Also, while usability should not be ignored on mainframe applications, it seems to be more of an issue with client/server applications since they also generally have GUIs.
Mainframe developer - It worked fine for me. You must be using bad data.
Client/server developer - It worked fine on my machine. You must have the wrong client code.
Tim Van Tongeren