New answers tagged

0

This is a very common scenario in a software testing company where sometimes a user falls into a situation having less experience in a field of work. So need not to worry. Below are some tips for the same: Firstly Understand the functionality of a product which is the most important task. . Secondly create the test cases (create one liner) if you have less ...


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 ...


2

I am not aware of a specific type/name for this documentation, but you can use draw.io to create a flow/path diagram as you mentioned. You can also explore the different types of diagrams they have and see if any of them is a good fit.


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 ...


3

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

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 ...


0

If you need both: text file and terminal output: Linux: adb logcat | tee $(date +"logcat_%Y_%m_%d_%H_%M_%S.txt") Windows: adb logcat 1>logcat.txt 2>&1 | type logcat.txt Powershell: powershell "adb logcat | tee log.txt"


2

We got nearly the same situation in our project. We got a couple of systems which we had to test, but just two testers for the different systems which are nearly independent each other. So I will try to summarize the lessons which we learned at our project: Exploratory testing We introduced exploratory testing and also used a tool which captured all the ...


6

Welcome to the site! Your situatiom might be a difficult one for a couple of reasons: you're new to the testing and you don't know much about the process, about the technical stuff, and about yourself in such a situation you're the only one on the team who is supposed to test; I find this the biggest obstacle because you basically have nobody to ask for ...


3

You have two advantages here, 1) Being new to the project You will test the product as if you are a customer using the product for the first time. If being a user with zero knowledge about the product forces you to ask so many questions and dig through documentation to do even the simplest tasks. Then there is a serious problem with the UX design. you ...


3

Hopefully, although alone, you can talk to the developers, the business owner, scrummaster, etc. At this stage you should primarily be in question mode Find out what the system is supposed to do, in detail Find out what the user is trying to achieve Ask about different workflows Determine positive and negative test cases to try Ask about devices and ...


0

This is a common case in a software testing company. In this scenario there can be 2 different point of views. You can review the important step again and check if it is a mandatory step else, can refactor the test case as the desired result is already achieved. You should fail the test case as an important step did not execute correctly even though ...


1

TBH this doesn't come from the culture characteristics, if so: Indians are some of the most unaccepting of many cultures that i have worked with. From my past experiences with Clients (Having managed many QA offshore teams) The problem here is the way we work in Agile(Mostly) It is highly results-oriented where all the teams(not just QA) are focused on ...


0

I work as an offshore QA in India and to some extent I agree to the problems shared in this questions. But this is not a cultural difference issue, instead it is organizational, leadership and engineers training challenge Many companies have mindset that keeping client happy by agreeing to their all proposals would keep them in business, rather it would ...


0

Ideally in a software testing company there is no standard guidelines. Actually if the issues are getting reopened due to a bug then all of them should reopened. Because if we do not reopen then there would be chances that this would penetrate into the release and at the end will impact the users. Moreover we also need to make a track of the same that how ...


2

I expect that your remote testers see their job the way it is defined for nearly all the organizations that use them: does the software work? and can they sign off on that and get paid? If you create an arrangement where their pay and employment is dependent on giving much greater feedback it will happen, though you'll need to invest time and training ...


1

This doesn't have anything to do with cultural differences. It's the issue with the organization's work culture. To fix this , you have to ask yourself some hard questions. How independent is the test team What are the KPI used to validate QA efficiency Is bug count and defect detection ratio could be considered as KPIs Does testers get appreciated and ...


2

Agile testing relies on a number of key concepts. Two of them are: The Test pyramid This provides a guide for having a large number of good unit tests, a medium number of integration tests and a small number of the slow and brittle (by their nature) UI tests. Agile Testing Quadrants Similar to the pyramid, another representation of the various different ...


4

I am not sure true Agile testing techniques exist. Some testing techniques are used and work well within the Agile context, others don't. Common agile quality practises, part of the technical excelence princible: Specification by Example Test Driven Development Whole team approach Unit testing Continuous delivery Some techniques that might help: A/B ...


4

Measuring test effectiveness is a great question. So many in our industry focus on "Tests, number of tests, how long they run, how often they fail", all without looking at the key question "How effective is my testing?" In order to evaluate tests, start with the business value. Ask questions such as: What is the software release cycle? Once every 6 ...


0

These days software testing company follow the approach of creating Requirement Traceability Matrix RTM lists out the test cases covering the aspects of that specific requirement. Let say the requirement of Sign up feature The matrix will include details like Requirement ID, Requirement description, Testcase ID and status. This would help the team to ...


Top 50 recent answers are included