ASP.NET QA Podcast – Episode 4

Posted by Matthew Osborn on April 13, 2009
This podcast is no longer maintained contact me for information about old episodes.

In the fourth installment of the ASP.NET QA Podcast Federico and Matthew discuss “The Good,” “The Bad,” and “The Ugly” of the history of the ASP.NET QA Team. Discussion ranges from the dark ages, to the renaissance, to the industrial revolution, to the “21st and half century”.  Join them as they discuss the lessons learned and how the team has improved over time.

  • The team released the April update to the Lightweight Test Automation Framework.
  • The Dark Ages” ASP.NET 1.0/2.0
    • During this time the team was very focused on automating everything.
    • (disadvantage) This approach is not good with a changing Spec.
    • (disadvantage) Bugs were being found to late in the process.
    • (advantage) Excellent automation coverage.
  • The Renaissance” Atlas/Microsoft Ajax
    • The division moved to a feature crew model for development and QA.
    • (advantage) The team adopted a heavy unit testing practice. Increase in code coverage.
    • (disadvantage) The QA team still worked has it had before. It would automate everything is less time.
  • The Industrial Revolution” ASP.NET 3.5
    • The QA team began to adopt the Feature crew model and started the process of agile testing with exploratory testing.
    • (advantage) Bugs were being found at the beginning of the process.
    • (disadvantage) The team still wrote a large amount of automation.
  • 21st and half century” ASP.NET 3.5 SP1/ASP.NET 4.0/vNext
    • The team has really started moving away from automating everything and is spending more time investigating user scenarios.
    • The team has formed its own unique blend of agile, scrum, and any other buzz word project management theory.
    • (advantage) Creating and automating sample applications provides feedback for real world customer scenarios.
    • (disadvantage) The team is young and is still learning the best practices.
    • (Struggle) Costing has become less of a clear cut process.
    • (Struggle) The is still a barrier between the QA and Dev teams.
    • (Struggle) No one wants the blame when a bug is found.

Links from the show :