This topic is so huge that there will be series of posts to cover some aspects comprehensively.
I will begin with testing as a task in agile projects.
Agile projects function such that the agile manifesto is followed. The manifesto indicates that there is value in process, contracts, planning, etc. however, it advocates people, team and core work (of building product) over these.
People sometime do take undue benefit of this and call process-less or chaotic way of working as "agile".
It is recommended that novice reads the myths along with the manifesto.
Few links to understand myths -
http://www.theappgap.com/exploring-ten-myths-about-agile-development.html
http://stackoverflow.com/questions/1871110/agile-myths-and-misconceptions
Naturally testing as a task - "should retain" its basics even while working on agile projects. Writing test cases, reporting defects, conducting RCA, Defect Prevention, metrics, etc have its value addition in agile projects. The difference is just enough & context specific application of these concepts. It is the 'team' that decides what is needed & not a uniform governing process document or a manager / testing head like authority.
One needs to understand about 2-3 flavors of agile. To begin with scrum, XP, agileRUP, would be good enough in my opinion. The purpose of understanding these is to get to know the 'culture & environment' when a particular approach is followed. The culture & environment plays key role to change the style of testing in agile projects.
In upcoming series I will cover more about -
I will expand this as I move further...
To end this today, I will say that - testing spirit remains unhurt in agile; it is just expressed in different way.
I will begin with testing as a task in agile projects.
Agile projects function such that the agile manifesto is followed. The manifesto indicates that there is value in process, contracts, planning, etc. however, it advocates people, team and core work (of building product) over these.
People sometime do take undue benefit of this and call process-less or chaotic way of working as "agile".
It is recommended that novice reads the myths along with the manifesto.
Few links to understand myths -
http://www.theappgap.com/exploring-ten-myths-about-agile-development.html
http://stackoverflow.com/questions/1871110/agile-myths-and-misconceptions
Naturally testing as a task - "should retain" its basics even while working on agile projects. Writing test cases, reporting defects, conducting RCA, Defect Prevention, metrics, etc have its value addition in agile projects. The difference is just enough & context specific application of these concepts. It is the 'team' that decides what is needed & not a uniform governing process document or a manager / testing head like authority.
One needs to understand about 2-3 flavors of agile. To begin with scrum, XP, agileRUP, would be good enough in my opinion. The purpose of understanding these is to get to know the 'culture & environment' when a particular approach is followed. The culture & environment plays key role to change the style of testing in agile projects.
In upcoming series I will cover more about -
- Test Story Point - how story point can be made a test story point.
- Useful web sites, books, etc on agile testing.
- Testing metrics in agile projects.
- Some open source tools that might be useful.
I will expand this as I move further...
To end this today, I will say that - testing spirit remains unhurt in agile; it is just expressed in different way.
