Hot answers tagged

22

Good and Interesting question. Here are some to make the tester's job easier: Developers should perform basic testing before giving the product to the tester. Include QA from the beginning of the project, not when the product is ready to test. Work as a Team, not as two different departments [Developer & QA] As the developer, never ask the QA to ...


13

Treat them as equals. I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.


11

I've worked in both roles for a while and my recommendation is: Pair (before coding when possible) on test plans See QA as an asset that is protecting you and customers from the mistakes we all make Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding Don't assume that they can ...


11

Just a few quick ones off the top of my head: Run the code they've completed at least once on their machine before marking it as 'Done'. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written Encourage QA to participate in sprint planning/grooming, design ...


8

Testing is not a standalone activity because: resolving bugs means talking with product and development to make sure that the bugs are well understood and that the path to correct them makes sense for all. understanding business requirements and what an application is trying to achieve means working with business users and product owners understanding ...


6

This is a simple point, but very effective: Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect. It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.


6

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


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


6

To start off, have a positive attitude towards tester's activities & identified issues Provide unit + dev-smoke tested builds to QA Share release notes with info like included fixes, features and known bugs etc Provide support in technical & back-end understanding of system Provide support in analyzing hard-to-reproduce issues Be appreciative ...


5

All the answers so far are good. A few other comments: Remember that the testers aren't there to make your life miserable. They're there to provide business stakeholders with information about how well the software fits what its intended users need from it. Don't just throw code over the wall and figure the testers will catch any bugs. They might, but ...


4

The software testing life cycle includes more steps than just the practical "doing". In short it starts with reviewing the design / requirements, going over to planing and designing your tests, execute the tests (often called testing) and finishes with reports. So I think you connect the word "testing" only with the "doing" while having an application ...


3

There are some major red flags here. You're only going to any testing after development is completely done? If this is development of a single feature, that's fine. If this is for an entire sprint worth of data, that's dangerous. You do not want to wait two weeks before sending a bug report to a developer. When I was developing I could barely remember what ...


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


3

Carpenters have this saying: "Measure twice, cut once." Before you cut a piece of wood, you measure it twice, because the cost of remeasuring is much less than the cost of recutting. The "plan before you act" principle applies to software, too. We make lots of decisions when we create software. We aren't even aware of some of them. The right amount of ...


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


2

I believe that a software tester should be involved at all stages of a website or software development. As a software tester, you are just as important as the developer and often have a more general knowledge of the item that is being tested than a developer may have. (Developers may just specialize a small component of a piece of software) If involved from ...


2

How are you the only QA guy going to test the work of 10 developers? You will be flooded with work, teach the developers to test! :) This is important, because you will be taking shortcuts under pressure. This could lead to lower quality then before there was a QA guy, because the developers think they have to test less since they now have a dedicated ...


2

What you have description is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example the y2k bug and I have been on such projects. However most development today is done with a more modern, typically 'Agile' process. I would suggest that you consider the following Agile process: devs and ...


2

I read my Software testers' test cases and give them feedback. I ensure every workflow-path you only would know from reading the code is covered or at least brought to their attention. I also keep them up to date with features I myself that may not be really covered in meeting or UX specs (normally small fillers).


2

Respect the time requirement for QA All to often, test time becomes the project buffer time. If the release candidate is a day late, do you shift the release date or do you tell the QA folk to test faster or to test less? Keep them it the loop if it looks as if there might be a delay. Give the testers recognition (like bonuses, promotions, ...) if they ...


2

All good points here, but there's one I run into somewhat regularly as QA, that is to remember that while I may know the product fairly well, I do not know the code at all. It's generally frustrating being asked what part of the code has the problem. If I find a problem with a dog fetching a stick, I don't know if it's the dog class or the stick class. For ...


1

IMHO most obvious hole in your process is missing bug tracker. Get one free, like TRAC. It includes wiki for technical documentation. Every feature should start as a bug in bug tracker. Get developers write whatever thoughts they wave to bug and/or wiki pages linked, so few months later you will be able to recall what assumptions developers made when ...


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

We have daily builds, Below are some of lessons that worked for us (Knowledge Part) - Documented notes (critical discussions, one liners - running notes are usually captured and shared after design discussions, MOM etc..). This is a quick reference used during testing, preparing test scenarios. We usually shared test queries, sql queries written during ...


1

I've introduced the following structure which includes a section that reflects the Agile Testing Quadrants for Unit, Integrated, Performance and Exploratory testing. Each link goes a detail page for that area which outlines what is being done for our company in that area.


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

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


1

The definition of ‘functional requirement’ is that it essentially specifies something the system should do. The definition for a non-functional requirement is that it essentially specifies how the system should behave and that it is a constraint upon the systems behaviour. One could also think of non-functional requirements as quality attributes for of a ...



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