Hot answers tagged

32

There doesn't seem to be a lot of research data on this; this is what I found: Waiting for builds: This article about "Why software testers can't test" quotes a survey from IBM (The Future of Testing: Where Do Testers Spend Their Time? 2014): 59% of those polled, the largest percentage for all the available choices stated that the one activity they ...


25

Disclaimer: this answer is purely based on personal, anecdotal experience. In my 10 years as a Software Developer, I have known 4 different situations: no tester (besides myself), tester in another team, large delay (weeks), tester in another team, short delay (hours), tester in same team, short delay (hours/days). Note that Unit-Tests were always on my ...


12

TL;DR: Devs write own unit tests. If you want different eyeballs to look at the unit tests code, code review is the answer. EDIT: OP clarified question: it is about e2e tests. For e2e tests, using separate team of developers is possible but adds different kinds of challenges. Added to the bottom. Related question: How does a tester's perspective towards ...


10

There has to be some sort of pain point to make Management and front-line employees aware of the need for testing. How your company does that depends on how mission or life-critical the software truly is. The typical Developer/Tester ratio in an unregulated development shop is anywhere from 4:1 to 8:1. NASA uses a ratio of 1:8. That's right, each Developer ...


9

Disclaimer: not hard data, but something from a personal experience. We currently have a good representation of why developers should write unit-tests for the changes they made (at least, critical and most error-prone parts if under time-pressure, as we are). One of our products is an AngularJS application, the front-end of which is being developed by ...


9

You should always try to do your job and perform good whenever it's possible. Unfortunately if you are finding issues (which is your job) that will always mean that developer/designer (or someone else) didn't complete task in a proper manner. You shouldn't feel bad or guilty because you are doing what is asked from you. If the product is not good and you ...


7

Let your manager handle this, it is their job. I would respond: Sorry, I will look into that. My action: Talk to my manager, get his/her take on things. Review if the bugs you are logging are valid. That's really it. I do not recommend further talking to the employee involved because they need education and are not going to suddenly learn from a 1:1 ...


4

From experience, I have found that developers are very effective at testing what the code does, but not as good at testing what the code is supposed to do. The first example that popped into my mind is a GUI I designed. I tested the daylights out of it, and though it was flawless. Brought it in front of my customer, and 10 seconds in he had crashed the ...


4

Companies like it when new potential employees have similar experience because in theory it gives them some familiarity with the industry, terminology, rules and regulations, common technologies and maybe even with theirs or similar products (as a basis for comparison). In theory it also makes it easier (or more familiar) for recruiters and managers to ...


4

You should start with a conversation with the developer to ask why he thinks there are too many bugs and see if there is a different approach possible. For example, if you are reporting a similar bug/bugs with each new build - perhaps consider helping the developer create a unit test or check before he produces the build. If he says that you are ...


3

Everyone has very well explained, how you should handle this scenario. And trust me; at some point almost every tester come across similar situation. So, my suggestion is: 1. Don't get upset about it. And don't get discouraged. Keep yourself motivated. 2. Ideally, project team (which includes both developers and testers) is responsible for delivering ...


2

Testing in every domain is different because any testing requires domain-specific knowledge. During my career, i worked in such different domains like: mortgage loan servicing (non-performing = overdue loans, which require lost of complicated handling, like knowledge that in West Virginia there are differences in foreclosure procedures per county). We had ...


2

As Chris has said, domain experience means that - in theory - a candidate won't need the lengthy domain learning time that's needed. For instance, I'm currently working in payroll and HR management. To be able to effectively test my employer's software, I needed to learn how payroll and HR management works, and the US regulations that the company needs to ...


2

I'd like to add something I haven't seen in many of the other answers - I think that the passion for QA is extremely important in a person looking for a QA position. It seems like a no brainer, but the reality is that there are many people out there who see QA positions as a stepping stone to development. I think that someone who truly wants to be a dev in ...


2

I will add to the above answers: Pays attention to details.


2

The Ministry of Testing has a growing following: https://www.ministryoftesting.com/ Also in every major tech dev city such as Boston, NY, London, San Fran, check https://www.meetup.com/


2

A few years ago I've done a quite extensive literature study into testing, especially regarding benefits of testing. I have not encountered a scientific study in precisely what you are asking (developer versus tester), but I did encounter a quite interesting scientific study: Mäntylä, M. V. & Itkonen, J., ”More testers - The effect of crowd size and time ...


2

When working on something complex, there is always the risk of bias, blind spots, tunnel vision, and stress induced malfunction of the thinking parts of the brain. ( one good book, though from outside the IT world, is Processing Under Pressure, by Matthew J Sharps) That is why it's always good to have another human around, not a yes-person or naysayer, to ...


2

Testing culture can only be changed with support of upper management. If management doesn't support you, then you won't be able to change the culture. So you have to make a case to management that testing should be prioritized. Try to build the testing as a part of the SDLC. Otherwise, people will always cite deadlines and release cycles as the reason ...


1

Who Test Often, Release Often. Proposed Solution:One needs to build a strong case for testing to project team/ management in terms of visibility. I think the key lies in release frequency.This is something which is most tangible to the team(AND to the management) and can be used to make a solid case on investing & implementing solid quality checks in ...


1

You can calculate the cost of defect leaked to production based on following factors: Effort: Typical effort when a defect is found in prod is split across - analysis, reporting, reproduction of issue, fixing, deploying, testing(scripting, execution ,monitoring) reporting. Resource cost: Onshore/Offshore (billing rate) Loss to business: application ...


1

Outside-the-box answer: Wrong question. Feces occurs. We don't celebrate it, but it happens. Your development team's response needs to be driven not by some abstract sense of responsibility, but by its concrete policy about fugitive bugs. Your team should have such a policy. It could be as simple as "ask the boss to make a decision" or a pre-...


1

I find posting the blame is the wrong way to think about it but to answer your question it could be a single person or everyone. I.e could of been a business spec that was not communicated to the dev team or it could be the tester that did not test a specific COS appropriately or everyone for that matter. Whats most important to me as a QA lead is what can ...


1

Disclaimer: I'm very bias (Director of Community at Applause) but this question is just too spot on to pass on answering. In December we relaunched uTest.com to become the, "LinkedIn of Testing". In doing so we've created a professional community of 200k+ software testers where members can learn, network, share and/or find paid projects, which sounds like ...


1

There are many great characteristics required for a QA/tester. To me, communication is really important. Also, a team spirit is equally if not more important. Trying to prove oneself being smart or the other dumb will not help. We are all in it together. Defects or issues should be discussed with as clear as possible steps to reproduce the defects. Come ...


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