Manual Testing, the Art That Cannot Be Lost
<p><pre><code>  To start let us talk about cost. Each is costly, but each is
  costly in different ways. Manual testing is costly because for
  every development team of four there should be at least one
  manual tester. That means hiring more people, which is
  expensive. Automation testing cuts the cost of manpower by
  almost 400% you only need one automation tester for every 16
  developers, but they is also a certain level of skill required
  for automation testing that requires you to pay the testers
  more. Both are costly just in there own way.
</code></pre>
We do automated testing, primarily. With manual testing during development and diagnosing errors (whether they are errors in our system or errors in understanding <i>about</i> our system or errors in systems we depend on).<p>I don&#x27;t see 1 tester for 16 developers, though. For us, it&#x27;s very nearly 1:1. Now, this is embedded and I&#x27;ve always worked in some way related to aviation. Perhaps our needs are different. But I honestly cannot imagine a scenario where you&#x27;d have a 1:16 tester-to-developer ratio. That seems like an environment highly skewed away from QA, in a bad way.<p>Similarly, how is this a &quot;fight&quot;? You need both. Manual testing is error-prone and non-repeatable (reliably), especially in systems with tight timing constraints. It&#x27;s excellent for identifying errors in development, finding problems in specifications, reproducing errors reported by users, but ultimately testers should be automating their tests. That was my job for years, I wouldn&#x27;t want to spend my time flipping switches or pushing buttons in a GUI for weeks at a stretch just to verify our latest build hasn&#x27;t introduced new or old errors.