A Documentation Model

Read the Documentation Model discussion document.

What's the next most groan inducing thing you can say to developers and management after "Let's introduce a Quality Management System!"? How about "... with a really good set of formal documents!". Yep, developing a Documentation Model that's how to gain friends and influence people all right.

OK, so as quality oriented professionals we know a rational approach to the documents we use is a good idea. We also know that some external groups such as those troublesome (kidding, we love you) customers and certification bodies keep wanting to see our documentation.

It sure is good to show off a little by providing documents that are clearly part of an organised and well managed set. But where to begin?

Well, leaving aside dry talk of such things as documentation audits let's just focus on getting some documents in place? Don't worry. I've developed a way for the software test team to put in place a structured system for test documents, that's easy to understand and maintain.

It can even be scaled into a full Quality Documentation Management System with a little help from a few tools and willing participants. But that's another dry part we can discuss later.

A document about documents, all in three pages or less. Wonders never cease.

Mark Crowther, Head of QA and Documents about documents

Quality System Implementation

One difficulty with doing something you've never done before is knowing what the thing you want to do 'looks like'.

It's the same with a Quality Management System. You can read all you like about the theory of it but sometimes seeing an example in front of you is by far the easiest way to really understand.

In keeping my approach of ensuring the fundamentals are made clear I've posted a paper discussing a small Quality System Implementation.

This wasn't for a software test team but a security team at a large Internet Service Provider. If you've read the paper "A Documentation Model" then this could be read as Part 2, a practical example. The discussion on scalability will make more sense after reading the paper here.

Mark Crowther, Head of Systematic Systemic Systems

Secruity Testing

These last weeks I've been drawn into the study of Software Security Testing. By that i mean testing of security features, not the infrastructure.

As if building the web site and playing video games while trying to learn Python wasn't enough. It's been a busy few weeks while I'm 'in between jobs'.

It seems that the area of software security testing has yet to reach the level of maturity that Software Testing is beginning to enjoy. Not that software testing, even your basic black box functional testing, is as universally accepted as software development.

Soapboxing that software security should be seen as a separate area of delivery, that needs trained and experienced professionals to deliver on it sounds like the evangelical standpoint that was adopted for testing a few years ago.

Yet, reading around you discover there are some luminaries in the field that are pushing for this to change. The likes of Gary McGraw, that CTO of Cigital, stand out as Security testing's own Cem Kaner. Visiting his software security website over at http://www.cigital.com/ and listening to the Silver Bullet Security Podcasts reinforces that.

A sister company of Cigital is Fortify and they've developed an interesting idea to approach the actual delivery of software security testing. Combine that with the need for building security into the product right at the design phase.

Over at the Cyreath website I've written a discussion document around software security testing, read it here: http://www.cyreath.co.uk/papers/Cyreath_Testing_Software_Security.pdf then come back to the blog and share your thoughts.

Mark Crowther - Head of SWT (South West Trains...)