New answers tagged qa-process
0
1) Everybody makes mistakes - if this were not so, testers would not be needed at all!
2) Think over automatization of important routine test cases
0
Text files and Excel sheets are fine, as long as you have an agreement with all the members of your team on the format. Definitely not the notebook - it’s extremely inconvenient when someone needs to replace you in this task for any reason and has no access to steps you’ve done beforehand, especially in exploratory testing.
Do you use a QA management tool ...
1
Just to add on to Michael's answer,
The thought that 'I' messed up something helps you in realising what went wrong and the realisation that Glad I made the mistake so that I can make sure I won't make the same mistake again helps you grow as a professional.
A good IT professional is not just a person who can code but can debug
So, that goes for ...
1
Welcome to Humanity
Admit the failure, feel bad briefly, move on.
It's hard being human with all the biological reasons behind many of our behaviors.
You will be ok if you start practicing the following beliefs:
We are all human and we all make mistakes
We often learn more from mistakes than successes
The scientific method for improvement relies on being ...
2
For 20 years now, there's been a huge gap between QA and DEV teams. Most QA people are not programmers and many don't want to become programmers. This gap has never really closed, rather it's being masked a bit; that on Agile teams today, the developers are expected to write Unit Tests on each Sprint.
Unfortunately due dates make it impossible to spend ...
2
I think you answered your question well, there's little to add on the side of what should be done. However, it might be useful to see what not to do when facing such a situation:
hope the problem will eventually go away. It won't, people don't like to change and there even might be more reasonable causes of the problem like programmers being under too much ...
3
This sounds like developers and testers are missing requirements. This doesn't mean you need a huge formal requirements document, but in the very least each product enhancement needs acceptance criteria. Each defect report needs steps to reproduce.
Developers should not be writing acceptance criteria. Someone on the product side needs to do this. If a ...
0
As for format, again, it really comes down to what is most helpful for you and your consumers
That is true! For us we had some struggle with our customers. Because the customer was complaining that testing was not "visible" within the department. Hence we decided also to add exporatory testing but with Kanban Board (at the same time it was also our bug ...
6
Avoid trying to direct people to change as it often backfires
Instead, use some or all of the following techniques:
Ensure there is a healthy and robust discussion of testing during the initial ticket sprint planning sessions.
Initiative '3 amigos' discussions when requirements / testing is not clear
Share knowledge and best practices through giving ...
Top 50 recent answers are included
