We spent some time on initial research. As time was short and lots of tasks were in the pipeline, we needed to find a creative way to integrate our solution within the existing resources. So we decided to start with a pilot with only one team member. We presented the initial direction to the rest of the team and started with the pilot team member. We built on our knowledge and made ourselves familiar with advanced topics in how to implement unit testing.
After a few weeks, we presented our pilot experience and what we learned, and we extended the pilot. After a few more weeks everyone joined, and as time went by, writing unit tests as part of the coding tasks became the de facto habit of every team member.
The next phase: System testing
Some time after adopting the concept of unit testing, we started to dream about having a framework for automatic testing for QA, which was a top need for the company. So we did some research and decided to go on a pilot with Cucumber. (Cucumber is a testing tool notable for being created with test-driven development techniques.) We started developing the infrastructure and built a pilot for one of the most important flows in our website. When this was done, we presented it to the QA manager, who was willing to give it a try and allocated one of her team members for the pilot.
There was a lot of passion about this automated testing system, and our belief in the benefits that automated testing would bring to the company really helped get the project off the ground. After the successful pilot phase, the QA team started building more tests scenarios. Now, any skepticism that might have existed about the efficacy of automated testing has vanished, and all QA engineers have gone through training sessions. Now, part of MyHeritage’s definition of “done” for each feature is beginning to include automated tests.
Creating a risk-free staging environment
Before, our staging environment worked with our production database, which was a huge risk to production.
Myself, our CTO and one of my talented team members worked on a plan to build a true staging environment that will not be able to access, even by mistake, the production environment. Our IT team also lent a hand, and we have now a real staging environment that allows in one click building new environments—copying complete data from the production environment—to apply DB schema changes and test them before they reach production, among other benefits.
Technical design phase
During some code reviews, we noticed that often some basic questions are left unanswered. How is QA going to test it? How is this solution going to be scaled up? We realized that major changes are required in the code to allow testing before it goes live, and that beyond this, significant changes are required to allow the solution to become as scalable as it needs to be.
Another thing we realized is that we don’t have a proper design phase where developers refer to the non-functional requirements in addition to the functional ones, get feedback from others, and add design-related documentation to the feature that is about to be developed.
So in one of the next features that we developed, we created a short document that presented the feature’s design. We discussed the design document with the team members and got feedback from them not only about the actual design, but also about instituting a process of designing features and getting feedback as a procedure for the team. Most team members were in favor of the idea of having such template, and we decided to give it a shot.