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 ...
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 ...
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 ...
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 ...
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 ...
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
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 ...
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 ...
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.
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
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 ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
