Testing teams and their managers need to unlearn the traditional mindset and practices when they want to adopt an agile way of working says Navneet Goyal. At the International Conference on Software QA and Testing on Embedded Systems he gave a talk about how test teams should adapt themselves in agile projects.
InfoQ interviewed Navneet about the differences in testing between waterfall and agile, the challenges of agile QA teams, the importance of unlearning when becoming agile and the Definition of Done for agile testing.
InfoQ: What are the main differences in testing in agile projects when compared to waterfall projects?
Navneet: There are several key differences between the agile methodology and waterfall methodology, which are:
- Agile uses iterations, waterfall uses stages. The agile process uses short iterations, known as “sprints”, which generally last between 3 and 4 weeks. The requirements are confirmed, system is developed and tested, and released during this iteration, and the next one begins. With the waterfall process, the requirements are all set at the start, and then the next stage begins
- Agile has constant business interaction; waterfall has varied high and low interaction (high during requirements and user testing, low during development and system testing)
- Agile roles are different to waterfall roles. Agile has a role called a Scrum Master, which is a kind of project manager and release manager, and may not be an IT person. Waterfall has a traditional project manager, which is almost always an IT person in the traditional sense.
- Once a stage is finished with waterfall, you can’t go back. If you’ve finished the requirements phase and obtained signoff from the business users, the requirements phase is over. There is no going back – unless a change process is followed which can take time. With agile, if requirements need to change, they are better handled with this process.
InfoQ: Can you name some of the challenges that an organization can face when they want to transition a "traditional" QA team to become an agile QA team?
Navneet: Introducing a new software development methodology has its own set of challenges which might range from ‘reluctance to change’ to ‘faulty adoption techniques thus resulting in a failure.
Transitioning the traditional QA team to an agile QA team is a critical task for the management.
Most of the companies interested in agile are those which have many years of experience in traditional methodologies. For moving to agile methods, they should confront with barriers and hindrances. Some challenges are related to organizational culture and management style.
People in traditional methods have pre-defined and strict roles and are controlled directly, but in agile, teams are self-organized and individual oriented.
Generally in companies, organizational culture puts significant influence on innovative practices, social negotiations, problem solving strategies, decision-making processes and planning and control mechanism. To transforming from traditional to agile methods, management style should be changed from “command and control” to “leadership and collaboration”. It could be facilitated by a right blend of cooperation and autonomy. The role of project manager should be altered from planner and controller to director and coordinator. In fact he/she should coordinate the collaborative efforts of team members. It is “inability to change organizational culture” which is a major barrier to agile adoption by over half the participants.
Other challenges are related to team members where because of human nature of resistance for any new thing, some veteran team members create obstacles while implementing new agile practices in teams.
InfoQ: You mentioned that unlearning is key to become agile. Can you elaborate why?
Navneet: A traditional QA is following certain standards and processes from many years, maybe for decades. Change is inherently difficult and uncomfortable, especially for veteran team members who have a long history of waterfall successes to look back on. It’s the human mind which mainly creates obstacles while learning new things. Its old things that we have learnt in the past which restricts us from learning new things.
So before starting to new learning journey, it is always important to unlearn something which may create conflicts in our mind, and create new space in our mind for learning new things.
As rightly said, "He who knows to unlearn, learns best.”
InfoQ: Can you give some examples what testers need to unlearn when transitioning to agile?
Navneet: The following are some of the key aspects that need to be unlearned before attempting to deploy Agile practices, from a QA perspective:
- The testing team needs to be independent and independently empowered in order to be effective.
- Without a separate test strategy and test plan, it's tough to manage testing.
- The V-model for verification and validation cannot be applied in an Agile sprint.
- Independent testing teams don't do white-box testing.
- The value of testing is realized only when defects are logged.
- Automation is optional and is required only when regression testing is needed.
- Testing nonfunctional aspects, such as performance of the system, is not possible in a sprint.
- Testing must follow planning, specification, execution, and completion sequentially.
- We don't have to write new test cases for detected defects.
- Poorly written code is not the testing team's focus, as long as the code addresses the required functionality.
InfoQ: You presented the learning agile quadrants which gives an overview of the testing that is required before a user story or feature is considered to be done. Can you explain the different quadrants?
(Image from the book Agile Testing: A Practical Guide for Testers and Agile Teams - Addison-Wesley 2009 by Lisa Crispin and Janet Gregory)
Navneet: A user story or a feature is considered ‘Done’ when apart from design and development; it has been tested in all four quadrants. The quadrants help to ensure that the team is supported and at the same time product is also critiqued. They also help to ensure that the product meets business as well as technology requirements.
Q1: Technology facing tests that support the team
The tests which fall in Quadrant1 include unit tests and component tests. These tests help ensure that the quality is built inside product and provide the basis for good design.
Agile techniques such as TDD, FDD, etc. come under Q1 tests. Usually developers perform these tests.
Q2: Business facing tests that support the team
Functional tests, story tests are some of the tests included in Quadrant2. These tests drive development with customer or business facing tests. Requirements from customers are captured in the form of executable examples which help developers in coding from customer point of view.
Specification by Example, Pair Testing is some of the agile testing methods followed in Q2. Programmers in collaboration with testers and customers carry out Q2 tests.
Q3: Business facing tests that critique the product
Exploratory tests, User acceptance tests (Alpha and Beta) which evaluate product from customer needs fall under Quadrant3 tests. These tests are carried out under realistic conditions and provide immediate feedback. Test execution fosters learning and new tests design (exploratory testing). Q3 tests are carried out normally by end users.
Q4: Technology facing tests that critique the product
Quadrant4 includes technical tests that analyze and evaluate the product. Non-functional tests such as scalability, stability, reliability, maintainability, interoperability, compatibility, and so on fall under this category. Other tests include performance tests, load and stress tests, security and recovery tests. The importance of these tests depends upon the customer and software to be developed and may be carried out at any stage. Special tools and skills are required to run these tests.
InfoQ: For testers to become agile, what do you think is most important: Deploying an agile process or applying agile practices? Why?
Navneet: In my opinion, both are equally important. These both things works parallel and not in isolation. Provide proper training and coaching to team members for agile practices.
Then deploy agile process in your SDLC and keep following agile practices.
