Let me start the blog with my experiences with few Agile projects during the Process Audit. The first answer for any question to show the process implementation, is undoubted “We are following Agile so process documentation is Not Applicable”. This was also one of the weirdest answers I received ever.
Another answer I received was “We work for Customers, whatever asked by Customers we will be doing only that”. Funny is it?
I am sure that in an organization every project following any methodology is striving towards “Meeting Customer Requirements”. Why is Agile alone not in the scope of Process Documentation?
I could say it is purely a misconception that Agile Methodology doesn’t follow the process documentation.
In Agile Testing, the first and foremost challenge is “Requirements will be ambiguous, not stable and changes to the requirements are very frequent”.
The second top challenge is “Test Execution cycles are multi-fold and flattened, so the team will have very less time to prepare Test Plan documentations”.
The last one is that the QC team will not have a detailed requirement document to estimate their effort for test case planning and execution. Also the same will undergo changes whenever the Developer or Business Analyst modifies the codes.
Considering all the above challenges, I would like to propose the minimal process documentation for agile projects blending with Traditional STLC approach.
Before moving on to the Process Documentation for Agile, Let us know why we need Documentation.
Avoids Dependency: Since the project rapidly changes the requirements, the core team will be fully deployed to enable the environment to meet the scope.
So the technology details or project knowledge will not be readily available for any future references. Hence it forces us into the situation of depending on Individuals.
Documentation would help the new team members to understand the project challenges. It helps to build the Communication Gap.
Every Organization Needs It: Documentation is very fundamental in all Clients dealing. Clients or Senior management would request for a documentation for their review or for any trade deals.
Documentation act as an Organization Data history which can be established or publicized during new customer acquisition to present them a case study.
To Justify: Many clients ask the question when he feels that the operation model or execution model is not clear to him “Can you share with me the Execution planning or Architectural document”.
At some point in time, the project manager should bring in the documentation part to prove the team’s efficiency by explaining the working time, approach, technology etc. Our Client is investing in us, so they want assurance that project will not go into risk.
Process Fusion for Agile with Traditional Testing Methodology
The traditional testing process has a proper STLC Top-Down process approach followed during the Test execution.
Normally Traditional method will be chosen when the requirements are stable and Clients are ready to adapt to the functions that they have decided.
Agile follows in an Iterative process approach. This method is chosen when the customer is not clear on what he wants to build.
Testing methods should be in a predictive manner to match the requirements. This is the major difference between Traditional and Agile Testing Methodology
Agile handles every project in a unique way. An overall requirement is to be broken down into parts and the verifications and validations are started.
They are of a particular build or feature and are successfully implemented. Requirement splits into parts are then categorized into Sprints.
Below are the classic Software Testing Process Lifecycle and Agile Testing Lifecycle
Proposed Fusion Model for Agile
The fusion of Agile and traditional method will definitely help the organization in meeting the process as well as product quality. This method emphasis not to skip any of the processes during agile mode, because the sprint cycle is kept iterative, where it can be tested all time till the project release.
Most importantly, the quality process documentations can be implemented while the client still updating or modifying his functionality.
There are few things we can address through this fusion model which will help both QC’s as well as Organization Process.
In Agile, the documentations are not expected comprehensively but expected to be sufficiently documented with detailed & consistent information.
In the above-listed deliverables, documents mentioned in “Italics” are already been part of Agile Cycle. The documents mentioned in “CAPITALS” are the additional process documents expected in the fusion model.
Business Overview & Approval document should be introduced during the “Requirement Gathering” phase.
Master Test Plan / Strategy & Release Plan should be introduced during “Test Planning” phase.
Test case Design & Review documents should be introduced during “Test Designing” phase.
In this fast developing world, the Technology is playing the major part and demands swift uplift in all product or project aspects.
Clients are also in a mindset that all current trends should be available and easy operable to users to make them stand in a market as a leader.
To support this, Software Testing firms, and other service oriented firms should come out of the Traditional Process thinking to deliver a Quality Product. It is indeed important that Fusion Model is necessary to handle both Delivery and Process implementation satisfied.
By Uma Raj
By Uma Raj
By Abishek Balakumar