Q1. Can you explain in detail the two common methodologies of software development?

Ans: In order to answer this question effectively, it is a good idea to discuss the main methodologies of software development which are Waterfall and Agile in detail. Here is how you can explain these two methods - 

• ‍Waterfall Method of Software Development- This method of software development first focuses on gathering requirements and based on the requirement, a specification document is created. It is this specification document which is the key driver for the design and development of the software. At the end of the software development cycle, the testing team tests the software.

• ‍Agile Software Development Model- This model of software development is different from Waterfall Software Development Model. This model works in small repetitions. The process of testing of the software is carried on simultaneously along with its creation. First, the process begins creating small functionality based on the requirements. This functionality is then tested and after receiving feedback from the customers, future course of development is decided.

‍

Q2. Is it a good idea for developers to test the software written by them? What is your opinion on this?

Ans: It is often said that developers are not good testers. One of the main reason for this belief is that they test the code with an intention to make it work rather than testing ways in which it may not work. Also, the developers are usually very optimistic about the code they have written and lack the attitude needed for testing. Many times, developers also miss the important aspects of testing which only an experienced tester would conduct with an intention to break the software. 

However, it would be incorrect to say developers must not test software. Testing done by developers often helps to identify bugs present due to programming errors. These bugs are mostly missed by the tester due to inaccessibility to source code. 

‍

Q3. Are you aware of the golden rule of “Test driven development?

Ans: This is a straight-forward question attempting to test the basic know how of test- driven development. Test driven development emphasizes on creation of test cases even before the actual code is written. This means that the codes for tests are written before the codes for the main application are written.

‍

Q4. Can you explain the difference between a latent bug and a golden bug?

Ans: A latent bug is a low priority bug which is present in the system since its earlier releases. These bugs are usually dormant. A golden bug, on the other hand, is a bug which surfaces in every release of the system. It is a high priority bug and is capable of impacting the critical functions of the system. 

‍

Q5. Please explain the process of creating a test script. 

Ans: Creation of a test script is a step by step process which begins with end to end understanding of AUT. This process begins with a careful read of the requirement document. In case requirement documents are not available, it is advisable to gain understanding of any particular point of reference for instance, a previous version of the application. 

The next step is to identify the areas of the application which need to be tested. This is also referred to as identification of test requirements. This step leads us to a list of test scenarios. 

The final step in the process of creating a test script is to decide the process of testing. In this step, detailed steps are written mentioning the process of testing a specific part of the application, data which needs to be entered and the results thus expected. At the end of these steps, the stage is set for the process of testing to begin. 

‍

Q6. How did you manage a challenging situation of testing when you did not have input documentation for testing?

Ans: This is a common situation for a tester which aims to gauge your experiential knowledge. In the absence of standard documents like BRD and FSD, most testers choose to depend on point of reference like screenshots or a previously available version of the application. It is also a common practice to have a discussion with the developers to get a thorough understanding. In a rare situation when none of this is available, a basic set of test scripts can be developed which is based on the experiential knowledge of the tester. During the phase of testing, test case management and setting up of some test cycle time can help create documents for subsequent phases. 

‍

Q7. Are the terms ‘test scenario, test cases and test script’ different from each other?

Ans: Here are the differences between test scenario, test cases and test scripts. Test cases refers to the set of documents which have the steps that need to be performed for the purpose of testing. Test scenario refers to the functionality of the application which must be tested. It is also referred to as Test condition. Test script is a program written with the help of a programming language and is useful for the testing an application’s functionality. In simple language, test script is a compilation of manual steps which need to be followed during testing. 

‍

Q8. Can you briefly explain mutation testing?

Ans: Mutation testing is a popular technique of testing where small modifications are made to the code with an intention to ensure usefulness of test cases. The purpose is to develop new software tests and also run quality checks on the already existing software tests. 

‍

Q9. Please explain the different types of defects.

Ans:  Defects can be of three types. These have been mentioned below- 

• Wrong- This is a defect where the requirements are not implemented properly as against the specified ones. 
• Missing- Missing defects usually happen when a particular requirement or specification has not been met. For instance- when a link or information is missing because of which the specifications could not be implemented in the correct manner. 
• Extra-When an extra or additional feature is added to the final product, which was not mentioned in the requirement or specification, it is considered a defect. 

‍

Q10. Can you talk about risk- based testing?

Ans: Risk based testing is a process in which test are executed in the order of priority based on risk. The execution is based on a thorough risk analysis which helps to categorize risks in the order of priority. This enables resolution of high priority risks first. 

‍

Q11. Explain the difference between Debugging and Unit testing?

Ans: This is a popular choice of question for interviewers as both, debugging and testing are executed by developers. In debugging, the tool verifies the code line by line and checks for any syntax or programming issues like runtime exception. In simple words, debugging can be defined as the process of bug removal from a software. 

Unit testing aims to test a particular unit. The purpose of unit testing is to validate the functionality which is executed by the developer. This is essential to reduce bugs at later stages of testing like integration testing. 

To summarize, we can say, while the process of testing displays the error, process of debugging is deductive. Also, testing can be automated but debugging is a manual process. 

‍

Q12. What do you understand by Test Harness?

Ans: A test harness is a compilation of software and test data which is set up with the aim of testing a program under varied conditions. It involves evaluating output as against the expected output. 

‍

Q13. What do you understand by test closure?

Ans: Test closure is the last document prepared by the testing team before concluding the process of testing. This document carries important information like total number of test cases, total number of executed cases, number of defects identified and fixed and if any bugs were left unfixed. 

‍

Q14. Can you enumerate the tasks of test closure activities in Software testing?

Ans: This question may seem tricky to answer at first considering the exhaustive list of activities, however, a simple trick that works is to categorize all the test closure activities in groups. There are four main groups which are mentioned below- 

• Completion check for tests - This check ensures that all the tests have been executed and the identified defects have been fixed or will be fixed in future release. 
  ‍
• Handover of test artifacts - This involves handing over of tests and tests environment to the team responsible for maintenance testing. Every defect which was identified (fixed or deferred) must be mentioned in a document and informed to the users of the system. 
  ‍
• Document learnings from testing - It is important to analyze the lessons learnt to keep a check on any changes which may be required in he future releases. Also, this helps to create a list of best practices for future. 
  ‍

The final step is to archive all reports, logs and supporting documents in the configuration management system. 

‍

Q15. What do you understand by thread testing?

Ans:  To answer this question successfully, it is important to understand that a software is divided into multiple threads and each thread is responsible for a task. At the time of integration of all the components of the software, it is imperative to make sure that the programs run as expected. Thread testing is yet another variation of top-down testing aiming at authenticating the main functional abilities of a particular thread (task). This testing is generally executed during the primitive stages of integration testing phase. 

‍

Q16. Can you explain how thread testing is performed?

Ans: As mentioned in the previous answer, thread testing is done at the primitive stage of the process of system integration testing. This is the main reason why it is imperative to arrange the modules in the right order so that they can be integrated well as a complete system. Below are some effective methods for integration of these modules- 

• Big Bang Approach - In this approach, there is only one single step for integration of all modules. This approach is most suitable for small systems. 
• Top-down approach - This approach begins with testing of the modules at the top level and then moving to testing of the subroutines. 
• Bottom up approach - In this approach, the individual subsystems are tested before the complete system is tested. 
• Mixed integration testing - This approach is a blend of top-down and bottom up approach. 

‍

Q17. Please explain the types of thread- based testing. 

Ans: Thread based testing is broadly classified into two types-

• Single thread testing- In this approach of thread- based testing, one transaction is tested at a time. This makes the process of testing a time consuming one as the response time is much longer. This type of testing is beneficial when the written code needs to be evaluated. 
• Multi-thread testing- In this type of testing, instead of a single transaction, multiple transactions are tested at the same time. In order to conduct this type of testing, separate threads are prepared for a given service or also to test the response time of a request. 

‍

Q 18. Which of the two types of thread- based testing is a better choice? Explain your reason.

Ans: Generally, multiple-thread testing is considered to be the most popular choice. This is so because multiple resources are able to work on a request at a given time which boosts the performance of the application and makes it quick. 

‍

Q19.  What do you understand by DOA? 

Ans: DOA refers to Dead on Arrival. It is a common term used to refer to those application builds which are not suitable for testing. Below is a list of scenarios in which an application may be declared DOA.

• When the application is unstable and crashes frequently.
• A situation in which the functionalities of the application described in the release notes are either missing in the build or not available for testing. 

‍

Q20. Describe the process you will follow when you detect a defect?

Ans: This question is yet another of the favorite questions of the interviewers. You must showcase your experience and knowledge and think of a real- life situation when you identified a defect. Then, talk about the step wise process you followed. Here is what you can say- 

The first thing to do is to recreate the defect to ensure consistency. Recreation of the defect must be done on a different browser or a different Operating System to identify if the defect is present on a particular device or across all devices. 

It is advisable to take a screenshot of the error before the required logs are collected.  Lastly, you can create a log of these details into the bug tracking tool in use. 

(Here, you can talk about the bug tracking tool which you have used in your previous organization). 

‍

Q21. Can you explain the difference between a latent and a masked defect?

Ans: Latent defects are defects which exist in the system but cause no impact on the functionality of the system. This is so because they do not meet the preconditions set for defects. 

Masked defects, on the other hand, are the ones which hide behind any other defect and are detected only when the other defect is detected. 

‍

Q22. How do you explain exit criterion and in what situations do we use it?

Ans: Exit criteria is a compilation of those situations in which the process of testing may be terminated at any point during the course of the project. It serves as a very important guide for rejection of the testing build while the project is being executed. Here are some examples of some of the common exit criteria.

• Absence of data in the application.
• Failure of the smoke test.
• Failure to login
• Failure due to build
• Crashing of application during critical functionalities.

‍

Q23. What do you understand by Smoke test?

Ans: Most companies follow a positive smoke test result as the first step for accepting a build for further course of testing. It is the first test and aims to ensure if the functionalities are working and if the build is suitable for testing. Here are some essential features of smoke testing- 

• It finds those critical functionalities which are essential to business and must be satisfied by the product. 
• It not only includes the designing of fundamental features and its execution. 
• It aims to ensure that smoke test is passed for each build in order to proceed with testing of the build. 
• Smoke testing unveils the basic errors which saves time and efforts of the testers. 
• Smoke tests can be both manual or automated.

‍

Q24. Have you heard the new buzzword called ‘Crowdsourced testing’? Can you explain it?

Ans: Crowdsourced testing is relatively a new approach to testing which amalgamates technology and human skills. It helps people (either testers or users) to utilize their technical knowledge and experience to reach quality improvement. In a lot of situations, this method of testing has proven to have yielded realistic results. The process of crowdsourcing includes the below mentioned steps -

• It includes sourcing skilled testers across levels who are suitable to carry out the task in the organization.
• It also involves creating a pool of users and testers based on evaluation of their performance over a period. This provides essential feedback on various aspects of product development. 
• Collaborating with multiple organizations and institutions strengthens knowledge and can be showcased to users. 

Overall, crowdsourcing is combination of efforts of a crowd of people who are working at separate locations however, contribute to the task with their knowledge and skills thereby resulting in superior results. The entire process of testing is managed by a project manager. It provides flexible options to testers with respect to their payment, work location and testing options which has led to many testers choosing crowdsourcing as a secondary job. 

One of the leading examples of crowdsourcing is Wikipedia which is an outcome of information shared by writers and editors from crowd. 

Crowdsourcing is a process that involves 5 stages. These have been explained below - 

1. The first stage is the stage of preparation which involves needs analysis of the client and their overall expectation. This stage is crucial as the decisions about designing of test plans, skillset required, payments and expected results to delivered are discussed here. 
2. The second stage is where the test cases are defined and crowd testers are onboarded. This stage also sets the work environment. 
3. The third stage is where the real action happens. It marks the beginning of testing on required software and devices. The performance of the testing teams is monitored to keep a track of the goals. 
4. The next stage includes evaluation of performance of testers. Outcomes achieved are validated and quality checks are run. This stage ends in processing of payment to the testers after the client’s deliverables are ready. 
5. The final stage is a completion stage where a detailed report of results is presented to the client, performance of the crowd testers is rated and test cycle is completed. 

‍

Q25. Explain the difference between Crowdsourcing and Outsourcing?

Ans: Crowdsourcing and outsourcing are both a new approach to getting work done. While crowdsourcing involves combined efforts of skilled people working at separate locations. The entire process of testing is online. The testers working in this model get paid only in a situation when the task is complete, i.e. the bug is detected and diagnosed. 

Outsourcing, on the other hand requires the testers to collectively work in the same workplace. The payment of the testers in this model is not dependent on the result of their work. One example of outsourcing is BPO (Business Process Outsourcing). 

The table below mentions a few more points of difference between the two.