Techniques For Producing Quality SoftwareThis is a featured page

A Geek Night Double Bill! (27 Aug 2008)


This event will be held in the Kilburn Building, University of Manchester at 6:30pm for 7:00pm on Wednesday August 27, 2008. The venue requires a list of names in advance so, if you'd like to come along, please register. If you have an upcoming.com username that is recognisable as your real name, you can register by saying "I'm coming" on our upcoming.org event page. Otherwise, please fill in this registration form.


MbUnit - Unit Testing on Crack!
Andrew Stopford

If you're unit testing in .NET, you're probably using test frameworks like NUnit or MSTest. These frameworks are handy but don't encourage efficient testing, wasting your time as you write libraries of custom asserts and fixtures. Stop writing a vast number of asserts to ensure your test are effective. Stop writing custom asserts or fixtures to get around limitations of these frameworks. Save time. Save money. Make your tests run to their full potential. This session will look at MbUnit an open source unit testing framework for .NET that can do all that. It's unit testing on crack! (This talk was previously given at AgileNorth 2007 and now updated for the v3 alpha release.)

Andy Stopford is a software engineer, blogger and author from Manchester, and a new dad to his beautiful baby girl. He was MbUnit’s former lead and its current poobah.


Eliciting Quality Goals
Chris Morris

For one software project, the most important quality might be accuracy, followed by usability, followed by scalability. For another project, other goals might be important, and the order of priority might be different. Developers are effective at meeting the quality goals that they feel are important, and different views on the priorities for quality are a common cause of conflict among developers. Ensuring that all the developers understand which sorts of quality matter most to the end users and those who are paying for the project is an important step towards success.

Unfortunately obtaining clear and accurate answers about quality goals is not easy. This workshop will model in a short time a way of eliciting a ranked set of quality goals. Participants will have an opportunity to discuss the different types of software quality and the trade offs between them, in the context of an experience that will equip them to elicit quality goals from the stakeholders of their current and future projects.

A quality policy consists of a ranked list of goals, processes which it is believed will attain those goals, and a plan for checking whether the goals were achieved. The workshop will make such a policy, based on a consensus view among the participants. However, the emphasis will be on the fact that each project needs its own quality policy.

Chris Morris has worked as a software developer on a variety of projects, including four years as a project manager and team leader. He began his software development career by developing in IBM assembler language for a utility company and went on to become a web developer for an ISP. Later he joined a UK government research laboratory with the brief of developing software to support biologists, and eventually became a project leader of a multi-disciplinary team developing a laboratory information management system for molecular biology in 2005, a post he still holds.


Images from Last Nights Session
:


As promised I'm posting pictures of the flipchart outputs that we produced yesterday. (They're not terribly clear thanks to Apple for the camera on the iPhone...)

Apologies to Chris in advance as I may have not quite got things correct yet. I'm hoping that he might log in and tidy this up for me...

Here first of all are the various categories that we posted against. We used green / yellow post-its to record the things in our current project that we are proud of; and purple / blue post-its to record things we are concerned about. Sorry, that you probably can't read the post-its on these pictures but you get the mix...

PortabilityFunctionalityReliabilityUsability
EfficiencyMaintainabilityOther

To summarise the categories are:

Portability- adaptability
- installability
- co-existence
- replaceability
Functionality- suitability
- accuracy
- inter-operability
- security
Reliability- maturity
- fault-tolerance
- recoverability
Usability- understandability
- learnability
- operability
- attractiveness
Efficiency- time-behaviour
- resource utilisation
Maintainability- analysability
- changeability
- stability
- testability
Other

Chris then took the categories with the majority of post-its and invited us to vote. 3 x votes for categories with room for improvement; 3 x votes for categories which are important to us and in each case you must vote for 3 distinct categories. This produced the following:

Votes

It's then possible to plot the categories on a grid, votes for room for importance against votes for room for improvement.

Quality Policy

The stuff in the top-left is that which is important and where we think there is room for improvement.

Finally you examine the items in the top-left of the grid and attempt to answer the questions -

How do we find out our current level of quality in this category ?
What Metrics should we use to determine quality in this category ?
How do we know that we're improving quality in this category ?

Final Step
How will we assess testability?
  • How easy is to to write a new test?
  • How great are the dependencies?
  • Running tools: Ndepend
What metrics for testability will we monitor?
  • Output from tools named above, e.g. dependency metrics, Npath complexity.
  • Code coverage.
  • Code coverage of automatic testing.
  • Number of defects in production code reported by users.

How will we improve testability
  • Training developers, and winning buy in.
  • Pair coding and pair testing.

Here are the categories, with the text from the post it notes. They are ranked by the product of importance and improvability.

Name Importance * Improveability Descriptions + if the code has the quality - if the code lacks the quality
Usability 17*12 + Good GUI + usability / Good GUI – UI – User interface - User interface (intuitiveness) + User interface improvements (V2 of a system)
Maintainability: Testability 13*14 - level of testing lack of test coverage + high test coverage + test coverage - not enough time to UAT / System Testability + Testability + testability + Many unit tests - legacy code
Maintainability: Changeability 11*12 - no “living” design documentation – no DRY - absence of architectural vision + Given changing requiremens, how we still manage to deliver releases - lack of unit tests – lack of automated testing - quality of repeatable testing (unit, integration, and regression) + Maintainability / flexibility + Easy to deploy - More complicated than it needs to be (based on legacy code) - unconfidence of changes implications due to code complexity
Reliability 12*11 + It works! +Automated acceptance tests + Continuous integration + Database versioning + Scalability and stability
Functionality: Suitability 10*11 - Does the software produced actually conform to what the business wanted? + Meeting User's needs + It works + Simple to use + Just works - Killer functionality removed - No true entities in the DDD sense - Lack of user input + Simplifies complex concepts
Portability 1*3 - No separation of concerns - Incomplete reference architecture affecting the overall quality of the system + Excellent domain model and decoupled data store + Extensible + Deployed to test environment today and it worked first time!









We'd like to thank the university for allowing us to use their facilities.



richard.filippi
richard.filippi
Latest page update: made by richard.filippi , Jul 28 2009, 12:14 PM EDT (about this update About This Update richard.filippi Moved from: Previous Geek Nights - richard.filippi

No content added or deleted.

- complete history)
Keyword tags: None
More Info: links to this page
There are no threads for this page.  Be the first to start a new thread.