Software Manual Testing Interview Questions for Experienced Professionals

The highest frequently posed scenario-oriented Manual Testing interview queries for seasoned professionals with comprehensive answers:

I recently seized this exceptional opportunity to mentor a QA professional with a decade’s worth of experience. This coaching was a preparation for a software testing interview at a prominent Entertainment firm in Los Angeles. The site to be evaluated was a straightforward customer-oriented site (akin to an online TV channel) with both Web and Mobile components.

A consulting agency was projecting portfolios to this client for an onsite tester + coordinator role but none of them were progressing through the testing interview stage. Consequently, they chose to collate the QA interview queries from the former attendees and handed me a questionnaire.

They wanted me to furnish answers to these queries for the following candidate and guide that individual to triumph in the testing QA interview.

When I received the list of queries, I was both astounded and unaffected. Astonished- since the inquiries were incredibly rudimentary and a QA professional with ten years of experience should have easily been able to respond to them. Not surprised since QA is the IT sector that has the most unwarranted elements according to me- but let’s not delve into it.

Upon completing the task, I thought it would be beneficial to disseminate this experience with STH readers. For novices, it could provide beneficial hands-on experience. For more experienced individuals, it would be a gentle reminder of the importance of fundamentals irrespective of the level of experience.

Suggested Reading => 101+ Software Testing Interview Questions and Answers.

Let’s begin…

Manual Testing Interview Questions for Experienced Professionals

Nine Most Frequent QA Software Testing Interview Queries for Novices as well as Skilled Candidates:

#Q 1) Describe the Procedure for Designing a Test Script?

Response:

Step 1: Comprehend the AUT thoroughly:

• This can be accomplished by closely examining the requirement documents.
• In the absence of documentation, we would attempt to interpret any available reference – a previous version of the application or wire-frames or screenshots.

Step 2: Once we comprehend the necessities, we compile a list of areas within this application that require examination. In other words, we establish the aims of the test. The objective at this stage is to determine “What” to assess. The conclusion of this stage results in a list of Test Scenarios.

Step 3: Once we’ve delineated the testing scenarios, we focus on “How” to evaluate them. This segment involves creating comprehensive steps to test a particular feature, what data should be input (Test Data), and what the expected result should be.

Upon completion of these three stages, we are ready for testing.

#Q 2) What elements comprise a Bug Report?

Answer: The following crucial elements should be integrated into a compelling Bug Report:

1. A unique ID
2. Defect Description: A brief synopsis of the bug in question.
3. Steps to Replicate: Details on reproducing the error, exact test data, the timings when the defect was spotted (if pertinent), environment settings: any information that could facilitate recreating the issue.
4. Module/section of the application (if applicable)
5. Severity Level
6. Screenshot
7. Responsible QA: In the event of any follow-up inquiries concerning the topic.

#Q 3) How can you assess a customer-oriented software program?

Answer: No matter what software we use, we seek to determine if the application meets a specified set of requirements. However, when it comes to a customer-facing site, we must focus not only on functionality but also consider a host of usability features and even performance and security aspects to a certain extent.

The initial testing stage involves: Determining if the site satisfies its functional prerequisites.

For Instance, if it’s a loan management site, we need to evaluate various aspects – can new clients apply for a loan, can existing customers access their loan details, is the interest percentage applied to the loan sum correctly, and so on.

The subsequent testing stage concerns: how user-friendly the site is, and whether its options align logically with the users’ expectations.

For Instance, if the user needs to navigate through 3-4 screens to submit basic information, they are bound to be frustrated, so such issues need to be addressed.

Another example, after entering a username and password, if the user clicks on the tab, the control should be passed to the “Sign in” button, rather than the cancel option. Should that happen, the user is likely to be greatly inconvenienced and the experience of navigating the site would be detrimentally impacted. We need to trap such issues.

Performance Testing might not be fully scoped, but simple situations such as how long the search results take to be displayed or how much time the system takes to fetch a client’s data at peak hour – these are samples of concerns we would want to closely monitor.

Security – for websites that require secure login to access the site, basic functionality around it has to be verified. For Instance, if the site remains idle for more than 10 minutes, does it auto log out or not? It’s imperative to concentrate on relatively straightforward aspects like this.

#Q 4) How can you overcome the challenge of lacking input documentation for evaluation?

Answer: In the absence of detailed standard documentation like a BRD and FSD, the tester must resort to some point of reference.

• Screenshots
• A previous iteration of the software
• Wireframes, etc.

Another hugely beneficial approach is to interact with the developers or the business analysts (when available) to either confirm our understanding or seek clarifications in case of uncertainties.

When all else fails, we can simply conceptualize the software based on our prior IT software experience and formulate a rudimentary set of test scripts. While approaching the testing phase, we can allocate part of the test cycle duration to manage the test cases (refine the pre-existing scripts) so we have documentation for future phases.

#Q 5) How can we maximize productivity from an offshore team?

Answer: The secret lies in ensuring that all the testers are knowledgeable about all the modules and that knowledge is not solely concentrated in a single location. Engaging everyone in peer reviews of test scripts, problem meetings, and KT sessions ensures widespread awareness of the application.

Moreover, fostering the concept of teamwork can facilitate team member collaboration, assistance, and mutual support to enhance productivity.

Habitual follow-up meetings also greatly aid this process.

#Q 6) What are the Duties and Obligations of an onsite coordinator? Is testing part of their job too?

Answer: The onsite coordinator serves as the point of contact for the offshore team and the client for any information related to the testing engagement.

This role includes:

• Knowledge transfer from and to offshore teams and clients
• Ensuring the testing environment is setup
• Sanity testing, smoke testing
• Testing of the key functionalities
• Examining bugs discovered by the offshore team
• Assigning bugs to the responsible developer
• Presenting metrics
• Signing off

Yes, testing is indeed a part of an onsite coordinator’s duties.

#Q 7) Unstable bugs- Why can the onsite team find them, but the offshore team can’t and vice versa? How can you manage this situation?

Answer: Every bug, regardless of whether it’s encountered onsite or offshore or if it’s repeatable or not, needs to be acknowledged and scrutinized. We add genuine value to a tester’s job when we participate in the root cause analysis process for a bug, instead of just documenting it.

Here are some ways we can manage this situation:

• Both onsite and offshore team members must comply with the fundamental guideline that screenshots must be captured for every error encountered, whether it’s repeatable or not.
• In case logs, system files, or anything similar that could possibly help us unearth any evidence of the problem exist, we should endeavor to locate it.
• Despite taking these steps, if we’re still unable to figure out why and when the problem occurs, we must still report it to the developer, providing them with as much information as we possibly can.

#Q 8) Video/audio-centric testing – What does it encompass?

Answer: How do you go about testing an application that features video or audio?

Here are the main points to consider:

• Access levels (whether restricted – password managed)
• Different types of environments
• Browser compatibility
• Screen resolutions
• Internet connection speeds
• The specific video features – play, stop, mute, etc.
• Size of the video
• User responses to the videos – comments (limits on the length and number of responses received)
• User video responses to the videos
• Integration with social networking platforms – Interoperability
• Buffering speed
• Embedding the video

#Q 9) Mobile Application Testing – What does it briefly encompass?

Answer:Important Test Scenarios for Mobile App Testing:

• Verifying if the app operates well with multiple carriers and devices.
• Usability of features on a mobile screen.
• Testing it across multiple mobile platforms – such as Android and iOS.
• Installation, uninstallation, launching the app with and without network connections, testing the functionality.
• Network connections like WiFi, 2G, etc.
• iOS iPhone configuration utility logs for Android Monitor.bat can be utilized for debugging.

That was it. It wasn’t that simple.

In conclusion, I repeat the STH philosophy – understand the basics well, and everything else naturally follows.

I wrap up this piece, hopeful that this effort proved worthwhile and valuable to our viewers. Please share your feedback in the comment section below on how we fared.

Author: This article was crafted by our STH team member Swati Seela.