Telephonic Interview tips

  • Always keep the phone fully charged before the telephonic interview
  • Make sure you are in a quite area / room where the network coverage is full
  • Never give interview on the speakerphone, it creates bad impression on the interviewer since the sound tends to echo when you speak via speaker on and the clarity is also not great
  • Keep your phone next to you before the interview starts as you do not miss the call
  • Always give telephonic interview with a smile, even though the other person cannot see you, talking with a smile gives totally a different and pleasant tone when you speak
  • Speak slowly and confidently
  • Always let the interviewer finish the question before you start answering, I know it is tempting to answer when you know it very well but keep those temptation away for a while and let the interviewer finish completely before you start answering
  • Always greet the interviewer first and thank him or her for taking the time out for the interview
  • Additional tips
  • It is a good idea to give the interview standing as the person is more attentive while standing up
  • Never fidget with papers, keyboard  while on a telephonic interview
  • Use landline if possible
  • Always  answer the phone with your name
  • Never talk about money / salary
  • Be prepared

SDLC -Waterfall and STLC

SDLC – Software Development life cycle

What does Software Development Life Cycle (SDLC) mean?

The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process. SDLC is a structure followed by a development team within the software organization. It consists of a detailed plan describing how to develop, maintain and replace specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

SDLC consists of following activities:

Planning: The most important parts of software development, requirement gathering or requirement analysis are usually done by the most skilled and experienced software engineers in the organization. After the requirements are gathered from the client, a scope document is created in which the scope of the project is determined and documented.

Implementation: The software engineers start writing the code according to the client’s requirements.

Testing: This is the process of finding defects or bugs in the created software.

Documentation: Every step in the project is documented for future reference and for the improvement of the software in the development process. The design documentation may include writing the application programming interface (API).

Deployment and maintenance: The software is deployed after it has been approved for release.

Maintaining: Software maintenance is done for future reference. Software improvement and new requirements (change requests) can take longer than the time needed to create the initial development of the software.


There are several software development models followed by various organizations:

Waterfall Model: This model involves finishing the first phase completely before commencing the next one. When each phase is completed successfully, it is reviewed to see if the project is on track and whether it is feasible to continue.

7-1-2016 3-51-54 PM


Advantages of waterfall model:

  • Simple and easy to understand and use.
  • Easy to manage due to the rigidity of the model – each phase has specific deliverable and a review process.
  • Phases are processed and completed one at a time.
  • Works well for smaller projects where requirements are very well understood.


 Disadvantages of waterfall model:

  • Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
  • No working software is produced until late during the life cycle.
  • High amounts of risk and uncertainty.
  • Not a good model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Not suitable for the projects where requirements are at a moderate to high risk of changing.


Software Testing Life cycle:

7-1-2016 3-51-46 PM


Phase Activity Deliverable Necessity
Requirements/Design Review You review the software requirements/design (Well, if they exist.) §  Review Defect Reports Curiosity
Test Planning Once you have gathered a general idea of what needs to be tested, you ‘plan’ for the tests. §  Test Plan

§  Test Estimation

§  Test Schedule

Test Designing You design/detail your tests on the basis of detailed requirements/design of the software (sometimes, on the basis of your imagination). §  Test Cases/ Test Scripts/Test Data

§  Requirements Tractability Matrix

Test Environment Setup You setup the test environment (server/client/network, etc) with the goal of replicating the end-users’ environment. §  Test Environment Rich company
Test Execution You execute your Test Cases/Scripts in the Test Environment to see whether they pass. §  Test Results (Incremental)

§  Defect Reports

Test Reporting You prepare various reports for various stakeholders. §  Test Results (Final)

§  Test/Defect Metrics

§  Test Closure Report

§  Who Worked Till Late & on Weekends Report




Difference between Severity of a bug and priority of a bug:

Difference between Severity of a bug and priority of a bug:

         You measure severity of a bug generally on a scale of 1 to 5 with

  • 1 being “Total system crash or failure” and the QA team cannot even proceed further with their test.  E.g., an e-commerce application is not even showing the login page and shows a “System unavailable”.  Or maybe, system is available but after putting username and password for authentication, the application just keeps spinning the globe (IE terms) and never logs in to show the welcome page.
  • 2 being “Major functionality of system not working: No workaround possible” e.g. in an e-commerce application, the credit card checkout functionality is broken.  E.g., in an e-mail application like gmail, reply button is not causing the compose window to open
  • 3 being “Major functionality broken but workaround possible”.  This means that the QA team or the end users are able to use the application for QA or in real life but have to change their behavior to use the application.  E.g, in an e-commerce application, QA team is not able to search for a product but they can navigate to the product.  So, they do have a workaround for buying a certain product but this bug still needs to be fixed.
  • 4 being “Minor issue”.  E.g., in an e-commerce application, say the requirements said that the product page should show 5 views of the product (front view, back view, side view, top view, bottom view: e.g. this is very common for shoes, necklaces) but you found that the product page is only showing 3 views for some products.  You have a feeling that this is because there are only 3 views of the product in the image catalog but you still want to open a defect just to make sure that this is not a programming error.  In this case, I would give severity of 4
  • 5 being “Cosmetic issue, Typos, almost a non-issue”.   E.g., not a new line between paragraphs or alignment issues or maybe the programmer is from India and still writing Color as Colour and Behavior as Behaviour

Priority of a bug means how soon (how fast or how quickly) should the development team fix it.  Priority is mostly measured on a scale of 1 to 5 also with 1 being fix it right now (like in the next N number of hours with N being pre-decided in the test planning phase), 2 being fix it with maybe 1-day turnaround time, 3 being fix it in say 2-3 days, 4 being fix it ASAP and 5 being fix it as time permits.

Most of the times, priority and severity would be coinciding.

However, there might be some strange cases where priority and severity are not in line. 

E.g., say a QA engineer opens a defect with severity 5 because he/she found that the application does not have a legal copyright notice at the bottom.  She opened it with severity 5 (low severity) because she thought this is just a cosmetic issue.  But, the Project Manager might assign this priority 2 because the PM does not want to be chastised by the Legal Team.   The opposite case can also happen.  E.g., the QA engineer opened a bug that the customers cannot write reviews of a product.  He/She gave it severity 2 (because review is major functionality and it is broken).  But, the PM may give it priority 4 because perhaps PM has gotten direction from the business team that other issues/bugs facing the application are more crucial than writing reviews component.



Difference Between Verification and Validation

Verification and Validation

 Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents (Project Charters, BRDs, FSDs), plans, code, requirements and specifications; this can be done with checklists, issues lists, and walkthroughs and inspection meetings.

 Realize that verification is not just in the hands of QA.  It is a team effort.

Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verification is complete.

 Difference between Verification and Validation (Both are part of QA)

Verification Validation
Making sure that the requirements documents have captured the true essence of the product. Actual testing of software through test cases to make sure the product has been coded properly
Is done during the course of requirements, design and development.  This is done before code is developed. Is done after code has been completed and a product has been handed over to the QA team
Manual process Manual or can be automated.
Happens throughout the SDLC Happens only in the Acceptance Phase.
Makes sure that the correct product is being built Makes sure that the correct product has been built.

Manual QA Interview Questions:

Master QA Interview questions library


Used for Mock Interviews:

Created by: Sunil S.


Note: Please take these Question and Answers as samples only and change accordingly based on your project, these are the questions I have collected working as a QA engineer for past 10 years with working on a different project, please excuse any spelling mistake(s), my goal here is to help candidates / professionals to prepare well for the interview, I take no responsibility of your interview / interview process and the outcome of the interview, please use this at your own discretion. Thanks


Tell me about yourself:

Hello, my name is [Name]. I have over [x] years of experience working as QA engineer in various domains like Technology, Communications, Finance, and banking.  I started my IT career as [tester] in [Year] with [Company Name] and over the years as I moved from one project to another and have worked with companies like [X, Y, Z] and my most recent project was with [Company Name] on [ project details]

Since then, I have progressively advanced as a senior QA engineer and gained extensive experience in test management tool like [tool name] and also various automation tools like [Automation Tool Name] and also acquainted with open source tools like [Tool Names].

My core ability is to work on multiple projects and making sure deadlines are met.

 What department you were working in (Current Project)?

[Project name] and [Project description]

Tell us about your current / previous project?

Explain your project in detail

 What methodology you worked on current project?

We used Agile methodology in our project. In Agile, testing requires at early and often as code becomes available and stable enough for testing. On one side it was really good as we were able to test the application along with the development and find the bugs sooner but on the other side Agile development result in either application with bugs and issues or slipping schedules because it is usually difficult to test the entire build before the production release.

 What was your role or job duties as a QA engineer at your current project?

I work as Automation, performance engineer as well as I am also a Quality Center Admin. I am responsible for Automation testing of [ application(s)] at [Company Name] as performance testing of the mainframe on a quarterly basis. My day begins with debugging the failed scripts which we ran previous night. If it failed due to a bug then I was entering a new bug in quality center which automatically sends email to my QA lead notifying him about the detailed bug report entered by me. Once the bug is fixed I used to re-run the regression tests to make sure that the fixed bug did not affect the other areas of the application as well  to make sure the bug is fixed. I was also responsible for writing new test cases in vbscript based on the test steps written in Quality center by manual testers. As it was very dynamic application I was constantly updating the existing test cases as well as the shared object repository in qtp to make sure the testing framework is always updated according to the application. I am also responsible for training QTP one contractor and two FTE employes. Apart from this I maintain QC users such as granting them with new user id’s and making sure to give them right access based on their user profiles.

I have to be constantly in touch with developers, manual testers and mainframe department to ensure that we are on the same page. In order to work efficiently I was always involved in conference calls, net meetings and walkthrough almost every day. This way saved a lot of duplicate work arising due to lack of communication between different groups.

 Explain your experience with QTP in your last project?

As, I was the only Automation tester, I was responsible for writing new test scripts based on the design steps mentioned in the Quality Center by manual QA’s. Based on the test need I was also responsible for writing functions in VB script in functional libraries associated with the respective test cases. As and when required I was maintaining the shared repository to make sure our testing framework in updated based on the application changes. I was responsible for regression testing and raising defect in Quality Center if any bug was found. Once the bug was fixed by the developers, I again used to do regression testing to make sure that the bug was fixed and it did not affect the other areas of the application. Apart of these activities I was responsible for installation of QTP and connecting with Quality Center. In my current project I was also responsible for giving training on QTP to 3 [Company] employees.

 Explain your experience with Quality Center in your last project?

Apart from putting defects in QC and keep track of them I am also  working on Test Plan and Test lab module to run regression and generating reports in dashboard.  Few months ago I was made QC  admin  so now I am also responsible for making sure to grant access to new users as well as making sure that they are in the right group as we have different groups such as “Developers”, QA Testers with no delete, QA testers, PM’s .

 What kind of load testing you performed and on which application and how?

I was first responsible for load testing on our MainFrame only by creating multiple loans with virtual users in loadrunner and trying to see how the server reacts when we create simultaneous loan using multiple vusers.

Currently I am involved in tesing our middleware which is called Café and it uses WebLogic server. I do stress and load testing my submitting Xml file using load runner to see how the server responds for that we use SiteScope.

 Did you find any difficult bug in your last project?

I found various bugs in my last project ranging from low severity to high severity. One particular bug broke all the automation scripts and it took me quite a while to figure it out what was the issue. The application I was working on interacts with mainframe while creating a loan. Mainframe developers added extra field in the loan creation screen which failed the tests due to script was trying to choose field based on the code and it wasn’t able to choose the right field due to one extra added field by the main frame developers. After running the test for few times I realized the problem and notified the mainframe team.

 How you approach when two projects are important and you don’t have time for both?

If both the projects are important then I do both them simultaneously. First I will cover the important functionality of both the projects once that is done that I will move progressively to work on the other functionalities based on their priority.

When you are given a set of requirements then how would you calculate the time required to finish test cases?

Usually in every release there is a time allotted by the team lead to finish the task, we also estimate based on our experience working on that project , if unsure the we always have a QA lead to cross check

 What kind of recovery scenario you wrote?

The application I was working on had lots of Policy Exception pop ups. Whenever there is a change in the data the application pop’s up a Policy Exception message. Earlier we were using message box exception but it was not very effective way to do it as we can never be sure when and where the pop is going to show up. So to overcome this issue I wrote a Recovery Scenario to close any pop up arises in the application. This helped us to run multiple tests without interruptions.

What kind of reusable actions you used in tests?

In my project I created a reusable action to log in the application by    creating a reusable action which can be used in various tests.

How many test cases you have written?

I wrote around 400 new test scripts and updated around 800 existing test scripts.

What Automation framework you were working on?

I worked on Hybrid framework a blend of Data Driven and KeyWord    in   which we use external tables, functional libraries and shared object repository.

 How do you deal with geographically dispersed teams?

Geographically dispersed teams are not an exception but a rule these days.  With the world flattening at a fast pace, I have had many opportunities to work with teams that are scattered not just across the country but the globe!

The key to still being effective even though we don’t have the luxury of F2F conversations is supreme documentation!  Documentation is key here!

I am fanatical about documentation and I want to make sure that if someone reads my
documentation, they don’t have to ask me a question.  My documentation
should be like a live person to them.

After working on documentation like Test Plans, Test Cases, bug reports, project sizing documents, I make sure that I do a walk through of the document!  I do these walkthroughs through Net Meetings.

Having collaboration software like Sharepoint and Quality Center also makes widely distributed teams work more effectively.    Meeting on the phones is so common that I could not even convince my team members on the same floor to jump into a conf. room with me

Most people prefer to work on the phones during conf. calls and I am absolutely comfortable with it!

Where do you see yourself in a few years?  What are your long term goals?

As a QA Engineer:

I am very lucky to be where I am.  I have worked hard, learnt new tools and technologies along the way (like QTP, QC, LR, Selenium, JUnit) to keep myself abreast of latest QA advances.  I would like to continue on this path.  I am very fond of continuing education.  I think there is still a lot to learn in the field of QA.  Tools like JMeter, SoapScope, etc. that I hear are emerging tools. I am not too hung up on designations and titles.  I like to have a challenging project and I am always looking forward to such projects and increasing my scope of knowledge.  Recognition and money will follow!

Say the following if the description of the position calls for a senior role.  If the position only calls for hands-on QA engineer, you DON’T want to say the following:

I already have 8 years of experience and I feel I am ready to move into a Senior QA role, perhaps handling a team of QA engineers and delegating work to them.  I am extremely good at time management and leadership skills and will thrive in a senior QA role!

What are your strengths?

My strengths are a combination of my technical skills and my ability to work with a variety of customers. I have a very positive mindset and always welcome suggestions from peers and subordinate. I am also very agile in learning new technologies with minimum effort.

What are your weaknesses?

Weaknesses are not something that I dwell on. I like to work with a sense of urgency and at times everyone is not always on the same wavelength.   What I have found is instead of getting impatient and frustrated, I try to help them. This way we can move project forward in a collaborative manner and not just point finger.

 What do you think are the key qualities to become a software engineer?

A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.

What are the most important things for you in any job/Company?

First I look for job satisfaction. By saying that I mean my work is of importance in some way to the bottom line or bigger scheme of things. I also look for job that has advancement opportunities. I want to grow with the company. Lastly, I would like to enjoy my co-workers and have some fun. I spend lot of time at my job and want it to be a good experience.

How do you resolve any dispute with Developers?

At times developers are not ready to accept the bug, so in that case I take screenshot of the bug and send it to developers. If still developers disagree then I escalate the situation with my QA lead.

 How would you prefer to work? Independently or in a team environment?

I would prefer to work in both ways; I am a very self – sufficient guy who knows his responsibilities and duties, ready to take ownership of an issue and have the ability to handle multiple tasks independently so working individually is not a problem for me at all.

On the other side, it’s always good to work in teams, working in a team environment made me help learn new things, everyone can share their own ideas based on their experience, if I miss out something, my team mate can pick that up, so over all we work as a team to achieve a common goal.

And hence I would go for whatever the situation demands.

As a QA engineer, how important is test documentation to you?

Documentation as a QA is very important to me especially when I am working on multiple complex projects simultaneously. When I have documented everything properly, it is easy for me and other team members to look back into the document when in need of some information. The importance of documentation comes whenever there is a change request and the developers have made some modifications to the existing application. In such situations we can easily look into the document and check the test cases of that particular module and get a better idea about how to test the changed requirement.

How were you tracking Bugs in your projects?

In [Company], bug tracking workflows like this –

As soon as I raise the defect in QC, it automatically shoots an email to my QA lead with all the details about the bug then my QA lead verifies the bug and enters in ClearQuest and assigns it to developers. As soon as the bug is fixed, developers change the status in ClearQuest and my QA lead notifies me thru Quality Center. I run the regression to see if the bug is fixed or not. If it’s fixed then I close the defect but if it still fails then I reopen it again in QC.

What kind of platform you are working on?

The application I am working on in BREF which is on Weblogic server and we have Oracle database and for middleware also we have weblogic server.

Have you used soapUI in your current project?

SOAP UI is a open source web service testing tool for SOA’s (Service oriented architecture)

We use it for loadtesting on our weblogic server. Like you can run many threads which is basically virtual users in loadrunner.

Did you take up any challenges in your current project?

Yes, so we were using clearQuest in our current project to track bugs but around 6 months ago our management decided to use Quality Center for bug tracking. My manager was looking for HP Consultant to migrate the bugs from ClearQuest to QC. I took up the responsibility by asking him to support me and assured him that I will make sure to do the task successfully. I had never migrated in my any project earlier so with the help and support of my boss and with the tool called HP ALM Synchronizer (this tool is used to migrate bugs) I was successfully able to migrate the bugs not only that after migrating I was also responsible for enhancing the Quality Center Defect module based on the clearQuest fields. As the users were not happy with the default QC field names so after having meeting with the users and my managers back and forth we planned a whole new field names and criteria’s for Defect module. I was successfully able to do it and that’s how I became a QC admin.

 How you tested the application for performance testing? Could you elaborate more?

I am responsible for testing our Mainframe and also two other applications called Café which is a middleware between BREF and CPS and the other application is called BDCAS – Business Direct Credit Application system.

So for Mainframe I was responsible for generating load on the server by create virtual users, I was creating multiple loan with vusers and also inserting rendezvous point ( basically all the vusers will stop at certain point and then perform the task simultaneously, in my case it was creating a loan. It was a doing load testing to see how CPS responds under a heavy load of users creating multiple loans.

And the other application, which is Café and that, is responsible for grabbing the XML file and submitting it to CPS. I was responsible for generating the load test by creating various vusers and while the script is running I was also gathering information on  throughtput, response time and resource utilization with the help of monitors in LoadRunner as well as using SiteScope on the server side.

 What is a Test Plan?

A Test Plan is a document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks and who will do each task (roles and responsibilities) and any risks and its solutions.

What does it include? A Test Plan includes Heading, Revision History, Table of Contents, Introduction, Scope, Approach, Overview, different types of testing that will be carried out, what software and hardware will be required, issues, risks, assumptions and sign off section.

 Have you written a Test Case?


What is a Test Case? What does it include?

A Test Case is a document that describes step by step process how to test the application. A Test Case includes Test Case ID, Steps Description, Expected Output, Actual Output, Pass/Fail, Remarks.

How many Test Cases did you write in your last project?

I wrote about 1100 Test Cases in my last project. (The reasonable number of Test Cases varies from 500 to thousands. The number 1100 test cases can be completed in a 6 month project duration).

What document did you refer to write the Test Cases?

Requirement document / User Stories (NOTE: It can also be Use Cases, or Design Document)

(Note: It depends company to company. In some companies, they use Use Cases. In some companies, they use Requirement Documents and in some companies, they use Design Document. However, in practical scenario, most of the companies have requirement document at least).

Did you have a situation where you did not have any documents (no requirement document, no Use Cases, or no Design Document) and you had to write the Test Cases? How did you write the Test Cases?

Yes. I have been to that kind of scenarios several times. There were companies where they had no documents at all. In that case, I had to discuss the application scenario and functionalities with the Business Analysts or developer. I kind of prepared a document in consultation with Business Analysts and Developers and then started writing Test Cases.

Have you worked with the Uses Cases before?

Yes. I have written Test Cases using Use Cases.

Can you tell me what a Use Case is?

A use case is a document that describes the user action and system response for a particular functionality. (you can also include, For example, in the Use Case given below, is a Use Case for login system for a company called Auto parts One. This application is being developed by Digital Systems, Inc. The project name is Auto Parts One. However, the business owner (user) is a company called American Auto Parts of the North (imaginary name).

What is a Use Case and what does it include?

A Use Case is a document that describes the user action and system response for a particular functionality. It includes cover page, Revision History, Table of Contents, Floe of Events (normal flow and alternative flow), Exceptions, Special Requirements, Pre-conditions and Post-conditions.

What is meant by Walk-thru meeting?

Before start working in a module and/or after accomplishing the testing of a module, the tester calls a meeting to disseminate his findings or to share his queries to other tester or leads of the company working on the same application that is called the Walk-thru meeting.

What is Build?

When each of the different modules of software is prepared, they are put in a single folder by the Configuration Management Team (CMT) and it is called the ‘Build’.  In other word, the developers put their code in the shared location (folder) and all those code (modules) are combined together so that it is a complete application that works.

What is meant by the Build Deployment?

When the Build so prepared by the CMT is sent to different Test Environments, it is called the Build Deployment.

What is Test Strategy?

A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

The test strategy describes how the product risks of the stakeholders are mitigated at the test-level, which types of test are to be performed, and which entry and exit criteria apply.

 What is Negative Testing?

Testing the system or application using negative data is called negative testing, for example, testing password entering 6 characters where it should be 8 characters should display a message.

When we test an application by putting negative values (instead of actual values), then the system should not allow the other values rather than the actual value.  The system should give a message that the value is not correct.  This is called negative testing.
Another example is, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the “Incorrect data type, please enter a number” message. The purpose of negative testing is to detect such situations and prevent applications from crashing. Also, negative testing helps you improve the quality of your application and find its weak points.

What is the difference between Load Testing and Performance Testing?

Basically Load, Stress and Performance Testing are the same. However, Load testing is the test to check the users’ response time of number of users of any one scenario of the application whereas Performance Testing is the test to check the user response time for multiple scenario of the same application.

What is the most common syntax you have used while writing SQL query?

Answer:  SELECT

What is a Primary Key?

In a database table, the Primary Key is a column which has a unique value for each of the row within that column. It can’t have NULL value.

What is a Unique Key?

In a database table, the Unique Key is a column which may or may not have null value of each of the row within that column.

What is Data?

Data is number, character or image which has some information.

What is Database?

It is collection of logically related data designed in a tabular form to meet the information needs of one or more users.

What is Change Control (OR Change Request)?

Answer:  It is a document that describes the additional functionalities that are added after the Business Requirement Document is signed off. It can be updated in the old business requirement document or it can be a separate document.

  What is Backend Testing?

It is a test to check whether the data displayed in the GUI front end report format matches with the particular data in the original database.

  Have you done any Back End Testing and/or if you did, how did you do it in your last project?

Yes I did. I was working on Reports. When I was working in my last project, this was my scenario:

It was the case of testing one part of application used in the bank, where a customer comes to a bank’s front desk associate and ask for opening an account. The associate then asks for the personal information about the customer which, are the primary data, such as: First Name, Last Name, Date of Birth, Address and Social Security Number. The associate then put these primary data of that particular customer into the computer, which then afterwards batch-processed into the DATABASE in XML Format. Then the batch-processed data is sent to ETL (Extract-Transform-Load, which is software made by ‘AbInitio’ or ‘Informatica’) which processes the job to create a file to produce the report. The file is displayed to a GUI Front End report format with the help of Crystal Report/Business Object. In the GUI Front End report, let us say, if for January, the income of that person was displayed as $ 900.00, then my job was to validate this data by writing SQL queries whether this displayed data matches with the original input data in the database, being called as the Back End Testing.

How can you be sure that the query you wrote is correct? Or how do you know that the data you pulled from the database is correct?

Answer: I write SQL query based on the requirement document. In the requirement document, various conditions are given for the query. Based on those conditions, I write SQL query. Therefore, anything different from the requirement document is definitely a defect.

 From you resume, I see that you have been working in one place for a very short period of time. This raises me questions why. Can you explain why?

Ans. As a consultant, I am hired for a certain period of time, normally for 6 months to 1 year. Once the project is over, I needed to move to another project. That’s why you see me in the resume jumping frequently here and there.

 What do you do on your first day of the work?

Answer: On the first day, normally, we will be given a computer and support people will set up the User Name and Password for the computer.  If that is done already, then the QA Lead or QA Manager will give me a brief walk through of the documents (which documents are where), introduce to different team members (normally to the ones you will be working with).  Then your boss will ask you to step into work what needs to be done.  However, the first thing normally is, they will ask you to read the documents available for that project.

 As a QA Tester, can you tell me the situation when you felt the most proud of it?

Answer: When I find the defect that normally others don’t find, then I feel very proud. For example, there were situations where I found bugs that crashed the whole system at the end of testing phase. I tried the scenarios where the scenarios were NOT mentioned in the test cases. For example, we can close the windows by clicking X on the page, with “Close” button and so on. But there is another way that you can close the window, by pressing Alt+F4 on the keyboard. Not many testers test this scenario. I have done this in my last two projects. Both the time, the application crashed which became a big issue. I felt proud.

 What made you to choose testing career?

Answer: I am a very detailed oriented person and I like process-oriented job. The way QA process works is just the kind of work I like. For example, analyzing requirement documents, attending walk-through meetings, writing test plans, writing test cases, executing the test cases (or running the test cases) testing the application, logging defects, retesting them and so on. I think I really like the process and that’s why I chose this career.

 How would you ensure that you have covered 100% testing?

Answer: The testing coverage is defined by exit criteria (There is exit criteria and entry criteria in the Test Strategy). For example, if the exit criteria says “The software will be acceptable to the client only if there are no critical defects, no high defects, no medium defects and only two low defects”, then all the critical, high, medium should be zero. Only 2 low defects are acceptable. Thus, 100% coverage is measured by the exit criteria. Also, 100% test cases must be executed in order to cover 100% of testing.

What do you like about QA?

Answer: The best thing I like about QA is, I like the job which is more process oriented. For example, we have to work right from reading the requirement documents, providing feedback to the Business Analysts as necessary, writing test plans, test cases, execute the test cases, interaction with different developers, attend walk-through meeting and so on. I am a very detailed oriented person. When I test applications, I try to get into the depth of functionality so that I don’t miss out anything. Finally, I love logging defects.

What are all the basic elements in a defect report?

Answer: The basic elements in a defect report are: Defect ID, Header, Description, Defect Reported by, Date, Status, Version, Assigned to, Approved by, Module where the defect was found and so on.

How to write Integration test cases?

Answer: I have never written separate Test Cases Integration Testing. Since Integration Testing is a test to check whether the all the modules are integrated together or not (meaning that when the developers compile all their module and make a build, all modules should be working when they are combined together and those modules when combined, should work as expected). If they are not integrated (combined) in a nice way, then the application breaks. Basically, when we do the functional testing, the integration testing is automatically done. This is my experience.

How to write Regression test cases? What are the criteria?

Answer: Regression test cases are also based on the requirement documents. They are written more into detail and with every release (build), the testers need to do regression testing. The criteria for regression testing are; there should be no major defects while we do our smoke Test and functional testing.
How to write User Acceptance Test plan & test cases?

Answer: The way of writing Test Plan and Test Cases is the same in all the test phases. However, specifically for User Acceptance Testing, the testers use data nearly real data (meaning that the data is very much similar to the production data or real data).

 What can be done if requirements are changing continuously?

Answer: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application’s initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to… · Ensure the code is well commented and well documented; this makes changes easier
for the developers.
· Use rapid prototyping whenever possible; this will help customers feel sure of their
requirements and minimize changes.
· In the project’s initial schedule, allow for some extra time to commensurate with
probable changes.
· Move new requirements to a ‘Phase 2′ version of an application and use the original
requirements for the ‘Phase 1′ version.
· Negotiate to allow only easily implemented new requirements into the project; move
more difficult, new requirements into future versions of the application.
· Ensure customers and management understand scheduling impacts, inherent risks and
costs of significant requirements changes. Then let management or the customers
decide if the changes are warranted; after all, that’s their job.
· Balance the effort put into setting up automated testing with the expected effort
required to redo them to deal with changes.
· Design some flexibility into automated test scripts;
· Focus initial automated testing on application aspects that are most likely to remain
· Devote appropriate effort to risk analysis of changes, in order to minimize regression-
testing needs;
· Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;
· Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
What if the application has functionality that wasn’t in the requirements?

Answer: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.

How can software QA processes be implemented without stifling productivity?

Answer: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process. However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers.

What is end-to-end testing?

Answer: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

What is security/penetration testing?

Answer: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

What is a ‘Show Stopper’?

A show stopper is a defect or bug that stops the user for further action (testing).  It has no work around.  In other words, it stops everything and the user cannot go any further.  This is called show stopper in software industry language.  (This is not an interview questions, but you have to know this terminology)

What are you expecting from our company?

Answer:  My expectation from you company would be I will have more challenges and new things to learn and whatever the skills I have to contribute, hopefully, I will be able to contribute if they are in any way helpful to enhance productivity of the company.

What did you learn from your previous companies?

Answer:  I learned a lot from the previous companies wherever I have worked.  Wherever I have worked, I found out the there is always something to learn.  Different companies have different ways of working.  The environment and technology always differ from one company to another company.  I have never found one company’s environment matching with another company.  For example, if one company is using documents called requirement documents, then the other company might be using Use Cases and some companies might be using Design Document and so on.  Therefore, in my experience, there are always new things to learn in every company and we can always contribute these thing in the next company if they help to be more productive.

What do you want to be in next 2 years?

Answer:  I want to be QA Lead in another two years.

Why QA Lead? Why not something else?

Answer:  QA is the only thing I love doing it.  I love this job and want to progress in this sector.  I want to know how to manage QA process, how to handle different jobs and so on.  Since the next step is the QA Lead, that would preferably be one I will targeting for.

Why do you want to work for this company?

Answer: (This is a tricky question.  They want to know what really interests you and you have to be careful when you answer this question.  You must admire the line of that company.  For example, if you are being interviewed by a pharmaceutical company, then tell them that you are always interested in the medical applications and the better part of your company is that it has exciting products that I am really curious to learn.  That’s why I would feel really great if I am given the opportunity to work in your company)

Did you get any compliments from your previous employers?  What were those situations?

Answer:  Yes. I did.  There were many occasions where I had compliments.  For example, I was testing an application going a little bit off my test cases. After I finished executing my test cases, I always think in a way what a real user would possibly click in various parts of the application.  So I was just clicking back and forth and at one specific scenario, the application simply broke and displayed an error message.  That scenario was not in the test cases. The manager really appreciated me and thanked for finding this kind of critical defect.  Answer:  Yes. I did.  There were many occasions where I had compliments.  For example, I was testing an application going a little bit off my test cases. After I finished executing my test cases, I always think in a way what a real user would possibly click in various parts of the application.  So I was just clicking back and forth and at one specific scenario, the application simply broke and displayed an error message.  That scenario was not in the test cases. The manager really appreciated me and thanked for finding this kind of critical defect. 

What is verification and Validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term ‘IV & V’ refers to Independent Verification and Validation.

What is a ‘walkthrough’?
A ‘walkthrough’ is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.


What are 5 common problems in the software development process?

  • Poor requirements – if requirements are unclear, incomplete, too general, and not testable, there may be problems.
  • Unrealistic schedule – if too much work is crammed in too little time, problems are inevitable.
  • Inadequate testing – no one will know whether or not the software is any good until customers complain or systems crash.
  • Features – requests to add on new features after development goals are agreed on.
  • Miscommunication – if developers don’t know what’s needed or customers have erroneous expectations, problems can be expected.



What is User Acceptance Testing?

User Acceptance Testing is often the final step before rolling out the application.

Usually the end users who will be using the applications test the application before ‘accepting’ the application.

This type of testing gives the end users the confidence that the application being delivered to them meets their requirements.

This testing also helps nail bugs related to usability of the application.

User Acceptance Testing – Prerequisites:

Before the User Acceptance testing can be done the application is fully developed.
Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT.

User Acceptance Testing – What to Test?

To ensure an effective User Acceptance Testing Test cases are created.
These Test cases can be created using various use cases identified during the Requirements definition stage.
The Test cases ensure proper coverage of all the scenarios during testing.

During this type of testing the specific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment.
The Test cases are written using real world scenarios for the application

User Acceptance Testing – How to Test?

The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing.

However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of the following:
…….1)User Acceptance Test (UAT) Planning
…….2) Designing UA Test Cases
…….3) Selecting a Team that would execute the (UAT) Test Cases
…….4) Executing Test Cases
…….5) Documenting the Defects found during UAT
…….6) Resolving the issues/Bug Fixing
…….7) Sign Off


User Acceptance Test (UAT) Planning:
As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria.

Designing UA Test Cases:
The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios.
The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating.

Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.

The Business Analysts and the Project Team review the User Acceptance Test Cases.

Selecting a Team that would execute the (UAT) Test Cases:
Selecting a Team that would execute the UAT Test Cases is an important step.
The UAT Team is generally a good representation of the real world end users.
The Team thus comprises of the actual end users who will be using the application.

Executing Test Cases:
The Testing Team executes the Test Cases and may additional perform random Tests relevant to them

Documenting the Defects found during UAT:
The Team logs their comments and any defects or issues found during testing.