<br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 2:19 AM, Ben Finney <span dir="ltr"><<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">"Noah Gift" <<a href="mailto:noah.gift@gmail.com">noah.gift@gmail.com</a>> writes:<br>
<br>
> If I was in his position, I would tell the developer(s) that<br>
> routinely give him broken web apps that they were poor developers<br>
> for not including at least some basic tests. These could even be<br>
> minimal, like a script that connects to the database and tests a<br>
> couple of URL parameters for example.<br>
<br>
</div>I recommend that anyone being asked to pay for software should receive<br>
the functional application, its source code, and the full automated<br>
test suite for the entire application as a routine part of the<br>
transaction.<br>
<br>
In other words, sufficient to, if and when the customer chooses, and<br>
without needing any further consultation with the vendor, allow the<br>
customer to take the whole lot to a trusted third party expert, ask<br>
*them* to examine the source code to see if it's of good quality, and<br>
examine the automated test suite to ensure it's comprehensive and<br>
matches the requirements, and that all of those match with the<br>
application as supplied.<br>
<br>
All of these are perfectly reasonable requirements, and no competent<br>
vendor can claim that they aren't necessary or that they're extra<br>
burdens on the process. They are the equivalent of land assessments,<br>
architectural blueprints, circuit diagnostic logs, and other<br>
supporting expert documentation of the design and engineering process<br>
that are routine in the process of building anything else to someone's<br>
specifications.<br>
<br>
Even if the customer can't *themselves* make use of these documents<br>
(although it's never wise to assume that the customer can't understand<br>
at least some of the technical stuff you're doing), they are thereby<br>
assured that their vendor accepts peer scrutiny of their work if it<br>
becomes necessary.<br>
<br>
It is astounding that so many vendors, and so many customers, expect<br>
that these can be omitted from the deliverables of the project. Yet<br>
there is no good reason for it, and we should be challenging that<br>
status quo and expecting the same quality of relationship that any<br>
other customer of a design or engineering profession would expect.<br>
<div class="Ih2E3d"></div></blockquote><div><br></div><div>That is exactly what I was thinking by a code of ethics as an engineer. I think there is a natural pull against more formal testing of small web applications for 3rd party web dev shops when often those applications are done with more photoshop, and javascript efx, then logic. I do agree with the analogy of a blueprint, or perhaps line drawing for an electrical engineer. One potential problem though, is that IT doesn't require certification, and software developer is a broad term. Getting a CTO at a small company to mandate full test coverage for web applications might be tough as there isn't necessarily an agreed upon level of testing before an engineer or company is considered irresponsible. There is pressure to produce quickly, and "fix it on the back end". Often small shop web developers are self taught developers with minimal software engineering experience.</div>
<div><br></div><div>I wonder if we could come up with a simplified standard of ethical testing, akin, to the golden rule, which is a pretty simple way of saying be good. Maybe it could be that if you use persistence, at a minimum, it should be tested. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
> Is there anything I could point him to that could help convince the<br>
> CTO and developers at this company that testing is just ethical?<br>
<br>
</div>Hopefully the above analogy can be helpful.<br>
<br>
--<br>
\ "I bought some batteries, but they weren't included; so I had |<br>
`\ to buy them again." —Steven Wright |<br>
_o__) |<br>
Ben Finney<br>
<br>
<br>
_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Noah Gift<br><a href="http://noahgift.com">http://noahgift.com</a><br>