13 ms·

Asking developers to do QA is broken – why anyone should own QA

• tpmx 5y ago
  I think product owners should do (manual) QA. On their own, and when necessary for scalability reasons also via a small team under their direct control.
  • ukd1 5y ago
    +1 - I think they should be able to for sure - with current tooling, this is basically impossible without manually doing it; which I've seen a lot of product folks do!
  • nullspace 5y ago
    Yeah, this is the only thing that practically worked, in a complex product I used to work on. - If you ask the devs to do QA, you'll get no bugs other than the ones they already caught during testing and deployment. - If you have a mostly independent QA team, they will find somewhat silly/trivial bugs like the login page not working in an extreme edge case scenario. - However, when you ask your Product team to own QA, you get the real good stuff - "Why does this feature not actually work well with this other feature when you combine the configuration" etc. It's great!
    • franciscassel 5y ago
      When I was a PM, I was lucky to have a big, talented QA team, but I still knew I'd have to do a "smoke test" myself after every major feature release. I cared the most, and I knew the most about the intricacies of the product.
      • tpmx 5y ago
        I really recognize that feeling. Also: Bliss is when you as a product owner get to such a place that you trust the QA team that you've worked with so closely so much that you only have have to some basic tests a few hours after the release.
    • travisjungroth 5y ago
      On independent QA teams finding trivial bugs, I think this is a social problem. Specifically an alignment one. If a bug goes out, whose fault is it? Eng for making it or QA for not finding it? The answers are different at different orgs, and they have more to do with power dynamics than anything else. QA is pretty easy to fake (for a while). The last thing you want to do is quality check your QA team. So the further the incentives of the QA team are from the success of the product, the worse things get. It's a spectrum from the other cofounder doing QA to someone in another country charging by the hour. There are opposing forces to this. It's inherently difficult for people to check themselves. Also, QA is its own skill. It's one more thing to ask devs to be great at. Maybe it's worth having some specific experts around. It's kind of a specific mindset that not all devs have. This mindset issue is where I'm not entirely sold on what looks like a new strategy from Rainforest QA (where I used to work) of strongly targeting product teams. I haven't seen any QA tool so good that it removes the complete need for skill like indoor heating means you don't need to know anything about how to tend a fire. The best ones are more like how a modern gas range helps a chef. So I question how great the results will be if you have a PM or CSM doing it. Still, I wish them the best of luck.
      • tpmx 5y ago
        We had a very large QA silo in a previous company. ~150 people all working under a former QA (non-developer) person turned into a "QA VP". It was a disaster in so many ways. Empire-building tendencies, large numbers of bad hires, etc. The solution was to break up this silo and getting these people into the product teams where more technical people could handle management and hiring.
      • ukd1 5y ago
        Thanks for the luck Travis! Def something we've been edging around for a while. From what we've been seeing, a lot of PMs and no/low code folks already do this kind of thing manually, and don't have tooling for it. RF automation is now way better / easier to use than when you were with us (imho, of course).
      • deleted 5y ago
        [deleted]
    • mschuster91 5y ago
      > However, when you ask your Product team to own QA, you get the real good stuff - "Why does this feature not actually work well with this other feature when you combine the configuration" etc. It's great! That would require a skilled product management that is on equal footing with sales and has a veto right before stuff gets sold to customers. All too often however, the only thing that matters is customer wishes for new features, with no one taking care that the tugs the customers are pulling on don't rip the product apart.
      • tpmx 5y ago
        Having previously spent a decade in that role for a $1B company: I never got a veto right before stuff got sold to customers. I really, really wanted that in the beginning. In the end what I ended up doing was spending a lot of time packaging the product as well as educating the sales force. If you don't have well-packaged products, the sales force will sell anything, even if it doesn't exist. And they'll get backed up by a typically slightly disconnected exec team, because they also want revenue really, really badly. This strategy worked surprisingly well. I think both the sales team and the ever slightly disconnected exec team benefited from the artificial structure that I spent so much effort making up. I guess people instinctively just like following clear structures over chaos. (This was 5-10 years ago, and not in Silicon Valley.)
    • sumedh 5y ago
      > when you ask your Product team to own QA, you get the real good stuff A good QA who is part of the team can do that as well.
    • salawat 5y ago
      >However, when you ask your Product team to own QA, you get the real good stuff - "Why does this feature not actually work well with this other feature when you combine the configuration" etc. It's great! This works right up until you hit a complexity point product can't handle, or worse, you find out that product is building something completely different from the requirements SME's are giving. Your QA group (or misguided product group) can do jack squat about badly translated reqs or the right questions not being asked, which in the presence of the best devs and QA's degenerates into building the wrong thing perfectly, which has to get redone over and over again. A good QA that's been around the block is usually pretty good at sussing out major communication defects, but it can be tough to pull out of. It's a surreal class of miscommunication to behold, and as close a death spiral as you can end up in, because everybody day in day out is working hard and getting frustrated but no one's getting closer to the end goal.
    • somerandomqaguy 5y ago
      > - If you have a mostly independent QA team, they will find somewhat silly/trivial bugs like the login page not working in an extreme edge case scenario. Fair but you have to keep in mind that part of QA's job is to explore the silly and extreme edge cases too. One of the nastiest bugs I ever found started as a joke of a test. What happens if you enter a massive long text string (I think it was something like 600 kilobytes) into the password field and enter it? I expected the UI to barf and a bit of mischief. What I got was the entire server backend crashing and loosing every user session with it when it restarted. The joke test revealed a uncovered a serious denial of service attack vector that was trivial to execute, trivial to automate, difficult to detect, and incredibly effective. I agree it would be silly if QA insisted that trivial or edge cases be fixed; every bug has to be judged on the cost of fixing vs the risk of it happening in the field. But finding those silly edge case bugs is still very well worth the time to explore. If not because chasing the edge can reveal serious problems, but also because it also helps define where the limits of sanity really are instead of were it is imagined to be.
  • TameAntelope 5y ago
    They don't have time, so they'd have to scale it, and once you scale it you basically are building a siloed QA team anyway.
    • tpmx 5y ago
      Well, then they are doing it wrong. Or maybe "my" process only scales so far... It worked well for me at this scale: 30 developers, 10 QA people, 3 ux people, 2 product people "vs" 50 sales people. There was also a separate delivery/consulting team of about 50 people which was important early on for revenue.
      • TameAntelope 5y ago
        How do you integrate the QA people into the product owner's processes?
• franciscassel 5y ago
  I've been on teams where the "siloed" QA model seemed to work pretty well -- we seemed to find a decent balance between test coverage and frequency of releases. But this was at a cash-rich startup that had lots of money to spend on making sure we had plenty of QA headcount. That seems to be the exception, rather than the rule. Lots of startups I talk to are quite constrained in terms of dedicated QA, so the argument for empowering product managers to own quality does make some sense to me.
• marielvargas 5y ago
  With more folks building using low code and no-code tools many different types of users will need to know how to do QA
  • ukd1 5y ago
    This; especially now more apps are being done with no-code tooling (bubble, anyone?) - not a lot of existing tooling work with it, and code-based testing isn't viable even if it did.
• g051051 5y ago
  The last place I worked would pull devs randomly to do QA tasks when QA got behind. Of course, since we weren't trained in the QA processes, and didn't do it all the time, it often wound up taking longer to do the testing, plus the devs would get behind in their tasks.
  • ukd1 5y ago
    It's also common practice; usually caused by testing getting under-resourced, bad tooling, or longer shipping cycles (more stuff to test, more pressure to get it out).
• ppeetteerr 5y ago
  Love the idea, but have you met product owners?
  • franciscassel 5y ago
    Yeah, the good ones really care about the product experience and customer outcomes, so this makes a lot of sense to me. But what do you mean?
    • ppeetteerr 5y ago
      It's hard to get them to provide details to the engineers. I haven't seen many who write user stories. Asking them to build no-code automated test cases, that's ... ambitious.
• bob1029 5y ago
  The complexity of our application necessitates that our business owners do a lot of the final integration testing. It also requires that our product owners handle a large part of the implementation & QA efforts. For our application, a single piece of code might be reused 40 different ways across 100 different customers based on configuration-time items. To ask a developer to figure out why something is broken would be a fool's errand for us. Only with the aid of trace files & configuration references are we able to perform RCA and clean up an issue from live usage. For us, 99% of the time it is a configuration thing (either on our end or some 3rd party system). If the code works for 99 clients and 39 other configurations, it might be your client+config that is wrong, not the code.
  • ukd1 5y ago
    What do you use to plan it or otherwise manage the process? Is it all manual?
    • bob1029 5y ago
      Essentially yes. We are trying to move to a hybrid model where we can send excel workbooks to the customer for completion, and then directly import these into the system. This would get us ~80% of the way there. One huge upside with configuration is that it can be copied really easily. If you have a model customer that is very similar to others, you can use it as a starting point and save 99% of the work effort.
      • ukd1 5y ago
        Makes sense. Did y'all try to automate any of it? I've seen situations where things are highly-configurable, and massive at the same time - mostly in the medical industry. Test plans are hard due to interactions between config being highly-complex. No sense testing all of the setups, as not all are used or would even make sense.
• void_mint 5y ago
  I think QA-specific people that are specifically not SDETs create bad habits on teams. I think asking developers and product owners/managers to "own" QA fixes the "just throw it over the wall and hope for the best" problem.
  • splitstud 5y ago
    But then you're settling for low quality testing. There's an excellent methodology a good test team uses on devs that throw it over the wall. They throw it back with the first bug report. That said, it's sometimes the right thing for the team when something gets thrown over raw. A good test team should be fine with that and play their part.
    • void_mint 5y ago
      > But then you're settling for low quality testing. Not necessarily though. I would also argue that manual testing is just an insurmountable timesink. You'll never have enough time because manual testing balloons to the time allotted. > There's an excellent methodology a good test team uses on devs that throw it over the wall. They throw it back with the first bug report. Sure, but continuing a cycle of "not my problem" helps no one and wastes time. Removing QA as a team/role/specialization, and instead making it a step in the process a dev goes through to ship software, you're fixing the broken feedback cycle QA teams create.
• mobilene 5y ago
  I've yet to see the automated test suite that replaces a skilled, sapient, human, functional tester. The automation takes away the drudgery of repeating tests, but it takes a skilled human to figure out what risks are in the code and figure out coverage to determine whether those risks are realized. If you have developers write good unit and integration tests, and build their work to their local environment to make sure it basically works, you avoid most of the "throw it over the wall" mentality. You also deliver way fewer needles in the haystack, if you will. Testers are free to look for more impactful bugs manually, and then to automate coverage as appropriate.
  • franciscassel 5y ago
    Totally agree that automation will never fully replace the value of human-powered testing. (Though it is great for the rote regression-testing stuff. The "drudgery", as you put it.) Isn't the problem with relying too much on unit and integration tests that they don't consider the end-to-end app experience? (Which, in my mind, is what ultimately matters when customers think of "quality".)
    • ukd1 5y ago
      IMHO, yep - it's a balance, but the great thing is they can be quick to run, and run locally-easily; which is great for developers to get fast-feedback. Unit testing is unlikely to catch all end-user level issues though; traditional automation too, which is why human-testing is still valuable today.
  • ukd1 5y ago
    I think you're pretty on point here; today human nuance is needed to decide WHAT to test as well as HOW MUCH to test. It's also useful for executing some types of tests too (which is why we support both automation, and human testing). IMHO Unit and integration tests should be a given. Human testers should be used with the highest leverage where possible. Being a functional-tester though, today is partly limited by what tooling is accessible to you - which we want to fix.
  • protomyth 5y ago
• politelemon 5y ago
  We've suffered from the same problems as highlighted here. What helped us was a low code solution, https://smashtest.io https://smashtest.io, which is basically an English wrapper over Selenium. The developers spend less time on tests, and the QAs aren't an afterthought.
• bilalq 5y ago
  In a model where developers adhere to a devops philosophy and are product owners, there's no need for a split. Developers should not be measured only quantity of releases, but also on metrics related to availability, customer impact, latency, operational costs, etc. I'm not opposed to a model where non-technical roles are empowered to define test cases and contribute to approval workflows of a release pipeline, but that doesn't absolve developers of the primary responsibility of being end-to-end owners. I know "devops" is an overloaded term that means different things to different people. To me, it's when developers are involved in product research, requirements gathering, user studies, design, architecture, implementation, testing, release management, and ongoing operations. They're supported by a dedicated product manager who leads the research/requirements gathering/user studies initiatives.
  • sethammons 5y ago
    This is how I've worked for most of the last decade. Empowered devs that are accountable for their releases and supported by metrics related to customer experience want good quality releases. Ownership works.
  • Rapzid 5y ago
    Agree but a lot of companies, particularly larger ones, don't have this sort of culture. They are filled with people whos sense of worth(at the company at least) is defined by a narrow job title and set of skills. Their worldview requires them to categorize everyone else on a narrow set of attributes as well: "Oh, you're a programmer so you must not be good at soft-skills and communicating with the business." "Ah, you have soft-skills and you also program? You must not actually be very good at programming so you should stop that and just become a PM." "Ah, they are PMs/Sales/Whatever so SQL is too hard for them and they can't be expected to learn git or markdown; that's for nerds." This leads to cringy, insulting sentiments like: > The most valuable thing you can be doing is writing code Ughh.
• wefarrell 5y ago
  This feels a lot like a reincarnation of cucumber/gherkin, except they've replaced business-facing text DSL with a no-code visual UI. The intention is the same - to have the customer own the tests. This looks like it has a shallower learning curve to get started, but I would imagine that after a certain point it winds up being less productive to use the UI than to write code and this is ultimately why visual coding hasn't taken off. At some point someone will need to become a power user and be their organization's resident expert on Rainforest, but at that point they're spending all of their time in Rainforest and they're no longer a product owner embedded in the business. At the end of the day the business owner should be writing specifications, the engineers should be using them to create tests and they each should be collaborating closely on both.
  • thrower123 5y ago
    I've had a couple goes at teams trying to roll out cucumber tests, and I still don't understand quite what the point is. Nobody but developers could actually manage to write any tests, and it was harder than just using the normal tools, plus maintaining all the glue besides.
    • billyruffian 5y ago
      The gherkin language that cucumber uses for its specifications, written well, are brilliant at distilling what the customer wants, what the developer is going to build and how the QA is going to assert that acceptance is measured. But it has to be written collaboratively by all of those together and by the end of it you get a shared understanding. This is the most important part. The glue code behind it is a different fish, and needs someone with software engineering trainging to build it and love it.
  • ukd1 5y ago
    If you want something it's closer to, it's sikuli script. Visually looking at the page (or whatever, tbh), then manipulating it using the keyboard and mouse. It's basically done using a KVM, so much closer to what a user would be able to see and do than something like cucumber or gherkin. However, we also allow you to test using a crowd of humans, should folks need more nuanced feedback about things, or have much more complex things to ask. Disagree on who should be writing tests; I think that's the case today as tooling doesn't support anyone but engineers (QA or not) automation things, or manual tests.
• kazinator 5y ago
  The right person for doing QA for code written by developer A is developer B, who is motivated to show that there is breakage in the code written by A. This is just good old peer review, in the sphere of development. The industry uses dedicated QA people based on the assumption that you can get two for the price of a developer. In fact, if you have two developers, one of whom is more clever than the other, you want to give the code cranking to the less clever one, and use the clever one to verify the code cranking and make improvement suggestions. If you have clever people designing the system, and clever people finding problems in the commits, you can just have average coders cranking out the bulk of it. Most code doesn't need cleverness, just persistence and consistency.
  • billyruffian 5y ago
    My org has mixed teams. We find devs are terrible at being QAs. This is not through lack of willingness but they're always either overtesting or undertesting and usually missing the test boundaries. So we use the SDET model, software developers trained in testing to build out the automation and high quality QAs with lots of domain knowledge to do the static and exploratory testing. In my experience (hiring manager for QAs), there's no way I can get SDETs for anything like the price of a journeyman dev. I'm probably looking at a 20-40% premium right now for someone decent.
• regularfry 5y ago
  Devs doing QA worked fine for us. You need to have a team that actually cares about the product, and you need figurehead devs - not necessarily seniors or team leads, but charismatic people others will fall into line with - who model the behaviours you want. The problem with almost anything else is that it increases the number of hand-offs between groups of differently-aligned people on the route to production. If you're aiming at multiple deployments per day, with sub-hour commit-to-prod times, the latency in those hand-offs adds up way too fast.
  • failwhaleshark 5y ago
    Yep. Fire the aholes and the egos, and keep the messianic figures who go-give and get shit done.
  • jokethrowaway 5y ago
    My main problem with devs doing QA is that QA is huge, knowing the entire product is hard. In my case, devs were just testing what they changed and never noticed something horribly broken somewhere else. I think all devs should test that what they built works in production (you don't need QA for that), you need QA to keep everything else tested and working.
    • regularfry 5y ago
      > devs were just testing what they changed and never noticed something horribly broken somewhere else. There's your problem. If they broke it but didn't test what they broke, then they changed it but didn't realise they had. "Horribly broken elsewhere" sounds like the sort of thing that should show up in an automated test, no? If the problem is "we don't have a good enough automated test suite and our architecture doesn't limit the blast radius of changes" then I can see how throwing QA headcount at it might look tempting.
  • notmyfuture 5y ago
    A person doing manual testing, which is a gate to deployment would certainly be hard to make work for deploys as fast as you're targeting. It may still be valuable to have someone separate to the devs testing your product (in production, not as a gate to release) looking for things your automated testing, customer feedback or metrics may have missed. Whether this would be valuable is really context-dependent.
• deleted 5y ago
  [deleted]
• MattGaiser 5y ago
  Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist? I had this in my past job. Have 1 QA per two developers, the QA sits with those two developers, and you are constantly telling them when a build is done and on staging. They write tests, do some manual checks, and then tell you how it is going relatively immediately. They also handle the problem of reproducing bugs and narrowing down exactly where they occur, which is not trivial. For all the faults in that organization (including letting our test runner be broken for months), we didn’t put out a lot of bugs and we found all manner of strange edge cases very quickly.
  • innagadadavida 5y ago
    > Why can’t the QA people just live on the dev team? Because there is little incentive for devs to police themselves and there could be multiple dev teams spanning client/server that needs to be integrated and tested. A slightly better org to own QA would be product team.
    • alistairSH 5y ago
      Each team should have some QA resources. Server can be tested independent of client, etc. Then the QA staff work together to ensure appropriate systems integration tests. Siloed QA team runs the risk of becoming a bottleneck as work from disparate teams comes through.
    • damontal 5y ago
      Sure there’s incentives for devs to police themselves. I’d rather catch problems early than have a to deal with a shitstorm from pissed off product owners and VPs when bugs are found in production. But our QA person is on another team. I’d much rather have them on my team.
  • GaveUp 5y ago
    The key part in that is communication. That’s makes all the difference whether it be with BA’s, QA’s, or the end user. Speeds up the development cycle and greatly reduces the number of bugs. The best experience I had was on a team that had essentially 2 BA’s and 7 devs. There was constant communication to clarify actual requirements, devs would build automated tests off them, BA’s would test against the requirements and then a business user would do a final look over. All in all features were able to be released usually within a day and there would be days we’d get out 3 or 4 releases. Only in one case did a major bug get released to production and the root cause of that was poorly worded regulations which had a clarifying errata come out at the 11th hour. For as many faults as that company had that caused me to move on I’ve yet to run across a team that functioned as well as that one did.
• arduinomancer 5y ago
  * Adopt this automation platform * It eventually becomes too much work for the PM as the product grows or the PM just gets tired of the tediousness of creating tests for all the edge cases * PM hires someone to help with creating the automation tests * That guy now becomes "the QA guy" * Repeat till you've re-invented "the QA team"
• eweise 5y ago
  We have a team that helps with testing infrastructure but the tests are created by developers on the functional team. Everything is automated. Seems to work well.
• protomyth 5y ago
  Dev sometimes aren't the best QA because they think like developers and not like end users. The mindset prevents you from doing things on the corners that end users do. Its like your instincts kick and a keep you safe without the railing where an end user might plow ahead thinking their path is ok and fall off the edge. Devs should do automated unit and functional tests, but after that, get some good QA that do not have the same boss (at least at the first level) as the developers.
  • regularfry 5y ago
    This can absolutely be learned, enabled, and encouraged by the right guidance and, if necessary, training at the dev-team level. It's just part of the job.
    • detaro 5y ago
      Can be, yes. Devs aren't always the best group to do that with though. I've had quite a bit of user training in a product I work on, but unsurprisingly the QA group of people who in their primary roles use it daily and have degrees in the problem domain are way more effective at finding non-obvious problems.
    • protomyth 5y ago
      I really don't think any Dev team will be as good at QA as a dedicated QA team. The mindset is very different and the context switch is hard. Checking your own work is also not the greatest of ideas.
      • regularfry 5y ago
        You are free to think that. I've seen it done.
    • tester34 5y ago
      for what kind of software? if your product is e.g docker, git - then yea, easily if it's soft for different industry, then complexity increases
• lowbloodsugar 5y ago
  The best outcomes are when people test what they are responsible for.
  • yellowfish 5y ago
    the more outcomes the better the learnings my friend
  • postalrat 5y ago
    What evidence do you have for this?
    • lowbloodsugar 5y ago
      I'd say google W. Edwards Deming to start.
      • postalrat 5y ago
        Can you help me find where he examines "when people test what they are responsible for"?
        • lowbloodsugar 5y ago
          I can't find the bit where he talks explicitly about this as I've lost access to the book I read it in (and don't even remember the name). I'll see if I can dig it out. In the passage I am unable to find, he gets into the issue of having a worker making widgets, and another worker checking the widgets. In our world this would be a developer and a test author. He states that this reduces quality: the maker knows that he can make poor parts when he is in a hurry, because the tester will catch them; the tester knows the worker personally, and trusts that he will make good parts, so doesn't have to be very thorough. Instead, we need the worker making the widget to be responsible for its quality, and further to be empowered to do so.
• dilatedmind 5y ago
  I think this article misses two important points on siloed qa teams 1. Qa doesn’t know what can be covered by unit or integration tests 2. Since they treat our code like a black box, they may create permutations of tests which which cover the same functionality Maybe this is part of the draw of having a qa team. Feature coverage rather than code coverage. The downside is this can create a huge number of expensive to run manual tests which may be hitting the same code paths in functionally identical ways. The tooling for automating manual tests of web apps is almost there: puppeteer, recording user inputs and network calls, replaying everything and diffing screenshots. Since qa tests are tied to features and not code, There’s also the problem of having to run all qa tests even if you’re releasing minor code changes. My build tools are smart enough to return cached results for unit tests whose dependencies didn’t change, but there’s no equivalent for qa tests.
  • cwkoss 5y ago
    Yeah, this article is shallow and avoiding the deficiencies inherent to Rainforest's offering. They are defining QA challenges as a nail so they can sell you their hammer.
• MontagFTB 5y ago
  Asking developers to own QA is broken because developers are naturally biased towards the happy path. If you want to build a bar, you need someone to order -1 beers[1]. Handing off QA to an external team is broken because those people don't have the necessary experience with the product, nor can they quickly and easily engage with development to get to the heart of a problem (and a fix.) Having QA rely exclusively on automation brings quality down as the application's complexity goes up. Writing tests to cover every possible edge case before the product ships isn't feasible. The best solution I've seen in the decades I've been in software development has been to have QA and Dev as part of a team. Automation covers as much of the product as possible, and continually grows as issues are identified that can be covered by CI from here on out. QA become essential at the boundary of new features, and require a deep understanding of the product in order to know what knobs to turn that might break the application in ways the developer never thought about. Once those sharp edges are also automated, QA pushes the boundary forward. [1]: https://twitter.com/brenankeller/status/1068615953989087232 https://twitter.com/brenankeller/status/1068615953989087232
  • notmyfuture 5y ago
    I've also arrived at this approach and don't think it's that uncommon - IMO the article is presenting a false dichotomy. There are still gotchas to look out for in the team-embedded QA approach. In typical team sizes, you often end up with only one QA per team - you need to make sure they have cover (everyone needs a break), and they need support in their discipline (do something to share QA knowledge across teams).
    • vlovich123 5y ago
      QA also works best for features that the user can meaningfully interact with. The more esoteric, interconnected, or complex the failure is, the more it gets muddled with other reports and weird conditions (it breaks on 3pm when the moon is in equinox and I have my mouse pointed north). That’s an over exaggeration but the sentiment is accurate. QA will frequently lack a deeper understanding of how the software works and is connected. That ignorance can be valuable (finds blind spots) but has trade offs (assumptions are made based on imperfect observation of cause and effect where human biases lead you down dark hallways). Speaking from experience with lots of manual QA which is actually a rarity these days. The other thing to consider is, if you’re careful, user feedback can be obtained more quickly. If you can keep things stable, then you won’t upset your users too badly and you’ll avoid the need for QA to act as a stand in.
• desc 5y ago
  Silver bullets. They don't exist. Code review. Read the results of someone thinking through a process. Spot more than they will, simply by throwing more eyes at it. Actually fairly effective: getting a senior dev to cast even a lazy eye over everything gives more opportunities to discuss Why It's Done This Way and Why We Don't Do That and Why This Framework Sucks And How To Deal With It with specific concrete examples which the other dev is currently thinking about. But it's still easier to write the code yourself than review it, and things still get missed no matter how careful you try to be, so it's still just another layer. Unit tests. They cover the stuff we think to check and actually encountered in the past (ie. regressions). Great for testing abstractions, not so great for testing features, since the latter typically rely on vast amounts of apparently-unrelated code. Integration tests. Better for testing features than specific abstractions, and often the simplest ones will dredge up things when you update a library five years later and some subtle behaviour changed. Slow sanity checks fit here. UI-first automation (inc. Selenium, etc). Code or no-code, it's glitchy as hell for any codebase not originally designed to support it; tends to get thrown out because tests which cry wolf every other day are worse than useless. Careful application to a few basics can smoke-test situations which otherwise pass internal application sanity checks, and systems built from the start to use it can benefit a lot. Manual testing. Boring, mechanical, but the test plans require less active fiddling/maintenance because a link changed to a button or something. Best for exploratory find-new-edge-cases, but throwing a bunch of students at a huge test plan can sometimes deliver massive value for money/coffee/ramen. Humans can tell us when the instructions are 'slightly off' and carry on regardless, distinguishing the actual important breakage from a trivial 2px layout adjustment or a CSS classname change. So that's the linear view. Let's go meta, and combine techniques for mutual reinforcement. Code review benefits from local relevance and is hampered by action at a distance. Write static analysers which enforce relevant semantics sharing a lexical scope, ie. if two things are supposed to happen together ensure that they happen in the same function (at the same level of abstraction). Encourage relevant details to share not just a file diff, but a chunk. Kill dynamic scoping with fire. Unit and Integration tests can be generated. Given a set of functions or types, ensure that they all fit some specific pattern. This is more powerful than leveraging the type system to enforce that pattern, because when one example needs to diverge you can just add a (commented) exception to the generative test instead of rearchitecting lots of code, ie. you can easily separate sharing behaviour from sharing code. Write tests which cover code not yet written, and force exceptions to a rule to be explicitly listed. UI testing is rather hard to amplify because you need to reliably control that UI in abstractable ways, and make it easy to combine those operations. I honestly have no idea how to do this in any sane way for any codebase not constructed to enable it. If you're working on greenfield stuff, congratulations; some of us are working on stuff that's been ported forwards decade by decade... Actual practical solutions welcome! That's my best shot at a 2D (triangular?) view: automated tests can enforce rules which simplify code review, etc. The goal is always to force errors up the page: find them as early as possible as cheaply as possible and as reliably as possible. The machine can't check complex things without either missing stuff or crying wolf, but it can rigidly enforce simple rules which let humans spot the outliers more easily. And it is amazing how reliable a system can become just by killing, mashing and burning all that low-hanging error-fruit.
• Tarucho 5y ago
  And what about asking devs to do QA while evaluating their performance on dev story points per sprint... The broken practice in our industry is management...
• jokethrowaway 5y ago
  I think asking PMs to become QAs with no-code is a hard sell. They made a nice looking product, they can just sell their product by saying they're making existing QAs more efficient / write less code / cheaper.
• sytse 5y ago
  I agree with not asking the developers of the feature. I don't think it should be part of product. QA is a deeply technical job. At GitLab QA gets own department called Quality. They are on the same level as development, design, development, and infrastructure. The people in it are mostly Software engineers in test. For more information please see https://about.gitlab.com/handbook/engineering/quality/ https://about.gitlab.com/handbook/engineering/quality/
  • ukd1 5y ago
    Some of QA is technical needlessly; we think that's a common issue with tooling today. QA today is just not accessible to folks that think about and manage change to the product, namely product folks. Why don't you think it should be part of product? Love that your department is called "Quality", implies more metrics-less-feeling before reading the doc.
    • sytse 5y ago
      Thanks Russell. In our experience a lot of QA improvements require automation which is more of a software engineering job than a product management one.
      • ukd1 5y ago
        I think this is mostly true today, but something which we think of as broken and we're fixing. We believe it should be accessible to a wider audience outside of just engineering; there is a lot to do, but we're starting with UI automation.
    • Rapzid 5y ago
      > folks that think about and manage change to the product, namely product folks It's weird to me that the software engineers building the product are not viewed as "product folk". The people designing the architecture for and building the actual product aren't managing the changes to it or concerned about it? The people who have to address any defects in it aren't concerned about their processes as they pertain to quality? This sort of worldview seems anti-agile and anti-lean TBH.
• flippinburgers 5y ago
  I recently finished working as a team lead in a small startup company in a foreign land where I do not speak the language fluently. The entire team aside from one member were unable to speak or write in English. We had no "QA" team. The director of engineering expected us to do our own QA. He expected me to make sure it happened. This project consisted of breaking up an existing system into three parts: a backend and two separate frontends. New technology was involved and parity + additional new features were expected. The team was small. Half of the six engineers were not performing as expected for a variety of reasons. This thing broke me. In order to try to attain what he was asking for evidence was required. Screenshots, gifs, explanations in PRs. I was removed from the position of team manager just two months before release and replaced by a native speaker. Yes I am bringing my weird personal anecdote into the conversation, but not having people who were specifically there to do testing was soul crushing.
• benreesman 5y ago
  Holding engineering staff responsible for the quality of their work is a lot more controversial than it is logistically or organizationally complex.
• cwkoss 5y ago
  This is a superlative blogspam sales pitch. Maybe their tool helps? but these sorts of self-justifying articles are just untrustworthy marketing babble. Big turnoff to me. I stopped reading halfway through, do they ever mention the pros of alternatives or is this purely arguing "here is why our company is the only good solution"?
• sitkack 5y ago
  > Every minute spent doing QA is a minute not spent writing code This is flawed reasoning. 80% of all engineering disciplines is in double checking your results. Bridges, space shuttles, heck even the chips. Only in software do we say that the 20% is 95%. *edit, fixed mistake.
• xyzelement 5y ago
  There's a little bit of an insane assumption in this pitch that PMs should be writing tests because they are the ones that "care a about quality." With my engineering hat on, I hate this idea because the message that devs don't care about quality (but PMs do) is not how I want to operate. With my PM hat on, I hate this because having the PM do test automation has got to be the lowest value activity you can ask the PM to do. That is, whatever the PM doesn't get to do because he's writing tests is almost certainly more valuable. So yeah this pitch is nuts. If your system makes it easy to define tests with no code, awesome and that should be useful by the teams that do testing today. Weird that it isn't their angle.
  • theptip 5y ago
    A problem with having engineers own the tests is that if the engineer misunderstands how the feature is supposed to work, then both the code and tests will be wrong, but because they are consistently wrong the tests will be green. So the product owner still needs to do ad hoc testing to verify that things work as expected. I like the “three amigos” approach from BDD as a solution here. The product owner writes the initial acceptance criteria, ie specifies the product. Then sits down with an engineer and tester to edit the ACs into sensible Gherkin so they can be executed as tests. The tester goes off and builds the tests (implementing the Gherkin steps) and the developer builds the feature. At the end you bring them together and if the tests pass, you are quite confident that you met the requirements. (If the error is not obvious you all huddle and figure out where the misunderstanding was). The important thing here is that everyone gets together and makes sure they share an understanding of the feature. You could skip the Gherkin and write the tests some other way. But having the product owner think through the process of specifying the acceptance criteria cleanly is a good exercise, I think. Now I don’t think that means they need to own the tests… but there is a case for it not being the engineer that’s implementing the feature, for sure.
    • musingsole 5y ago
      > The important thing here is that everyone gets together and makes sure they share an understanding of the feature So true. Communication is everything, but because it's hard it gets short circuited everywhere. Where I work, devs write their own tests. It's as terrible as you can imagine while still having a successful product. I once suggested we split to a designer/verifier model...and got the weirdest blank stares. I honestly think it's because no one I work with wants to talk to each other.
• hyfgfh 5y ago
  Does a project needs a QA person? It depends. I had projects where QA did offer negative productivity and projects where we spends weeks because we didn't have QA. I believe the problem is that we do not have good QA professional. Being QA is more the applying a process is understating the projects needs, UX and the process, and being able to delivery on all fronts.
• Maximus9000 5y ago
  I've been a QA Automation Engineer for 15 years. This is the best thread ever on HN! I've read every single comment. I've found the best approach is for QAs to be embedded right into the product team - where the product team manager is the same person for both Dev and QA. QA and Dev all review each others code. QA reviews the Dev unit tests, and Devs review the QA integration tests (API and UI). QA may not be able to provide in-depth reviews on dev code, but at least they can double check that unit test coverage is adequate. As for UI automation, one point of friction that often happens is that QAs want unique IDs on each UI element. If the devs fail to provide those unique IDs, then QAs are often forced to do some convoluted workaround. However, there is a better option where QAs simply add the unique IDs themselves and request a code review from the dev. This works well because the change to developer code is benign and QA is not slowed down.
  • terpimost 5y ago
    Thank you for your comment (useful and interesting information). So it looks like your suggestion is to have 2 types of engineers in the team, where at least one of them is focused on QA + encourage bi-directional code reviews. Could you tell a bit about the involvement of PMs in the QA process from your experience? What's working and what isn't?
    • Maximus9000 5y ago
      The PM is busy doing their own job (writing new stories, managing old stories, talking to clients, etc). They typically only do a superficial amount of testing on new features (and usually only on their pet-features). The vast majority of testing comes from QA and Dev.
  • ryathal 5y ago
    Having QAs that technical would be amazing. Most of the time I find that anything more complex than basic JSON editing is the limit of their technical abilities.
    • beatthatflight 5y ago
• alexpotato 5y ago
  Many years ago I asked a developer which was a bigger deal: - Having an outage - Missing a deadline They answered: "oh having an outage is WAY worse". I then asked: "if that's the case, why do you push so hard to hit your deadlines with code you know and I both know is probably not ready?" They didn't really answer at the time but it eventually dawned on me what's happening: - odds of being yelled at if you miss a deadline: 100% - odds of being yelled at due to an outage: unclear as it depends on the odds of an outage in general so let's say "less than 100%" Therefore, they are "gambling" rationally by pushing for deadlines vs pushing out good code. The point I'm getting to is that if the goal is "hit the deadline" vs "deploy code that runs in production for two weeks with no errors", QA is going to be less of a priority. Couple this with the fact that many firms think of QA as "they have to be cheaper than devs!" and then compensate them accordingly, means that QA people are fighting down both the comp front and the incentives front. I've seen this happen so many times that I'm not really sure why people are surprised by it any more. (NOTE: you could say "well then testing should be automated" but you get into a similar argument on who is building and maintaining the testing frameworks).
  • trynewideas 5y ago
    > - odds of being yelled at if you miss a deadline: 100% > - odds of being yelled at due to an outage: unclear as it depends on the odds of an outage in general so let's say "less than 100%" To reframe this, the odds of a dev having to crunch to hit a deadline they're behind on is 100%, but the odds of any developer catching a support escalation or on-call page from an outage are usually way less, especially on larger teams, because it's rare for every dev to always be on the hook for escalations. That's why things like goalies and pager rotations exist; the perception is that saddling one person with the responsibility occasionally is better than splitting it to everyone all the time. One weekend of abject hell a month is better than four weekends of annoyance. But when any developer can shirk ownership of an outage, they all effectively do. Even from a support perspective, that doesn't even make me mad — who wouldn't want to sleep in, ignore Slack on weekends, and not feel dread every single time your phone pings with a notification? On the other hand, teams _never_ let developers off the hook when there's a deadline that might slip. If you don't have something to do, you're pairing off to help someone else who does, or if you can't then you're more likely to be working on the next thing down the pipe so there's not as much deadline pressure, than supporting on stuff (like tests! and docs!) that won't be considered tech debt until someone (probably support!) hits something related to it and calls it out later. Dedicated QA doesn't lift the outage ownership problem, it helps mitigate it before it happens. But QA teams that deflect outages struggle to provide data-driven reasons for their existence, because they can't track a negative, and credit for _n_ 9s of uptime is always split multiple ways such that nobody gets a big piece. QA winds up forever underappreciated because their wins are so much harder to count, but the times QA causes a deadline to slip are _always always always_ flagged. Nevermind that outage response pulls engineering resources off hitting deadlines... so that becomes a self-perpetuating cycle... The best route is to never have deadlines. Just convince sales and marketing of this and you're golden. /s
• jorblumesea 5y ago
  Mostly the issue with developers doing their own QA is the time is never allocated to do it properly. They are expected to design, dev, test, release, participate in improving team processes every week. Testing almost always gets cut due to the constraint of reality. Barely enough time is allocated to dev itself. Everyone talks about the advantages of devs doing their own QA, but what it means is that they just cut QA out altogether.
• bedobi 5y ago
  In my experience what's worked the best is making the team that own the product (or feature or what have you) cross functional and let everyone own everything. Of course everyone brings different skillsets, and of course everyone has falls into their natural domains accordingly, but it really shouldn't be that Bob and Alice have exclusive domain and responsibility over this and Jane over this and John over that. It's a product and a team for a reason.
  • fredsters_s 5y ago
    this has been our experience as well - sadly, however, most (all?) teams specialize and silo as they scale, and so you don't tend to see this setup beyond the very early stage
• trynewideas 5y ago
  From a couple different perspectives, docs and support also love (or should love) dedicated QA as a last line of defense against product changes that engineers don't consider worth documenting. Every single release in an org with no dedicated QA and dev ownership of testing, I've seen something a dev has changed in the product that developers deemed weren't worth documenting, and every single release a user hits that thing and support is left not even knowing the change happened and looking like they aren't the product experts that sales told the user they were. But aside from the dedicated viewpoint change of a QA analyst vs. an engineer, it's also a different relationship with other teams. Whether QA is part of engineering teams or siloed, it's usually a little easier for a tech writer or support engineer to pitch process improvements and regular communication to QA than developers. It's not about capacity, but value — adding a test to the product that confirms a code example in the documentation is accurate helps the product and the writer, so someone with a QA-first mindset doesn't have to think twice. But to a developer with a velocity-first mindset, it's busy work (shouldn't the tech writer own that check?) and maintenance load (isn't this another low-value test I have to manually update every release?). Tests should be a form of docs for what's supported in the product. If a feature isn't tested, documenting it for users is a risk. If the tests don't confirm what's documented, it's a risk. If it's a risk, it's not the devs who'll deal with it first when it breaks, it's support. Having that healthy relationship between documentation, support, and testing is a force multiplier, and it's harder to build that relationship when development priorities like velocity conflict with testing priorities like coverage and accuracy.
• Supermancho 5y ago
  Tangentially, over my lifetime experience, I understand that QA Testing should be done on public (user) interfaces. Intermediate data marshalling or transport, eg kafka delivering data from one application to another, is a dev ticket but has no QA component. Just as QA doesn't look at the individual data structures and method access modifiers, there are technical tasks and processes that QA has no stake in, nor can they do anything but complicate a delicate system with additional instrumentation/hooks. Generally, developers will want instrumentation, which is a public interface that QA can test, but is not mandated by QA as part of design.
• im_down_w_otp 5y ago
  I deeply wish that more sophisticated automated testing methods like Property-Based Testing were more prevalent among QA teams and organizations.
• jesseduffield 5y ago
  Looks like a pretty cool product. To play devil's advocate I'd like to poke holes at two things: Product team caring about quality: Devs need to balance quality with speed, and feel appropriately ashamed when something breaks on prod. To the extent that devs optimise for speed, I don't see why product would be any different. The product team has a large backlog and many important deals blocked by certain features. The incentive to optimise for speed is just as strong. The tension you get between a dedicated QA team and a dev team arises precisely because the QA team cares _only_ about quality. So by moving the responsibility to product you'll either see more corner cutting due to product optimising for speed, or more tension due to product optimising for quality. I don't think you can have your cake and eat it too. Feasibility of no-code testing: having your browser interact with the page in the way you would like is a good fit for a no-code approach. But most of the effort in writing tests, I've found, is setting up the data (e.g. with factories or fixtures). I'm not so sure that you can no-code that side of QA as easily. If I'm right about that, it means product will end up dependent on devs to write the tests.
  • fredsters_s 5y ago
    [author here] Both are solid points! Regarding the incentive structure, I think you're right - there's no way to eliminate the friction that comes from competing incentives. Our experience has been that empowering the product organization to make that tradeoff themselves leads to the optimal outcome for the business. The goal isn't to eliminate the tradeoff between speed and quality, but surface it, and put it in the hands of the people who are the business decision makers, which tends to be product. Re test data - we had seen this bottleneck with our previous product, which was purely about crowd testing. What we've seen since we shipped no code automation is that much of the data seeding by less mature teams can be done through the tests themselves. This is suboptimal, but with automation so cheap and fast, it works. Then over time the engineering team can seed the states that are most often created through the tests.
• deleted 5y ago
  [deleted]
• Copenjin 5y ago
  "Time spent doing QA is time not spent writing code" I wonder, is the time spent fixing inane production issues time well spent? Is the time spent by testers/QA to report obvious bugs well spent? Devs, test your stuff like if you were the only one doing QA, and everyone else along the chain should do the same.
• andix 5y ago
  Wherever I worked so far as a software developer we had the QA department very close. In the same room or next door. They were there from the beginning until the end, tested our software continuously. If we developed something, that was hard for them to test or to understand, they gave us a hard time. So we tried to make software testable. Do meaningful logging. Make things repeatable. Develop tools to export state/parts of the database, that can be restored. So you can actually test one feature and don't have to do 100 steps every time you need to test Feature X. All that also greatly helped the developers, because a lot of companies develop software, that the developers can't even try out, because it only runs in a QA system they don't have access to. That's horrible.
  • indogooner 5y ago
    This has been my experience as well. The places where testing was an afterthought meant the software was not testable easily. Executing multiple steps to test one feature meant QA folks kept running into one or other service issues causing delay in bug discovery. Rather than giving time to devs for fixing this, the management put more devs on test writing and were more interested in looking at dashboards.
    • andix 5y ago
      I've seen this behaviour in outsourced software development. In the end they had 10 times the people they would actually need on projects. And they were mostly trapped inside deadlocks and doing nothing. Just like if you try to parallelize a single threaded application without redesigning it. Just multiplying the core count of the CPU by 10 may bring you a few percent increase in speed, but nowhere close to the expected +1000%.
• joker-at-hft 5y ago
  I guess this debate entirely depends on the product and the customer base. If you make a product like Excel or Photoshop you probably need enough people to have taken an independent look before releasing it to the customers. QA is a legit formal step and protects the reputation, time and money for the organization. Smart QA teams will automate their processes and I have seen some pretty sophisticated automated test suites. In such a setup fluent communication between dev and QA is probably critical. On the flip side there are organizations which do not have the burden of fickle customers. An example of such an institution is a high frequency trading firm. The firm that I work for has two roles, developer or trader. These companies hire exclusively on-campus and with very transferrable skill-sets between the two roles. In such an environment, where both the writer of the application and the user is equally competent, the role of QA is a burden, there isn't much to add. The trader proposes an idea, developer implements it, trader has all the incentive to make the idea work and the two basically figure out ways to get a feature in prod as fast as possible and ensure that you make money. The success is tangible, the money is directly linked to the bonus you make. I see similar parallel in a startup where the people who generate the idea and people who implement the idea are the same pool. In such empowering environments, the proximity of user and developer just pushes for excellence. Most of the time the advocates and critics of QA do not realize that it is all context. QA as a role saves embarrassment, money, time etc. but that does not mean an engineering team is incomplete without a QA. I do feel that this article is offensive to QA community when it portrays QAs as inferior members of team doing work that is not worth the `expensive` developer.
• developeron29 5y ago
  In one of my previous companies, Our workload as developers went significantly down, code quality went up and bug complaints went down after we hired a QA team, as opposed to the developers doing it themselves. It is important for code to be looked at and tested with a fresh perspective and that's what a separate QA team aids in
• physicsguy 5y ago
  There's a really important issue with QA which is that you can't just farm it off to a team that doesn't know how to use the product. In my last job, which was working on Engineering software, they had a few student interns and a couple of permanent staff that had no training as engineers. So when bugs came in from customers, they had no ability to try and work out what the issue was, it was really dysfunctional - they weren't able to say "this is because the custoemr doesn't understand the physics" for e.g. They eventually moved an application engineer from pre-sales into the team and it made a huge difference in triaging this stuff, because many 'bugs' that came in were things like "my model isn't converging" and the answer was 75% of the time things like "you need to refine your mesh further", whereas previously it got shunted onto the dev team.
• darkwater 5y ago
  Sorry to sound harsh but IME I find - to be kind - naïve saying that developers are incentivized for release speed and at the same time pretending that product managers/owners WILL NOT have the same, exact incentive. I mean, I don't know in which dreamland company you are working but in the average company the ones pushing for new features and not caring about code quality are... PMs. I know they have to sell their no-code product which is not targeted at the QA teams but this is too much...
  • draw_down 5y ago
    Agreed, many issues are boiled down to some quirk or incentive of engineers, leaving pretty much the entire business apparatus out of the analysis. Like, if a game has a female character with huge breasts, it’s because devs are horny. Well, someone had to conceive of that character, iterate through sketches, design the models, biz people had to sign off on everything, etc.
• intellix 5y ago
  Am I reading the pricing correctly? 135$ for running 30 specs? We have Cypress tests that run automatically for every single git push which are running throughout the day constantly... if you did a price comparison we'd be saving something like $140k per month by not having a pretty UI for building tests
• fnord77 5y ago
  asking developers to do OPs is broken, too.
• ChrisMarshallNY 5y ago
  In my experience (and I have a great deal of that), true product Quality is dependent upon an endemic cultural philosophy of an organization; not a single tool or technique. It's a shared discipline, and a cultural imperative. It's like those ads for exercise machines, where professional athletic models, who train for five hours a day, and drink broccoli smoothies for lunch, are shown using a machine for a couple of minutes, with the inference that the machine is the reason for their washboard abs. The Quality formula is hundreds; if not thousands, of years old. Software development is just another context. There are significant costs to doing real Quality, which is the main reason that more people don't do it. One of the biggest costs, is that there isn't really that much money to be made, doing superb Quality. You get to sell to snooty customers, and feel smug, but there just ain't that many people that are willing to pay the premium for top Quality. Dreck sells. People who get truly rich, seldom do so, selling Quality. The ones that do, have that endemic culture. It's really difficult (and expensive) to maintain that; especially at scale. Lots of humbling and hiring expensive, cranky old craftsmen that can be difficult to work with. Lot of broccoli smoothies.
  • ozim 5y ago
    Totally agree. You just need good enough quality and prevent total catastrophes that would drive customers away. A lot of the time it is about making sure that stuff just works and not about testing edge cases - in my current company we did not really care about edge cases and I don't remember when we had an issue because of something like that. Mostly issues are popping up because people don't understand how things work or how they should work. People not understanding how things work leads to "exercise machine" metaphor, because to keep all people updated with knowledge is hard work that needs to be done every working day and it is hard work that costs a lot of money. For this "test-automation" and "low-code" solutions are promising that you can put your domain knowledge into such "exercise machine" and have it regardless if you keep people or let them go, if they spend time learning about system or not. Which is a false premise just like "excercise machine" giving six-pack without much work.
  • fredsters_s 5y ago
    First off, we totally agree on this: "true product Quality is dependent upon an endemic cultural philosophy of an organization." What we're asking you to consider is how much of that is because the tooling is shutting out the roles who are naturally incentivized to care about product quality? I think your broader thesis, while amusing, is ignoring some of the biggest and most valuable brands ever created... Apple, Rolex, Mercedes...
• sdevonoes 5y ago
  Being part of a medium-size company I realise the reason to not have QA is to save money. When an outage occurs because "oops, we didn't catch that bug", the issue is fixed within minutes. I suspect this is fine for the company and I imagine that the cost of these outages is cheaper than the cost of dedicated QA teams. Besides, this "culture" of "developers should own their products from conception to deployment, including QA" is becoming more ingrained in all new companies. It almost seems as if developers should be in charge of almost everything... and certainly it does cut costs (at least in Europe where we don't have such salaries as in the USA): developers should know about frontend, backend, databases, now the cloud, devops, developers should have a "product mind", they know monitoring, they should do paid on-call rotations, they should do QA, they should help in technical interviews, they should mentor juniors colleagues, they should do "dojos" and "katas", they are encourage to go to conferences and "share knowledge" when they come back, they should help onboarding of new colleagues, they should organize "tech talks", they should... and all with the excuse "we care about you growing as a professional".
  • jakubp 5y ago
    If you were running a business, and wanted someone to do tech talks, or design/run interviewing for tech candidates, or have mentoring for junior devs, would you prefer non-developers to do it?
• skyzyx 5y ago
  I agree with the premises, but not necessarily the conclusion. Any team with an attitude of “that’s not my job” is fundamentally broken. The team is responsible for product, development, quality, ops, CI, etc. But you have to adjust your definition of “team”. I very much agree with Google’s SRE model, and implementing it has worked well for us. The dev team is not an island unto itself, but rather a piece of a larger whole. SREs, Quality, Ops, and others are also true software engineers, and we tear down the silos between teams by working across our imaginary lines. Because we all rise and fall together. QA isn’t responsible for writing all of the tests, but they work to build a platform that makes it easier for anyone to write and run tests. Ops isn’t responsible for managing all of the infrastructure, but they work to build a platform that makes it easier for anyone to deploy services quickly and with great success. Security doesn’t stand in the corner telling what to do, but they work together to build tools and systems that can help an app team discover and remediate security issues. The solution is not no-code anything. The solution is software engineering and building platforms to reduce the “toil”, build repeatable automated processes, and work together and listen to each other to make sure we ship high-quality services for our customers. Full-cycle development. Similar to the concept of “cross-training” in your first job in fast food. It’s like “full-stack development”, but encompasses everything a service needs to succeed and not be a pile of shit.