Situational FAQ | A practical Software Testing Interview

Knowledge about fundamental Testing concepts is necessary to crack an interview. But now-a-days only knowledge is not enough. Interviews are not just about the theory anymore. Every interviewer is looking for candidates who have practical exposure to different kind of situations and is able to handle them effectively. Most of the companies will have it as one of their selection criteria. And yes, it doesn’t depend on the technology. For every technology there will be situations that an experienced professional knows how to tackle. In this article, we will look at some of the situational FAQ commonly asked in a testing interview. But we will need your help here. It is just a beginning, please comment any situational question that you might have faced in a recent or any past interview. This would help us to collate an informative list for the Testing community.

Situational FAQ #1 – The application is currently in production and one module require code changes, i.e. Change request. Is testing the module-under-change enough to ensure quality delivery? Why or Why not?

No. Testing the module-under-change is a must-have whereas the changes might have an impact on the integration with the other modules. Most of the development teams follow modular coding wherein same functions are re-used in different modules of the application. If a change is made to a particular module, it doesn’t guarantee that the change is isolated to that module. That’s where ‘Regression Testing’ comes to rescue. After a thorough impact analysis of the changes, Test team needs to verify all the impacted areas – be it within same module OR outside it (ensuring that there are no side effects of the code changes).

Tip: Test team’s understanding and Inputs from the development team are a must to identify all the impacted areas!

Got any other situation or solution? Please comment…Let’s learn, together!

Situational FAQ #2 – What is the most challenging situation you have had in your Testing experience?

As you might have guessed, it depends on each tester’s experience. The challenge can be technical, process-oriented, people’s related, domain specific OR anything within your Testing experience. For me,

  • Testing a technically-challenging application such as social-connected applications, application involving multiple third-party interfaces, cloud-big data-IoT-Analytics-etc. applications.
  • Maintaining a balance between design/execution efficiency and defect detection. Improving the Test coverage. Sticking to agile principles.
  • Resources on unplanned leaves, some even abscond. Estimation gone wrong, requiring weekend & extended working hours. Rating discussions with unhappy employees.
  • A team of fresher’s with limited domain knowledge. Planning for knowledge transfer sessions.

The thumb rule – be realistic & tell your genuine challenges!

Situational FAQ #3 – One of the most common situation, How will you start Testing without any functional specification or any related documents?

No wonder there are sometimes these kind of situations, ex. Resource attrition, no-documentation-with-agile-projects, etc. The only hope in these situations is ‘Exploratory Testing’. Since there are no documents to refer, refer the application directly 😉 Explore it, Test it. Gradually the flows make sense and we start actually testing it. Other option is to sit with Business analysts and developers to get application understanding – listening to experts instead of reading a document. Personally I like to build a document thereafter, so that someone joining after me doesn’t have to face this kind of challenge!

Situational FAQ #4 – Ever worked with a challenging client? Who is adamant & rigid? About the design, requirements, process or timelines. What was the situation & How did you tackle it…?

Sometimes we do get that unfortunate project (fortunately there is much to learn from it) where the client is uncompromising – they think they are Google who knows everything OR just that you are a labor working for them.

  • Don’t panic. Don’t react. Instead respond. Think it through what client is demanding & analyze your options at hand.
  • Consult your seniors on how to handle the situation.
  • Do what the client is asking. After all he/she is paying for your cheque.
  • Be flexible in accommodating client requests, to whatever extent possible. Two adamant sides won’t solve the problem.
  • Pull in subject matter experts to talk it through with client, hoping that he/she will at least listen to the respective SMEs.
  • Maintain a balance between your team & the client. No one should suffer for the other.
  • Report it to the higher management to take care at their level.
  • We are no laborers. Clear it with the client or else say No.
  • Put down the papers ?

I guess there are so many different ways to either make it or break it. What will be your approach?

Situational FAQ #5 – One of your resource takes unplanned leave & is now absconding, i.e. no status update. How will you manage the work & people?

Unplanned leaves are one of the common things. Sickness cannot be planned 🙂 But as a Lead/Manager, first things first – the work shouldn’t be impacted,

  • Re-plan the activities & task allocation.
  • Forecast & publish the risks, if you see any like timelines impact.
  • Always keep some buffer when estimating.
  • Employees are valuable assets for any company. Check for any professional problems the resource might be facing & try sorting it out.
  • Resort to warnings as the last attempt.
  • Check with seniors & HR Dept. for the organization’s leave & abscond policy.

What do you think should be done to handle such cases? Or if you faced a similar one?

Situational FAQ #6 – As a Test team you complete functional testing but most of the times UAT will catch some more bugs. Any idea why?

  • System Testing, though should cover all the possible “user-scenarios” but still UAT team is more closer to business hence more aware about the actual business use cases.
  • The UAT environment correctly mirrors the actual production environment. System Test environment is more sort of a scaled-down version.
  • The Test Data. UAT team has access to masked production data, i.e. more realistic set of Test Data.
  • Testing can never be complete. Every phase will have some or the other defect waiting to be caught.
  • System Test team starts from initially developed build which already has more defects. And within the time frame, they try to catch maximum bugs – say improving the quality from 60% to 95%. UAT team then starts from a relatively stable build (95%) & focus on identifying the remaining bugs.

Any other perspective or rationale you can add to this? Please comment…

Situational FAQ #7 – Ever had an argument with your Manager? I am sure you have heard about it at least ? what was the case & how did you handle it?

  • The most common: after all the hard work you get a bad rating. Manager states that it’s ‘relative’. There is no ‘weakness’ in IT industry, only improvement areas ?
  • Argument over some Test metrics, be it the status report, defects metrics, productivity, design efficiency. The conflict in understanding.
  • Some process doesn’t make sense to you?
  • Micro-management is demotivating?
  • Manager playing favoritism & supporting his aides?
  • Too demanding? He/She just needs the work done, even if that means you doing extended hours or working on weekends.
  • Task allocation or Project management conflicts?
  • Manager: People are too careless for you to be strict?
  • People don’t understand how this works. It’s relative. Even if you are good, only the best of the best gets 1 – rest we have to maintain a pyramid.

It can be anything. The Manager – Employee relation is somewhat tricky. Employee thinks Manager is clever/shrewd, Manager thinks employee has attitude problems. I guess “communication-to-understand” is the only key. What say? What is your situation like? ? you are the employee or the manager? ?

Situational FAQ #8 – As a Manager, How do you discuss low rating with a team member?

Performance evaluation is a relative assessment of employee’s work w.r.t. others in the team. No wonder some employees will be rated low in spite of the hard work done. And here organizations imbibe positive culture by replacing people ‘weakness’ by letting you know the ‘development areas’ instead. We as employees need to understand that company growth is equally important. Though you performed well but there are others in the team who out-performed you. Everybody has a potential to be at the top, people who work on their development areas eventually grow up the success ladder. Pinpointing mistakes & blame games can help in the short term but will eventually fail. Feedback needs to be transparent & constructive, delivered with a positive outlook. That’s when you grow as a team!

Did you have any weird, witty or wise experience with the appraisal meetings? Do share in the comments ? Let’s discuss something that is “confidential” ??

Situational FAQ #9 – I assume ‘every’ fellow Tester in my network have experienced this situation at least once in his/her career. One of the most common Testing situation – How do you handle timeline crunch?

Since Testing is the last step before client demo, the Test team has to make-up for the delays encountered till the build is deployed in Test environment. Now how do you handle crunch timelines without impacting the quality?

  • Consider some buffer in planning phases to accommodate the usual delays.
  • The most common: Extended & Weekend working hours.
  • Prioritize the Test efforts and communicate the same to all the stakeholders.
  • Do nothing & complete as much Testing as possible in the given timelines. Convey the sorry picture to stakeholders at the end to get an extension.
  • Highlight the delays to buy some extra time.
  • Plan & make efficient use of working 9 hours.
  • Convey the situation as-is to the stakeholders, asking for some time to complete testing.
  • Quicken the defects turn-around time by communicating it to the development counterparts.

Whatever be the approach, always take a retrospective look once the testing is complete in order to avoid delays the next time. How did you tackle the timelines? Awaiting inputs…

Situational FAQ #10 – Which Tests do you think should be automated?

Using tools to test helps in building a re-usable framework for any repetitive tasks. Or some tasks which are way too tough when done manually.

  • Automate whatever possible (not a worthy solution if it is required to be run just once).
  • Undoubtedly the regression suite (no explanation required I guess)
  • Using tools for performance & security tests
  • Unit tests for build confirmation.
  • Only the tests which needs to be run repeatedly, i.e. ‘multiple’ times.

Calling all automation experts to provide the inputs in light of changing QA landscape – Tools, TDD, BDD, Agile, Continuous Integration…where does automation fit? What tests to automate?

Situational FAQ #11 – The QA team starts testing a software/product and there are “way too many” defects…Every other scenario is failing, new flows are explored & clarifications sought. What would be the strategy now?

It’s a complex application with tight schedule. Too many defects add cherry on the cake. The blame game starts. But at the end, development & QA are expected to work as a team & deliver the product/software. What are the options?

  • Reject the build. But that would mean delay in delivery.
  • Get into a war room, daily. It helps to triage the defects & increase the seriousness.
  • Prioritize. Work as a team & ensure priority flows are working as soon as possible.
  • Identify super-devs & super-QAs to take up some additional tasks & ensure minimum turn-around.
  • Involve the higher management (risk aware) just in case something goes wrong. It shouldn’t come as a surprise.

Since timelines are fixed, make sure turnaround time is as minimum as possible – be it defect fix, retesting, business clarifications, anything. Everybody has to be on their toes.

Note: Retrospective w.r.t. estimations, build quality, management screw-up, etc. is altogether a different discussion.

Hope these Situational FAQs help you build a better understanding of the Software Testing process. As stated earlier, please comment any situational question that you might have faced in a Testing interview. Let’s capture all the situations together 🙂



Leave a Reply

Your email address will not be published.