Hot answers tagged

25

If request sounds reasonable (which includes taking into account my other priorities), I would spend some more time researching. If not reasonable, I will respond "sorry this is the best I can", and if my polite refusal to spend more time researching is not enough for the developer, I will ask my manager to make the decision. I would also mention to ...


14

It depends. As Joe Strazzere explained, it is a matter of discussion between devs and testers. The question is what factors to consider in such a discussion. I think Danny R. Faught explained that pretty well in How to Make your Bugs Lonely: Tips on Bug Isolation. There is no clear dividing line between the bug isolation and reporting that the tester ...


13

I think this is a delicate topic in the software industry, one that I have experienced in the past. Essentially what I did was have a one-on-one conversation with the person and tried to bring it up conversationally with the development lead. This led to the conversation of job place requirements and what I was responsible for and what the dev. leads ...


10

You're going to get all kinds of recommendations on QA team sizes, from zero to twice the number of developers, or higher. The right number for you depends on what you need to test, what kind of testing your developers do, and how solid your software needs to be. My experience is that small teams -- no more than a handful of people -- are more effective ...


9

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years: This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it'...


9

Emphasis added: There have been situations where the Devs and the QAs ask questions about this same process. And I always jump in to clarify when this happens. Since I have been there, done that. However, in most of these instances, the Dev lead says something to this effect after my response: "We will discuss this with the QA engineer and the PM" OR "I ...


9

We have several "testers" who are involved in manual testing and test automation, but all of that part-time. Some of them are not really interested in testing and test automation as a field and lose interest in test automation and improving testing skills pretty quickly. How should we deal with them? That depends on why you have uninterested ...


9

Many companies I've worked for shared a policy... ...and that policy is: Testers are free to consult with developers while attempting to characterize, isolate or reproduce anomalous behavior. Once a tester can document the steps necessary to faithfully recreate the behavior, the developer should be able to take it from there. Developers are free to consult ...


8

It depends. Right now you might not see much need for a single repository design. Later, you may find your opinion changes. You might want to use a single repository if you need to keep your different projects in sync. It's more difficult to keep separate repositories in sync than a single repository. your team members will need to switch between ...


8

Great Question As per my experience, it's very difficult to get a right employee who has very good judgment, sharp focus, attention & great observation skills. Earlier it was very difficult to filter right candidate but our team come with some solution for that We made some minor changes in our interview process as follows:- Now before conducting F2F ...


7

As a manual/exploratory tester who works very closely with developers I find that the best way to improve my effectiveness is to learn as much as possible about programming in general, plus the languages/technologies (e.g. Drupal, WordPress) being used. Being able to code to the same standard as a developer is not a requirement to be an effective tester, but ...


7

But, what are the general ways to avoid having or deal with such conflicts keeping the relationship between the teams healthy and productive? Both QA management and Development management must come to an agreement regarding the ground rules of bug reports. In some shops, more detail is required before the bug report is sufficient to hand off to ...


5

Testing on the Toilet (from Google) Repeating the testing on the toilet prints on your toilets might be a way to spread testing knowledge and get developers to do more and better testing. I have downloaded all the Google ToT articles to a single folder, you can find them here. This so you don't have to go through the whole blog. Print one for each toilet ...


5

Challenge developers Another company I was working for held competitions among developers / testers. People love challenges; when challenged with coming up with new testing ideas and writing tests as quickly as possible, they became very motivated. Results: Within a few hours, lots of new ideas turned up as well as written test cases. You got to know ...


4

Make it easy Build frameworks which Mock and Stub out portions of the system Set up examples Use frameworks which allow reuse for integration testing (BDD frameworks work well here) Make it beneficial for the Developer Use new technology Treat it as an R&D project Allow Developers to use the test classes as areas to expand their skills Make it fun ...


4

Running all tests at once is something that a Continuous Integration server should do for you, not something you do manual as it lets you wait for a long time. Let a server do the work and reporting. Multiple repo's have the following advantages: Easier to schedule parallel-runs in a CI. Will be faster. (technically also possible with a single repo, but ...


4

Adding to the awesome and very detailed existing answers. There is a well-known success story of using a single large repository - Facebook and Google. As of 2014, Facebook's main repository was 54 GB in size. As of 2016, Google's main repository had 35 millions commits. One of the most important advantages of having a single repo is atomic commits across ...


4

This question is by definition very broad and depends on so many human factors that are not necessarily related with quality of your work. To disregard all human aspects of this question such as (your charisma, characters of people who are making those judgment, your look and style and even more trivial such as, your background and opinions you have). From ...


4

You might want to consider breaking your QA team into smaller groups so they can focus on specific products. Keeping QA engineers 'generic' doesn't really work for agile teams, especially when the application engineers they work with are allowed to specialize.


4

TL;DR: The smaller the better, I would aim for 3-6 people. The overhead of communication clearly grows when your team size becomes bigger. I guess the tipping point is around 10-12 people, now to many influence each other and your in for some real communication pains. I like to keep a a team to a maximum of 5-6 people doing the actual work and only handful ...


3

As an actual software developer, who is going to keep an eye on that tester's skill progress - what practical skills, typically found in software developers, are most recommended to transfer to QA people to let them later find some work in that quality? What I think the majority of manual testers need to be taught first would be the basics behind ...


3

A qa architect is a person who design the building block of qa process. Basically this is more relevent to test automation where many things comes in picture. So his role is to place and consult the optimized way to place the block so that whole system is stable economic scalable, fast and optimized. Test automation uses a lot of resources like machines. ...


3

I'm a workmanlike Tester who's had the good fortune to work with some excellent people over the years. When I hire people, there are some key characteristics I look for: Eye for detail This is the obvious one. Testers need to be able to see the little details that others miss. You know those Facebook questions? The ones that go: Spot the mitsake : 1 ...


3

I think the primary benefit is that they can Join the development conversation and help improve the product with the developers and talk about technical terms and understand them when heard. Although I often prefer black-box testing (not knowing the internals), I find that understanding the tech setup is a key skill. When something breaks a tester with a ...


3

Get a Tester invited to the planning meetings along with the Developer and Product owner. As the PO describes the feature to be built and they way it should work, the Developer is already building the feature in his head. He's thinking about how to make it work. The Tester is thinking about how it might not work. If the Tester shares his scenarios in the ...


3

You and your team cannot .... I repeat, simply cannot afford to have testers low on motivation. You can probably have lesser talented testers, high in morale and eagerness... but you just can't have people who are not motivated enough! Period! Poorly motivated period think negatively and their negativity can rub off on other resources. This will impact ...


3

Although this question has been asked two years ago, it is still a current topic. Regarding payment; money does not really affect the motivation of people (see: Harvard Review ) So I wouldn't raise salary just to motivate people.. But based from our projects experience we faced the same situation as you. We got unmotivated testers. Hence we reflected the ...


3

Without looking at the quality of your work, some of the techniques I've used successfully include: Be tactful. If I can, instead of simply creating a bug, I'll ask the developer what should be happening, and show them what I'm seeing. I'll often do this from the perspective of "what am I doing wrong?" or "what am I missing?". Ask questions. Particularly ...


3

In my own experience, healthy personal relationship between developer and tester helps to sort out this problem. If a tester and a developer are friendly enough under company environment, then the negotiation will never be felt as negotiation. Rather both will consider as, this should be done with team effort and success or failure will be shared among both ...


3

To me, who is responsible depends on what kind of team you have. If you have a traditional team, there will have to be an agreement detailing what the testers will do and what the developers will do. If you work in a Scrum team, the bugs are the responsibilitie of the team. This means both developers and testers. Depending on how your team prefers to work,...


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