Dear members,I need your advice. I am going for an interview to a front-middle-backoffice fin. software development company. Below is the job description: Along with solid knowledge of derivatives and underlying math models (I am OK with that) prospective tester should:"Write test plans and test specifications. Perform manual system testing. Test database upgrade scripts and batch-mode utilities.Perform regression testing. Perform automated test script coding usingautomated test tool. "Based on your experience, could you give me some advise (references) on the testing part.Thank you very much.Alec

<i>"Write test plans and test specifications. Perform manual system testing. Test database upgrade scripts and batch-mode utilities.Perform regression testing. Perform automated test script coding usingautomated test tool. "</i>Alec,Being a software house, they'll need you to understand the functionality of the software (the 'business rules' i.e. the analytics and their applications), as well as understand the software itself - its architecture/components and how they function together. The understanding of both the 'business rules' and the underlying software technology is necessary in order to test the product.To be able to develop an appropriate test plan, you need to understand what the users will be doing (the 'use cases') and why. You also need to know something of the architecture of the product to ensure that your test specifications cover all the underlying components.Manual testing usually means sitting down in front of the computer, and going through the steps a user would - as opposed to automated testing whereby you use testing scripts which will automatically feed data and parameters to the software to simulate users (not only do you want to feed typical data, you also want to feed extreme values, invalid data etc. to make sure the system responds according to plan). Typically testing tools can also automate interaction with the GUI (graphical user interface) i.e. clicking on buttons, selecting from drop-down lists etc.You'll be expected to actually code test scripts - the scripting language used will depend on the tool.You'll want to know about basic database administration/configuration: how to set-up a database, how to set-up clients, and have some understanding of the logic behind relational database (e.g. SQL Server, Oracle).'Regression Testing' generally refers to testing for the potential domino effect of updates/changes to the software system i.e. does a fix on component A have an unexpected effect on component B ? Does upgrade XYZ have any unexpected consequences on the behaviour of the system ?Some other terms you may want to look up are: Unit testing; Integration testing; Usability testing; Beta testing. It probably wouldn't hurt to look-up the 'UML' design process, as you will probably be dealing closely with developers and development specifications.Some background which may be of use:Think of the different roles of (1) Developers, (2) Technical Support, (3) Quality Assurance (QA a.k.a 'testing'), and (4) Documentation -these are 4 groups you'll find in any software house:- Developers have a complex product to develop. They don't often understand very much of the 'business rules' and often don't have time/desire to find-out. Their work eats-up most of the development time-line.- Technical writers need to document the 'final' product. They communicate to the end-users. However, they often don't see the 'final' product until the very last minute - as a result their job is one of extracting the information they need from whoever they can get their hands on (all other groups listed above) - writers typically end-up knowing the product better than anyone (at least initially, after which the support folks get to know it quite well too .- QA/Testing have a complex product to figure out and test. They have the final say as far as releasing a final product. Like writers, they are at the mercy of the developers as far as getting their hands on the software and the time needed to do their job. Creating a test plan is one thing - carrying it out as planned is another.- Technical Support: These folks will have to deal with the end-user issues that will arise when the product is out. They are a great source of information as far as what can be expected from users, and how users will react to missing/broken functionality. They end-up knowing the business pretty well. When the product is out and a critical technical issue comes up, they'll be coming to the testers and developers for assistance. 'The upgrade script we sent them doesn't work - did you test it under Windows XYZ (Service Pack N.0123)and SQL Server ABC release M.764 ? Can you help us recreate their environment ?'Oh yes, I forgot ... you also have (5) the product manager or marketing folks who dreamed-up the application in the first place ... don't know much about them ... in fact, nobody does. When I think of them I have visions of Brownian motion in a petri-dish Here's a link which will probably lead you to some good sources of information: SQATester.comGood luck with your interview!B.

PinnballWizard,Thank you very much for your time and effort.Wilmott forum is such a rare medium where you can have experts answering your questions.All the best.Alec