Tag Info

Hot answers tagged

8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


7

It depends, and there are no industry standards. Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using ...


5

There's a few extra factors here that can impact the way you handle this problem: Do you get results for each test as it completes or do you have to wait until all tests complete? Do you have multiple machines on which to run the tests (and is it possible to do this) or are you tied to a single system running your tests in sequence? Can you break your ...


3

When you say that bug triage is impossible (or improbable), you need to determine the opportunity costs associated with that: In the case where no triage is performed, there is the probability that a single or multiple developers will attempt to fix the same bug. At minimum, there is wasted development time that could be focused on other areas. Worse, the ...


3

I think Agile testers should assist their Product Owner with writing Acceptance Criteria in the user stories. If you write scenario's in Gherkin you can create manual test cases that match your four criteria of a test. Scenario: Some action (1. Name) Give I am logged in (2. Pre-condition) And I setup something else When I do some action (3. ...


3

Depends on the quality requirements of the project and the maturity of its user stories. If the test has to be done once by the same person who has written the test cases, then documenting the test case steps would not be essential or indespensable. On the other hand, a project requiring different phases of regression testing over a long period of time with ...


2

I think you might have got yourself a bit confused here. You're not really testing the software's suitability, you're evaluating it - that is, you're looking at how well the process and workflow the software imposes meshes with the development framework. It's not so much a pass/fail thing as whether this tool is a good choice with this methodology. For ...


2

Have you considered using post actions to either pull the UATs from the tasks or push the UATs to the task? This is relatively easy to accomplish if you have some experience of configuring your own workflows. It allows you to generate the tasks required based on the Acceptance Criteria (i.e. each would create a new task) and copy the details of that into ...


2

Having done 23 years of performance tests including trouble shooting, correction, and rerun I can agree with testerab on long reports full of nice graphs that remained unread (and even if scanned certainly not understood). Of course if you are a paid for third party, or even expendable employee, that report might be the only way you can justify your costs ...


2

I have served as QA lead for multiple Scrum teams. Any release might have multiple teams releasing at the same time. I was responsible for the overall QA sign-off and test summary. What we provided as a summary document: What user stories were included from each group Any documented defects that were not fixed and therefore constituted a release risk ...


2

Testing is not an individual function on a scrum team. The concept that developers develop and testers test (I coded it I am done, you test it) is a waterfall practice. The team is responsible for a feature getting into a "done" state. Testers with SQA experience or as their professional discipline bring value in their understanding of how to test and how ...


2

Bug triage is very important, especially when time is limited. Bugs have different levels of severity. Examples include very high: someone may die as a result; high: the company may lose business; medium: the customer will be upset; low: there is a minor spelling mistake. The actual outcomes and severities depend upon the organisation. Bug triage is about ...


1

As a former tester and now a QA Manager I have worked for over 15 years testing and managing the testing of very complex Geology and Geophysics interpretation software. My test team are all geoscientists first and testers second since you have to have an advanced degree to understand what the software is doing. I worked on a team using RUP, and we were ISO ...


1

This all feels like a great waste of time, because there is a very big chance no-one will read them ever. I hear you on this one. I have wasted far too many hours of my life producing documents that nobody ever read - enough so that at one point, I devised Anna's Chocolate Bar Test. (Somewhere in the last half of the document, you state that you have ...


1

I do not know what documentation you currently has or what tools you use. So I do not know is all of the following possible for you. But maybe you found some helpful ideas. Defect Overview How many defects was created. How many defects was fixed/closed. How many defects of the ceated/fixed/closed has a low, medium or high priority. (Maybe you has more ...



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