4

Pick some samples for training but don't add more process for all I recommend not documenting the details of all exploratory testing sessions for future re-use because trying to script, what is essentially a voyage of exploration, is not in the nature of exploratory testing. The main exception to that is to get examples for training and education. Instead I ...


4

Concern: One big concern received from QA group is if they start documenting these sessions output in formal test cases , they will loose the advantage of speed because documenting each test case step by step takes time. Sometime more time than the testing session itself. Support via tool: We got similar situation in our case. Hence we searched for a tool ...


3

Quite interesting topic and although this question has been raised two years ago it is still a current topic! Hence I would like to share our experience / thoughts. Preparation from our side as business department: We used a web application Before starting we explained the product We encouraged the applicant to speak all his steps "loudly" so that we ...


3

Either way, it's gonna slow down testers. However, I think you can work in pairs, one tester doing exploratory testing and the other helping out and documenting. They can swap roles once in a while. I guess this would not slow them down as much because one tester would be mainly focused on exploratory testing just like now. There's also a question of how ...


3

You can use tools like owasp zap to find all the API calls. It spiders through most of the endpoints in search of security vulnerabilities. https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Read about different scans: https://github.com/zaproxy/zaproxy/wiki/ZAP-Full-Scan https://github.com/zaproxy/zaproxy/wiki/ZAP-API-Scan https://zaproxy....


3

If you have no endpoint documentation then the things are really bad. I would use the following aproach: examine known clients which use the api extract all possible invokations which the client can do guess what is the client missing but might be supported by server like if you have order/create then there is a chance the server has order/update as well ...


3

You've brought a bit of the human factor (randomness) to automated tests. What if you try to bring some flavor of automation to your exploratory tests? In general, I think the problem stems from thinking that test automation is only about automating tests, or to be more precise, automating whole regression tests. No, think rather of using automated tools ...


2

In our project we used both methods. Automation testing: We used the automation for repeating test cases. Especially for Smoke Tests and for normal Regression test suites. E.g. a user story has been created, then we adapted the user story in our test automation procedure. This means that our test automation suite has been enlarged dramatically but that was ...


2

I think this is a much better idea than asking questions such as "Where do you see yourself in 5 years?" etc. :) Let me share a few points I find important: Regarding the application under test. I'd personally choose one I know and one where at least some bugs could be found. That's because I'd like to see the candidate reporting issues or at least talking ...


2

This is a very interesting topic and I have conducted a few interviews similar to this and here is my feedback based on the interviews: You can evaluate candidate's ability to find out bugs within the given timeline. You can evaluate the candidate's ability to focuses on functional or non-functional issues first. You can judge the testing approach of the ...


2

I would suggest picking up either a free browser plug-in or some other free tool that can run in the background while your testers run their exploratory sessions. I would treat the output of the tool this way: If no problems are found discard the log - The nature of exploratory testing requires intuition, guesswork, and a fair amount of serendipity. If a ...


1

Although this topic is 8 years old nevertheless there are some updates in the exporatory testing methodologies and tools. Hence I will provide an update: In our project we tried it with Tricentis. It was very helpful for the testing procedure - especially in the way of exploratory testing. Somehow with this add-on tool you plan your session testing before ...


1

My approach would be to examine the network traffic. If the application operates over HTTP/HTTPS, the easiest way to do this is to use a tool called mitmproxy as a proxy that sits between the client and the server, and examines and logs all requests that pass between them. Using this tool, you can see all the endpoints the client hits during normal ...


1

My experience is that even if there is some documentation, it's quite often rather vague and incomplete. So, you should never completely rely on just documentation even if it's presented to you as good documentation (you want to be a sceptical tester). Therefore, the following points are pretty much valid in any situation - if you have or don't have ...


Only top voted, non community-wiki answers of a minimum length are eligible