Hot answers tagged

6

The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation. The long version: This question and its answers is a good starting ...


4

By the success of the company. Buy-in for QA will need to come from the top rather then the justification being looked for in data. You will, over time, be able to point to things like some major bugs prevented from reaching customers performance issues anticipated and planned for unusual bugs discovered for certain conditions more new customers more ...


3

No, this is not a common practice. QAs are and should be kept in light and every communication involved related to the requirements. The sole purpose of the documentation created during the requirement gathering phase is to keep it updated and validate the application according to that document, so this document serves as the single point of information for ...


2

Actually, we're doing this exact thing you mention. Testing in the same three weeks as development is nefarious for testing time and quality overall, as you seem to have experienced. So, we're testing for two or three weeks after the development sprint has finished. By delaying testing for a few weeks, you'll be working on a fully delivered sprint ...


2

I'd consider this more of a process question than a tool-specific question: a requirement has a critical bug in the implementation. My opinion is that the critical nature of the bug should mean that the requirement is consider not implemented until the bug has been fixed. At that point it returns to in testing while the correction is tested and the ...


1

I've never used metrics in this way, however, you can build a case with some care and a lot of data mining. First find out the average time cost per bug found by customers. You're going to need to find out how much time is spent in diagnosis, fixing, devising workarounds, and pushing patches, and average over the total number of bugs (this will never be ...


1

Metrics are misleading. You can catch 10 000 useless bugs, but if the one that kills a few patients in the hospital is not caught, you're dead. Well, dead in terms of career, not as much as the hospital's patients. But metrics can be useful to convince people who believe only in them, unfortunately. If, and only if, the rationale behind the metrics is to ...


1

You need to set below code in robot.txt ( you need to stop googlebot looking at your website ) User-Agent: googlebot Disallow: / Its not happen in one day, Its take some time when google next time crawling your website then it not access your website.


1

Personally I believe in the automate everything pattern, if you cannot automate it your doing it wrong. Using Excel sheets sounds like another piece in the process that could be prone to human error. The installshield documentation talks about that you can automate, nearly everything: InstallShield enables you to automate build processes through the ...


1

The second and third bullet points are arguably not bugs at all. They're new feature requests. Invent a list where anyone -- testers, programmers, marketing, subject matter experts -- can suggest a new feature. Sticky notes on a wall will do. That new request gets prioritized like any other request. (By contrast, a policy might be that regression bugs must ...


1

We can't tell you how to fix your process because it depends on your own circumstances. That said, this does not sound like a hard problem solve. It sounds as if your Jira configuration is not expressive enough for your workflow. If it were me, I would do start by getting agreement on which workflow problems need fixing. It sounds as if you already have ...



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