Improving Software Quality

1
Improving Software Quality

• Bruce Logan

2
Brief Bio

• Originally from Zimbabwe
• School in Zimbabwe
• Studied Electrical Engineering

3
Career background

• Plant maintenance
• Stint at CSIR
• Systems integration testing (Kentron)?
• IT (technology support)?
• Software development
• Project mgmt
• Testing
• Team mgmt
• Quality assurance

4
Systems integration training

• Weapons systems require systems approach
• System engineering training
• Complex systems testing formal
• Written requirements signed off by the customer

5
Software development experiences

• No written requirements make me one that looks
  like this!
• Customer changes their wishes
• Expect that the schedule stays the same
• No time to do it right end up patching fixing
• Cost overrun unhappy customer

6
VV experiences

• Opportunity to set up VV team
• Support from senior mgmt
• Project of limited scope
• Understand requirements in detail
• Draw up test spec according to requirements
• Skilled team
• Spectacular success
• Extend to other projects

7
VV success factors

• Limited scope
• Skilled team although not testers
• Mgmt support could build on early success
• Proved the formula repeatedly

8
Improving quality - overview

• ID areas for quick wins get mgmt support
• Formalise requirements?
• Formalise test spec?
• Feedback to developers?
• Follow through and get the wins
• Standardise relevant documentation
• Defect tracking resolution
• Separate test environments
• Formalise process for delivering systems
• Applicable to all sizes of systems

9
Improving Quality - suggestions

• Formalise the delivery process
• Determine requirements
• ID relevant documentation
• Set out the gateways for progress
• Make teams part of the process
• Make it positive not a witch-hunt
• Learn from mistakes
• Make sure the process helps developers
• Engage with the customer understand needs
• Get QA involved as early as possible

10
Improving quality further suggestions

• ID your goal focus on that
• Dont get sidetracked or sucked in
• Keep QA function independent
• Tailor the generic process to fit your
  organisation

11
Summary

• Focus on the desired result
• QA is positive a force for good
• QA can add large value on most projects
• Aim at building a quality process
• A quality process results in a quality product
  Ad Sparrius
• Problems downstream result from mistakes made
  upstream Ad Sparrius
• Early involvement mistakes fixed more cheaply
• Tailor, tailor, tailor!

12
Major insight?

• Re-branding of QA to VV
• Dont do it at the end
• Get mgmt involved keep your customer close to
  the process (common wisdom)
• System eng can be presented as VV
• V-model is another representation of SE
• Cant test quality into a system
• Inherent risk in decoupling teams
• Close the loop quickly comms
• Top quality skills in QA team
• Define roles process clearly

13
A Question?

• How to balance QA process with dev process, with
  limited resources
• In terms of being successful, how much is dumb
  luck
• When are you done with testing?
• What metrics are used to measure project success?
  (how do you justify the QA investment?)
• How does QA deal with external vendors
  suppliers?
• Define the core skills of a VVer!

14
Something to Add?

• Would you build a house without having an
  architect?
• Difference between Agile Waterfall is how easy
  it is to change the plan (you still need the
  plan!!)
• Agile is a good example of tailoring the process
• Risk mgmt identification, and closing the loop
  to mitigate in time
• Solution-focus methodology vs problem-focus
• Need the balance between the big-picture and
  doing the job

15
Thank you!
16
Actions

• Make slides available
• Cyberspace interactions
• INCOSE groups
• LinkedIn