3 ms·
At our company developers rarely write tests. They rely on the QA for testing. Obviously it doesn't work, like, at all. I think a key aspect of this post is to
by djfm 10y ago
At our company developers rarely write tests. They rely on the QA for testing. Obviously it doesn't work, like, at all. I think a key aspect of this post is to highlight the fact that testing is in fine the developers' responsibility. Test engineers are here to make it easier for them to write tests.
- ng12 10y agoI think scale has a lot to do with it. Google has enough money, know-how, and headcount to invest in good testing technology. Smaller companies are probably lacking in at least one of those categories. For example at my last company hiring QA interns was cheaper and faster than developing good testing environments. Of course it started to come back to bite them but at the time it was hard to construct an argument for anything else.
- Afton 10y agoThere are levels and levels at which companies engage in Q.A. 1. There is none, and it's awful, once there are more than two developers. 2. There are dedicated QA people, who click on things in a more or less formalized fashion depending on the company, and sign off on releases. This is "pretty bad" at most places once you have a product that can't be easily verified by a couple of people in a few hours 3. You have dedicated Test Engineers, who are just software developers who write test automation. This can be good, but usually ends up with mid-low quality engineers filling this role for a variety of reasons. 4. Test Engineers are just Software Engineers who specialize in test-automation work. They write automation in high bug areas, and keep a larger overview of the product (set) to identify problematic areas and work with the product developers to solve those problems. 5. The article. Test Engineers write infrastructure for testing and reporting, (and possibly proof-of-concepts). Product developers are responsible for their own quality. Test Engineers may also act as consultants for product teams. It's probably worth pointing out that 2-5 are all reasonable places to be for different sized companies, at different stages. We shouldn't assume that everyone should be at a company that is 'like Google', since things that make sense at Google scale may not make sense for your 20 developer startup. edited for formatting only
- adrianratnapala 10y ago#5 is all very well, but I don't think helping devs write test is a substitute for actually having QA people. Testers should have a mentality of "I want to break this", and like it or not, the developers just won't think like good testers. Do Test Engineers at Google do this kind of work as well?
- yaaaq 10y agoTo add another question from an sre (swe), tools and infrastructure is a subset of my daily responsibilities (60%). Reading the couple comments it's hard to see where the line falls between these two roles. I'm on a smaller team so perhaps I just find myself handling both roles or.. ?
- ajeet_dhaliwal 10y agoWell said, I've been a software developer in test for several years and number 5 is definitely where you want to get to if you have the resources. Very few do from my experience but when they do it's really beautiful and I'm not surprised Google is one that manages to do this. Half my job has become evangelism to get to this point now, half is development. Also (half important point, half plug) solid test results reporting is underestimated in importance and generally not done well. Doing that right can boost engagement with testing. A reason that Tesults (https://www.tesults.com https://www.tesults.com) exists and I'm involved with it.
- dimino 10y ago> At our company developers rarely write tests. Ahhh! You could like, be the guy who writes a few unit tests.