How to increase Team Velocity by 50% I

How would you like to increase your team’s velocity by 50%? Well, I was able to accomplish such a feat as the capstone to my last internship. It took a lot of help from the team I was on, and a lot of support from the Team Lead. But we implemented a system that increased our velocity by 50% in roughly a month. Our tale begins with the database access team, working with Entity Framework. I had just arrived. I was learning C#, Integration Test practices, and other new technologies as fast as I could.  I was shadowing the team’s current tester to learn the ropes, and contributing where I could. Even with two of testers, the developers often need to wait for the us to catch up, up to an iteration after them. Moreover, released entities are later discovered to have inadequate test coverage, or undesirable behaviors. The idea hit me one day when I was literally copying and pasting tests, and then replacing class names. I admit this was a poor habit, but I was endeavoring to keep up with the team. What I realized was a great number of our tests were of the same type. This kind of property gets that battery of tests, that kind gets a different set. Thanks to recent lessons in T4 templates, I realized we needed to generate the correct battery of tests for the entities in a programmatic way. I tried to compile a set of known test scenarios. Then I enumerated the entities we’d produced or modified in the last PSI that matched the set I wrote. These data sets provided a good coverage. But I needed a place to store that information for all the entities, and the templates had to be able to read it. I experimented a bit and found that, with some C# code, the templates were able to read the a database. The database tables would represent a single entity. The rows would represent the properties. They could even store boundary conditions! Then a master table would control what entities would have tests generated. The master table could also present the relationships between entities. But this was too big a task for me. I needed help, so I brought my idea and some of my findings to my team lead. She called a small meeting between myself, the other tester, and the architect. I explained my idea, and showed them some of what I’d done. After a lot of discussion, the team lead decided that it was a worthwhile project. She then set about getting the team ahead of schedule. This was we could put a month into the new project, and not be behind. Meanwhile she had me setup the core of the system and a scaffold to make sure we could delegate work. Additionally we spent a lot of time polishing the format of the generated tests. By the end of that month we were ready to start making our team faster! With a  moment of inspiration, and the support of the team lead, my plan to put in place a system to generate our tests was ready to begin. In my next post I will discuss more of the implementation details. The various discoveries that occurred while the team worked on the project will also come up. In the end, we easily achieved a 50% increase in our team velocity!