Top 75 Manual Testing Interview Questions

Manual testers will always be in demand. Without manual inspection, the emotional engagement of the software cannot be measured. But to get that dream salary package in that dream company, you need to crack the interview. Both verbal and in the form of tasks.

For all the aspiring testers, freshers, and experienced ones who are looking for a job change, please have a look at these manual testing interview questions before going for the interview.

Like it’s mentioned before, the Q and A used in these blogs can be helpful for

  • Manual testing interview questions for freshers
  • Manual testing interview questions for experienced
  • Manual testing interview questions for 2-5 years experience

Before digging deep let’s have a look at questions that have frequently been asked. FAQ!

  1. What is the Severity and Priority of a bug?
  2. What is a traceability matrix? Why is it important?
  3. What are the different levels of testing?
  4. What are the most common risks associated with project failure?
  5. What is an exit criterion and why is it used?
  6. What are the details included in a test case?
  7. How does testing fit into a CI pipeline?
  8. What is risk-based testing?
  9. Name some best practices in software testing
  10. What are the qualities of a good tester?
  11. Name some challenges in software testing?

Manual Testing Interview Questions and Answers pdf

Q 1: What are the 2 main types of testing?
Ans: The 2 main types of testing are:

  • Manual Testing: where the testing activities are performed by testers without the help of any tools.
  • Automation Testing: where the testing is carried out with the help of tools or stand-alone scripts that can replicate the manual operations performed.

Q 2: What is BVA?
Ans: BVA, Boundary Value Analysis, is a validation technique used for checking the edit boxes that take in numbers. For example, if a field takes the values 1 to 100, under BVA you would test the field with values +1 and -1 from the boundaries. So, in this case, the tester would check to see if the field with values 0,2,99, and 101.

Q 3: What is DOA and how is it used?
Ans: DOA, Dead on Arrival, is used to refer to applications build that are unsuitable for testing. There can be several situations where a build is declared as DOA. Some of these are:

  • Smoke Test fails
  • Application is unstable and crashes intermittently
  • The functionalities mentioned in the release notes are not included in the build or are not available for testing

Q 4: What is the Severity and Priority of a bug?
Ans: The severity and priority are important aspects of a bug. The Severity is decided by the tester based on the impact on the testing and the functionality of the application. For example, an app crash or user unable to login, back end server down, etc would all be high severity defects.

Priority on the other hand is decided by the developer based on how soon they can fix it or how much time would be needed to fix the defects.

Some in most cases high severity and high priority bugs would be the same. But there can be some cases where the Severity is low but priority is high. Like a spelling mistake in the company name on the home page.

Now, an example of high severity but a low priority can be unable to open a link in a web page, when the link is rarely used by the customer.

Q 5: What is a traceability matrix? Why is it important?
Ans: Traceability matrix is the link between a client requirement or use case and the test case.

While writing a test case, a tester should ensure there is at least 1 test case for every use case of functional requirement. This mapping between the requirements and test cases is called traceability.

The traceability matrix helps to ensure that each requirement in the functional document is considered for testing, thus avoiding any misses.

Q 6: What are the different levels of testing?
Ans: Testing is done at different levels, they are

  • Unit testing or component level testing
  • Functional and module testing
  • Integration testing
  • System testing
  • Acceptance testing

Q 7: What is a test plan?
Ans: A test plan is a document that enlists all the aspects of the testing project. Some of the main headers under a test plan are:

  • In scope and out of scope features.
  • The hardware, software, and resource requirements
  • Entry and exit criteria
  • Test strategy
  • Test deliverables
  • Risks and contingencies
  • Roles and responsibilities
  • Escalation mechanism

Q 8: What is the difference between regression and retesting?
Ans: Regression testing refers to repeated testing of the functionalities already delivered and tested in previous testing cycles.

Regression testing is done to ensure that the new code changes in the current build have not broken or adversely impacted any previous functionalities.

In many companies, regression testing is automated to ensure more time can be dedicated to the thorough testing of the new features.

Retesting, on the other hand, refers to rechecking the defects after they are fixed, to ensure the issue is completed resolved.

For retesting, a tester would perform the same steps as mentioned in the defect steps to reproduce to ensure the defect is fixed, and then based on their discretion they would also check areas that might get affected by the defect fix.

Q 9: What is a defect?
Ans: Any deviation from the expected behavior of the application can be termed as a defect.

Q 10: What are the different stages in a defect life cycle?
Ans: The different stages in a defect life cycle are:

  • New
  • Assigned
  • Fixed
  • Moved to QA / Ready to test
  • Retested
  • Closed
  • Reopen
  • Duplicate
  • Redundant
  • Moved to next iteration / Deferred

Q 11: What is a latent defect?
Ans: There are some defects in the system that may not cause failures or impact the customer usage of the application because the preconditions for these defects are rarely met.

Such defects that are silently present in the system are known as latent defects.

Q 12: What are the most common risks associated with project failure?
Ans: The most common risks are:

  • Shortage of time or squeezed timelines
  • Shortage of skilled resources to perform the testing activities
  • Limited Budget
  • Absence of a stable environment for testing

Q 13: What are stubs and drivers?
Ans: Stubs and drivers are used in incremental testing. Testing follows either a top-down or a bottom-up approach.

In the top-down approach, a stub is used to help in the testing of other modules. Similarly, a driver is used in the bottom-up approach for facilitating the testing.

Q 14: What would you do if you find a defect?
Ans: Here is what you should do once you find a defect.

  • Recreate the defect to make sure it is consistent
  • Try to recreate the defect in a different device, browser, or OS to make sure if it occurring everywhere or is specific to any particular device, browser, or OS.
  • Take the screenshot of the error
  • Capture the required logs as applicable
  • Log the details in the bug tracking tool used by the team

Q 15: What is fuzz testing?
Ans: Fuzz testing is commonly used in security testing to find vulnerabilities and coding errors in the system. In fuzz testing, data is added to the system to make it crash.

Sometimes, a fuzz tester is also used to find the causes of the vulnerability as well. It is mostly done in big projects and may not prove cost-effective for smaller projects.

Q 16: What are the test cases you can create for a simple login screen with username, password, and login buttons?
Ans: Some of the test cases that can be created for the login screen are:

  • Test cases for login edit box, what type of characters it can take.
  • Test cases for password edit box, what type of characters it can take.
  • Password should be masked and should not be visible
  • Valid credentials should allow users to log in and move to the next screen
  • Invalid credentials should block the user, the appropriate message should be displayed
  • Username blank – appropriate message should be displayed
  • Password blank – appropriate message should be displayed
  • The edit boxes should be aligned properly
  • A forgot password link should be available
  • Appropriate labels should be written for the login and password edit boxes

Q 17: What is the difference between a latent and masked defect?
Ans: Latent defects are those that are existing in the system but do not impact the functionality since the preconditions for the defects are never met.

A masked defect, on the other hand, is those which are hidden behind another defect. And they can be found only once the other defect is found.

Q 18: What techniques can be used to understand the test coverage?
Ans: The 3 different techniques used for ensuring the test coverage are:

  • Statement coverage: testing ensures that each line of the code is executed at least once.
  • Decision coverage: testing is done to ensure that each path of the decision code loops and decision boxes are executed at least once.
  • Path coverage: testing is done to ensure every possible code path for a particular functionality is executed at least once.

Q 19: What is a code walk-through?
Ans: A code walkthrough is an informal analysis of any code to check if the logic is correct and if the proper coding standards are followed. It is an unmoderated review.

Q 20: What are the different parts of a defect report?
Ans: A defect report would ideally include:

  • Summary
  • Tested By
  • Assigned to
  • Tested environment
  • Build No.
  • Severity
  • Steps to reproduce
  • Expected and Actual Results
  • Screenshots
  • Logs
  • Defect status
  • Comments

Q 21: What is an exit criterion and why is it used?
Ans: Exit criteria list the conditions in which the testing would be stopped at any point in the project.

It is very useful during the project execution as a guide to reject the testing build.
Some of the main exit criteria are:

  • Build Failure
  • Login failure
  • App Crash in critical functionalities
  • No data in the application
  • Failed smoke test

Q 22: What is alpha testing?
Ans: Alpha testing is the testing done by a subset of potential users or clients in the developer’s site with the development infrastructure.

Q 23: What is beta testing?
Ans: Beta testing is the testing done by a subset of the potential users or clients at their locations which is generally different from the environment where the product was developed.

Q 24: What is crowdsourced testing?
Ans: Crowdsourced testing is a new and upcoming form of testing that involves people, not necessarily testers, from across the globe to test the product and provide their feedback. These people get paid to perform the task.

Q 25: What is a smoke test?
Ans: A smoke test is the first test that is done to ensure the shared build is ready for testing and the critical functionalities are working.

In many companies, the build is accepted for further testing only if the smoke test is a pass.

Q 26: How does testing fit into a CI pipeline?
Ans: In a CI pipeline all the tasks are automated, hence testing is also automated.

A trigger is set to start the testing suite every time there is a new code check-in and build.

Once the testing is complete a pass/fail report is sent out to the stakeholders and based on the results the decision is taken to push the build to production or to roll it back.

Q 27: How is testing possible in the agile/scrum sprints?
Ans: In Agile and Scrum the testing would start early along with the development. As and when a block of code is ready, testing starts for that functionality with the help of stubs, drivers, and harness.

Q 28: What are positive and negative testing?
Ans: Positive testing refers to all the happy paths where the application performs as expected with the correct input.

Negative tests, on the other hand, involves giving incorrect data to the system to ensure it responds appropriately.

Q 29: What is an exploratory test?
Ans: Random tests that are done without any pre-decided steps to just traverse through the application and find defects are called exploratory testing.

Q 30: What is DRE?
Ans: DRE, defect removal efficiency, a metrics commonly used for evaluating the effectiveness of the testing process. It is defined as the percentage of the defect found in testing by the sum of defects in testing and production.

Q 31: What is the career path for a tester?
Ans: Just like a developer there is a great career path for testers. It starts with a tester or junior tester, test analyst, test lead, test manager, and test consultant.

Q 32: What are the roles and responsibilities of a tester?
Ans: A tester is expected to

  • Take care of the day to day testing activities
  • Report bugs when found
  • Retest the bugs

Q 33: What are the roles and responsibilities of a test lead?

Ans: A test lead would

  • Assign the tasks to the team members
  • Monitor the defects raised by the team
  • Participate in defect triages when required.
  • Consolidate and share the daily or weekly testing status with the manager
  • Help the manager while creating a test plan
  • Inform the manager of any foreseen risks

Q 34: What are the roles and responsibilities of a test manager?
Ans: A test manager is responsible for

  • Getting the testing projects from clients and stakeholders
  • Preparing and presenting the strategy document
  • Preparing the test plan with the help of a lead
  • Help the team with the resources needed
  • Help the team with mitigating the risk
  • Prepare and present the testing metrics to the team
  • Help in escalations as and when needed

Q 35: What are the different types of testing. Name a few types in each.
Ans: Testing can be divided mainly into 2 types:

  • Functional Testing: It deals with testing the functionality of the application under test. Some of the testings under functional testing are:
    1. Unit Testing
    2. System testing
    3. User Acceptance testing
    4. Integration testing
  • Non-functional testing: it involves testing the non-functional features like performance, scalability, security reliability, etc.
      1. Load testing
      2. Stress testing
      3. User Acceptance testing
      4. Security testing
      5. Endurance testing
      6. Installation testing

     

Q 36: What are the stages in the software testing lifecycle?
Ans: The stages in the software testing lifecycle are:

    1. Requirement Analysis
    2. Test Planning
    3. Test Case Development
    4. Test Environment Setup
    5. Testing
    6. Test Closure and deliverables handover

Q 37: What are the qualities of a good tester?
Ans: Some qualities of a good tester are:

    1. An eye for finding details and mistakes in the system
    2. A good understanding of the application under test and how the users would be using the application
    3. A good domain knowledge
    4. Good communication skills are important for a tester
    5. Good contacts within and outside the team help the tester reach out to people and get issues resolved easily speeding up the process.

Q 38: What is cross-browser testing?
Ans: Cross-browser testing refers to testing a web application on different browsers like Chrome, Firefox, Edge, Safari, etc. to ensure it performs equally well in each.

Q 39: What is responsive testing?
Ans: Responsive testing involves testing a website or mobile app on devices of different screen sizes to ensure it renders properly in each device. This testing also helps to eliminate any alignment issues during the rendering.

Q 40: What is a software bug?
Ans: Any deviation from the expected functionality of the application as documented in the specifications document is called a software bug.

Q 41: What is black box testing?
Ans: A type of testing where the tester understands and has access only to the input and output of a system through a graphics interface is called black-box testing. Here the tester would not know the code or how it is written.

Q 42: What is white box testing:
Ans: In white-box testing, the tester has access to the code implementation.

The test cases are designed to cover the different paths and loops in the implementation.

For white-box testing, some basic coding knowledge and background are an additional advantage.

Q 43: What are the advantages of manual testing?
Ans: The advantages of manual testing are:

    1. It is more suitable for small projects
    2. A tester can find more bugs when performing test cases unlike automation
    3. The test cases can be easily tuned to adjust to the changes in the code and UI
    4. Difficult scenarios and switching between systems and modules can be easily done
    5. Very useful in ad-hoc, exploratory, and usability testing
    6. Needs fewer skills and can be learned easily

Q 44: What are the disadvantages of manual testing?
Ans: Some disadvantages of manual testing are:

    1. It is time-consuming and not suitable for projects with strict timelines
    2. It can become redundant for functionalities that are stable with no code change
    3. Performance tests can not be performed manually
    4. It proves more expensive in the long run.
    5. With every iteration or release, the timelines keep on increasing.
    6. It is prone to human errors

Q 45: When will you choose manual testing over automation?
Ans: Under some situations, manual testing is preferred over automation, these are:

    1. Bug re-testing
    2. For testing cases, that need to be run only a few times for the project.
    3. For Adhoc and exploratory testing.
    4. For checking the user-friendliness of the application
    5. While handling complex scenarios.
    6. For testing cases, where some random decision-making is involved.

Q 46: What is a testbed?
Ans: The environment for testing with the needed parameters is called a testbed. It is a digital platform that can include the OS, hardware, software, database, network, etc.

Q 47: What is a test case?
Ans: A test case is a set of instructions that the tester is expected to perform to test functionality.

A good test case can be easily understood and run by any person even if they do not have a testing background.

Q 48: What are the details included in a test case?
Ans: A test case would include:

    1. S No.
    2. Traceability reference to the requirements document
    3. Pre-conditions
    4. Steps to reproduce
    5. Expected result
    6. Actual result
    7. Result (Pass/Fail)
    8. Bug ID
    9. Comments

Q 49: What is user acceptance testing?
Ans: Also known as end-user testing, it is performed by a subset of the actual users to understand if the application is working as expected for the users. In UAT, the users would suggest some improvements in the application that would make it more suitable.

Q 50: What is Soak Testing?Ans: Soak testing is a kind of performance testing in which the system is kept under continuous load for a long time to find defects and bottlenecks in the system. It is also called as Endurance test.

Most commonly memory leaks and system utilization-related issues can be found during these tests.

Q 51: What is localization testing?
Ans: The localization testing is done to check the functionalities that the dependent on the location. These can be related to map, search features, regional languages, etc.

Q 52: What is A/B testing?
Ans: A/B testing is done when there are 2 or more versions of the app. Both these apps are given to the client or each app is given to a set of clients,        for testing to decide which one is better and should be deployed to production.

Q 53: What are the different types of integration testing?
Ans: The different types of integration testing are:

    1. Big bang testing
    2. Bottom-up testing
    3. Top-down testing

Q 54: What is called the pesticides paradox?
Ans: When the same tests are conducted on the same system, again and again, no new defects can be found and the system becomes immune to these tests. This situation is called the pesticides paradox.

To avoid such a scenario, the tests should be modified with new strategies and approaches.

Q 55: Name some test deliverables?
Ans: Some test deliverables are:

    1. Test Plan
    2. Effort estimation report
    3. Test cases
    4. Traceability matrix
    5. Defect report
    6. Test report
    7. Test summary

Q 56: What is big-bang testing?
Ans: Testing all the modules together once the development is complete is called the big-bang testing approach. The defects found in big-bang testing have a very high fixing cost since they are found towards the end of the development cycle.

Q 57: What is top-down testing?
Ans: In the top-down testing approach, the top modules are tested first and then moved on to the smaller modules.

Stubs are used as a temporary module to assist in testing the higher modules.

Q 58: What is bottom-up testing?
Ans: Bottom-up approach is the opposite of the top-down approach, here the lower modules are tested first as and when they are ready. Moving up to bigger integrated modules.

Drivers are used to doing integration testing till the module development is complete.

Q 59: What is end-to-end testing?
Ans: End-to-end testing means testing the entire flow of the application from the start to the end. One of the biggest challenges in end-to-end testing is that it spans multiple systems, so the verification can become complex.

Q 60: What is GUI testing?
Ans: Testing an application using only the graphical user interface is called GUI testing. In this, apart from the functionality, a tester would also check the alignment, color combinations, readability, ease of navigation, etc.

Q 61: What is recovery testing?
Ans: This testing is done to check how soon the system can recover after a system crash. It is a type of non-functional testing.

Q 62: What is risk-based testing?
Ans: In risk-based testing, the critical modules and those which are likely to have more failures are tested first. This type of test prioritization based on risk is the basis of risk-based testing.

Q 63: What is security testing?
Ans: The testing that is done to find the vulnerabilities in the system, protect the data, and ensure the functionalities are working as expected is called security testing.

It also involves checking the access to systems. This means people with different access levels should be able to access only parts of the system they are allowed to as per the business.

Q 64: What is load testing?
Ans: Load testing is done to see the performance of the application under load. A load is simulated on the system and then functional testing is performed to find the bottlenecks in the system.

Q 65: Name some best practices in software testing.
Ans: Some best practices are:

    1. Start early
    2. Update your test cases, and test approach frequently to identify more defects
    3. Always think like the client
    4. Think out of the box
    5. Automate repeated tests and focus more testing on new modules

Q 66: What is exhaustive testing?
Ans: Exhaustive testing is testing the system with all the valid and invalid inputs.

In most cases, exhaustive testing is not possible and a tester would go with BVA or equivalence partition techniques to test the application.

Q 67: What is the 80:20 rule?
Ans: The 80:20 rule states that 80% of the defects are found in 20% of the code. This is also called defect clustering.

Q 68: What is defect cascading?
Ans: The phenomenon where one defect if left undetected, triggers multiple defects in other modules and later stages are called defect cascading.

The cost of fixing this defect cascading can be high, due to the greater number of defects in the system.

Q 69: What is outsourced testing?
Ans: Assigning the testing task to a third party or separate team within or outside the company is called outsourced testing.

This is done to ensure free and unbiased testing. Sometimes it is also helpful in giving a fresh perspective to the testing activity.

Q 70: What is bug leakage?
Ans: A bug that is missed by the testing team during the testing phase and escapes undetected to production, where it is discovered by the actual user is called leaked bug and the phenomenon is called bug leakage.

Q 71: What is a show stopper defect?
Ans: A defect that does not allow the testing activities to proceed is called a show stopper defect.

App crash on launch and login failures are examples of show stopper defects.

Q 72: What is a hotfix?
Ans: Sometimes a build that is deployed to production would have some critical error and it would be rolled back.

Now an emergency fix for the issue is released as a new patch and this build is called a hotfix.

Q 73: What are the different models of SDLC?
Ans: The main models are:

    1. Waterfall model
    2. V model
    3. Spiral model
    4. Agile

Q 74: Name some challenges in software testing?
Ans: Some challenges in software testing

    1. Insufficient documentation or unfrozen requirements.
    2. Unavailability of skilled testing resources
    3. Stringent timelines
    4. Unstable systems and incomplete modules are given for testing

Q 75: What is the age of a defect?
Ans: The age of the defect is defined as the number of days between the day the defect is accepted or assigned by the development team and the day it is verified and closed by the testing team.

The age of the defect can be defined in hours and days.

Conclusion

We wholeheartedly hope that you crack the next manual tester interview and the manual testing interview questions that we have prepared for you have helped in it.

Top 50 Must Read Jmeter Interview Questions

To be able to answer the questions about Jmeter Interview Questions you must go through the most frequently asked interview questions about the tool. Let’s have a look.
Q 1: What is JMeter?
Ans: JMeter is a Java-based tool used for Performance and Load Testing. It simulates virtual users and sends multiple requests to the server. It then collects the response and other details to assess the performance of the system under different conditions.
Q 2: Explain Samplers and Thread Groups in JMeter?
Ans: Sampler generates sample results sets with different attributes like time, data size, etc. These allow JMeter to send requests to the server. Some of the most frequently used samplers are HTTP requests, JDBC requests, etc.
Thread Groups are user sets that contain the details of the number of users to be loaded into the system and the time gap between them. It is the basic step for any load testing activity.
Q 3: What is a pre-processor element? Name some.
Ans: A pre-processor is something that is executed before the sampler executes. It can be used to set the values for the sample request.
Some of the pre-processor elements are:

  • HTTP URL re-writing modifier
  • BeanShellPreProcessor
  • HTML link parser

Q 4: What is the order in which the test elements are executed?
Ans: The sequence is:

  • Configuration elements
  • Pre-processors
  • Timers
  • Samplers
  • Post-processors
  • Assertions
  • Listeners

Q 5: What is a regular expression? What is the difference between “contain” and “matches” in the regular expression?
Ans: A regular expression is a pattern used to search and match a particular text.
In a regular expression, “contain” means the search text can be some part of the matched expression. Like “press” in “expression”. “Matches” on the other hand need to match the complete expression. “exp.n” for “expression”.
Q 6: What are the configuration elements?
Ans: A configuration element works in parallel with Samplers. They are used to set the default values for variables.
Q 7: What is a timer in JMeter? Mention different types of timers?
Ans: JMeter is designed to send requests to the server continuously without a break. If we need a pause in between successive requests we can make use of the timer. There are many timers available and some of the most common ones are:

  • Constant Timer
  • Gaussian Random Timer
  • Uniform Random Timer
  • Synchronizing Timer

Q 8: What is an assertion? Name some assertions in JMeter.
Ans: Assertions are used to help validate and verify the server response with the expected results.
Some of the common Assertions are:

  • Response Assertion
  • Duration Assertion
  • Size Assertion
  • XML Assertion
  • HTML Assertion

Q 9: Can you do spike testing using JMeter?
Ans: With help of a synchronization timer we can achieve a spike effect in JMeter. A synchronizing timer will block all requests till a particular number of threads are blocked and then release them all together, creating a huge load or spike.

Tensed regarding your Automation Tester Interview?: Read This blog

Q 10: What is distributed load testing?
Ans: The load testing in which loads are simulated from numerous systems to create a huge load is called distributed load testing. In JMeter, we can use the master-slave configuration to achieve distributed load testing.
Q 11: What are the benefits of JMeter?
Ans: The benefits of JMeter are:

  • It can be used for the performance testing of both static and dynamic resources
  • It can handle the maximum number of concurrent users
  • It provides very detailed graphical results and analysis.

Q 12: What are the protocols supported by JMeter?
Ans: The protocols supported by JMeter are:

  • Web: HTTP, HTTPS
  • Web Services: SOAP /XML RPC
  • Database via JDBC
  • Directory: LDAP
  • Messaging via JMS
  • Service: POP3, IMAP, SMTP
  • FTP Service

Mobile app test cost calculator
Q 13: What is the difference between Test Fragment and Thread Group?
Ans: Test Fragments are similar to Thread Groups with the difference that they are implemented only when they are referenced by a Module controller or an Include controller.
Q 14: What are Configuration Elements?
Ans: Configuration Elements are used to create variables and default values for the Samplers. They can also be used to alter the requests made by the Samplers. It is executed at the start of the scope and can be accessed only within that branch.
Q 15: How will use ensure the reusability of your JMeter scripts?
Ans:  Some things that help improve the reusability are:

  • Use of config elements like “CSV Data Set Config”, “User-Defined Variables”
  • Modularizing the tasks and calling them via Module Controller
  • Writing BeanShell functions.

Q 16:Name some listeners in JMeter?
Ans: Some listeners are:

  • BeanShell Listener
  • Monitor Results
  • Aggregate Report
  • Summary Report
  • View Results Tree
  • Spline Visualiser

Q 17: Name the different types of controllers?
Ans: There are mainly 2 types of controllers in JMeter:

  • Samplers Controllers – They are used to send specific requests to the server and simulate the user request.
  • Logical Controllers – Logical Controllers control the flow or order of processing of the Samplers. It can be used to change the sequence of requests coming from the child element.

Q 18: What is a workbench?
Ans: Workbench is like a storage area for components that can be added to the test plan as per the need. They are not saved with the test plan but get saved as Test Fragments separately.
Q 19: What is co-relation in JMeter?
Ans: Co-relation is the process of extracting a value from the response received, to use in upcoming requests. This is especially useful for session-id, cookies, etc.
Q 20: Can JMeter be used for load testing mobile applications?
Ans: Yes, JMeter can be used for sending HTTP or HTTPS to the server from your mobile application provided both the mobile and the server are on the same network.
Q 21: What is a root CA certificate?
Ans: In the case of HTTPS requests, when the browser hits the server, authentication is required. JMeter can generate this certificate temporarily to intercept the traffic and record the actions. To perform the action on mobiles, the certificate needs to be installed on your mobile as well. These are called the root CA certificates.
Q 22: What is the default screen in JMeter?
Ans: The default screen in JMeter opens the Test Plan and Workbench tabs.
Q 23: What is a Test Plan and what the important elements in the Test Plan?
Ans: A test plan contains the details of the things to test and how the tests are carried out. A test plan in JMeter contains the following elements:

  • Pre-processor Elements
  • Post-processor Elements
  • Thread Groups
  • Controllers
  • Listeners
  • Timers
  • Assertions
  • Configuration Elements

Q 24: Is it possible to reduce resource utilization in JMeter?
Ans: Some of the popular ways to minimize resource utilization while running JMeter are:

  • Use a non-GUI mode for running the tests
  • Use only the minimal number of listeners
  • Avoid using the “View Result Tree” listener as it consumes a lot of space
  • Use parameterization where ever possible
  • Avoid the functional mode
  • For the output select CSV instead of XML
  • Disable unwanted graphs, they consume a lot of space

Q 25: What is Beanshell scripting?
Ans: BeanShell is a lightweight java scripting that can help you with complex and application-specific tasks.
Q 26: What is the difference between Gaussian and Poisson Timers?
Ans: Both the timers use mathematical formulas to create delays and offsets. The difference between the two is that in the Gaussian Timer the deviation value is calculated whereas in Poisson the lambda value is calculated.
Q 27: How can you configure the master-slave configuration?
Ans: The master-slave configuration is used for distributed load testing.
To configure we can:

  • Edit the JMeter.properties file on the master machine and add the IP addresses of the slave machines in the remote_host field.
  • Save the properties file and relaunch JMeter for the changes to be effective
  • From the RUN menu, select Remote Start and choose the above-added IP address of the slave machine. Choose Remote Start all to invoke all the slave machines.

Q 28: Which is the XML parser present in JMeter?
Ans: Apache’s Xerces XML parser
Q 29: What is the default protocol used for testing a web service using SSL encryption?
Ans: TLS protocol is used for testing web services using SSL encryption.
Q 30: What is the default LDAP port over SSL?
Ans: 625
Q 31: What is the maximum number of users that can be simulated by JMeter?
Ans: JMeter can simulate an unlimited number of users. The number of users is equal to the number of threads in a test plan. The only limitation to the number of threads is the hardware resources of the test machine. For getting a higher number of users we may need to scale up the hardware.

Are you a tester? Then you must go through these interview questions

Q 32:Can JMeter be used for API testing?
Ans: Yes, it can be used for SOAP and REST web services testing. Performance testing of RESTful API can also be done with JMeter.
Q 33: What is a JTL file in JMeter?
Ans: JTL stands for JMeter Test Logs. It contains the results of the tests. The file extension of the JTL file can be selected before the execution. If the same file is selected for multiple runs, each subsequent result gets appended to the end of the same file.
Q 34: What is the latest version of JMeter?
Ans: The latest version is JMeter 5.4.1 and it was released in January 2021.
Q 35:What is Throughput in JMeter?
Ans: Throughput is the number of requests served or successfully processed per unit of time.
Throughput = (No. of requests)/(total time)
Q 36:How can you calculate the number of concurrent users?
Ans: Concurrent users mean the number of users performing the same operation at the same time in the system. The number of users in the system can be found out using the number of threads. But a vague calculation of the number of concurrent users – if there are
100 unique visitors, with each visitor spending 10 mins in the system. Then we can say that the number of concurrent users is 100/10 = 10 users.
Q 37: What is the load time in JMeter?
Ans: In JMeter, load time refers to the total time before sending a request to after receiving a response. For multiple threads, the load time is calculated at the thread level and is the total time between the thread request and the response received.
Load Time = Time after a response is received – Time before a request is sent.
Q 38: What are Monitor Tests?
Ans: Monitor Tests are generally used for stress testing. They provide additional information about server performance. It also helps to monitor multiple servers from the console.
Q 39:Can we use Selenium scripts in JMeter?
Ans: Yes we can. One way is by using Junit libraries to create Selenium scripts, save them as Jars and copy them to the JMeter directory. Another way is to add the web driver sampler plugin to the JMeter ext folder.
Q 40: Explain how JMeter works?
Ans: JMeter simulates multiple concurrent users using threads and sends requests to the server, create a load. It then measures the time and performance of the server and displays it in the form of tables and graphs.
Q 41: What is the ramp-up period in JMeter?
Ans: While running load tests, all the users are not loaded into the system together. The number of users is slowly and progressively increased to better understand the system bottlenecks and performance. The ramp-up period is thus the time taken for all the users to get into the system.
Q 42: What is the Rendezvous Point?
Ans: The Rendezvous Point is the term used with stress testing. It is the point at which all the delayed requests are released to hit the server and create a spike.
Q 43: What are Post-Processors?
Ans: Post-Processors are the elements of the test plan that are executed after the sampler request execution. Generally, they are used for extracting some values from the sampler response.
Q 44: What is the 90% line in JMeter?
Ans: 90% line is one of the metrics of the Aggregate Report Listener. It means 90% of the responses were within this limit. It is similar to the percentile value and can also be called the 90th percentile of the response time.
jmeter interview questions
Q 45: What are the common techniques of Performance Testing?
Ans: The most common performance testing techniques are:

  • Spike Testing
  • Load Testing
  • Volume Testing
  • Endurance Testing
  • Stress Testing

Q 46: How can you run JMeter in GUI mode?
Ans: The following command is used to run JMeter in GUI mode:
:jmeter -n -ttest.jmx -l test.jtl
Q 47: How can you analyze the JMeter results?
Ans: The JMeter results are stored in the .jtl file. It is possible to add different graphs like the response time graph, aggregate report, etc. We can also analyze the response time and the TPS (transactions per second). In some cases, we may also want to add some plugins to get additional graphs.
Q 48:Is it possible to configure email notifications in JMeter?
Ans: Yes, we can use the SMTP sampler to trigger emails at the start and end of the JMeter tests.
Q 49: What are the different types of recording in JMeter?
Ans: JMeter allows manual and automation recording. For automation recording, we can use the workbench to record the script. For manual recording, we can make use of fiddler or network log (F12)
Q 50: How can you forcefully stop a test in the middle of the execution?
Ans: For Windows machines, we can double-click on the stoptest.bat and shutdown.bat to forcefully stop the test. In the case of Mac, stoptest.sh and shutdown.sh files need to be double-clicked.
Hope you have gone through all of the Jmeter interview questions we have listed here. We wish you all the best!
 

How to test a taxi booking app like Uber?

How to test a taxi booking app like Uber? They are extremely complex and demand high data security.  On the top, they have to offer unvarying stability and high UX. If you are thinking about testing. you need assistance from someone who knows what they do.
However, some might be thinking that they have put a lot of effort when it comes to the development of the app, they have extremely skilled developers and they can carry out the process with ease.
But remember one thing, user perspective is what matters, your developers might be partial, and this might be has a huge weightage considering the competition that you are going to face and the huge amount of money hat’s been invested.
Testing is indeed extra cost, but the amount of risk it mitigates is immense.
But the question prevails! How to test a taxi booking app like Uber?
before we get into that, let’s know about the need in detail.

Why thorough testing is needed
Every customer user app needs thorough testing to succeed in the market. No customer would be willing to use a non-secure or slow app. In this digital age, competition is very high and most likely you will not get a second chance. Here are some reasons why a thorough and meticulously planned testing effort is needed for a taxi booking app:

  1. Security of Customer/Driver Data: the app would include the customer’s and drivers’ personal data (PII). Any security breach in this area can lead to legal complications for the app company and owner. 
  2. Integrated Payment and Wallets: Most booking app would have an integrated payment gateway to enable easy payment for the rides. These gateways and payment options need to be tested minutely to make sure the clients’ money is safe. 
  3. Easy to Use UI: The app should be designed in such a way that different types of users including aged people and people who are new to the internet can use the app with ease. 
  4. Accuracy of data: The app needs to be tested to ensure data accuracy in multiple points. This will include the data of the customer, driver, the trip details, the offers, the fares, the distance calculations, and much more. The accuracy of every data displayed on the app needs to be verified for its correctness. 

Uber App Screen
What to test in a taxi booking app?
Now that we have understood why testing is so important for the taxi booking app, let us look at some important focus areas and test points. While this list is not exhaustive, it will give you a fair idea of how to get started. Feel free to add points as per the app and requirements in hand.
From a Customer Perspective

  1. Customer Data: The customer data in the app needs to be tested to ensure it is accurate. This will include the personal details, the payment details (if they wish to save), the trip details, favorite pick-up and drop location, the offers available, and more.  
  2. User and driver registration: Registration for both customers and drivers needs to be tested to check the data is getting saved corrected in the server. The users and the drivers should be able to add, edit, and delete their details as well. 
  3. Map Related and live tracking: Testing the map related functionalities are very critical for any taxi booking app. This includes opening the app in the current location, finding cabs in the vicinity, and live tracking of the cab movement before and after confirming the booking. 
  4. Time Tracking: The live movement of the cab should be linked to the time taken to reach the destination or time to reach the customer. These values need to be constantly changed to verify the functionality is working fine. This can be tested by simulating a moving vehicle and then calculating the location and time. A critical requirement here would be the refresh. This needs to be decided by the business, ideally, it should be 1 sec or less, so the customer does not see a lag. But based on the system design and the load the business may decide for 2-5 secs also. 
  5. OTP: Most apps will have an OTP generation system for authenticating the user at the time of registration and even when boarding a cab. The OTP needs to be validated against the customer data with valid and invalid entries. The number of retries allowed is another important yet overlooked point. If the OTP is regenerated, the system should accept only the latest OTP and none of the previous ones should be accepted. Ignore this if not applicable to your app. 
  6. Wallet Transactions and history: Most apps will have an option to load money into the wallet using a pre-established payment gateway. The wallet needs to be checked for money top-up, balance, transaction history, refund, and offers. The same will be true for other payment options like debit card, credit card, UPI, and other options as per the app.
  7. Trip – distance and time: The details regarding the trip needs to be tested. This will include the distance between the pick-up and drop location. The way chosen should be the shortest way with the least traffic based on the congestion points in the location. The estimated time of travel and other details of the trip as per the business needs. 
  8. Trip Modification: The user should be allowed to make changes to the trip. This will include cancellation and changing the destination point. In the case of the latter, the trip distance, time, amount, and route should change accordingly. Check if there is a limit on the number of times the user can make the changes. If there is a limit like 2 or 3 then it needs to be tested that the 4th change is rejected by the system. 
  9. Cab Sharing: Most of the apps would allow the sharing of the cab between people. In this case, it is important to test the distance between the shared pick-up points. This limit must be set by the business. Check with the requirements and then test to make sure the sharing pick-ups are scheduled within that range. 
  10. Driver and cab details: The customers should be able to view all the driver details and his previous customer ratings. They should also be able to see the cab number and the model along with the driver’s contact number. As per the app, these may contain driver pictures as well. 
  11. Push messages and SMS: Every app has its own requirements for SMS, email, and push notifications. These will include notifications for booking confirmation, cab arrival, driver details, OTP, trip completion, the amount payable, cancellation request, feedback request, and others. Each of these needs to be tested to make sure they are time-bound as per the business requirements.
  12. Search: One of the most important aspects of the map search. This will include searching for cabs in the current location and location as per the user’s interest. Suggestions for the location once the user starts typing will be good to have feature. The search should show the cabs available in the area along with a route map. It should inform the customer of the distance and time to the nearest cab. 
  13. Offers: Every now and then, the company may come with offers and discounts for all or specific customers. The offer code and their validity need to be tested along with any specific requirements for availing the offers. The amount being reduced after availing the offer is another test area. 
  14. Feedback and Rating system: The app should include a feedback and rating system for both the customer and the driver. They should be able to give feedback and ratings to each other. These ratings need to be analyzed to improve the drivers and the services provided.
  15. Customer Support and Escalation: The app will have customer support and escalation mechanism in place. This can include support through email, call, or chat. Each must be tested along with the different escalation levels. 

From a Driver Perspective

  1.  Driver Data: Like the customer data, the app will also contain the driver data, his incentive, the number of trips undertaken, the star ratings (if available), his payment schedule, and other details. This again needs to be tested to make sure the mapping in the database or server is correct and the queries used to fetch the data is as expected. 
  2. Trip Visibility and Options: The driver should be able to see the customer search within a specific distance as per his current location as fixed by the business. He should have the option to accept or decline the trip as well. Once accepted the trip should be hidden for the other drivers. 
  3. Benefits and Trip history: Most drivers will be paid based on the number of trips they have undertaken, and the benefits would increase with the increase in the daily or weekly completed trip count. All these details along with the payment options and history should be available for the driver to verify. 
  4. Hiding Customer Personal Data: Customer data is very critical especially the phone numbers. This information need not be shared with the drivers. To contact the customers there should be a hotline number and the customer details should be hidden from the driver. 

Types of Testing 
For all the above test cases, there are different types of testing that will be done. Here is a list of these:

  1. Manual Testing: Critical business functionalities need to be tested manually. Manual testing is also needed in cases where the team does not have the time or money for automation or when the automation feasibility for the features is low. 
  2. Automation Testing: The app will have a lot of validations. If the testing is to be done only once, then automation is not required. But if there are likely to be regular updates or new features added, it would be better to have an automation suite in place to reduce the future testing efforts and save time as well. 
  3. Security Testing: The app server or database contains personal data of the customers and the drivers. This will include the names, address, phone number, mobile number along with the payment details that can include the bank or card numbers. The security of this data is very important. The app should be safeguarded against external attacks. 
  4. Performance Testing: Based on the anticipated load performance testing needs to be done so that the search, map loading time, and other transactions are well within the SLA at peak and off-peak loads.  Based on these results the business will decide to scale-up the infrastructure if needed.
  5. Integration Testing: There are several systems involved in the app. This includes the GPS tracking or mobiles of the driver and customer, the database or server, and the booking app. The integration between these systems needs to be verified for accuracy and data flow. 
  6. DB testing: Customer and driver details along with all the trip information are store in the database. Hence, DB testing is imperative. While testing we need to ensure that the basic operations like adding a record, editing a record, deleting a record, fetching the record are being performed as per the expectation. 
  7. Exploratory Testing: Exploratory testing is a kind of informal testing in which the user would just explore the application trying to go through all the different pages and verify that nothing is broken. 
  8. Responsive Testing: Responsive testing needs to be done to ensure that your taxi booking app renders itself well in devices with different screen sizes and resolution. With so many new devices entering the market and the extensive usage of the internet, responsive testing of the app needs to be taken very seriously. 
  9. UAT Testing: The ultimate testing for any app or software must be the UAT or User Acceptance Testing. UAT gives the usage pattern and the most frequently used areas of the app. This will be helpful in deciding the future features of the app. 

app crash
How do I test the Uber app?
Apps like uber are bound to be installed across many devices with varied OS versions.  Performance testing has to be done at intervals to make sure that the app is working fine and it has what it takes to meet up customer expectations.
While testing make sure that

  • Complete assessment of the business requirement of the apps
  • Identify the important performance testing metrics
  • Create perfect and realistic test scenarios
  • Analyze and validate the test result and measurements
  • Preparation of reports that can also be useful for developers.

Tips for testing apps like uber

  • Apart from the normal workflow of the registration module, you must also make sure that social media login and integration is carried over the system with ease.
  • Check email authentication process to make sure that your domain will not be marked as spam
  • Make sure that there are unnecessary links attached to the mail send by the system
  • Make sure that the user is able to differentiate auto-generated messages
  • Make sure that the geographic information system (GIS)  is in sync with the system and functionalities
  • Check the OS compatibility of the app with various versions
  • Make sure that the information provided to the user is concise and precise
  • Proper localization testing needs to done to make sure that it’s not hurting any sentiments
  • Real drivers and passengers have to be used for testing rather than a simulated environment
  • A payment gateway is integral for taxi booking apps. make sure that it doesn’t have any loophole and is working fine
  • Trace out all the security loopholes in the system
  • Test the authorization workflow and functionality
  • Gamification is indeed the star nowadays. Make sure that it’s in a way that will make the driver and the customer feel rewarded
  • Test the system in varied internet strength and load

Top 10 Taxi booking Apps

  1. Uber
  2. Lyft
  3. Ola Cabs
  4. Taxify
  5. DIDI
  6. Cabify
  7. Lecab
  8. Curb
  9. Gett
  10. GoCatch


Which are the tools that can be used for taxi booking app testing?
While the listed set of testing might be overwhelming, here is a list of tools available in the market to get you started.

  1. Appium and Appium Studio
  2. TestComplete
  3. Calabash
  4. Webload
  5. Zed Attack Proxy
  6. Android Debug Bridge
  7. Lambda Test
  8. Studio Press
  9. DBFit, SQLUnit
  10. Visual Studio Team Edition

Hope you have a fair idea now about how to test a taxi booking app now. This should be enough to get you started and rest you can improvise when you are at it. 

Difference between regression testing and retesting

Regression testing Re testing
Done whenever there is a change in code A confirmation technique used once the defect is fixed
To  assure that new changes hasn’t caused new issues To find out whether the issue has been rectified and functionality is restored
Can be done parallel with retesting Should be performed before regression testing
Passed test cases are used Failed test cases are put to use
Defect verification is not apart Defect verification is a part
Can be used to check unexpected results Confirms that the original fault has been corrected
Automation is the key Can’t be automated

 
difference between regression testing and re testing

Difference Between White box and Black box Testing

Black Box testing: it’s kind of testing where the tester doesn’t know the architecture of the software he is testing. These tests can either be functional or non-functional. It’s high-level testing that’s meant to test the behavior of the software.
White box testing: White box testing is used to test the internal structure of the system. In this type of testing, usually code statements, branches conditions, etc. are covered. White box testing is considered a low-level testing often called a glass box, transparent box or code base testing.
difference between white box and black box testing

Difference between use case and test case

Use case Test case
Set of variables, conditions or steps used to define the interaction between a role and a system to attain certain objectives. Conditions or variables used to define the functionality and behavior of a software
Prepared by business analyst Prepared by test engineers
Different case can be combined One at a time
Use case is something that has to be designed Testcase is something that has to be executed
Describes the flow of events of  the software A document that contains events, action and expected result of the software
Provided to developers Provided to testers
 
Managed by diagrams Managed by function tests
Requires proper document and research Requires test scripts are required

 
Difference between use case and test case

Smoke Testing Vs Sanity Testing: What’s the difference?

Smoke testing vs sanity testing! which one hail? To be frank, each process is important and the situation and requirement demand which one to choose from.

However, the comparison depicted here in this blog will help you understand more about smoke and sanity testing.

Smoke Testing

Smoke Technique is one of the testing types that’s instigated from hardware testing.

This technique comes into the scenario at the time of attaining build software from the development team.

The main reason to go for the smoke testing is to find out whether the software which is built is testable or not.

It is usually done at the point where the software is built.  This process has been given another name as well. It is actually called “Day 0″.

The smoke Testing process is counted as the best one because it is a time-saving one.

The most astounding feature about the process is that the time consumed is less since the testing is only done when the main functions of the application are not properly working or if certain major bugs are not sorted till that moment.

The main emphasis of Smoke Testing is on the working of the major features and primary functions of the application.

Going for the test is the basic and important feature of an application before one goes for the deep, accurate testing (before understanding all probable positive and negative values) is referred to as smoke testing.

The whole emphasis while going for the smoke testing is on the productive flow of the claim and it possesses only the verified data, not the unacceptable one.

In smoke testing,  the process confirms every build is testable or not; hence it is called Build Verification Testing.

When smoke testing is being conducted then one can look for the blocker bug at the initial period only so that the test engineer just doesn’t have to sit idle, or they can go on further and do the analysis of the independent testable modules.

Which test comes first smoke or sanity?

Smoke testing is usually performed on a new build/feature.  The main motto behind smoke testing is to ensure that the software is ready to be tested.

Sanity testing is performed when time is not at the disposal of the dev team. Smoke testing is done first and then the application goes through quick regression or sanity testing

What is the process for conducting smoke testing

The process to Conduct Smoke Testing:

For Smoke testing, there is no requirement to create test cases. In this, the only requirement is to pick the required test cases from the already created test cases.

As stated before too, Smoke Testing emphasis the workflow of core applications so that choosing test case suits that cover the main functionality of the application is done.

It is vital to bring down the number of test cases as much as possible and the time of implementation should not be more than half an hour.

When smoke testing is performed

Usually when the new build is implemented then one round of smoke testing is conducted because there are chances of blocker bugs in the latest one which is created.

However, there can be a certain change that might have wrecked a major feature that as fixing the bug or adding a new function which can affect a major piece of the original software, or the smoke testing is done where the installation is taking place.

When the stable build is all installed then smoke testing is conducted to find the blocker bug.

Why is smoke testing done?

There are certain reasons because of which smoke testing is conducted. Stated below are the important ones.

  • The smoke testing is basically done to make sure that the product is testable.
  • The smoke testing is done in the beginning so that the bugs which are there in the basic features could be detected and further can be sent to the development team so that the development team gets a lot of time to get rid of the bug.
  • Smoke testing is done to ensure that the application is installed in the approved manner.

Types of Smoke Testing

The Smoke testing is further divided into two types:

 Formal smoke testing

In this, kind of testing the application is sent to the Test Lead by the development team.

Further, the test lead will divide the task of testing the app among respective tests along with reports which state the whole scenario after going through the smoke testing.

Once the testing team is over with smoke testing, they will report for the testing done to the test lead.

 Informal smoke testing

Here, the Test lead notifies that the application is all set for further testing.

The test leads do not give any specific instructions to perform the smoke testing, but still, the testing team begins with the testing procedure of the application by going for the smoke testing.

Example for smoke testing

A detailed explanation about smoke testing and example for the process is given in this blog, please go through

Sanity Testing

Sanity Testing is a division of regression testing. Sanity testing is usually done to make sure that the code changes which are being done are carried out properly.

Sanity testing is a general strike to note down that the testing for the build can further go on or not.

The main emphasis of the team while doing the sanity testing process is to confirm the functioning of the application and not about the detailed testing.

Sanity testing is usually carried out on build where the production deployment is essential right away similar to a critical bug fix.

The functionality of Sanity Testing:

The main reason for which sanity testing is conducted is to know about the changes or the projected functionality is being done in the same order as it was mentioned.

If the sanity test fails, the software product is declined by the testing team to stay on a safer side in terms of time and money.

It is carried out once the software product has carried out the smoke test and the Quality Assurance team has acknowledged for the further testing.

Features of Sanity Testing:

  • Division of Regression Testing:

Sanity testing is further a division of regression testing and emphasizes the smaller part of the application.

  • No script required

There is no such script available for sanity testing most of the time.

  • No documentation

There is no documentation required for the sanity testing so it is undocumented.

  • Narrow and extensive

Sanity testing is narrow but at the same time it is an extensive approach of testing where limited functionalities are covered in depth.

  • Carried out by testers

Usually, sanity testing is carried out by the testers only.

Advantages of Sanity Testing:

  • Sanity testing is a great aid when it is about quick identification of the defects in the main area of functionality.
  • It can be further performed in a lesser time as there is no need for any kind of documentation for performing the sanity testing.
  • During the sanity testing if there are defects found then the project is further declined and this is a great way to save out on time which can be further utilized to carry out regression tests.

Example for Sanity Testing

  • For instance, build 2 has a multitude of feature which are tested and fixed accordingly.
  • Now build 3 with added features and integration has again come for testing
  • To make sure that the new features haven’t affected the existing ones, smoke testing will be performed
  • Once that’s done a high-level analysis of the entire software will be carried out to ensure no new bugs have surfaced.

Sanity Testing Process

The main reason for which the sanity test is performed is to know about the incorrect outcomes or faults which are not accessible in the constituent process.

Even it is done to make sure that the newly added features do not disturb the functionalities of ongoing features.

Further, three steps are implemented in the sanity testing process that is Identification, Evaluation, and Testing

First step- Identification

In the sanity testing process, the first step is the Identification one where one finds out the newly added constituents and features along with the adjustment there in the code while going for the process of fixing the bug.

Second step- Evaluation

Once the identification step is completed, one needs to analyze the recently implemented constituents, characteristics and further change them so as to verify their proposed and suitable working as mentioned in the stated requirements.

Third step- Testing

After performing the identification and evaluation step one needs to go further to the third step which is testing.

In this step, we examine and evaluate all the connected constraints, constituents, and fundamentals of all the above analyzed attributed and change them so as to ensure that all of it is working properly.

Once all the above-stated steps are going in the right manner, the build can be made to undergo more exhaustive and strenuous testing, and the release can be carried further for the thorough testing process.

Comparison of Smoke Testing and Sanity Testing

Thus both the tests have their own unique traits which make them required for the software processes.

Smoke testing vs sanity testing

                               Smoke Testing                  Sanity Testing
Used for checking critical functionalities of a software The focus will be on a particular area or minor functionalities
Performed to check the stability Used to verify the rationality
Both manual and automated test cases can be used Generally, sanity testing does not have a test script or test cases
Usually performed before passing the build to the testing team Executed before UAT and regression
Carried over by developers Performed by testers
A subset of acceptance testing A subset of regression testing

Some testing vs sanity testing

Conclusion

Hope you got to know the difference between sanity testing and smoke testing and are able to understand, smoke testing vs sanity testing has no meaning to it as both processes have equal importance.

Load Testing vs Stress Testing: What’s the difference?

Load Testing vs Stress Testing what’s the striking differences between both the process?
In the following sections, we will discuss in detail load and stress testing. People often get confused between these 2 and refer to them as a load and stress test. But there are fundamental differences between these 2 performance tests, as we will discuss in the upcoming sections. These are the 2 most important performance tests that you may wish to see the results for before your product or application goes live. This is especially true for applications that are connected to the internet.
Load Testing
As the name suggests, in a load test, many users are loaded into the system or application, and then the transactions are performed to see how well they work. Load test gives you an idea of how your application would perform in the real world with “n” numbers of users (referred to as the load) active in the system.
The results of a load test are generally expressed in terms of TPS or transactions per second. This means the system can process “N” transactions per second with an active user load of “X” thousand. The value for “N” and “X” needs to be defined by the business based on the expected number of users and the infrastructure you have in place to handle this load.
Type of performance testing
Stress Testing
In Stress testing, the system is put under stress and then its performance is measured. It is used to verify the stability and reliability of the system under stress. It is also done to ensure the system does not crash at any point.
Considering your application can handle 1o0 concurrent users. In a stress test, you may start by having 100 or more users in the system performing data transactions. Slowly you would stress the system by either increasing the load or having more transactions performed. Then you would monitor how your application is performing in this stressed situation. The stress test is also performed to understand at which point your system is likely to crash or break.

Major Differences between Load and Stress Testing?
Here are some major differentiation points between load and stress testing.

Sno Load Testing Stress Testing
1 It is used to check the performance/functionality of the system under load (multiple active users) It is used to test the reliability of the system under stress or extreme load
2 The load is set up with multiple active users – virtual or real – inserted into the system Stress is created by creating more users, data, and transactions in the system
3 Load test helps to identify the upper limit of the users that the system can handle. A stress test is used to understand the behavior and reliability of the system under extreme load or stress.
4 The performance of the app is measured with load in the system The reliability and stability of the system is measured under extreme load or stress
5 Some of the load testing tools are Jmeter, NeoLoad, Headspin, Experitest, etc Some tools recommended for stress testing are Stress Testers, Jmeter, NeoLoad

Difference between stress testing and load testing
Examples of load and stress testing
To better understand the difference between load and stress testing, let us look at an example. Let us take an example of an online shopping site. Assuming that your application is designed to handle 1000 concurrent users. When you do a load test, you may want to start with a 50% load. So, you set up your systems to simulate 500 users and then check how the system responds by checking the API response times. If the response time is within acceptable limits, you progressively increase the load to 700, 800, 900, and 1000 to see how your application performs under the different loads.
For the same application, if you were to do a stress test, you will 1000+ users simultaneously generating calling multiple APIs. This will stress out the system which is designed to handle only 1000 users. The reliability of the system is then checked by checking the correctness of the API response, to check if the application or pages crash at any point, the data is saved to and from the database, etc.
Some other examples of load testing are sending multiple files for printing at the same time to the printer, sending thousands of emails at a time to load the mail server, or changing large volumes of data in a word or excel or any other processing system.
Some scenarios that emphasize the need for a stress test are an educational website at the time of result declaration, or eCommerce website during their annual sales or new and anticipated product launches, or the latest vaccination availability and booking apps as well.

Wish to know about the best performance testing tools in the market? Read here!

Performance testing includes various types of testing including Load, Stress, and others. A performance test is done to validate the reliability and stability of the system, ensure the response time is within the defined SLA, and also ensure that the system is scalable.
Load test only concentrates on the performance of the application or system with many active users or with a load. Hence, Load testing can be considered as a subset of the performance test.
What is the purpose of load testing?
The main purpose of Load testing is to understand, how the system would perform under the real-life load. For this, the business first needs to analyze the expected user base for the application. Then a load similar to that number is simulated and the performance of the system is measured. The results are normally mentioned as successful transactions per second under “X” load or “X” active users.
It is very helpful in understanding the achievable performance of business-critical transactions along with resource utilization. Based on the load test result, the business decides to scale up or scale down the backend infrastructure.

What are the different types of load and stress testing?
Load testing can be further divided into 4 different categories based on the load used. These are

  1. Load Testing: Here you simply check the performance of the system under different levels of load which are well within the expected load limits.
  2. Capacity Testing: Also called scalability testing capacity testing is mainly done to identify the maximum load the system and the infrastructure can take without breaking down or without breaching the SLA.
  3. Stress Testing: It is done to find out how the system performs under stress or extreme load. This is achieved by reducing the infrastructure, reducing the database size along increasing the load many folds.
  4. Soak Testing: It is a long-form of load testing where system performance or degradation in performance is monitored over a long duration.

How are load and stress testing done?
Every application or system will have a limit to the load it can handle at a particular time. This limit is decided by the size of the database and servers used. Both in load and stress testing,  load or stress in the system is simulated using real users or using tools.
Load testing is done with real users and with simulated users as well. When real users are used, due to the limitation to the number of users available to database, servers, and other infrastructures are scaled down to create a load on the system. Then the testing is performed and the response times are calculated. The results are then extrapolated to derive the performance numbers for the actual infrastructure. When tools are used, any number of users can be simulated, so the actual infrastructure is tested.
Stress testing can be performed only with the help of tools. Here the system is put under stress by having inserting users many-folds than the expected told, or by putting stress on the DB and servers with many transactions and API calls. The aim is to check the stability and reliability of the system under extreme load. It also helps to identify the point at which the system is likely to crash. Based on the results of the load and stress testing, the business may decide to scale up the infrastructure for better application performance and reduced downtimes.
What are the goals of load and stress testing?
The goal of load and stress testing in to find the performance defects in the application and in the infrastructure or network that can affect the application.
The main goals of load testing are:

  1. To ensure that under different permissible the response time for all the transactions is within the SLA (Service Level Agreement) as fixed by the business.
  2. To measure the performance of different application modules under different loads.
  3. To measure the network latency and other components that can impact the response time.
  4. To uncover application design issues that can reduce the performance.
  5. To check the server configurations for web and application to ensure they can handle the load.

The main goals of stress testing are:

  1. To uncover issues that occur only at extreme load conditions.
  2. To check the stability and reliability of the application under heavy load.
  3. To uncover synchronizations issues, memory leaks, and race conditions
  4. Optimizing the system to prevent a breakdown in production.
  5. Planning for the scalability and best utilization of the available infrastructure.

Do you know that volume testing is absolutely needed before app release? Read more

Soak Testing is a type of Performance Testing where the performance of the system under load is analyzed for long-duration similar to a production scenario. Some applications need to be online 24/7 like the eCommerce websites. They may have a different load at different points, a soak test would put the system under test with a specific or varying load and monitor its performance for hours or even days.
A soak test aims to identify issues that occur only after the system has been active for long durations. The most common issue identified in a soak test is related to memory leaks where the system starts degrading after being live for a long time.
Conclusion
The performance of a software application is critical to the success of the application. For this purpose after the functional testing, performance tests are performed. The most common performance tests are load and stress tests. Based on the results of the load and stress test the business decides on the infrastructure needed to support the application.
The load and stress result thus play a very important part not only in the success of the application but also helps business in optimizing resource utilization and improved profit.
 

Agile VS DevOps: Difference between Agile and DevOps

Agile vs DevOps which is better? Agile, Scrum, and DevOps are some of the buzzwords these days. They are changing the way people look at how and when testing and automation need to be done. In this section, we will discuss the difference between Agile and DevOps and the testing methodology in both.
What is Agile Methodology?
Agile Methodology diagram
Agile literally means “moving quick and easy”. In terms of software development, Agile means delivering small chunks of stand-alone and workable codes that are pushed to production frequently. This means your traditional project plans that spanned over months and sometimes years in now cut short to sprints no longer than 2-3 weeks. All timelines are shrunk to deliver working code at the end of each sprint.
Know more: Why Agile testing is so innovative!
What is DevOps Methodology?
DevOps Methodology
DevOps is a set of practices that aim to automate the development, testing, and deployment so that code gets deployed to production as small and rapid releases as part of continuous development and continuous deployment (CI/CD). DevOps is a combination of the terms Development and Operations and aims to bridge the gap between the two entities enabling smooth and seamless production code moves. 
Test your app in various screens
Testing in Agile
The traditional STLC holds no good when it comes to Agile. There is no time for all the documentation and the marked-out phases. Everything from plan, design, development, testing, and deployment needs to be winded up in a 2 to 3-week sprint.
Here are some pointers that explain how testing is done in Agile projects:

  • Testing is a continuous process. It happens along with the development. The feedback is shared with the dev team then and there, ensuring a quick turn-around. 
  • Testing is everyone’s responsibility and not only of the testing team. Product quality is the greatest priority. 
  • With shrinking timelines, documentation is a bare minimum.
  • Automation Testing is used for the N-1 iteration code. That is, in the current iteration, the automation team would be automating the functionalities of the last iteration and running the automation code for N-2 iterations. This will give more time for the manual testing team to work on the thorough testing of the current iteration functionalities

Agile Testing Methods
Traditional testing methods are difficult to fit in Agile and are unlikely to give the desired results. The best-suited methods for agile testing are listed below:

  • Behavior Driven Testing (BDD)

BDD Testing makes life simple for both testers and developers. The test cases and requirements are written in readable English with keywords (Gherkin Given/When/Then syntax). These requirement documents double up as test cases. 

  • Acceptance Test-Driven Testing

This is another way of ensuring the best test results for an Agile process. Think and test as a customer would do. In this case, meetings are held between developers, testers, and other team members to come up with different test scenarios to match the application usage by the end-user. These are given the highest priority for testing.  

  •  Exploratory Testing

Another very useful but non-structured testing approach frequently used in the Agile process is exploratory testing. This involves playing around with the application and exploring all areas as per the understanding of the tester. This is done to ensure that there are no failures or app crashes. 
Testing in DevOps
DevOps testing is mostly automated just like most of the other things in DevOps. The moment there is a code check-in, automated code validation is triggered. Once that passes the testing suite or Smoke test is triggered to ensure nothing is broken. If everything goes well, the code is pushed to production. 

  • Most business-critical functionalities are tested through automation or API responses to make sure there are broken functionalities due to the latest code change. 
  • Based on the business requirement, the automation code can be expanded to include more functionalities or limit to a smoke/sanity test. 
  • The testing is triggered with the help of microservices and API responses. 

DevOps Testing Methods
Here we discuss some tools and techniques in testing that can be very beneficial for the DevOps process. These help to reduce the time-to-market and also improves the overall product and testing efficiency. 

  • Test-Driven Development (TDD)

In a TDD approach, the developers are expected to write unit test cases for every piece of their code covering all the workflows. These tests ensure that the piece of code is working as per the expectation. 
Apart from TDD the DevOps teams also use the ATDD and BDD approach as discussed above in the Agile section. These are equally helpful in ensuring greater quality and a streamlined approach to continuous development and deployment to production. 
Read also: Software testing Models: Know about them
Core Values of Agile and  DevOps (Agile VS DevOps)
Let us now discuss the core values of Agile and DevOps that make them different from each other. 
Agile – Core Values
Below are the values that govern any Agile process. 

  1. People over Process: In Agile there is more focus on the people, their skills, and how best to put them to use. This means elaborate processes and multiple tools may take a backseat. While the process is important, things as rigid as the traditional waterfall model can not work in Agile 
  2. Working code over documentation: Agile lays more importance on a stand-alone working code to be delivered at the end of every sprint. This means that there may not be enough time for all the documentation. In most cases, there will be a minimal document for the agile development processes and more focus is on getting a working code at the end of the sprint. 
  3. Customer Feedback over contract: While there are contracts in place on when and how the complete project needs to be delivered, in Agile the team closes work with the customer and is flexible to move around the dates of the planned features within a specific project line. This means if the client needs a certain feature ahead of time and needs some improvements these can be easily prioritized for the next sprint. 
  4. Flexible over fixed plan: Agile sprints can be redesigned and re-planed as per the customer’s needs. This means the concept of fixed plans does not fit in Agile. Since the Agile plans are created for sprints that are only about 2-3 weeks long, it is easier to move features from one sprint to another as per the business and customer needs easily. 

DevOps – Core Values
DevOps is an amalgamation of Development and Operations. Both these teams work together as one to deliver quality code to the market and customers. 

  • Principle of flow: Flow means the actual development process. This part of DevOps normally follows Agile or Lean. The onus is more on quality than quantity. The timelines are not as important as the quality of the products delivered. But this is true only for new features, not the change requests and hot fixes. 
  • Principle of feedback: The feedback and any broken functionalities reported in production need to be immediately fixed with hotfixes. The delivery features are flexible based on the feedback received from the features already in production. This is the most important aspect of the feedback principle. 
  • Principle of continuous learning: The team needs to continuously improvise to streamline the delivery of features and hotfixes. Whatever is developed needs to be automatically tested and then a new build delivered to prod. This is a continuous process.

Test your ecommerce website for bugs
Wish to know about TMMI (Test Maturity Model Integration) Reas this!
Agile VS DevOps: The key differences
In this section, we have tabulated the differences between Agile and DevOps for a quick understanding and review. 

Feature  Agile DevOps
Type of Activity Development Includes both Development and Operations.
Common Practices Agile, Scrum, Kanban, and more CI (Continuous Integrations), CD (Continuous Deployment)
Purpose Agile is very useful to run and manage complex software development projects DevOps is a concept to help in the end-to-end engineering process. 
Focus  Delivery of standalone working code within a sprint of 2-3 weeks  Quality is paramount with time being a high priority in the feedback loop (hotfixes and changes requests)
Main Task Constant feature development in small packets Continuous testing and delivery to production
Length of Sprint typically, 2-4 weeks It can be shorter than 2 weeks also based on the frequency of code check-ins. The ideal expectation would be code delivery once in a day to once every 4 hours. 
Product Deliveries Frequent, at the end of every sprint Continuous delivery. Coding, testing, and deployment happen in a cyclic manner
Feedback Feedback and change requests are received from the client or the end-users Feedback and errors are received from automated tools like build failure or smoke test failures etc.
Frequency of Feedback Feedback received from the client at the end of every sprint or iteration Feedback is continuous
Type of Testing Manual and Automation Almost completely automated
Onus of Quality More than quality, priority is on working code. Ensuring good quality is the collective effort by the team. Very high-quality code only is deployed once it passes all the automated tests. 
Level of Documentation Light and Minimal Light and Minimal (sometimes more than Agile though)
Team Skill Set The team will have a varied skill set based on the development language used and types of testing used The team will be a mix of development and operations. 
Team Size Agile teams are small so they can work together delivering code faster Teams are bigger and include many stakeholders
Tools Used JIRA, Bugzilla, Rally, Kanban Boards, etc. AWS, Jenkins, TeamCity, Puppet

Agile VS DevOps Infographics for quick understanding
difference between agile and devops
Last Thoughts,
Agile VS DevOps which one is better?
Both Agile and DevOps are here to stay. While Agile is a methodology or process that focuses on the delivery of small packets of working code to production, DevOps is more like a culture. A culture that advocates continuous delivery of code to production automatically after successful testing. Agile enhances DevOps and its benefits too. Both work hand-in-hand for a better and more quality product.

Protractor vs Selenium: What are the major differences?

Protractor vs selenium who will win? Both the test automation tools are equally good. However, one has some features that make it supreme to the other.
Test Automation is the need of the hour and is widely adopted by the testing teams across the globe; to assist testers in automation testing several testing tools are now available in the markets.
To achieve the best testing results, it is very important to choose the most appropriate testing tool according to your requirements.
Sometimes, testers sometimes get stuck between two automation testing tools.
And if you are the one, who is having a difficult time picking the aptest testing tool out of Selenium vs Protractor, then go ahead and read this article to find out a solution.

Selenium 
Selenium is used for automation testing of web applications and is an open-source testing tool.
Selenium is meant only for web-based applications and can be used across various browsers and platforms.
Selenium is an all-inclusive suite that is licensed under Apache License 2.0. It constitutes of four different tools under it:

  • Selenium Integrated Development Environment (IDE)
  • WebDriver
  • Selenium Remote Control (RC)
  • Selenium Grid


Selenium IDE
Selenium IDE GIF
The simplest among all the four tools under Selenium is Selenium IDE. Selenium IDE is used to record the sequence of the workflow.
This Firefox plugin is easy to install and is also companionable with other plugins.
It has some of the most basic features and is largely used for prototyping purposes. It is very easy to learn and use.
Selenium RC
RC
Selenium Remote Control (RC) allows the testers to choose their preferred programming language.
It’s API is quite matured and supports extra features to assists tasks beyond even browser-based tasks.
Selenium supports  Java, C#, PHP, Python, Ruby, and PERL and can perform even difficult level testing.
Selenium WebDriver

Selenium WebDriver is an advanced version of Selenium RC. It provides a modern and steady way to test web applications.
Selenium directly interacts with the browser and retrieves the results.
An added benefit of WebDriver is that it does not require JavaScript for Automation. It also supports Java, C#, PHP, Python, Ruby, and PERL.
Selenium Grid
Selenium grod
The main benefit of automation tools is faster execution and time-saving. In Selenium, Selenium Grid is responsible for the same.
It is specially curated for parallel execution of tests, on various browsers and environments; it is based on the concept of hub and nodes.
The main advantage of using this is time saving and faster execution.
What Protractor is all about?
Protractor is a powerful testing tool for testing AngularJS applications.
Though it is specially designed for AngularJS applications, it works equally well for other applications as well.
It works as a Solution integrator by assimilating the dominant technologies like Jasmine, Cucumber, Selenium, NodeJS, Web driver, etc.
Protractor also has a high capability to write automated regressions tests for web applications. Its development was started by Google but was later turned into an open-source framework.
Protractor
Why do we need Protractor?
Here are a few reasons to convince you to use Protractor:

  • Generally, most of the angular JS applications have HTML elements like ng-model and ng-controller, Selenium could not trace these elements, whereas Protractor can easily trace and control such web application attributes.
  • Protractor can perform multiple browser testing on various browsers like Chrome, Firefox, Safari, IE11, Edge. It assists in quick and easy testing on various browsers.
  • Protractor is suitable for both Angular and Non-Angular web applications.
  • Because of the parallel execution feature, it allows executing test cases in multiple instances of the browser simultaneously.
  • It permits the installation of various packages as and when needed. In simple words working with packages is easier in Protractor.
  • Working with multiple assertion libraries is possible with Protractor.
  • Protractor supports various cloud testing platforms like SauceLabs and CrossBrowserTesting, etc.
  • It assists in faster testing.
  • Runs on both real browsers and headless browsers.

What is Selenium Protractor?
If the app you are developing is on AngularJSit’s always a better option to use Protractor since

  • it’s meant for AngularJS apps
  • We can create customization from Selenium in creating Angular JS apps
  • Protractor can run on top of selenium giving all the advantages of Selenium
  • You can use API exposed by Webdriver and Angular
  • Uses the same web driver as that of Selenium

What is the best IDE for protractor?

  • Visual Studio
  • CodeSublime
  • TextAtom Editor
  • Brackets
  • Eclipse
  • EclipseVisual Studio
  • ProfessionalWebstorm

Difference between Protractor vs Selenium
Here are the basic points of differences between Selenium and Protractor:

Comparison Basis Selenium Protractor
Supported Front End Technology-Based Web Application Supports all front end technology Specially designed for Angular and AngularJS applications, but can be used for Non-angular applications also.
Supported Languages C#, Java, Haskell, Perl. PHP, JavaScript, Objective-C, Ruby, Python, R JavaScript and TypeScript.
Supported Browsers Chrome, Firefox, Internet Explorer ( IE), Microsoft Edge, Opera, Safari,  HtmlUnitDriver Chrome, Firefox, Internet Explorer ( IE), Microsoft Edge, Safari
Synchronization or Waiting Does not support automatic synchronization between tests and application. It needs to be explicitly synchronized using different waits. Supports Automatic wait for Angular applications, but they are not applicable for Non-angular applications. But you can explicitly synchronize waits in Protractor.
Supported Locators Strategies Supports common locator strategies like Id, className, name, linkText, tagName, partial link text, XPath and CSS  for all web applications Supports common locator strategies like Id, className, name, linkText, tagName, partial link text, XPath and CSS  for all web applications plus it also supports angular specific locator strategies such as model, repeater, binding, buttonText, option, etc. also permits the creation of custom locators.
 
Supported Test Frameworks
 
Based on language binding, it supports various Test Frameworks C#- NUnit,
Java- JUnit, TestNG
Python- PyUnit, PyTest
JavaScript- WebDriverJS, WebDriverIO
 
Protractor aids Jasmine and Mocha. The protractor is provided with Jasmine as a default framework.
Support for BDD Yes. (Serenity, Cucumber, JBehave, etc). Yes. Mocha,  Jasmine, Cucumber and Serenity/JS
Reporting Requires third-party tools:- TestNG, Extent Report, Allure Report, etc. Requires third-party tools:- protractor-beautiful-reporter, protractor-HTML-reporter etc
Managing browser drivers Requires third-party tools like  WebdriverManager to sync browser version and driver. Requires web driver-manager CLI to automatic sync between browser version and driver for Chrome and Firefox.
Parallel Testing Requires third-party tools like TestNG. Supports parallel testing.
Cost Open-source Open-source
Nature of Execution Synchronous Asynchronous
Needed Technical Skills Average Moderate
Support No official support operates on open community model No official support operates on open community model
Ease to automate Angular Applications Not easy, a lot of sync issues and difficult to find real wait conditions. It is made for angular applications hence it is easy to automate Angular Applications
Test Execution Speed Slower Faster
Ease of Scripting Requires more lines of code and hence scripting is difficult. Even more difficult than Selenium.
Support for Mobile Application No direct support Direct support
CI/CD integration Yes Yes
Docker Support Yes Yes
Debugging Easy Difficult
Test Script Stability Less stable scripts More stable scripts


Is protractor better than selenium?
Both Selenium and protractor are automated test tools for web applications.
Both are used to automate Angular Applications. As Protractor is specially designed for angular applications, so if you are testing angular applications, it is better to opt for a protractor.
By now you would have been pretty clear about the differences in both. and it would now be easier for you to choose the better tool for your requirements and the winner in Protractor vs selenium will change according to it.
Study your requirements clearly and pick the aptest tool for more efficient testing results.