Top 50 Manual Testing Interview Questions | Software Testing Interview Preparation | Edureka

Summary

Highlights

• Archana kicks off the video highlighting the need for manual testing despite the rise of automated tests. 🎬
• The session is divided into categories: beginner, advanced, and real-world scenario-based questions. 📚
• Key differences between manual and automation testing are thoroughly examined. 🔄
• She explains various manual testing types, emphasizing the significance of each. 📝
• There's an in-depth discussion on dealing with defects and bugs within the software lifecycle. 🐛

Key Takeaways

• Manual testing is indispensable when automation isn't feasible, ensuring versatility in software testing. 🛠️
• Understanding the distinction between quality control and quality assurance is crucial for effective testing strategies. 🔍
• Knowledge of different testing types, like black box and white box testing, enhances a tester’s toolkit. ⚙️
• Real-world scenarios discussed provide a practical approach to manual testing. 🌍
• Preparation for the 'Top 50 Manual Testing Interview Questions' can significantly boost interview confidence. 🚀

Overview

Chapters

• 00:00 - 01:00: Introduction and Importance of Manual Testing This chapter introduces the significance and role of manual testing in the software development process. Presented by Archana from Ed Eureka, it emphasizes why testing is vital for the success of software products in the current competitive environment. While acknowledging the rise of automation testing, the chapter underlines that manual testing is still necessary in many situations that automation cannot cover, thus highlighting its enduring importance.
• 01:00 - 02:00: Categories of Manual Testing Questions The chapter explains the importance of manual testing in software development. It emphasizes that not everything can be automated, making manual tests crucial. The demand for manual testing skills is high, and this session provides guidance to help master it. The agenda for the session is briefly hinted at but not detailed.
• 02:00 - 22:00: Basic Interview Questions on Manual Testing The chapter begins by categorizing manual testing interview questions into three levels: beginner, advanced, and real-world scenario based. The intention is to make it easier for readers to understand and prepare for interviews. The speaker also urges the audience to subscribe to the Eureka YouTube channel for updates on current training technologies.
• 22:00 - 45:00: Advanced Manual Testing Interview Questions The chapter "Advanced Manual Testing Interview Questions" discusses higher-level questions related to software testing. The first question addressed is fundamental - 'What is software testing?' It explains that all systems inherently have software bugs, as achieving a flawless software product is practically impossible. Thus, software testing is defined as the process of executing a software application to identify bugs or errors.
• 45:00 - 53:00: Real-world Scenario Based Questions The chapter discusses the rigorous process programmers undergo to ensure software is bug-free before it goes public. It highlights the importance of software testing, which involves checking the developed software's design and functionality for any errors. The chapter concludes by introducing a question regarding the necessity of software testing.
• 53:00 - 56:30: Conclusion The chapter titled 'Conclusion' discusses the critical importance of software testing for organizations. It emphasizes that testing ensures that a software product is safe and ready for public release. The chapter outlines key reasons for the necessity of testing: it identifies defects and errors from the development phase, provides quality assurance, and reduces the coding cycles by catching issues early in the process.

Top 50 Manual Testing Interview Questions | Software Testing Interview Preparation | Edureka Transcription

• 00:00 - 00:30 [Music] hey guys this is Archana from Ed Eureka and a welcome you all to this session on manual testing interview questions testing is really crucial to success of any software product in this competitive world Domitian testing is raised these days unfortunately it cannot be applied in all the scenarios no matter how good
• 00:30 - 01:00 automated tests are you cannot automate everything and that is why manual tests play a very important role in software development as well as testing and they come in handy whenever you have a case where you cannot use automation hence there's lot of demand for people with skills relevant to manual testing this manual testing interview question session is the perfect guide for you to master manual testing so without any delay let's go ahead and take a look at today's agenda to make it much more
• 01:00 - 01:30 easier for you guys to understand I've divided the questions into three categories Wignall level manual testing interview questions advanced level questions and lastly we have real-world scenario based questions which are based on manual testing so I hope agenda was clear to you guys but before we actually get started please do not forget to subscribe at Eureka youtube channel to stay updated with current training technologies so here we go let's begin with the first category of questions
• 01:30 - 02:00 which are bigger level questions the first question that we have here is very basic what the software testing explain in simple terms do you guys agree with me when I say every system has software box well it's true light it's impossible to design and bring out a perfect software product so software testing basically is the process of executing any sort of software or an application to find out if there are any bugs or some sort of errors in it so before
• 02:00 - 02:30 actually goes public programmers spend Hass trying to iron out every little bug there is they check for any mistakes and problems in the design and the functionality of the software well until then product won't be available for commercial use in the market so as the name already suggests software testing means checking the develop software for any mistake and problems in the initial design next up we have a following question which says why software testing require and
• 02:30 - 03:00 how does testing benefit and organization software testing is really a mandatory process which guarantees that software product is safe and good enough to be released to market for public to use it well here are some compelling reasons to provide testing is really needed first of all it points out the defects and errors that were made during the development phase so basically it provides a quality assurance it reduces the coding cycles by identifying issues at the initial
• 03:00 - 03:30 stage of development itself it ensures that a software application requires lower maintenance cost and net results and more accurate consistent and very reliable results testing ensures that customer finds the organization more reliable and their satisfaction in the application is maintained continuously testing also make sure that software is buck free and the quality of the product meets the market standard and lastly it ensures that the application doesn't
• 03:30 - 04:00 result in any failures that could be of some harm to people who are using it so in this way software testing is really required to bring out a high-quality and safe product to market moving on to next question we have what are the two main categories of software testing well software testing can be divided into multiple categories based on different scenarios but mainly you can divide software testing into two types which is manual testing and automation testing so
• 04:00 - 04:30 manual testing it's pretty self-explanatory which is testing of a web application is basically done by human action that means someone actually goes on a device to evaluate numerous components like design functionality and performance of the application but a testing to find defects or bugs manually is really time consuming light it's expensive it's often repetitive and it's subjective to human error and that is why automation testing comes into picture automation testing is well automated if I have to tell Ordovician
• 04:30 - 05:00 testing uses the assistance of tools scripts and software to form test cases by repeating predefined actions so these are two main categories of software testing manual testing and automation testing next question that we have is what exactly is quality control there are different terms that are associated with quality when we are referring to software you have quality control quality assurance and many more so what exactly is quality control
• 05:00 - 05:30 well quality control is a product oriented approach of running a program to check if it has any defects the key point that you have to remember is it is product oriented approach so using quality control testers make sure that the software meets all the requirements which are put forth by stakeholders and end-users it includes different type of testings like you are functional testing like unit testing usability and integration testing you also have non-functional testing like compatibility security and
• 05:30 - 06:00 performance and all that so quality control in general is a product oriented approach of running a program to determine if it has any defects or not moving on to the next question it says what different types of manual testing are there will basically you have six types of manual testing which are black box testing white box testing unit testing system testing acceptance testing and integration testing well let me explain you all of these types in a very brief manner but if you want to
• 06:00 - 06:30 know more you can actually go ahead and refer to Ed Eureka YouTube playlist on software testing so what exactly is blackbox testing and blackbox testing testers analyze the functionality of the software or an application without actually knowing much about the internal design or structure of the application that they're testing talking about a white box testing and light black box testing white box requires a profound knowledge of code as it includes testing of some structural part of the
• 06:30 - 07:00 application next step you have unit testing it's a way of testing the smallest piece of code which we usually refer to as a unit then there's integration testing where you test the interface between the units after that we have system testing which is done to examine the fully working of an integrated software system against the user and lastly we have UAT or acceptance testing it's a formal testing that's performed based on user requirements and function processing this type of testing
• 07:00 - 07:30 that's acceptance testing it covers end-users real-world scenarios so yeah these are six typical types of manual testing moving on to your next question explain the difference between alpha testing and beta testing well both alpha and beta testing are customer validation methodologies on top of that both of our acceptance testing types they help in building confidence to launch the product in the market and that's how
• 07:30 - 08:00 they result in success of product in the market so what exactly is alpha testing all 4 testing is internal acceptance testing which is performed to identify all possible issues and box after acceptance testing but before releasing the software for beta testing so the focus of this testing is to simulate real users by using black box and white box technique the key point is you perform it after acceptance testing but before actually releasing the product for beta testing now beta testing of a
• 08:00 - 08:30 product is performed by real users of software application in real environments it allows the customer an opportunity to provide inputs to the design functionality or it could be usability of a product though companies like do rigorous in-house Quality Assurance with dedicated test teams it's practically impossible to test an application for each and every possible combination of test cases right and that is why it beta releases make it much more easier to test the application on thousands of test machines and fix the
• 08:30 - 09:00 issues before actually releasing the product to market an alpha testing is performed before beta testing so yeah that's the difference between alpha and beta testing and hope the difference is clear let's move on to next question what are the different levels of manual testing so beat a manual testing or automation testing or software testing in general there are like four levels first up you have unit testing then there's integration testing after that system testing and lastly you have acceptance testing so unit testing is a
• 09:00 - 09:30 way of testing the smallest piece of which is referred to as unit a unit is something it can be logically isolated in a system it can be anything that you want it can be a specific piece of functionality or it can be a program or a method in a program anything so the main focus here is on the functional correctness of these standalone modules or units next up there's integration testing it's performed after unit testing when different units components
• 09:30 - 10:00 and modules of software are integrated together the focus of integration testing is to check the correctness of communication among all the modules so in simple terms you can say that you are checking the interface that's there between the different units or modules after that the system testing is carried out on a complete fully integrated software product to evaluate the behavior of the system and then to examine the fully working of an integrated software application
• 10:00 - 10:30 according to user requirements on the system testing we have different techniques like functionality testing performance testing scalability testing load testing stress testing regression testing and many more and the last level that we have is UAT or user acceptance testing or in simple terms acceptance testing it's the formal testing that's performed based on user requirements and a function processing this acceptance testing actually covers end-users real-world scenarios and this
• 10:30 - 11:00 last level needs to be done correctly because it provides you with a little on the bases off if the software product is fit to be released to the market or not so yeah these are four levels of manual testing so the next question that we have is what's the difference between quality control and quality assurance we did already talk about what quality control is quality control is set of activities for ensuring quality in the product so the activities focus on identifying defects in actual product
• 11:00 - 11:30 produced where is quality assurance a set of activities for ensuring quality in the processes by which product or develop so you get my point right quality control is a product oriented approach were checking the quality or defects in the product whereas Quality Assurance is a process to the preacher checking the quality of the process by which products or develop so quality control aims to identify defects in the finished product therefore it's a reactive process whereas quality assurance prevents
• 11:30 - 12:00 defects with the focus on processes which are used to make the product therefore it is a proactive process i hope the difference is clear let me summarize quality control is a product oriented approach of running a program to determine if it has any defects as well as making sure that software meets all the requirements put forth by end-user and stakeholder where is quality assurance is a process oriented approach that focuses on making sure that methods
• 12:00 - 12:30 techniques and processes which are used to create the product meets the quality standard the next question that we have is of what is a testbed in manual testing explain with help of an example testbed in simple terms is a test execution environment which is configured for testing it consists of hardware software networking figuration application which is on the test operating system settings software configuration test terminals and much more so in simple terms it's a test
• 12:30 - 13:00 execution environment which is configured for testing well a typical test pit for a web-based application looks something like this you have Java version listed out you have the browser that you're using listed out operating system settings like Windows or Linux then the database that you're using web server etc it has all the details which are required for you to perform testing next question is explain the procedure for manual testing well it's quite simple and similar to any other standard
• 13:00 - 13:30 software testing first of all you start by understanding the requirements which are put forth by the users based on the requirements you write the test cases and after that you conduct the test cases that you have written and categorized once you're conducted the test and you have your result you create good bug report which you will have to submit to your manager or higher-level people in the next stage simple enough right you start with understanding the requirements put forth by the users
• 13:30 - 14:00 categorize the requirements and write test cases and separate them into different groups to make it much more easier to identify once you have your test cases you execute them and once you get the results you create the report and submit the reports to higher authorities so that's the general procedure that you follow when performing manual tests the next question is what exactly is test case explained with an example guys documentation plays a very important role in testing be it manual testing or automation testing a test
• 14:00 - 14:30 case is one of the documentation used it's a document which are set of conditions or actions the top performed and software application in order to verify the expected functionality of a feature so basically test cases describe a specific idea that is to be tested without actually detailing the exact steps to be taken or data to be used for example let's say in a test case your document looks something like this
• 14:30 - 15:00 quotation test if coupons can be applied to actual price quotation clothes so that's your best case statement let me read it again test if coupons can be applied on actual price so as you can notice the statement doesn't actually mention how to apply the coupons or whether they are multiple ways to apply or not it doesn't mention if tester uses a link to apply this count or does he enter a code or does he have a customer service to apply it it doesn't go into much detail it just specifies the major
• 15:00 - 15:30 objective of testing in simple terms so this test case is they give flexibility to tester to decide how they want to execute the test next question that we have is what is API testing API as you guys might know has an acronym for application programming interface which is a software intermediate tree that allows two applications to talk to each other so API testing is a type of software testing where API or application programming interfaces are tested to check if they meet expected
• 15:30 - 16:00 functionality reliability performance and security API testings really needed to reveal bugs inconsistencies and deviations from the expected behavior of an epi well to be honest API testing office Lord of advantages like its language-independent first of all and its graphical user interface independent it offers improved test coverage it reduces the testing cost it enables faster releases and all that on top of
• 16:00 - 16:30 that one more thing that you remember is basically application is divided into three stages you have presentation day or then you have business layer and database layer so API testing is usually performed in business layer let's mount your next question let's see what that is so what's the difference between verification and validation in manual testing in software testing a verification is a means to confirm that the product development is taking place according to the specifications and using standard development procedures it
• 16:30 - 17:00 consists of different activities like you have reviews inspection walkthroughs demos and all that so basically you're confirming that the product development is taking place according to the requirement specifications and using standard procedures now coming to validation it's a means to confirm that the developed product doesn't have any bugs and it's walking as expected it consists of activities like functional and non-functional testing techniques so
• 17:00 - 17:30 that's the difference between verification and validation moving on to next question what's the difference between a bug and a defect so a defect is simply defined as a variance or difference between expected and actual result it's an error found after the application goes into production it commonly refers to several troubles with software products with a external behavior or with its internal feature so the key point is defect is an error which is found after the application goes into production coming back to bug
• 17:30 - 18:00 Park is a result of a coding error an error which is found in the development environment before the product is shipped to the customer a programming error that causes a program to work poorly produce incorrect results have crashed the system that's a balk or it can be an error in software or hardware that causes a program to malfunction entirely bug is the terminology of a tester now you understand the diff the effect is the difference between
• 18:00 - 18:30 expected and actual result and it occurs after the application goes into production there is bogus result of a coding error like I said it can be anything so it's error that's developed before the product is shipped to the customer moving on the next question that we have is what are advantages of manual testing manual testing is Lord of advantages to offer first of all you have life testing so with manual testing test you can test the application on the similar condition when your application goes life so any bugs or glitches which
• 18:30 - 19:00 shock of an application is life can be easily tracked with help of manual testing secondly in manual testing less programming knowledge is required basically when you're testing on an application manually your main focus is on understanding requirements documenting the test cases and executing the test cases then there's this case of UI and UX is issues when it comes to automation testing so basically automated tests are quite literally robotic right they fail to act as a real end user would but manual testing helps
• 19:00 - 19:30 test you to identify any shoes which are related to look and feel of the application it also helps to find out the usability issues in the application on top of all that manual testing requires you early low investment as it doesn't require any costly tools or highly skilled people to be hired so what I meant to say is initial investment in manual testing is very low and a man is testing is cost-effective for short term projects lastly in manual testing you can swiftly
• 19:30 - 20:00 test and see the outcomes so it's well suited in cases when you're making lot of unplanned changes to your application and also your application needs to be tested immediately after implementing these changes in such cases manual testing is really effective let's move on to your next question which is what are disadvantages of manual testing apart from the pros it offers it has lot of D merits as well first of all it's really time-consuming manual tests cannot be reused which means every time there's a change in your application the
• 20:00 - 20:30 tester needs to run all the test cases again well this is rather time consuming activity and that is why manual testing is usually time-consuming then you have like testing limitations you can't go and apply manual testing for performing load and performance testing see to check the performance of an application using manual testing you require Lord of users and gadgets which again increases the cost of the testing so it's better to go for automation in that case and obviously since manual testing is performed by humans there's
• 20:30 - 21:00 always this possibility of errors the testing results will be as good as the tester performs the test that's it you can't guarantee the quality with a manual testing there are chances that the tester may miss out the same box on early testing application because it's being performed by human there's always possibility of that human making an error so yeah these are certain disadvantages of manual testing moving on the next question is is documentation really necessary in manual testing yes
• 21:00 - 21:30 documentation plays a critical role in achieving effective software testing well details like your designs business rules requirement specifications inspection reports configurations code changes test plans bug reports etc all should be documented documenting the disk cases will facilitate you to estimate the testing efforts that you will need along with your test coverage it'll help you to track and trace your requirements as well some commonly applied or used documentation artifacts
• 21:30 - 22:00 that are associated with manual testing hard with a discus one earlier which is test case after that we have test plants the scenario traceability matrix and many more well guys would this we've completed the basic level questions so let's move on to next level which is advanced level manual testing interview questions so let's see what's the first question an advanced level category so what's the difference between manual testing and automation testing you guys all know the
• 22:00 - 22:30 basic difference well manual testing is literally performed by humans or human action whereas automation testing is performed by human but with the assistant of tools scripts and other things that being the main difference let's go ahead and discuss other differences as well so manual testing since it's performed by humans the accuracy and the reliability of test cases are low whereas automation tests the hand is performed with tools and skips the reliability and accuracy is literally high the time required for
• 22:30 - 23:00 manual testing is literally high as human resources perform all the tasks where as time required for automation testing is comparatively low as software tools execute the test cases in manual testing the initial investment which you make is low because you don't use any kind of tools and all that your but the written of investment is low as well whereas an automation testing initial investment is literally high but your return of investments is also high manual testing is performed when you have test cases that need to be lon only
• 23:00 - 23:30 once or twice also when you have test cases suitable for exploratory testing usability testing or ad hoc testing you can use automation for performing regression testing performance testing load testing or when you have cases that need to be tested multiple times now one best thing about manual testing is that it allows for human observation to find out if there are any glitches and that's why manual testing helps in improving the customer experience when it comes to automation testing is no human
• 23:30 - 24:00 observation involved and that is why doesn't guarantee the positive customer experience that a manual testing guarantees so these are certain basic key differences between manual testing and automation testing now let's move on to our next question venture your opt for manual justing / automation testing there are certain key cases or scenarios when manual testing should be preferred for example when you have short time projects automated tests are aimed at saving time and resources
• 24:00 - 24:30 and yet they take lot of time and resources to design and maintain them for example if you are building a small promotional website it can be much more efficient to rely on manual testing rather than go ahead and create all those automated test cases well it takes time right so in such cases when you're working on small scale projects or projects which take small amount of time you could go for manual testing also when you have ad hoc testing in ad hoc testing there's no specific approach as in there's no fixed approach it's a
• 24:30 - 25:00 totally unplanned method of testing where the understanding and the inside of the tester is the only well again manual testing sounds good then there's the case of exploratory testing even then manual testing is preferred because in exploratory testing it requires test use knowledge experience skills analytical skills creativity and mainly intuition so human involvement is really important here lastly you have usability testing so when performing usability testing go ahead and use manual testing so when
• 25:00 - 25:30 performing usability testing usually the tester needs to measure how user-friendly efficient or convenient the software or the product is to end user so you should think in terms of end user for that again manual testing is preferred so these are certain scenarios where you can prefer manual testing over automation testing the next question that we have is what are the phases involved in software testing lifecycle well it's quite simple it begins with requirement analysis where you figure out or categorize the
• 25:30 - 26:00 user requirements next up based on the requirements that you've gathered you plan your entire test lifecycle once you're sure as to what you're performing testing on which type of testing you have to perform and all that you start developing your test cases then setup the entire test environment which will make your testing more effective after that you can start your test execution and lastly you have test cycle closure so let me repeat it again you begin by analyzing the requirements put forward by the end user then you start planning
• 26:00 - 26:30 your entire test cycle then you develop your test cases categorize them design your test environment after that basically you design on different kind of tests that you want to perform what you want a test on and all that then you execute the test cases that you've created and lastly then there's just cycle closure which indicates the end of your testing cycle next question that we have is a really interesting one what's the difference between a bug a defect and an error we did already discuss the difference between a bug and a defect
• 26:30 - 27:00 let me go through it again so defect is a variance or a difference between expected result and actual result detected by the developer after the product ghost life so defect is an error which is found after the application goes into production in simple terms it refers to several troubles with the software product with its external behavior or with it's internal features next up this bug it's a Ford and software that's detected during test time they're commonly because of some coding error which might
• 27:00 - 27:30 lead to the entire malfunctioning of a program they may also lead to a functional issue in the product so basically box our fatal errors that could block a functionality or result in a crash or cause performance bottleneck now what exactly is Error error is a mistake misunderstanding or misconception on part of software developer so when I say software developer it includes software engineers programmers analysts testers whoever is in contact with the software so for
• 27:30 - 28:00 example a developer may misunderstand a design notation or a programmer might just type a wrong variable name which might lead to an error error normally arises and software and it leads to change the functionality of the program so that's the difference between a bug a defect and an arrow moving on to the next question what actually makes a good test engineer first of all a good engineer should have a test to break attitude that's an ability to take the point of view of a customer you should have a strong desire for quality and
• 28:00 - 28:30 keen attention to detail also tact and diplomacy roles are needed which is to maintain a cooperative relation with rest of the developers that is involved to it and obviously it should have an ability to communicate with both technical people non-technical people as well so you should have excellent communication skills and it should have ability to judge the situations and make important decisions to test high-risk areas of an application when the time is actually very limited along with all
• 28:30 - 29:00 this it's always best to have an experience in software development or testing field because previous experience can be helpful as it provides a deep understanding of software development process and it gives the test us an appreciation for the developers point of view so these are certain qualities that you look for when you're hiring a good test engineer moving on to our next question what is regression testing and when to apply it a regression test is basically a system-wide tests whose main purpose is
• 29:00 - 29:30 to ensure that small change in one part of the system and break the existing functionality elsewhere in the system so if you consider regression testing as an unintended change then this type of testing is the process of hunting for those changes so in simple terms it's all about making sure that your old box doesn't come back to haunt you let's take a look at fixes example that illustrates the concept so when adding a new payment type to shopping website you have to rerun the old test to ensure that new code hasn't created any new
• 29:30 - 30:00 defects or it hasn't introduced or reintroduced any old ones so regression testing is really important because without it it's quite possible to introduce intended fixes into system that create more problems that they can actually solve so how do you actually a progression testing it's quite simple you have tested software but you'll have to add a new feature so a feature has been updated now you want to check if the new feature is affected or brought out any old bugs or if it has introduced
• 30:00 - 30:30 any new bugs for that you perform regression testing all you have to do is create a regression test plan just like how you perform the entire software testing lifecycle you carry that and you'll have newly tested software with updated feature well that's regression testing the next question that we have is what's the difference between system testing and integration testing it's quite simple system testing it tests the entire software application to see if the system is compliant with user requirements and stakeholders
• 30:30 - 31:00 requirements but integration testing it tests the interface between the modules or units of software application system testing it involves both functional and non-functional testing will examine a usability testing performance testing load testing and all that whereas only functional testing is performed an integration level or integration testing to check if two modules when combined gives the right outcome or if they are able to communicate properly through the interface or not well system testing is a high level testing which is performed after integration testing whereas
• 31:00 - 31:30 integration testing is a low level testing which is performed after unit testing the next question that we have is explain the defect lifecycle what are the different phases involved so you guys already know what bug is we already discussed this many times a bug is actually an arrow that could have been introduced in the due course of software development life cycles due to multiple reasons the common sources of bugs are it can be ambiguous requirements programming errors unachievable deadlines and much more every poor dead
• 31:30 - 32:00 bug actually follows a life cycle till its closure a bug lie circle basically illustrates the journey of a bug from the time it is reported to the time it's fixed and closed so let's quickly go through the steps that are involved in defect lifecycle or bug life cycle first if we have something called new state well in this step if a defect is logged and it's posted for first time its state is given as new then you have assigned state so after the tester has posed to
• 32:00 - 32:30 the bug the leader of the testing team approves that the bug is genuine and he assigns the bug to corresponding developer and the developing team to solve it then it's said to be in assigned state after that you have two other status which says open and fixed so in open state developer actually start analyzing the bug and start fixing it once he's sure that he's fixed the defect he changes the state of the bug to fixed next step we have the state so at this stage tester does the testing of change code which the developer has
• 32:30 - 33:00 given back to him so basically here the tester is checking of the bug which she has designed to developer has been fixed to not so once he is verified he changes the status of the buck to verify now in case if the bug still exists even after the bug is being fixed by the developer the tester it might decide to reconsider the bug in such state it goes to reopen state now if the tester things that bug is fixed he marks the status as closed there's another state called duplicate when the bug like cycle if bug is
• 33:00 - 33:30 repeated twice or there are two bucks which deals with the same concept then one bug status is changed to duplicate after that you have rejected and deferred rejected is if the developer feels that bug is not genuine he rejects the bug and the status of the bug has changed to reject before if the bug is changed to defer state it means that is expected to be fixed in next few releases it's quite simple if you have any queries in this defect lifecycle you can actually go ahead and refer to software testing tutorial by a new rake
• 33:30 - 34:00 up the entire lifecycle is explained in detail so I expect this concept is much more clear for you guys now let's mount the next question what is a test harness in testing explained in software testing a test harness or automated test framework is a collection of software and tested are configured to test a program unit by running it under multiple conditions and monitoring its behavior and output for all these conditions so basically it's a collection of software and test data
• 34:00 - 34:30 configured to test a program under multiple conditions by monitoring its behavior and its output test harness has two important paths test execution engine and test script repository but test harness should have low specific tests to be run it should all get straight a runtime environment and it should also provide a capability to analyze the results moving on to your next question what is test closure well des closure is a document which
• 34:30 - 35:00 gives a summary of all the tests which are conducted during the software development lifecycle and it also gives a detailed analysis of bugs removed and there are farm so this document or memo actually contains the total number of experiments total number of experiments executed total number of imperfections found and total number of imperfections settled total number of bugs or imperfections not settled total number of bugs rejected total number of bugs deferred and so forth so in simple terms
• 35:00 - 35:30 test closure is a document which was like summary of all the tests that are conducted during entire software development and testing lifecycle next question that we have is very basic question what's the difference between positive and negative testing and manual testing so positive testing means actually testing the application or system by giving valid data whereas negative testing means testing application or system by giving invalid data so positive testing it determines that your application is working as
• 35:30 - 36:00 expected the negative testing it ensures that your application can run gracefully and it can handle invalid input and unexpected user behavior in a very proper manner positive testing is always done to verify a known set of test conditions whereas negative testing is always done to break the project and the product with unknown set of test conditions positive testing checks how the product and the project behave by providing the valid set of data there is negative
• 36:00 - 36:30 testing checks how the application will actually perform if we provide the invalid output will it actually deal with it or give the wrong output or what would be the result that's negative testing so that's the basic difference between positive and negative testing so the next question that we have is define what's critical bug well a critical bug is a bug that's got tendency to affect majority of functionality of a given application it means that a large piece of functionality or a major system
• 36:30 - 37:00 component is completely broken and there's no way to walk around it application cannot be distributed to end client users if the critical bug has not been assured remember that moving on to our next question what has pesticide paradox and how do you overcome it if same test cases are repeatedly run over and over again eventually they will no longer will help you find new box and this concept is called pesticide paradox in testing
• 37:00 - 37:30 after certain number of iterations of testing has the testing improves the defect number actually starts dropping and most of the bugs will actually be fixed so developers will be extra careful in only those places where testers found more defects and they might not look in the other areas this is what you call pesticide paradox so how do you actually go ahead and overcome the specced aside paradox do you have any solutions well yes you can go ahead and write whole new set of test cases to exercise different parts of the software and you can prepare new test
• 37:30 - 38:00 cases and add them to your existing test cases so by following above two methods of prevention it's possible to find more potential defects in the area where you might have actually missed previously or where you might have neglected this that's what pesticide paradoxes and how you overcome it moving on to next question what is defect cascading in software testing certificate is process of triggering other defects and application simple right it's just triggering other defects and
• 38:00 - 38:30 application when a defect goes unnoticed while testing it invokes other defects well as a result multiple defects crop up in later stages of development if defect cascading continues to affect other features in your application identifying the affected actually affected feature becomes very challenging you might actually go ahead and take different test cases to solve this issue even that's difficult and time-consuming let me give you a simple example to understand the concept so an application is being deployed to calculate a monthly salary of the
• 38:30 - 39:00 employees the module which is responsible for calculating salaries is having an unidentified defect as a result it's strongly calculating the salary this prompts the database to transmit in collect salary numbers which are further reflected in your balance sheet tax calculations and wherever the salary part is used so one defect is triggering other defects in obligation that's what defect cascading is let's move on to our next question which is what do you actually mean when you say a
• 39:00 - 39:30 quality software so in general quality software is reasonably bug free it's delivered on time and within budget it meets the given requirements or expectations and it's highly maintainable but again quality is always a subjective term it will depend on who the customer is and their overall influence in the scheme of your testing for example each type of customer will have their own slant for quality the
• 39:30 - 40:00 accounting department might define quality in terms of profit whereas if you ask a general end user he might define quality as user friendly safe and buck free so again quality is a subjective term the next question that we have is what is black box testing and what are various techniques that come under black box testing so black box testing is also known as specification based testing it analyzes the functionality of the application without knowing much about the internal
• 40:00 - 40:30 structure or design of the application that's being tested so what's the purpose of blackbox testing well it's to check the functionality of the system as a whole to make sure that it works correctly and it's meeting the user demands you have various techniques that pop up under blackbox testing like you have equivalence partitioning use case testing cause-effect graphing and many others the next question is also somewhat similar to that what is white box testing and what are various techniques white box testing is also
• 40:30 - 41:00 known as structured based destiny it requires a profound knowledge of code as it includes testing of some internal structures a part of application so unlike blackbox testing in white box testing the tester need to have some sort of knowledge regarding internal architecture of the application that is testing the purpose if you ask is to enhance the security check the flow of input/output through application to improve the design usability and all that various techniques that come under
• 41:00 - 41:30 white box testing are you have decision coverage statement coverage condition coverage multiple condition coverage and many others another question based on the same concept is what our experience based testing techniques experience beta testing is all about discovery invention intuition and it's all about learning so the tester constantly studies and analyzes the product and accordingly applies or skills traits experience to develop at rest at eg and design test cases so various techniques that come
• 41:30 - 42:00 under this category are exploratory testing in irrigation the next question that we have is what's the difference between top-down and bottom-up approach while it's all there in the name of the term itself in top-down approach testing happens from top to bottom that's high level modules are tested first and after that low level modules and lastly low level modules are incorporated into a high level state to guarantee that framework is working as its supposed to do similarly in bottom-up approach testing
• 42:00 - 42:30 happens from base levels too high up levels the lowest level modules are tested first and after that high level modules and lastly high level modules are cooperated to low level state to see if the framework is working as expected or not moving on we have what's the difference between smoke testing and sanity testing it's quite simple the concept of smoke testing and sanity testing is very similar except smoke tests are executed on initial bills of
• 42:30 - 43:00 software product where is sanity testing our tests which are done on the bills that have passed smoke test and other rounds of regression test so what's the motive of smoke testing it's to measure the stability of newly created built so that it can go for more like restaurants of testing what's the motive of sanity testing that's to evaluate rationality and originality of the functionalities of software bits another main difference is that smoke testing involves lot of
• 43:00 - 43:30 documentation and scripting ugh whereas sanity testing doesn't emphasize any sort of documentation smoke testing is a shallow and wide approach to include all major functionality is without actually going much deep whereas sanity testing is narrow and deep approach and it involves detailed testing of functionalities and features smoke testing is executed by developers as well as testers sometimes where a sanity testing is executed only by testers we have another difference based question which is the difference between
• 43:30 - 44:00 static testing and dynamic testing so static testing is a white-box testing technique it includes the process of exploring the records of documents to recognize the imperfections in early stages of software development lifecycle the key point is static testing is performed in the early stages of development lifecycle to recognize imperfections dynamic testing it includes lot of execution of code and it's done at later stage of software development lifecycle it validates and
• 44:00 - 44:30 it approves the output with expected results static testing is usually implemented at verification stage so that's early stages whereas dynamic testing usually starts during validation stage static testing is performed before the code deployment and dynamic testing is performed after the code deployment another important thing is code alert detection and execution of program is not much of a concern when it comes to static testing whereas execution of code is really
• 44:30 - 45:00 necessary when you're performing dynamic testing so these are some key differences between static testing and dynamic testing so guys with this we have come to the end of advanced level questions or you can say theory based questions now let's go ahead and deal with some real-world scenario based questions so the first question that we have under this category is how will you actually go ahead and determine when to actually stop testing deciding when to stop testing can be really difficult many modern software applications are so
• 45:00 - 45:30 complex and they run in such interdependent environment that complete testing can never be done you agree with me there right so some common factors that you can consider when you're facing difficulty to decide on when to stop your testing are that you can go ahead and consider the deadlines which are release deadlines testing deadlines and all those and suppose if I have test cases which are completed with certain pass percentage then maybe you can go ahead and stop testing after you think that the amount of pass percentages enough or when your test purchase is
• 45:30 - 46:00 completely depleted well again that's another reason to stop testing or when coverage of korah functionality or any other requirements reaches a specific point or when your bug rate falls below a certain level that you can no longer proceed with testing or when your beta or alpha testing period actually ends well these are certain simple ideas that can help you decide when to stop testing moving on to the next question what if the software is so buggy that it cannot be tested at all offering testers
• 46:00 - 46:30 encounter a bug that cannot be resolved at all in such situations the best thing is for testers to go through the process of reporting whatever bugs they find and focus mainly on critical box well since this type of problem can cause other issues like insufficient unit testing or insufficient integration testing poor design of the application improper build or release procedures etc the higher authorities or managers should be notified and it should be provided with
• 46:30 - 47:00 some sort of documentation as a proof or evidence of the problem saying that so-and-so bug has come up and we are facing an issue where we're not able to solve this bug at all so in that way they should provide some sort of documentation as an evidence of proof to their higher authorities saying that bug is really not testable at all moving on the next question how you actually test a product if the requirements are yet to freeze it's possible that a requirement stack is not exactly or not
• 47:00 - 47:30 available for a piece of product sometimes it might be exceed is effort to decide if an application a significant unexpected functionality and obviously it would indicate deeper problems in software development Russells so what do you do in such situations so if the functionality for this for which requirements are not there is it necessary for functioning of your application maybe you can actually remove that functionality well if you think that functionality is really necessary then go ahead create a test plan based on the exceptions that you have made
• 47:30 - 48:00 about the product but again make sure that all the assumptions that you've made you get it right and they are well documented in the test plan moving on to the next question what if an organization is growing so fast that fixed testing procedures are impossible what are you doing such situations well this is a very common problem which is perfect in software industry especially considering the new technologies that are being incorporated and some that are being popped up very now and then so there's no easy situation or solution
• 48:00 - 48:30 for the scenario you can actually go ahead and I very skilled and good people to deal with the situation our management should actually ruthlessly prioritize quality issues and their main focus should be put on customer and everyone in the organization should be clear on what actually quality means to them so these are certain solutions that they can adopt in situation where they actually think that the fixed testing procedures are no longer plausible or it can be applied next question that we have is how do you know that the code
• 48:30 - 49:00 has actually met the specifications so when I say a good code it doesn't have any particular definition in simple terms good code is code that works that's bug free it's readable and highly maintainable so most organizations have their own coding standard that all the developers and testers are supposed to stick to but everyone has to the ideas about what's best what's too many tools and what's very few rules so there's no fixed thing as good code or anything well honestly there are a lot
• 49:00 - 49:30 of tools these days that can help you check if your code is sustainable if it's good or if it is met specifications for example you have something called traceability matrix which ensures that all your requirements are mapped to the test cases and when the execution of all the test cases finishes with success it indicates that the core is met your requirement so you can go ahead and use such tools to see if your code has met the specifications or not let's move on to a next question so what are certain
• 49:30 - 50:00 cases where you consider to choose automated testing or manual testing automated testing can be considered over manual testing during multiple situations for example when you have test cases that require periodic execution when the tests include repetitive steps when tests need to be executed in a standard runtime environment you can go ahead and adopt automation testing rather than manual testing also when you have very less time to complete the test phase when there's lot of code that needs to be repeatedly tested and then there are
• 50:00 - 50:30 reports that are required for every execution then actually you can go ahead and use automation than manual so the next question that we have your is quite interesting what's configuration management so every high functioning organization has a master plan right that details how they're supposed to operate and how they're supposed to achieve their goals and all that well software development and testing are no different software configuration management or SCM is set of processes
• 50:30 - 51:00 policies and tools that organize control coordinate and track code different documentation problems change request designs tools compilers and libraries well you can call it as a master plan for testing next question is is it true that you can actually go ahead and do system testing at any stage system testing all the components of software are tested as a whole in order to make sure that overall product meets the requirements specified so no system
• 51:00 - 51:30 testing cannot be performed at any it can only start if all the units or modules are in place and they're working individually properly another thing is that system testing actually happens before you perform user acceptance testing next question is what are certain best practices that you should follow in writing test cases when you're performing testing on a large scale you have like thousands of requirements to consider and if you go ahead and write
• 51:30 - 52:00 your desk cases randomly it will become difficult for you to track later on for that very reason you have some practices that you can go ahead and follow and it'll make you much more easier to keep track of your test cases so first of all prioritize which test case to write based on the project timeline and the risk factor of your application always remember the 80/20 rule so to achieve best coverage 20% of your test should cover 80% of your application that's 80/20 rule so don't try to test all the
• 52:00 - 52:30 cases in one attempt instead improvise them as you progress let's down your test cases and classify them and separate them based on your business scenarios and different functionality make sure your test cases are modular and your test case steps are as granular as possible another thing is that write your test cases in such a way that others can easily understand them and modify them if required always keep end-users requirement and back of your mind because ultimately the software product that you're testing or
• 52:30 - 53:00 designing is for the test end users well always remember using a test management tool to manage stable release cycle monitor your test cases regularly write unique test cases and remove irrelevant and duplicate ones moving on to your next question why is that boundary value analysis provides very good test cases so the reason my boundary value analysis provides good test cases is that a greater number of errors actually accurate boundaries rather than in the center of the input domain for any test
• 53:00 - 53:30 so basically in boundary value analysis test cases are designed to include values at boundaries and that's why boundary value analysis provides very good test cases so if the input is within the boundary value it's considered positive testing and if your input is outside of your boundary value it's it's not- testing so when I say boundary value analysis it includes different values like maximum minimum inside or outside edge typical values or error values next question that we have is why
• 53:30 - 54:00 is it impossible to test a program thoroughly or in other terms 100% bug free cuz it's impossible to build a software product which is 100% bug free you can just minimize their or flaws or failures all falls in your computer programmer system which cause it to produce an unexpected result but it's impossible to make it hundred percent error free well here are some two principal reasons that make it impossible to test a program entirely first of all software specifications and
• 54:00 - 54:30 requirements can be subjective and it can lead to different interpretations secondly a software program might require too many inputs too many outputs and too many path combinations just test well these reasons make it impossible to test a program entirely so the last question that we have is can automation testing replace manual testing automation testing isn't a replacement for manual testing no matter how good
• 54:30 - 55:00 our tomato tests are you cannot actually go ahead and automate everything right manuals does play a very important role in software development and they come in handy whenever you have a case where you cannot apply automation so automation and manual justing each have their own strengths and weaknesses in simple terms manual testing helps you to understand the entire program or problem and explore the functionality of your feature or applications from users perspective or in other words with more flexibility another hand automated
• 55:00 - 55:30 testing helps save time in long run by using lot of tools and techniques and scripts so like I said both of them have the pros and cons so automation testing is an actually replacement it's another way of performing software testing well that's my opinion if you have different opinion or if you agree with me or no please do put them in the comment section below it'll be interesting well that's it guys but this we have come to the end the session regarding manual testing
• 55:30 - 56:00 interview questions and answers I hope you found it informative and interesting if you have any queries or any doubts please do put them in the comment section below and we will get back to you as soon as possible thank you guys I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist and subscribe to any rekha channel to learn
• 56:00 - 56:30 more happy learning