As Agile gets larger acceptance across the industry, the (manual) testing community has been concerned about how it will impact them. They hear about developers doing testing, test automation and hence wonder – what role am I going to be play? Is this going to kill my job? The concern is natural given a general perception that in Agile, developers should be doing testing. This concern has been part of the resistance that some of the organizations are facing in adopting Agile thinking.
This concern is misplaced and if anything, Agile thinking only makes the Tester more central to the teams. Fact is that developers were always supposed to test their own code! It’s a different matter that this was not happening, and when it did, generally not with the right spirit. Agile makes this even more imperative – you cannot be truly Agile without developers doing testing and automating it on a continual basis. Of course, if you can do Test (First) Driven development, you would have addressed the long term challenge of “Test Coverage” (a topic for another day)!
Development and Testing: Ne’er the Twain Shall Meet!
Coming back to the topic, let us understand why development and testing was split traditionally. We all grew in the industry being told that developers and Testers had to be separated for the following reasons:
- Reason 1: How can the developer be trusted to tested his own code? He/she would always pass his/her code!
- Reason 2: If the developer has understood the functionality wrong, he/she will build it wrong and he will test it wrong, even if he tests with utmost sincerity.
- Reason 3: testing needs special skills. The ability to write boundary value test conditions, negative test cases, do test data planning, compliance to various standards (UI, navigation, etc.), complex functional test scenarios were not exactly a developer’s core competency or his area of interest.
Test Automation: Nice to Have…
Test Automation was always an optional practice – good to have but too expensive to maintain. Focus used to be largely on automating functional test cases. These would break frequently because of changes in the UI. Newer approaches like keyword based test automation addressed this problem, but it still was an expensive process. It needed a lot of effort, took long execution time, took a lot of hardware resources and needed high maintenance.
The Agile Approach
Agile thinking, with some of the associated engineering practices, makes some fundamental changes:
- Agile thinking puts the responsibility with the team – not with the managers! In other words, we are encouraged to trust the team. Interestingly, this way of execution actually works! This killed “Reason 1”.
- Agile thinking accepts that Requirements will never be accurately written or fully understood in one pass. It shifts focus to the developer sitting with the business or Product Owner and understanding the requirement, in a conversational process. It insists on small and early releases to the user and taking their feedback. This killed “Reason 2”.
Test Automation: With Test (First) Driven development (TDD) and with the correct implementation of the Testing Pyramid, Test Automation is faster and practical. Functional test automation is a small % of the total. Bulk of the test automation is at the unit level. It is extremely fast and has no dependence on the UI.
What Agile thinking has not changed is that testing still needs special skills (Reason 3). In fact, with the rapid evolution of technology, the demand for special testing skills has only increased over time.
Whither Manual Testing?
So, how does the role of Manual Tester change? It truly doesn’t. However, their skill profile and how they work in a team changes. Let us understand these:
- Early Involvement: testing was generally considered to be a late in the SDLC cycle activity. While some testers would start early test case development or test data planning, the bulk of the testing team members would join much later. With Agile thinking focus on continuous delivery, testers need to get involved early in the project life cycle, understand the business and be an integral part of the team. They are expected to almost become the “next level” domain experts!
- Understanding the business requirement: Gone are the days that someone will define Requirements in a Word document and that will be taken as the single/only version of the Requirement. Agile accepts that Requirements need to be discussed and understood in a manner of conversation with the user. Accordingly, the tester needs to participate in this requirement conversation, with the user or the product owner (whosoever is the requirement owner in the environment), understand the requirement and draft the functional test cases. Thus, the role graduates to the next level – from writing test cases based on a MS Word requirement document to actually participating in a discussion with the user, understanding the business requirement and then, writing the test cases.
- Accepting requirement change: Agile thinking accepts requirement change as a continuous process. Hence, test case drafting isn’t a one time activity. As requirements evolve from one iteration to another, test cases keep evolving. Testers need to accept it… not crib about it! Layering test cases in one of the possible approaches to address this.
- A different mindset: A tester’s responsibility is not just to find defects! His/her job is to improve the quality of what the team is delivering. A tester is part of the team that is delivering the scope in that iteration/value stream. A tester cannot be pointing fingers at the developer. If he/she sees that a developer is not clear about a functionality, he/she should clear it for them! A tester needs to think like the user… they are the closest to the functional user inside the team.
- Automate: A tester cannot be manually doing regression testing as the product functionality evolves from one iteration to the next. They have to automate, automate… and automate. Automate everything! A tester will have limited value to the team if he/she is not willing to learn and excel in any of test automation frameworks.
In summary, be rest assured that a tester’s job isn’t going away! If anything, they are now a central part of the team. They should act like one! They should excel in the domain… and drive the overall work product quality.