Real Interview Script That Landed Us Every Job As QA Engineers

This is the exact script my colleagues and I use in every interview we ever had. We've received an offer 90% of the time following an interview! Our offers range from $95, all the way up to $145,000! These are absolutely amazing results that you too can replicate. Just memorize the below script, and tweak it based on your previous job positions. We guarantee that if you memorize this script and go to the interview, you will absolutely deliver with confidence!





It all starts with a simple question. "Describe your last project". At this point, you can either impress and amaze your interviewers or you can miserably fail. The key is to talk for at least 10 minutes about everything that you did at your last project. You crush the interviewers with your mastery and knowledge. You impress them with all of your skills. You take all questions out of their mouth and answer them yourself, through a methodical approach.

With the exact script below, there is no doubt in my mind that you will succeed. For companies with Waterfall methodology, we always landed any job that we want just by following this. Just make your own modifications based on your knowledge and skills.

Tell us something about the last project that you did?

My last project was working at Company X. I was part of a team of Testers, helping to develop the Application Name. The main goal of this project was to admit patients that are suffering from some disease and then do research on those patients. There is the CDR that contains all of the patients information. Demographics, doctor notes, medications, medical records and so on. The CDR is the repository and the main UI for all the clinically related tasks.  There a number of units that log in and exchange data in our app. Pharmacy, Surgery, Nursing, Nutrition, Home Monitoring, Medical Records, Customer Service are just a few of them. The CDR feeds all of the information into the second core of CRIS, the CDW.

I can tell you a little bit about the Front End of the application. It is a web based UI that allows access for authorized personnel only such as nurses, surgeons, techs, some receptionists and other personnel that have direct contact with the patient. These authorized personnel must have PIV cards, PINs, passwords and properly configured workstations with a card reader. Furthermore, access outside of is only allowed through a VPN. Also, before being able to access our application, the users must pass specific training as defined by the clients. Afterwards, the users are able to log-in to the application and perform the required functions such as logging orders, entering appointments, updating demographics, updating patient forms, submitting test results and much more.





I began the project in Planning Phase where I participated in meetings with client, product development team, developers, designers, DBA and so on. At the meetings, I contributed ideas about handling the project objectives and the resources required to carry them out.

After I received the requirements from the BA I participated in Requirements Validation and generated the Requirements Assessment Report. I check that the requirement is Specific, Measurable, Timely, Realistic, Attainable. After the requirements had their final approval, I logged them into QC so that the entire team can be on the same page.

At this point I began generating my test cases. To write my test cases, I mainly use an Excel Spreadsheet. I study the application as much as possible by reading the documentation such as Requirements and Use Cases.  I will create test cases for Positive Testing, Negative Testing, Boundary Testing, Backend Testing, End to End Testing, Cookie Testing, and Security Testing. After generating my Test Cases, I uploaded them to QC's Test Plan Module so that it would be located in a central repository for the entire team. At this point, I updated Requirements Traceability Matrix  to make sure that each business requirement and test case is linked correctly. I can do single requirement coverage or multiple requirement coverage, depending on the Test Case of course.

Exit criteria for this stage: Signed RTM



In the Design and Development Phase, I participated in the Critical Design Review, providing some feedback regarding GUI, user-friendliness, spelling and consistent formatting. I continued to create more Test Cases as necessary.



After I wrote all of my test cases, I performed Dry Runs to make sure that they were accurate. Also, I checked that the test data provided was there. I am a strong believer that every Tester should generate his own Test Data, hence, I always create the test data for my Test Cases. For example, most medical personnel need to be able to attach medical files with the patients' information. I generated different medical files such as .pdf, .doc, .xls, .gif and so on. Also, I created valid user names and passwords for positive testing, to ensure proper flow of the application. Generated invalid data for negative testing to check for the proper error messages. Also, I generated data for boundary testing to ensure that this data will not crash the back-end and that proper alerts are shown to the user.

Exit criteria: Test Cases, Test Data, Test Plan are ready




Entry Criteria: Application is stable enough for testing.

After I received the first build of the application, I performed Smoke Testing to make sure that all of the major functionalities were working and that the application was stable enough for further testing. For example, I went through and made sure that users can log in, that their authorization criteria is properly accepted, that their permissions were properly configured, that they can log out and so forth.

After the application was cleared for further testing, I began Functional Testing. I utilized QTP for my automation testing and performed manual testing whenever automation was not appropriate. I probably did about 70% automation. I used QTP to enhance each Test Script. I insert checkpoints to validate that expected results match the actual results. I utilized the Automation Object Model to keep the scripts running under the same conditions on any environment. I used synchronization points to keep QTP properly synced with the web application. I created functions to save time, decrease code size and increase efficiency for future Regression Testing. I use VB Script and Descriptive programming in most of my test scripts and depending on the application.

To record the defects, I utilize an excel spreadsheet to log my defects immediately upon their discovery. The reason I use an excel sheet is to limit the need for a large quantity of QC licenses and allow the sharing of a QC license amongst a large testing group. After validating that they are reproducible, I fill out all of the required fields such as Detected By, Detected On Date, Priority, Severity, Assigned To, Status, Description, Summary. I will include a screenshot of the error to prevent future misunderstanding. After that, it is very easy to export the defects into QC.

I spent a great deal of time performing Regression Testing on every bug that was opened, fixed and ready for retest using QTP and sometimes Manual testing. Also, I made sure to run my regression Tests before application was pushed to production to make sure that nothing major was broken. If I had a lot of Regression Tests to run, to be most efficient, I always do risk analysis on Regression Test Cases. For example, we had a bug that misdirected the pharmaceutical orders. They were supposed to go to the Pharmacy unit, but instead they ended up in Nutrition. This was a high-priority bug that required immediate retesting after it was fixed. As opposed to another bug that was not allowing access to a tutorial video, which is a much lower priority bug. I did testing on both, but I tested the higher priority bug first.



For this portion, we recommend you familiarize yourself with the automated framework. We have an amazing course that you can follow step by step! Watch the course here.


First, I generate a driver script. In here I create an excel object and link it to my excel workbook. With the Excel object, I can manipulate all of the data from my Excel Sheet. For example, I had a loop that would read data from Excel, enter it into our application, get the output of the application, compare it to another web applications numerical data, and it would record the results of all of that into the excel sheet. I also capture different error messages into my excel workbook.

Second, I create all of the data. I use an Excel sheet to keep track of the input, output and results. The data that I stored in there included information for all relevant personnel, PIV cards, PIN, passwords, patient ID's, patient names, DOB and so on. It's a lot of data.

Next, I create a function library where I store all of my general functions to read data from excel and convert it into QTP format. This involved reusable functions for navigating through objects, opening and closing browsers, sending emails, generating dates and so on. I always utilize the AOM to make sure that my script runs under the same conditions in any environment. If any failures occurred through our Regression Testing, emails were generated to the appropriate individuals so that we can handle the failures accordingly.

Fourth, I created environmental variables where I kept my variables and their values. For example, excel sheet name, excel sheet path, and any other variables that I defined in my QTP Script. This library is beneficial because on huge projects like this one, I just need to change values in one location and they will be changed in all of my scripts.

I would analyze the results of the runs performed by the DDF and then record any defects into Excel and then transfer them to QC. An example of a bug I captured was that the application would not allow the users to submit .pdf files, although this was specified in the requirements. This error was captured by the automation, I verified that this was a legitimate issue and passed it along to Development through QC.


For this portion, we recommend you familiarize yourself with the automated framework. We have an amazing course that you can follow step by step! Watch the course here.


  1. I use an Excel Sheet rather than QTP to form the test flow of the test cases.
  2. First, I developed the Test Data, Test Cases, Test Steps and Keywords in the Excel workbook. I use different worksheets in the same workbook for this process. Test Data will involve information regarding the Test such as login credentials test steps will have TC ID, step number, step name, input parameters, results and keyword will include TC ID, TC name, TC Description, Whether to Execute, Execution Results, Remarks. My Keywords spreadsheet will contain the Name of the keyword and its Description.
  3. All of the sheets are linked by a Test Case number
  4. Second, I create a function library with all of the keywords and the actions that they will do. I have my select case function here to search for the corresponding keyword. Also, I use it to generate a results sheet in Excel.
  5. Next, I create a driver script- a qtp script to start and finish automation, launch AOM, associate function library with the Test Case. My driver script will open the excel workbook, look in Test Cases sheet, read to see if a Test Case needs to be executed, then it will get the corresponding Test Case ID. It will go to the Test Steps sheet, find the corresponding Test Case ID and then read the Keyword associated with that Test Case ID. It will execute the associated Keyword Function from the function library.
  6. I do not use an Object Repository, but instead I use Descriptive Programming to identify all of my objects. But of course, this depends on the application
  7. Finally, I create an environmental variables file in XML format to store all of my variables and their corresponding values externally. This makes future modification of them much easier as a change in one file will change all of my Test Cases.


For this portion, we recommend you familiarize yourself with the automated framework. We have an amazing course that you can follow step by step! Watch the course here.


  1. I created the FUNCTION LIBRARY. In there I stored any necessary function required to run through my excel data. Functions for clicking buttons, reading and writing to and from excel, AOM and so forth.
  2. Then I created the DRIVER SCRIPT where I called all of my functions
  3. All of the input data was stored externally in Excel
  4. I utilized a different excel sheets for the test cases, test data, and keywords
  5. All of the results I stored in another excel sheet of the same workbook

Afterwards, I did UAT TESTING by acting as a User. I created scenarios, carried them out and recorded defects into QC. For example, I would open the CRIS front end and try to navigate through links, watch the tutorials, open documents and so forth. I would make sure that medical orders were properly received by all departments.

After all testing was done, I generated the Test Analysis Report with the assistance of QC. The TAR includes information regarding how many Test Cases were executed, how many passed, how many failed, how many were never executed, the number of defects found, defects fixed, defect status. The TAR is pretty much a summary of our testing efforts up until that point.

Exit Criteria: At our company, we have to have 100% execution rate and 96% Pass Rate of the Test cases. We cannot have any critical bugs in the non-passing Test Cases. Very minor bugs may be allowed.



I also created Video Tutorials on the usage of YOUR APPLICATION. In Implementation phase, I worked on the Release notes. Also, I did smoke testing to test all of the major functionalities. This was very important because an application that deals with human life cannot have the major functionalities failing.




I participate in weekly Status Meetings where I present my Status Reports. I log any bugs that we have into our Test Management tool and any show stoppers I forward directly to the developers. I am also teaching my team Automated Testing so that they may use it in the future for their next projects.

  • Chris Engler

    As a Test Manager, these are the things I look for when hiring someone. However, be careful to make sure that what you say during an interview is the truth. Nothing is worse than hiring someone because they aced an interview only to find that their actual skills do not meet expectations. Nobody wins in this scenario.

    • QTPtutorialnet

      Hey Chris! Thanks so much for your feedback. And I completely agree. I do not believe that anyone should embellish any details regarding their previous work experience. All I was suggesting was that this is what an excellent project description looks like. The level of detail, flow, and clarity is what should be conveyed based on personal experience.

      Does it seem like this is what we are suggesting? Let me know, if this is the case, I’ll definitely fix that.

      • Chris Engler

        I did not feel like you were suggesting being dishonest in anyway. I really liked your script… It is excellent! I wanted to add some perspective from a hiring manager.

        Long live!

Pin It on Pinterest

Clef two-factor authentication