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


12

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 never see common agreement on any software-related titles. In some shops where I have worked "Architect" implies a thinker, not a doer. For QA Architect, it means someone who thinks about QA, researches and suggests improved methods and metrics. Sometimes it's someone who trains others. In other shops, "Architect" just means "very Senior". It's the top-...


9

Eduard, welcome to SQA. I will assume you are that developer. I think there are a lot of ways a developer can help a QA team. The most obvious way to help would be to write automated tests or to write tools that make testing easier, e.g. creating test data or automating a deployment. You may have skills outside of coding that would also benefit your ...


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


8

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


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

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


8

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

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

We have always called this bug bashes bug bashes Some guidelines we have used include: Set a date and put this on the team's schedule Provide guidance on the purpose/scope of the bash - specific area (at risk feature, globalization, security, etc) or anything goes Provide a template for filing bugs (including guidance for pri/sev, etc) Provide incentives (...


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


6

A developer can be also useful to QA team in defect isolation. Having skills to read the code, understand the architecture of the system and debug a running program, you will be able to isolate the root cause of the defect you or the rest of your QA team has found. It is often faster to reproduce and isolate the issue, when you are performing the tests and ...


5

@user246 has some good options - the first that came to mind for me as well was the creation of automation and support tools. I think that another area where many test teams that I've been on could benefit is from having a deeper understanding of the system architecture and technologies. A developer has a different perspective on the system - they have more ...


5

Agreed there are overlaps between QA and DevOps. Whether a DevOps person belongs in a QA team depends on the specifics of your organization. I think the more important issue is whether DevOps addresses your QA needs. About an hour ago, I talked with a developer whose team includes a DevOps person. The dev team treats DevOps as their own problem, not a ...


4

That sounds like a great practice. You described at least two kinds of activities: Ten people clicking around in parallel on the same server. I would call this an informal load test. It is informal in the sense that the individuals are not coordinating their activities and may not be following a predetermined (or repeatable) process. While the process ...


4

I could give you my best guess, but really you ought to ask them. Titles and responsibilities vary from one company to the next.


4

I'd second Phil's plug for the Software Testing Club website, and encourage you to seek out the mentoring group on there (although it does appear to be pretty quiet at the moment - perhaps it might be prodded back to life? I recommend it because that's how I ended up receiving some absolutely invaluable mentoring from Michael Bolton. (Who is, incidentally, ...


4

Welcome to SQA, Rumi P. It sounds like you have a bootstrap problem rather than a chicken-and-egg problem. There is nothing intrinsically wrong with using software under test to create your test data, especially if it lets you write and maintain tests more easily. Of course if you don't implicitly trust your Linq classes, you should test them. One way ...


4

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


4

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

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

Have you considered less competitive approaches to achieve your goals? Your teams may learn practical skills using deliberate techniques. I'm not sure how that increases morale (or team spirit), though. Note that for a deliberate technique to be effective, it must be: demanding targeted at improving specific areas of performance (so you must exactly know ...


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