Hot answers tagged

31

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


13

I feel like certain teams or people are in need of tough love when it comes to this. When there is a quality issue, point out that it could have been prevented by the rest of the team following some best practices. For example, if there are frequently broken builds, broken deploys or entire features that are blocked or not functional due to bugs you can ...


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


8

Part of this starts at the top. Among other things, the team's performance should be judged in terms of quality. You need to choose your quality metrics carefully so that the team's goal is to improve quality rather than just improving the metrics. For example, if you measure the team by bug count, people will stop logging bugs. Organizations go through ...


8

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


6

One way could be to get them to do end time with the end users and customers so they are aware of the impact of their work and don't just interact with a keyboard and screen. The company has to have a culture of it as well and it has to come from the top with managers leading by example A quick google for 'culture of quality' will bring up lots, e.g., http:...


5

It's common to see graphs in textbooks of the costs of fixing bugs found at various stages: The source for the graph is Software Engineering Economics by Barry Boehm, which is probably worth getting hold of. The cost of fixing a bug is a metric which probably has little value on its own. This article (Word doc) explains some of the problems: The cost-...


5

The two obvious steps that you seem to have missed out: Perform the tests. Much may be done auto-magically, but manual testing is still a key aspect at integration and system test levels. Report the results. Whilst automated tests may generate a results file, you'll need to interpret and present the results in a format that is appropriate to the audience. ...


5

Thank you for the opportunity for me to delve into the theory of testing and Quality Assurance. As you seem to be mostly interested in the role of a test specialist in software realization projects, I will keep the scope of my answer in that general area. Please keep in mind that most here is written from my opinion and experience and less based on books. ...


4

"$5,000 is the average cost of repairing a defect in production" I've never heard that. Do you have a source? Unfortunately, I don't know of any meaningful Industry Average here. I'd also be very skeptical of anything that would purport to be one. I do know that many of these sorts of popular truisms "it costs 10 times as much to fix a bug in production ...


4

This may or may not help you, but my guess is that software bug cost is likely power-law distributed. This roughly means that there are many bugs that don't cost very much to fix (imagine a bug found from unit test results early in production code; the cost to fix that is essentially zero and there may be several of these kinds of bugs) and that there are a ...


4

As with all positions the title means whatever the hiring company wants it to mean, nothing more. The term "QA Engineer" might mean "Tester", "Standards Enforcer", "Auditor", "part-time Developer/Analyst", all of these, or none of these. I've seen them all. In my company, the team used to consist of "QA Engineers", until we were purchased by a larger ...


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


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


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


3

INHO the testers' responsability is the sameone that all other roles' responsibility: to contribute as much as possible to the success of the project. That is, keep an eye on the ROI of every one of your activities. Keep a balance between the cost and benefit the project (and the whole team) will get for those activities. Keep aligned with the project and ...


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

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

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

The Leprecahauns of S/W engineering book (http://leanpub.com/leprechauns ) has a chapter on 'The cost of defects: an illustrated history' where he tries to find the data behind the claim that the later a defect is found the more expensive to fix. Might be worth you reading the book to see how a lot of industry myths are exposed


1

In my opinion the tester should be a more active role with these aditional responsibilities. (Note: this idea is not state of the art but a vision) Analyzing the Requirements from the client. When the requirements are written down make shure that the requierements are smart and automatic testable by using bdd-style / Gherkin-style language. These smart ...


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