5/5 - (1 vote)

Q1. What is Software Testing?

Say you want to transfer 10K INR to your friend via Net banking. You make the transaction & inform your friend. But when you check your SMS, it says 11K INR has been debited from your account. How do you feel? Frustrated? Angry? Resolution to change your Bank? I.e. if you don’t like testing your product, most likely your customers won’t like to test it either.

To make it right, you first need to identify what’s wrong. And when it’s about finding the wrong in software, we call it “Software Testing”! Testers don’t break software, software is already broken. As simple as that. To tell somebody that they are wrong is called criticism. To do so officially is called Testing 🙂 it’s the software analysis in order to find defects to be corrected. It provides customers, client, and stakeholders with information about the quality of the product or service under test – whether it meets the requirements that guided its design and development.

Officially:

“Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users.”

Also check Software Testing Career FAQs

Q2. What’s the difference between Test Matrix & Metrics? Any examples?

Metrics: a scale for measurement, we can’t control things which we can’t measure – i.e. no. of defects identified, count of test cases executed, execution productivity, and test completion % age – anything that can be expressed in numbers or % age, generally to track performance (& take corrective actions if required)!
Matrix: remember the mathematics’ concept you studied at school? Applying it to Software Testing – ‘Matrix’ is nothing but a tabular structure representing the relationship between rows & columns. Now what would a Test team want to relate? A simple example would be ‘Requirement Traceability Matrix’ – Requirements >> Test Scenarios >> Test cases >> Execution status >> Defects. & why to use RTM? Simple, to measure Test coverage w.r.t. clients’ requirements – every requirement has been tested & every defect resolved successfully.

Q3. What’s the difference between Mistake, Error, Bug, Defect, Fault and 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!

Q4. What do you mean by ‘Mobile App Testing’?

Mobile App Testing: As the terminology states, it’s the Testing of Mobile Apps keeping in mind the holistic view, i.e. Devices, Operating Systems, Networks, Usability, Performance, Security, Blah Blah Blah…to ensure that your App is easy-to-use, free of bugs, User-friendly, works with every platform, is secure – which places you much ahead of the competition. With different permutations & combinations & focus on Quality – a holistic Testing Strategy is as important as the App Idea itself.

“Mobile App Testing” is nothing but a holistic Test Strategy to maintain the “App Quality” in order to stay ahead of the competition so that End-Users approve (install) the App and in turn spread positive word-of-mouth, thus benefiting the overall Business.

Q5. What are the different phases of Software Testing Lifecycle (STLC)?

‘To make it Right, first identify what’s Wrong’ – but how? How do you identify what’s wrong? Intuition says – Just give me the application and I can find what’s wrong (defects), right? Nah! We are not workers, we are professionals. How do you build customer confidence with your ad-hoc tests? After all, Client is paying you to get the job done. And he/she wants ‘Quantitative’ reports & a ‘Quality’ product at the end. So how do you make sure that your Client is happy? Forget about ‘Software Testing’ – in any Technical background, how do you make sure that your Client is super-happy @ the end?

Lifecycle as in how a product or process grows to maturation, from inception till the end. And at every phase you keep the client updated of the progress via a set of deliverables.

Requirement Analysis (What): Understand client’s business & what does he/she wants
Test Planning (What, How, When, Where & Who): Plan it how you are going to deliver, the activities involved
Test Designing (How): Draft the detailed steps to-be-completed
Test Environment Setup (Where): Identify the vendors & procure all the necessary items
Test Execution (Just do it): Execute the detailed steps using items identified above
Test Closure: Deliver the quality product
Post-implementation support: Support your deliverable for certain duration (training, etc.)
Retrospection: Take a Retrospective look as to what can be improved the next time

Q6. You have worked on which all Test Levels? OR What are the different Test Levels?

Generally a solution comprises of multiple integrated systems. As a QA what will be the level of your tests?

Unit Tests (Developer): Done by developers as soon as they develop a certain code, if it’s 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 systems, so as to confirm that different components can work together in harmony.
System Testing (QA): Testing of the system as a whole.
End-to-End Testing (QA): What if multiple systems are involved? E.g. Payment processing starts when you initiate a payment from the front-office (Net banking website) >> It goes to mid-office for routing >> Reaches the correct back-office where it is finally settled. E2E Testing involves verifying the E2E functional flow involving multiple systems.
User Acceptance Tests (Business Users): How does client accept your test result without system walkthrough? Business Users walkthrough the system during the UAT phase in order to provide approval / sign-off.
Beta Testing (End-users): Giving access to a set of end-users to gauge system usage feedback.

Q7. What do you mean by Functional & Non-functional testing? OR What are the different types of Software Testing?

Broadly, Testing Types can be distinguished as either Functional or Non-functional, i.e. you need to validate the functional aspects like functions, compatibility, user interface, etc. OR you need to validate the performance, security aspects.

Functional Testing – The most-essential Test type, Functional testing focuses on testing the software against design document, use cases and requirements document – that it correctly performs all its required functions.
Non-Functional Testing – Here, you are not testing the software for any functionality. Instead the focus is on non-functional aspects like performance, load, accessibility, localization, security, reliability, recovery, etc.

Functional & Non-functional are the root testing types and every other type falls in either of the one category.

Q8. What is the difference between Performance, Load, Stress and Volume Testing?

Performance Testing – The objective is not functional but to uncover performance issues such as network delay, data rendering, database transaction processing, load balancing between servers, throughput, response time, etc. (speed and efficiency of the system). Performance covers Load, Stress & Volume testing.

Load Testing

Load as in testing the ‘capacity’ of the application under test. Didn’t get it? The common scenario in most of the IT firms – the company portal cannot be accessed as soon as you get the news that appraisal letters have been released J the reason – Load testing wasn’t performed. The portal couldn’t handle the Users’ rush or concurrent access to the system.

The objective is to check the behavior of the software under normal and over peak load conditions – at what point the system’s response time degrades or fails.

Stress Testing

When do you get stressed? Yeah! When we can’t handle the pressure. To a certain limit, we can handle the tension but beyond it – stressed.

Similarly a software is built to handle a certain load, beyond that it breaks. The objective of ‘Stress Testing’ is to test the software under abnormal load conditions (beyond the acceptable limit) and then its performance is monitored to observe how the software would behave at breakpoint. There are many ways of creating abnormal conditions – the database can be turned off and on, complex database queries, continuous input to system, database load or network ports can be shut or restarted randomly.

Volume testing

Volume (meaning ‘Bulk’) testing is carried out to find the response of the software with different sizes of the data being sent/received or to be processed. E.g. If you were to be testing Microsoft word, volume testing would ensure if word can open, save and work on files of different sizes (10 to 100 MB).

Q9. What do you mean by ‘Penetration Testing’?

Also known as PenTest in short, it’s a type of security testing. The objective is to gauge how secure software and its environments (hardware, operating system and network) are when subject to attack by an external or internal intruder. Intruder can be a human/hacker or malicious programs. Pentest uses methods to forcibly intrude (by brute force attack) or by using a weakness (vulnerability) to gain access to a software or data or hardware with an intent to expose ways to steal, manipulate or corrupt data, software files or configuration. Penetration Testing is a way of ethical hacking, an experienced Penetration tester will use the same methods and tools that a hacker would use but the intention of Penetration tester is to identify vulnerability and get them fixed before a real hacker or malicious program exploits it.

Q10. How do you ensure Test coverage? OR What’s RTM & why to use it?

What’s the basis for the Test coverage? Yeah! Requirements – functional, technical & non-functional – every single requirement needs to be tested. What if by mistake the Test team over-looked one of the requirement & didn’t write test cases for it? How will a Test Manager or Client come to know about it? ‘Requirement Traceability Matrix’!

A traceability matrix is a document that co-relates any two baseline documents (section to section) that require a many-to-many relationship to check the completeness of the relationship, i.e. to ensure that everything within both documents is related in any way!

Applying the concept of Traceability matrix to requirements, i.e. one of the reference document will always be ‘Requirements Specification’. In simple terms, Requirements Traceability Matrix (commonly known as RTM) is a tool (mostly excel document) that traces requirement throughout the validation process, i.e. Requirement Analysis, Test Design, Test execution & Closure phase.

How? Simple mapping – Requirement IDs >> Test Scenario IDs >> Test cases IDs >> Defect IDs (including final status)