Best Practices for Testing Process in Scrum
I am always struggling to put Test process in Scrum. What is the best practices for Testing Process to put in Scrum framework ?
1) Unit Test
2) Regression Test
3) Functional Test
4) Integration Test
Scrum doesn't say anything about testing because it's "a framework for developing, delivering, and sustaining complex products". It transcends the type of product that you are developing, and what types of testing you need to do and how testing fits into the process is different for producing different types of products.
Even when the product is a software product, how you incorporate testing is different. For example, I've worked in regulated industries - aerospace and pharmaceutical. In order to maintain compliance with regulations, there are rules put around testing. You can use Scrum and be in compliance with the required regulations. However, if you did not need to maintain compliance, you may not want your testing to look like it does for a team or organization that does need to maintain compliance.
So, consider the Scrum Guide. It says that you have a Definition of Done for every Product Backlog Item and Increment. In order for a Product Backlog Item to be done, what kinds of testing must be performed? In order to an Increment to be done and potentially releasable, what kinds of testing must be performed? Given a Sprint cadence, how do you fit the required test design, development, and execution into your Sprint cycle? The answers are going to vary widely.
This is one of the challenges I faced when I transitioned my project from the waterfall model to Scrum. The test team did not want to write test cases unless the team have the output, and by the time Dev has an output worth testing, it is too late in the scrum to start testing.
We tackled the issue by:
Breaking each selected product backlog item into many small subtasks which can be delivered and tested.
Taking the help of testing team during integration testing itself, so that they can identify potential issues in advance. To do this, the testing team starts writing test cases based on each subtask, which will fail if the outcome is not met. This, in turn, gives the development team an advance notification of a potential issue.
Now, my testing team helps dev team during the integration testing and they test each sub-story deployed in test environments, which helps us to wrap up the testing before the sprint review meeting.
I will not say the transition was easy, but at the end, it was worth it.
Why is testing and development handled by different teams? Why separate these skills out?
Testing should be factored during sprint cycle.
As per definition Development team are cross functional team and they should be able to test the solution, during the sprint cycle.
As per Ian question, Development team should have the necessary skills to turn Sprint Backlog into a releasable increment at the end of the sprint that meet the Scrum Team Definition of DONE, all type of testing that are require to produce such increment should be included in the Scrum Team Definition of DONE such Unit Testing, Regression Testing, Functional Testing, Integration Testing (Automation Testing). Although this may varies from team to team which means team with less experience may require Testers to be included in the team. This type of practice will give development team capability to practice how to write different type test
In my experience, in large and complex projects, when we demand a high level of quality, even leaving aside the tests required by regulations, we generally generate a large number of tests in which We invest a lot of effort to meet the requirements, which surely leads to delays or low value delivery due to the high consumption of the team capacity.
In most cases, we put more effort into the test development than in the development of the value / feature.
Is there any way or method to manage or balance this situation?
I remember my previous development director doing a scrum session with the teams.
He made us (Devs and QA) write the different things that (1) developer and (2) QA do in every sprint on post-it notes and paste on a white board. He then ask us to remove which we think should be done by both Developer and QA.
After the session, there was only 1 note left, coding.
All other aspects we wrote down (e.g. Testing, clarifying requirements, documenting features or discussing items) can be done by both Devs and QA.
If your QAs are the only ones doing testing, it will be a bottleneck at some point in the sprint.