Forgot your password?
typodupeerror

Comment: Re:Marketing or Research? (Score 1) 133

by yorgo (#48168553) Attached to: Mixing Agile With Waterfall For Code Quality

Thus far, I've been unable to find the actual report. I found and downloaded the "Summary of Key Findings", which says, "This report provides a brief summary of the important results from the full 2014 CRASH Report.". But, I can't actually find the "full 2014 CRASH Report".

This is making it difficult to evaluate. Perhaps on purpose...?

Comment: FDX not FDD (Score 2) 232

by yorgo (#47925667) Attached to: Ask Slashdot: Have You Experienced Fear Driven Development?

I’d guess that FDX (Fear Driven X) exists in nearly every industry. Google “motivated by fear” or “driven by fear”, and you won't just find a bunch of software development articles. This is a human problem, not an engineering problem.

Figure out how to stop this type of behavior at a larger scale, and the answer will probably apply to the smaller one.

Comment: Re:Of course you can have a standard (Score 1) 152

by yorgo (#47824213) Attached to: Can ISO 29119 Software Testing "Standard" Really Be a Standard?

This.

Testing is essentially "evaluating a product via experimentation". While experimentation certainly requires plenty of scientific rigor, it also requires plenty of creativity, as well. And trying to standardize creativity is unwise. There simply is no "one size fits all" way to test. Extended, or not.

Comment: Re:just like ISO 9000, that worked well! (Score 1) 152

by yorgo (#47824101) Attached to: Can ISO 29119 Software Testing "Standard" Really Be a Standard?

This. Mod parent up.

In (very) short, "testing is evaluating a product via experimentation" (see http://www.satisfice.com/blog/...). According to this definition, truly anyone can test. Anyone can "evaluate a product via experimentation".

However, formal, professional testing also has a purpose: to inform. That is, "testing provides information about the quality of a product so that others can make informed decisions."

So, formal, professional testing is "evaluating a product via experimentation - in order to inform". And /that/ requires "a modicum of skill and critical thinking".

Comment: Re:Wrong focus? (Score 1) 152

by yorgo (#47824039) Attached to: Can ISO 29119 Software Testing "Standard" Really Be a Standard?

Sadly, not everyone thinks like you.

By using words like "internationally agreed" (instead of "locally agreed" or "internationally begrudgingly accepted") and "standard" (implying "the way", and not "a way"), ISO/IEC/IEEE strikes fear into the following, unthinking leaders of companies, who then force the workers to...begrudgingly implement and comply with the "internationally agreed standards".

Anyway, I don't believe that something like testing can be standardized anyway. There simply is no "one size fits all" way to test. "Internationally agreed", or not.

Comment: Re:Which Michael Bolton? (Score 1) 152

by yorgo (#47823967) Attached to: Can ISO 29119 Software Testing "Standard" Really Be a Standard?

Mod parent up.

http://www.developsense.com/bl... is a treasure-trove of testing (and other) information. Simply reading his (and similar) blogs is an quick, easy, and effective (and free!) way to learn about testing. Also, be sure to check out the blog of James Bach for the same reasons: http://www.satisfice.com/blog/.

Comment: Re:Standards (Score 1) 152

by yorgo (#47823929) Attached to: Can ISO 29119 Software Testing "Standard" Really Be a Standard?

Companies can't do anything. But, people that run companies can. And people that run companies might be leading, thinking, reasonable people. But, very often, they're following, reacting, unreasonable people. People that will blindly follow "standards" simply because they're called "standards". And other people that report to those people must implement and live by those "standards". Even if the "standards" hinder, instead of help.

+ - ISO 29119 Software Testing "Standard"

Submitted by yorgo
yorgo (595005) writes "The International Organization for Standardization (ISO) will soon publish part 4 of a 5 part series of software testing standards. According to the website, “ISO/IEC/IEEE 29119 Software Testing is an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation.” However, many in the testing community are against it.

Some wonder how the ISO/IEC/IEEE achieved consensus without their input. James Bach speculates that exclusion helped build consensus. Others, such as Iain McCowatt, argue that something as variable as software testing cannot be standardized, at all. And others believe that the motive behind the standards is not increased quality, but economic benefit, instead. Michael Bolton explains “rent-seeking” as he builds on James Christie’s CAST 2014 presentation, “Standards – promoting quality or restricting competition?”. A comprehensive list of many other arguments, viewpoints, and information has been collected by Huib Schoots. Opponents of ISO 29119 have even started a petition aimed at suspending publication of the standard.

Even so, this might be an losing battle. Gil Zilberfeld thinks that companies will take the path of least resistance and accept ISO 29119.

So, where do you stand? What constitutes a consensus? Can a standard be honored without consensus? Can an inherently sapient activity, such as testing, be standardized, at all? What is the real purpose of a standard? Will companies acquiesce and adopt the standard without question?"

+ - IEEE Guides Software Architects Toward Secure Design->

Submitted by msm1267
msm1267 (2804139) writes "The IEEE's Center for Secure Design debuted its first report this week, a guidance for software architects called "Avoiding the Top 10 Software Security Design Flaws." Developing guidance for architects rather than developers was a conscious effort the group made in order to steer the conversation around software security away from exclusively talking about finding bugs toward design-level failures that lead to exploitable security vulnerabilities.
The document spells out the 10 common design flaws in a straightforward manner, each with a lengthy explainer of inherent weaknesses in each area and how software designers and architects should take these potential pitfalls into consideration."

Link to Original Source

Some people carve careers, others chisel them.

Working...