Looking for Software Testing Interview questions? Let us start with basics…What’s the difference between a defect & a failure? What Test methodology did you follow? Which all methods did you use? You have worked at which all Test levels? How did you organize different Test cycles? Involved in what all Testing types? What about the Test artifacts – did you prepare any? Which technique did you use for Test Design or execution? Confused with these fundamental Software Testing Interview questions?
Yeah! At times, most of us in ‘Software Testing’ arena get confused with different terminologies, i.e. fundamental Software Testing Interview questions. After all, Testing is not just an activity, it’s a complete process to ensure Quality. Even an experienced tester might have a hard time recalling different terms. We have observed that almost all of the available online content confuses these with one another, after all it’s not that straight-forward. But now you don’t have to fear, when we ‘Studio’ is here 🙂 Just kidding 🙂 But seriously get your facts clear before facing the next round of Software Testing Interview questions, to avoid embarrassment!
Defect & Failure
Say you are testing an e-commerce checkout functionality. You observe that even after selecting ‘Debit card’ as the payment method, you are being navigated to Bank’s Net Banking login page.
- Mistake: There was a slipup by the developer hence the issue
- Error/Bug: Due to developer’s mistake, there is an error/bug residing in the code
- Defect: Once the bug is identified during testing, it is logged as a ‘Defect’ in the tracking system
- Fault: Now this is tricky. Pay attention! As an end-user of the application, the User clicks on the ‘Debit card’ option at checkout. The erroneous code has been triggered. But when will the end-user come to know of the defect? Yeah! When he sees the Net Banking login page. The duration from clicking on the ‘Debit card’ option till the User lands on the Net Banking page – there was a ‘Fault’ in the system.
- Failure: Literally a disappointment or a letdown. And no one wants to do business with a failure!
What’s your approach to Testing with respect to development process? I.e. how as a QA team, you are going to follow STLC (The Testing Bible, The Gita & The Quran). Will it be after development is completed for the complete system (Waterfall)? Or will it be in parallel (V-Model)? Or will it be Agile (responsive)? Testing methodology determines how QA is going to co-work with Development phases. Practically, the most followed methodology is:
- Waterfall model
- Agile methodology
Once you have identified the methodology to be followed, the next is to identify the means to testing? Are you going to understand the system at coding level? I.e. identifying the coding defects (White-box). Or will it be only at the application functional level (Black-box)? Or a hybrid method (Gray-box)?
- White-box: internal structure/design/implementation of the item being tested is known to QA team
- Black-box: Internal structure is not known hence it solely depends on the functional/non-functional requirements
- Gray-box: A hybrid method involving both functional & structural tests
Generally a system comprises of multiple integrated components. One of the common Software Testing Interview Questions is – As a QA you have worked on what all test levels?
- Unit Tests (Developer): Done by developers as soon as they develop a certain code, if its working or not.
- Component Testing (QA): Individual component testing by the QA team, without integration with other components. This is to verify that standalone components are working as expected.
- Integration Testing (QA): Testing of the interfaces between different system, so as to confirm that different components can work together in harmony
- System Testing (QA): Testing of the system as a whole
- User Acceptance Tests (Business Users): How does client accept your test result without system walk-through? Business Users walk-through the system during the UAT phase in order to provide approval / sign-off.
Testing Types (types of software testing)
Testing Types define the different aspects of the software which you are going to cover as part of your Test efforts. Will it be only Functional? Or are you going to measure the system performance as well? What about the database schema? What if the Banking application you are testing is secure or not? Will it work on Mobiles as well? There are numerous Testing Types one can opt for now-a-days, for e.g. Functional, Security, Performance, Mobile App Testing, Cloud Tests, IoT Tests, Database Testing, ETL tests, etc.
Another one from Software Testing Interview Questions – Any trick or best practice that you follow irrespective of the Testing phase or methodology? also known as a Testing Technique. Over the years, certain tricks have been accepted by the Test fraternity as the best practices – be it for Test Design or Execution. For e.g. Equivalence partitioning, Boundary Value Analysis, Cause Effect Graphing, Control flow testing, Data flow testing, Branch testing, Path testing, etc.
What will be the sequence of your Test execution? Or rather how many sets of Test cases will you execute? What will be the approach to fixed defects? How will you organize the test execution phase in particular? The general practice is:
- Sanity tests: Verifying the basic application functionalities & features. This works as a sign-off for the developed build to enter the test execution.
- Cycle 1: Execute ALL the test cases against the deployed build & log the encountered defects in tracking system. Retest the defects as & when it is fixed.
- Cycle 2: Re-execute ALL the test cases to ensure all the defects have been fixed, retested & closed.
- Regression Testing: Execute a pre-designed regression suite to ensure that defect fixes haven’t impacted the already-working functionality.
Any article, item or object you produce as a QA team. Unlike development, there is a horde of documentation involved in Testing activities. Every Testing phase has a set of pre-defined testing deliverables – Test Plan, Test cases, Test Report, etc.
These are some of the most common software testing interview questions. The interview generally starts with your resume, and then moves on to general QA concepts. Unless you have these terminologies sorted out – god save you the embarrassment. Hope “Software Testing Studio” helped you get some facts clear. Stay tuned for our next round of software testing interview questions!
Social Discussion that ensued
A transcript of the discussion that happened over this post on the Social media. Feel free to add your inputs in the comments section…
Paul Seaman: We really have stop putting out stuff like this article. Testing should have gone well past this by now. These are not questions that will help you find a good tester. Make these questions the foundation of your test interview and, well, you were warned.
Kanchan Kapoor: Agree with you Paul Seaman that the Testing has gone past this, but only for the experienced. For entry-level testers, they still need to clarify these terminologies to better understand the current changes. Only when you know the history, you can understand the present, i.e. what is the ‘change’ actually!!
Paul Seaman: These questions tell me if someone can remember things, they tell me little about their aptitude for, or their desire to, test software. There is a big difference between remembering and understanding. There is a big difference between understanding and applying. There are much better ways to interview than asking these kinds of questions.
Kanchan Kapoor: Paul Seaman – Would love to read about some kick-off interview questions then…
Paul Seaman: Why does the interview have to be predicated on questions? There are other ways of having useful discussions about testing. Questions about testing don’t have to be planned or scripted. Think about how you might achieve this. I’m not planning to write an article about interview kick off questions when I don’t believe in that as a particularly effective way of progressing. Perhaps you can write about ways of running interviews that don’t involve the approach you wrote about.
Kanchan Kapoor: Thanks for the clarification Paul. I understand your view-point now. But most of the organizations have ‘Interview’ to hire rather than a healthy ‘Discussion’. I agree that a discussion would benefit more in selecting the right candidate, but only a few follow it. Interviews are mostly scripted knowledge-checkers with some flavor of situational/scenario-based discussion. But Yeah! It would be a good change from formal ‘interview’ to a candid ‘discussion’ – for adoption, will take some time though! Anyways thanks for the inputs Paul!
Brijesh Deb: These questions are kind of obsolete in the current context. They certainly are appropriate but are more towards the theory behind all the testing you (some might even have a different opinion about this theory).
Off late the questions are a lot more pragmatic and focused on solutions to real world testing challenges. For example, how would you strategize the testing for a customer who wants to do a real-time implementation of his current software?
If you look at the theory, it would lead you model based testing but that may not suffice so you will need to probe and that’s how the testing skills and acumen of a tester would come out.
I have been doing interviews with people and every interview is different from the previous one because the candidate is different. The job may be the same and skill set needed to but no two individuals have the exact same personality.
Testing is a very highly skilled profession and hiring of testers needs to be meticulous!
Paul Seaman: Kanchan Kapoor you said “But most of the organizations have ‘Interview’ to hire rather than a healthy ‘Discussion'”. If you are interviewing and not having discussions, what are you doing? If you are asking questions and expecting people to recite back answers you agree with, that’s a shallow approach (and IMO, not very useful). Discussions tell you much about a person beyond technical knowledge. You seem to focus on memory, I prefer to focus on critical thinking, imagination, lateral thinking, collaboration, etc. when interviewing. I learn a lot about people this way. You might want to consider why you would place some fundamental test knowledge above other personality traits. You can teach somebody the fundamentals you mention quite quickly. Try changing someone’s personality or attitude, that’s not quick, not easy and sometimes not possible.