What is ET (exploratory testing)? What are the main concepts and proper uses of this practice? Basically it is an entire process dedicated to determining whether software under test is acting the way it is designed to and what would happen if something does not go as planned. ET shows how software will be handling both complex tasks and easy ones.
ET quality is directly related to the skills of testers responsible for the process. Testers should know all possible details about the product under test as well as different testing methods (the more the better in relation to ET quality). The process is of colossal value to many project and has a great impact on overall quality on the product you are developing. Technically ET is a fine solution resolving many different issues. Though it is not applicable everywhere and may, sometimes, do more harm than good.
When great things do harm!
There is already a lot of material written about how to properly use ET in an efficient manner or what are the actual benefits of it. Here is a nice example you may consider reading through with lots of great thoughts. Though don’t even consider ET if any of the listed below scenarios is your case. However, feel free to use it after the described issues are resolved.
- Your testers are too impressed with their own abilities. Words like “why even bother automating tests and using scripts if we are all a skilled team of testers” will never fly out a real professional’s mouth. Though they are still heard too often, which is saddening.
- Often small companies are experiencing lack of skilled testers hence many people that should be even into QA are starting clicking on this or that button and are calling those tests satisfying. Even developers should not be testing their own software. Such an approach is nothing but rubbish and is not worth investing even a minute in. Tests should be conducted by testers.
- A lot of minor defects is being missed or neglected during ET. Surely the general business goal of the application is worth attention and requires to be covered with tests accordingly but there is always a little bit more to ET. That’s why it’s called exploratory in the very first place. If your team is moving in such a direction ET value is minimized.
- Also, reworking is a terrible practice. Every tester should clearly know the actual difference between testing sessions. If some place should be validated during a different session like Unit testing, etc. testers should not waste time and effort there.
- If you already have a dedicated set of testers that are constantly doing ET. Routine kills exploration. Mostly testers will be following some scripts they have created for themselves after some time they are literally forced to do the same activity over and over. That is also an ‘exploration’ killer.
But don’t get all this in a wrong way. Despite all the dangers and pitfalls Exploratory Testing is still a valuable addition to your testing hence you should not reject its very idea. You should rather move in a direction when there is nothing in a way between you and ET.
Check out our related articles:
Check out our related articles: