Exploratory testing involves understanding and testing an application without formal requirements by exploring and identifying scenarios.
Key Takeaways
- Exploratory testing is essential when requirements are missing or unclear.
- It requires testers to actively use and investigate the application to identify test scenarios.
- This method supports testing legacy or long-term projects lacking updated documentation.
- Misinterpretation of features as bugs is a common challenge in exploratory testing.
- Exploratory testing complements traditional testing methods like component and system testing.
What the video covers
- Exploratory testing is performed when formal requirements are missing or incomplete.
- Test engineers explore the application to understand its functionality and identify possible test scenarios.
- They document these scenarios and test the application based on their findings.
- This approach is common in long-running projects where requirements may be outdated or unavailable.
- Exploratory testing involves component, integration, and system testing while learning the application.
- It helps new testers understand complex or legacy applications without formal documentation.
- Drawbacks include the risk of misinterpreting features as bugs due to lack of requirements.
- Exploratory testing is a hands-on, investigative approach to software testing.
- It is useful in environments with slow release cycles or ongoing development over many years.
- Testers rely on their experience and intuition to uncover defects and understand the system.
Chapters
- 00:00Introduction to Exploratory Testing
- 01:11Definition of Exploratory Testing
- 02:21Process of Exploratory Testing
- 03:26Challenges in Software Development Timelines
- 04:26Exploratory Testing in Long-term Projects
- 05:31How to Perform Exploratory Testing
- 07:42Exploratory Testing and Component Testing
- 08:50Exploratory Testing and System Testing
- 09:57Drawbacks of Exploratory Testing
- 11:06Common Misunderstandings in Exploratory Testing
Full Transcript — Download SRT & Markdown
Speaker A
Hi guys, I welcome you all to another video of Software Testing by Entity. In this video, we are going to talk about what do you mean by exploratory testing in software testing. Before we proceed in this video, make sure that you hit the subscribe button down below. Let's get started with exploratory testing.
Speaker A
subscribe button down below let's get started with exploratory testing so in exploratory testing we have to explore the application to understand to understand the requirements completely and then we have to start testing our application requirements will be missing we need to
Speaker A
So, in exploratory testing, we have to explore the application to understand the requirements completely, and then we have to start testing our application. If requirements are missing, we need to explore the application ourselves in order to understand the requirements, and then we need to test. That is called exploratory testing.
Speaker A
that identified scenarios and then finally test the application by those looking into those scenarios that is called as exploratory testing so in easy one I am going to make the presentation what do you mean exploratory testing guys in exploratory testing your
Speaker A
The actual definition of exploratory testing says that I understand the application, identify all possible scenarios, document those identified scenarios, and then finally test the application by looking into those scenarios. That is called exploratory testing.
Speaker A
we I mean they will see the application of the trying to understand what was the requirement so they will take the application they will explore the application and they will identify all possible scenarios and finally they are going to write those particular
Speaker A
So, in easy terms, I am going to make the presentation: what do you mean by exploratory testing, guys? In exploratory testing, your application will be there, but there is no requirement. So, what test engineers will do? Test engineers will take the application and test themselves, explore the application. They themselves try to understand what is the requirement.
Speaker A
will do exploratory testing now the question arises why varmint will be missing chi is in each and every company you don't see a fast process means you cannot expect release to be done in just one month in each and every company you
Speaker A
I mean, they will see the application and try to understand what was the requirement. So, they will take the application, they will explore the application, and they will identify all possible scenarios. Finally, they are going to write those particular scenarios, and finally, they are going to test the application by looking at those scenarios. That is called exploratory testing.
Speaker A
human companies who are developing who are into the same project from the last 20 years there are companies if you want I will write down the list of those companies in the link description please check it out so question was why the
Speaker A
The thing is, I will do exploratory testing when there is no requirement at all or when requirements are missing. That type of test engineers will do exploratory testing. Now, the question arises, why requirements will be missing?
Speaker A
scratch from starting it is very difficult for him in that case what the stingy that will do software will be ready right from 20 years what are things you have done right he will take the application and he will start
Speaker A
See, in each and every company, you don't see a fast process. I mean, you cannot expect a release to be done in just one month in each and every company. You cannot expect people to deliver the software in a very small period of time. So, there are many companies who are still in the development process for that particular software from the last five years, from the last 15 years. There are human companies who are developing, who are into the same project for the last 20 years. There are companies. If you want, I will write down the list of those companies in the link description. Please check it out.
Speaker A
time you won't be knowing how to work it but over a period of time when you keep using that application even people understand how the application works right in a similar way when a project is 15 years old continuous or let's say one
Speaker A
So, the question was, why the requirements will be missing? Suppose companies are into some project which is 20 years old. You have hired a test engineer. Now, for the new hire test engineer, it is very much difficult to understand each and every scenario or requirement from scratch, from the starting. It is very difficult for him.
Speaker A
the application nothing but he will do exploratory testing why the comment will be missing because if project is very old it is highly impossible for the testing unit to crap or to understand each and every scenarios from scratch or
Speaker A
In that case, what the test engineer will do? Software will be ready, right, from 20 years. What are things you have done, right? He will take the application and he will start exploring the application. He will start, guys, exploring. Exploring is nothing but he will start using the application.
Speaker A
the application you use the application in trying to understand the application that is called as exploratory testing as you guys know that in any application the main testing that we do is called as component testing integration testing and system testing so if you want to
Speaker A
And once you use any application, you will get to know how the application is working, right? When you download any application for the first time, you won't be knowing how to work it, but over a period of time, when you keep using that application, even people understand how the application works, right?
Speaker A
will try to understand each and every component when you try to understand each and every component you are doing component testing you are trying to test each and every component but you're actually doing exploratory testing you are exploring it
Speaker A
In a similar way, when a project is 15 years old continuous or let's say one year old also, it is highly impossible for the newly hired test engineer to understand the requirements from scratch. In that case, the test engineer will just pick the application and he will explore that provision. He will use the application. Nothing but he will do exploratory testing.
Speaker A
understand the application when you are doing your testing the application you will even perform system testing why doing system testing you you're doing is system testing but indirectly you're trying to understand the application that is nothing but exploratory testing you're trying to
Speaker A
Why the requirement will be missing? Because if the project is very old, it is highly impossible for the testing unit to grasp or to understand each and every scenario from scratch. Or if the project is highly old, chances are there that requirements will be missing. In that case, we go for doing exploratory testing.
Speaker A
doing exploratory testing so the first drawback of doing exploratory testing is guide you when you don't have any requirement with you you are testing the application you are exploring it you don't have any requirement we're just trying to explore
Speaker A
Now, the biggest question is how do exploratory testing? Guys, you use the application and you try to understand the application. You use the application in trying to understand the application. That is called exploratory testing.
Speaker A
don't know what are not feature it should have but when you see the application you are trying to understand the application there is a feature in application but you think that it is not at all required that time you feel that
Speaker A
As you guys know that in any application, the main testing that we do is called component testing, integration testing, and system testing. So, if you want to understand any application, the application is in front of you, but you don't have the requirement. So, what will you do? You will try to do component testing first.
Speaker A
and they are also asking you to put your employee ID and then login button this is how the requirement says but when you are doing exploratory testing you feel that only use the name password and login button was sufficient there is
Speaker A
Suppose it is having a registration page. It is having many components in it. You will try to understand each and every component. When you try to understand each and every component, you are doing component testing. You are trying to test each and every component, but you are actually doing exploratory testing. You are exploring it.
Speaker A
requirement and you are doing exploratory testing you feel that it is a pub so this is a first drawback of doing exploratory testing second drawback of doing exploratory testing is you might misunderstand bug that means suppose there is a login page
Speaker A
Suppose you now have many modules in it. You are trying to do some integration scenarios. While doing integration scenarios, you are doing integration scenarios, but indirectly you are just doing experiment with exploratory testing. Good. I know understand the application.
Speaker A
going to spend a core same code in mobile also mobile number also and email ID also but when you're doing exploratory testing and you are in the login page we are giving all the details your first name last name your mobile
Speaker A
When you are doing your testing of the application, you will even perform system testing. Why doing system testing? You are doing system testing, but indirectly you are trying to understand the application. That is nothing but exploratory testing. You are trying to understand the application.
Speaker A
in both both the places but when you started testing it the peepees will only move I'm not in Gmail but since the requirement is missing you will miss understand that this bug is actually a feature you will never come to know that
Speaker A
You are trying to perform all component testing, integration testing, and system testing, but since you don't know the requirement, you are doing nothing but exploratory testing. This is exploratory testing.
Speaker A
doing exploring the application and you are testing it that time time-consuming will be more this is a third trauma of the exploratory explain the fourth drop of doing exploratory testing is suppose your application is developed and you are exploring the application if any
Speaker A
Now we will discuss what are the drawbacks when you are doing exploratory testing. So, the first drawback of doing exploratory testing is, guys, when you don't have any requirement with you, you are testing the application, you are exploring it, you don't have any requirement, you are just trying to explore the application and trying to understand the requirement.
Speaker A
fourth because disadvantage of doing extra lately extinct now the question arises how to overcome the drawbacks of bring exploratory testing how do or commit so whenever you are joining any company and people are telling you to start doing testing without giving you
Speaker A
In that case, you might misunderstand the feature as a bug. So, the first drawback of exploratory testing is you might misunderstand any feature as a bug. Since you don't have the requirement, you don't know what are the features it should have, but when you see the application, you are trying to understand the application.
Speaker A
application always try to understand the requirements from the person who is having good product knowledge you can ask you like food doubt from product manager you can ask your doubts from the senior person who is in the testing
Speaker A
There is a feature in the application, but you think that it is not at all required. At that time, you feel that it is a bug. So, the first drawback of exploratory testing is you might misunderstand a feature as a bug.
Speaker A
company he will be having the good domain knowledge so he will be able to make you understand how application works so how to overcome the tropics of exploratory testing is to understand the requirement first with whom with the
Speaker A
Example, suppose there is a login page which is used in some corporate industry where they are asking you to put your username, your password, and they are also asking you to put your employee ID and then login button. This is how the requirement says.
Speaker A
it and you can also test your application with the competitive products which are already launched in the market so this is how you overcome the drawbacks of doing exploratory testing so you go for exploratory testing when there are no requirement or
Speaker A
But when you are doing exploratory testing, you feel that only username, password, and login button was sufficient. There is no use of putting employee ID option. So, since you don't have the requirements, now you are doing exploratory testing, you will feel that this employee ID component is a bug, which is actually a feature.
Speaker A
this video was useful to you guys if you just give a thumbs up to this video and subscribe to my channel thank you so much
Topics:exploratory testingsoftware testingtest scenarioslegacy softwaremissing requirementscomponent testingsystem testingtest engineersoftware qualitytesting methodology









![Психосинтез Роберто Ассаджиоли [Психотерапия #144] — Transcript](https://i.ytimg.com/vi/owVEFniaHT0/maxresdefault.jpg)

