Monday, November 26, 2012

Fault injection - overview of techniques...

Fault injection - a vital technology for evaluation of safety critical systems.
http://dx.doi.org/10.1109/2.585157

This paper presents a nice overview of what kind of techniques for fault injection exist and where to look for more information on them. It also lists example tools for each class of the technique that the paper discusses.

In ISO 26262 this fault injection is important as it allows to test the safety mechanisms themselves. Even though in theory this is a simple task, in reality it is far for trivial to observe how the safety mechanisms, e.g. sandboxes, work when something gets faulty. One could do a lot of testing, but the most important part is to see whether the runtime mechanisms handle the situations in software that could cause hazards. Fault injection is also required for higher ASIL levels I chapter 6 of the standard.

@MiroslawStaron

Agile and Lean in Finland

How much agile is there in Finland?
http://dl.acm.org/citation.cfm?id=2372275  

This paper presents an interesting survey on how the Finnish industry adopts Agile and Lean software development principles. 
The paper shows that the majority of companies follow Agile principles (33%) and Agile+Lean (21%). What the survey also showed is that Lean principles on their own are not that common and are used only by 2%of the surveyed companies. 

Out of all the Agile methods it is Scrum which is the most popular, while TDD is used only by 1% of companies adopting Agile. 

This paper is a great view on the current status of adoption in industry (perhaps not all of it though). It gets even more interesting if we can consider this paper together with the work of Korhonen (see my previous post at: http://semetrics.blogspot.se/2012/09/supporting-agile-transformation-with.html).


@MiroslawStaron

Sunday, November 25, 2012

Great examples of Lean QA

Cases of QA in Lean software development...
http://lnkd.in/SYcD_F 

This weekend my Twitter feed showed a series of great articles from Tom Gilb @TomGilb where he provided a set of really interesting examples of companies who moved towards Lean.

The examples include Google and how they work with Chrome. What I like about that example was the analysis of short- and long- term costs of low quality. Not monetary or resource costs, but branding costs, for example - variety of programming languages which make it hard to debug lead to winning grounds of languages like Python or Ruby.

Another case from Hanssen which he shows is a great example of how companies engage customers and shorten interations.

Following the link above opens up a lot of great material about QA.

@MiroslawStaron

Wednesday, November 21, 2012

More projects == better defect predictions?


More efficient defect prediction when using data from multiple projects?
http://dx.doi.org/10.1016/j.infsof.2012.10.003

By looking at the newest research in the defect prediction field I've discovered this piece of work which intrigued me a bit. Usually we build statistical models in forms of equations describing defect inflows or use analogy based estimates - we use historical data to create models for new projects. This usually works fine, but this paper discusses things one step further, namely (and I quote):

RQ2: How much within project data should be enriched with data from other projects to achieve comparable performance with full within project data predictions?


The results show that using only 10% of the data can yield results of the same quality, which can significantly improve the cost-efficiency of defect predictions in industrial contexts.

@Miroslaw Staron