When it comes to any transition / migration / organizational change, there is significant amount of unlearning that needs to happen. Most teams that are trying to move from their traditional approaches of software development to the newer AGILE ones are also bound to accept the fact that they won’t be able to adapt perfectly to AGILE unless they are ready to unlearn.
Change is good but is not easy. And unlearning is exactly the reason that makes it so difficult. People are so used to doing things the way they are doing that it becomes very difficult to convince them to change their practices. And it’s not just one team that is involved when it comes to AGILE software development. There are plethora of them who are directly / indirectly involved in the process of software development and delivery. And each has to change itself to adapt to the required changes.
The task is to change the traditional mindset and objective is to un-learn some of the testing team’s practices. Here are some tips to unlearn what you might have learn in traditional approaches –
Quality of the code:
Code quality, in traditional approaches, was never a concern for the test teams. They only bothered about doing the black box testing and validating weather the application performed the functionalities that it was expected to. In AGILE, the testing teams are expected to not just test the app but also help the development teams proactively to debug issues. Thus the approach has now moved from testing to software improvement now. Now the testers go to the code level to identify design level issues while validating functionalities and thus the app.
AGILE managers go for minimum documentation and only the most required ones. Details of most documents as required in the development cycle are clubbed in one to save time of many persons and teams. Hence the test approach and test strategy, in AGILE, is advised to be documented in release plan. Moreover, most teams are minimizing the test teams and the role of test managers is also being clubbed with that of the project manager who maintains the documents.
Test case updates:
In traditional approaches, an identification of a new test case during execution never resulted into documentation of the same for obvious reasons of approval requests. The documents were kind of sealed in the planning phase and teams were asked never to change / update those. AGILE approach resolved this problem by giving liberty and agility to the testers to permit them to update the documents and inform about the changes to the teams whenever they want (during the development cycle). This liberty not only empowered the team but also helped them create a better document (which would be more helpful for future teams to refer).
Phases in testing cycle:
Traditional approaches emphasized people and teams to follow processes and standards. It advised to test the code as per a definite cycle and never to move out of the planned phases. Plan, Schedule, Execute, Complete were the phases followed during testing. Though similar phases are followed in AGILE the dependence of one over the other is completely removed and in AGILE, one can be testing a defect and planning (discussing) for another defect at the same time.
Traditional approaches demanded creation of automation test framework since it was a part of standard followed by the models that the teams had adopted. Many-a-times the frameworks which used to be created for regressions, used to fail in next releases due to design changes (every release being spaced by a considerable amount of time > 3 months). In case of AGILE though, going for automation is optional and the approach is opted only in-case of regression testing. Also since the team follow data driven approach, the test approach always is very AGILE and how the team wants it. In many teams, developers themselves are responsible for testing and following peer testing approach. This also makes them multi-skilled which is another target of AGILE teams.
Performance & other non-functional testing:
In traditional approaches, performance testing always remained a part in the testing cycle and usually at the end part of testing cycle (just before UAT). Like other areas of testing, Non-functional testing is also made a continuous ongoing task. However since the performance testing activity requires a lot of data setup and other (pre-test) requirements, its sprints are not planned to overlap with the development sprints but the performance testing follows its own sprint model in which the app is testing for its performance in regressions.