Here's an outline of Jason Arbon's arguments for Agile methods leaving traditional test engineering in the dust.
In the Better Software (May/June 2012) article "Traditional Test Engineering, Your Days are Numbered; Turing Software Quality on Its Head."
"In this shift to agile, late cycle or manual testing efforts are often dropped or, worse, the program management and development teams embrace agile and continuous practices, but the old world regression test cycle is left hanging around like an archaic ritual that adds a few days or weeks to an engineering process that wants to be continuous."
Test Plans - quick cycles out pace the ability of managers to create the traditional test plan. Modern software development teams do more concurrent testing than was ever done in traditional processes.
Regression Testing - ninety some precent pass all the time, is this a good use of time and energy. Create a risk view of the application under test. Use automated tools and focus time and energy on these risky areas.
Textual Bug Filing and Triage - this manual process is bugger than the software being reported upon. Try logging the number of defects with the defects already recorded in your logging system. Move to automated systems that report bugs with attached screen shots of the systems and the steps to reproduce the incident.
Bug and Work Item Backlogs - the best advice for managers is "Don't". If you have to refer to a list of bugs then you don't know your software. People that know and use your software know what bugs need to be fixed. That information is in there minds daily, ask them. There is no need of a list of bugs that will take 3 years to get to the end of it. Trust me - you will not forget the really important bugs.
Test Case Databases - these are a sign of non-agile work methods. Databases are very heavyweight, compared to a lightweight list of areas to test that the team is currently work upon, and a suite of always green, passing tests.
Release Management - we are in an era of continuous releases, the question is not if or when the release goes out the door - but only if a feature is turned on or off in that particular release. If your features can not be expressed in this binary state, your application is really old-school.
Team Structure - many smaller companies reap the benefits of crowdsourced testing teams that and virtualized testing teams.
----
see also:
The 21st century definition of TEST
In the Better Software (May/June 2012) article "Traditional Test Engineering, Your Days are Numbered; Turing Software Quality on Its Head."
"In this shift to agile, late cycle or manual testing efforts are often dropped or, worse, the program management and development teams embrace agile and continuous practices, but the old world regression test cycle is left hanging around like an archaic ritual that adds a few days or weeks to an engineering process that wants to be continuous."
Test Plans - quick cycles out pace the ability of managers to create the traditional test plan. Modern software development teams do more concurrent testing than was ever done in traditional processes.
Regression Testing - ninety some precent pass all the time, is this a good use of time and energy. Create a risk view of the application under test. Use automated tools and focus time and energy on these risky areas.
Textual Bug Filing and Triage - this manual process is bugger than the software being reported upon. Try logging the number of defects with the defects already recorded in your logging system. Move to automated systems that report bugs with attached screen shots of the systems and the steps to reproduce the incident.
Bug and Work Item Backlogs - the best advice for managers is "Don't". If you have to refer to a list of bugs then you don't know your software. People that know and use your software know what bugs need to be fixed. That information is in there minds daily, ask them. There is no need of a list of bugs that will take 3 years to get to the end of it. Trust me - you will not forget the really important bugs.
Test Case Databases - these are a sign of non-agile work methods. Databases are very heavyweight, compared to a lightweight list of areas to test that the team is currently work upon, and a suite of always green, passing tests.
Release Management - we are in an era of continuous releases, the question is not if or when the release goes out the door - but only if a feature is turned on or off in that particular release. If your features can not be expressed in this binary state, your application is really old-school.
Team Structure - many smaller companies reap the benefits of crowdsourced testing teams that and virtualized testing teams.
----
see also:
The 21st century definition of TEST
Comments