Comments for Adrian Smith

Comment on 7 Deadly Sins of Automated Software Testing by Seven Sins of Software Testing Automation

Seven Sins of Software Testing Automation — Tue, 31 Jan 2012 11:34:57 +0000

[...] == "undefined"){ addthis_share = [];}In this blog post, Adrian Smith discusses 7 pitfalls of automating software testing. The seven sins are over indulging on propriety testing tools, too lazy to setup CI server to [...]

Comment on 7 Deadly Sins of Automated Software Testing by A Smattering of Selenium #77 « Official Selenium Blog

A Smattering of Selenium #77 « Official Selenium Blog — Tue, 31 Jan 2012 01:53:00 +0000

Nice article and as someone who has done linocut before, that’s an impressive print that is featured.

Comment on 7 Deadly Sins of Automated Software Testing by Adrian Smith

Adrian Smith — Mon, 23 Jan 2012 12:22:34 +0000

Thanks Frank

I agree that organisational constraints are a common problem and a problem I have spent plenty of time tackling.

Comment on 7 Deadly Sins of Automated Software Testing by frank1914

frank1914 — Wed, 04 Jan 2012 14:58:21 +0000

Aside from point #6 – which I fully agree with – you’re tossing out a lot of generalizations.

Pure API testing is no guarantee of success either since many bugs are caused by interdependence of calls and residual artifacts. People who write API’s aren’t always the best judges of how they’ll be used.

True, automated UI tests can be brittle and difficult to maintain if they’re not designed for reuse and maintenance with the same care you’d apply to ‘real software’. That’s not the same as saying they cannot be – I do it daily and in this shop manual testing is far more of a bottleneck during cycles than maintaining or executing the automated tests are.

In my experience, the single greatest obstacle to automated testing success is not technical, it’s organizational: entrenched management with little understanding of the concept and unrealistic expectations.

Comment on Open Source Computational Engineering Tools by chemionix

chemionix — Fri, 19 Aug 2011 06:10:06 +0000

I like your post.With ENGINEERING POWER TOOLS, the answers are just a click away. Program categories include Math, HVAC, Mechanical, Electrical, Materials, and Structural. All calculations are fully functional in the evaluation version, and the programs will function indefinitely. The software is easily networked.engineering tools include the capability maturity models, standards, data flow diagrams, work breakdown structures, and so on.

Comment on Open Source Computational Engineering Tools by ChrisVdV

ChrisVdV — Tue, 28 Apr 2009 01:13:31 +0000

This thread has some interesting comments about the value of using one of the above tools in particular (Open Cascade Technology) rather than a non-open source solution.
http://www.opencascade.org/org/forum/thread_15248/
Cheers,
Chris

Comment on Applying Agile Principles to Traditional Engineering Design by Adrian Smith

Adrian Smith — Tue, 28 Apr 2009 00:54:54 +0000

Thanks Rick – Great to hear you enjoyed the content and would be interested to hear if you are able to apply any of the ideas at your workplace.

Cheers
Adrian

Comment on Applying Agile Principles to Traditional Engineering Design by Rick Zhang

Rick Zhang — Sun, 26 Apr 2009 13:24:26 +0000

Adrian,

I am a fan of both Agile and your weblog. I have been following your blog for a while. I particularly like this post on Applying Agile Principles to Traditional Engineering Design. It is very insightful and interesting.

Keep up the good work. I am looking forward to reading your next post.

Rick

Comment on Open Source Computational Engineering Tools by ChrisVdV

ChrisVdV — Fri, 06 Mar 2009 04:57:25 +0000

I think it will be interesting to see if current economic conditions (I’m sick of the term GEC) result in a higher adoption rate of some of these tools by larger engineering companies. Even though there is often more work involved when using open source tools (in terms of set-up and in some cases writing customised front ends), I think the cost benefit will become very attractive.

I also wonder what licensing issues will be raised if these tools gain mainstream commercial use.

Cheers,
Chris

Comment on KBE System Definition by a.s.mitchell

a.s.mitchell — Mon, 19 Jan 2009 11:51:42 +0000

I don’t agree with Dave Coppers paper. What sort of technology you choose to develop your system is dependent on the skills of the developer and user base.

The focus on functional languages and especially Lisp would rule out all but a few developers and most of your users.

Anyone that says dynamically typed languages are good is crazy. Basic typing errors that can be caught at compile time now become runtime errors resulting in less robust code.

The aerospace industry (boeing ) is used as example of KBE success. In reality it is an example on how to get stuck with old technology and an expensive legacy system that only a few developers can maintain. It has also meant that they haven’t been able to leverage the latest technology available in the market place.

There is a definite start and finish to a KBE model as you are trying to capture the optimum workflow. You can’t do an analysis before there are loads, geometry etc. are defined.

I do agree with the point that new web-based technologies and OS independence are the way to go. However, this seems in contradiction with his previous requirement of the system having to last upto 50 years. Web-based technologies currently are lucky to have a life span of 5 years.

Successful KBE systems in industry act as the glue around other proprietary systems. Not the system on which everything else sits.