Microsoft Interview Questions for Test Consulant

1. How would you give a testing estimate of Google Search functionality?
2. How do you ensure code coverage?
3. What are memory leaks?
4. Write an sql query to find differences between the contents of two tables (two tables with 3 row each are given)
5. How would you apply Boundary Value Analysis and Equivalence Partitioning for the range of numbers 1-10

Manual Testers are best at what they do!

OTC Credit/Equities Derivatives Workflow Testing Approach

In the evolving OTC derivatives industry, more and more Financial Institutions are inclined towards developing their own infrastructure to manage the OTC derivatives workflow to maintain the efficiency and accuracy of the workflows involved.

Here, in this article we will be discussing about testing the Credit Derivatives which constitutes more than 50 percent of market volume and Equity Derivatives which constitutes 5-10% of the total market volume.

Here is a typical structure of the Reconcilliation system X which is the system under analysis

Please note that DTCC is the Reconciliation and Confirmation system used for the Credit and Equity Derivatives. The Data is communicated to and fro to DTCC is in the form of xml's.

Test Approach 

There are a few workflows that are most commonly used in the Credit and Equities Derivatives -

1. New

2. Amend

3. Termination or Buyout

4. Increase

5. Exercise

6. Novations or Assignment

Each of these 6 workflows are very important because of their business importance. Now, we also have different products in the OTC Derivatives industry like CDS, LCDS, Index CDS, Equity Swap, Equity Index Swap etc and these 6 workflows need to be tested on each and and every product which would make the size of the test suite like the alps. To reduce the size, we need to follow the following approaches -

• Risk Based Testing
• Smart Testing where mix and match the workflows and scenarios because testing every workflow on every product is very difficult
• Automation by uploading bulk deals in DTCC and the upstream trading system for the deals to reconcille
• Automation using tools like QTP, Winrunner etc 

I will now take the example of a "New" or "Direct" workflow to explain the test cases required in the test suite -

• Party A books, Party B books. Deals matched
• Party A books, Party B books. Deals mismatched
• Party A books, Party B books. Deals mismatched, Party A modifies, Deals Match
• Party A books, Party B books. Deals mismatched, Party B modifies, Deals Match
• Party A books and cancels
• Party B books and cancels
• Party A books, Party B books. Deals mismatched, Party A cancels
• Party A books, Party B books. Deals mismatched, Party B cancels

Similarly we can also write these tese cases for other workflows as well

Gotchas

Since the data is communicated in this model in the form of xml's, there are mainly 2 kinds of code changes

1. Mapping of xml's

2. Coding of Workflows

Mostly the issues would surround the mapping changes as there are a lot of tags in the xml and the trick is to find the correct one, the issues around workflows would be incorrect handling of an event or unable to handle an event.

Defect Life Cycle

Explanation :
1. When anything thats a deviation from usual behavior/requirement occurs, a tester raises a defect which is in "Open" state. The tester should check in the available prod like environment if this defect is already existing in the production environment before marking the affected version.
2. If this issue is already present in production, then the first step is to check if this issue has already been reported in the previous releases, if not raise and mark the affected version as the current version and the production version in the defect details. Note that if a defect is already in production it may be deferred to the next release based upon the decision from business.
3. If this is not an existing issue in production, then its a new defect based on the code changes from the current release in which case the affected version can be marked as the Current relese version
4. After the tester has raised the defect and assigned to the release owner, the release owner would then assign this defect to the concerned developer who woul start the analysis of the defect
5. If in the analysis, the defect is found to be already reported then the defect is marked as duplicate and closed OR if the developer is unable to replicate the issue, then the developer should discuss it with the tester and if not reproducible then close it
6. After identifying the root cause of the defect, the developer starts fixing the code then the status of the defect is "In Development"
7. When issue is fixed and unit test cases passed, Developer should mark the defect as Development Complete and assign it back to the Release owner
8. The release owner would then check in the fix in the next build and after the deployment in the testing environment assigns it back to the tester
9. Tester would test the defect again based on all the positive and negative scenario around it
10. If the functionality is working fine after the fix, then the developer can mark the defect as closed OR if the defect is still persisting then again re-open the defect and assign it back to the developer

Top 10 Manual Testing Interview Questions

1. Explain Defect Life cycle

2. Different Functional testing techniques

3. Different testing methodologies

4. Why do we do negative testing?

5. The scenario of conflict where the developer doesn't agree that a bug is a bug

6. Explain Agile testing methodology

7. How do we link requirements, test plan, test case and defects in Quality Center or Test Director

8. What is the difference between Test Approach, Strategy and Plan

9. Explain some important QA processes

10. The scenario of playing smart where you have less time and more work

Database Migration Testing

Why Database Migration?

Database Migration in Investment Banks or any other place is done for the improvement of technology leading to a better performance. For example the same query fired on Sybase 15 database would take lesser time as compared to Sybase 12. The database migration can be between different versions of the same database for example Oracle 9i to Oracle 10g or migration to a different type of Database example Sybase to Oracle.

Test Approach for Database Migration Testing

The test approach for database testing is very crucial since in any investment bank the data is of utmost importance. If data is not migrated properly on the new database then the results could be disastrous. Hence, it is very important to use an approach which takes care of the existing data being migrated smoothly and the new data can be created like it was before migration.

Also, it is very important that the existing functionalities of the application do not change after the migration. So, the regression phase in database migration is also very important. If the migration is from one version of the database to another version of the same database, then running a sanity pack is enough generally but if the migration is to a different kind of database then running a regression pack is inevitable.

It is always advisable to do the database migration in parts in the following cases

• When the database is huge
• When the database migration is to a different type of database

The testing approach for Functional testing should take care of the following steps-

• Before the developers run the build for database migration, extract the data which is already present on the older database with all the details and verify the data after the database has been migrated
• After the database has been migrate, create the same sort of data that you were able to successfully create before the database migration
• Also try operations like amending and deletion after the database has been migrated on the new and old data.
• Also, try to perform all the operations which involves querying database