Arrk’s Radical Transition Towards Test Automation

“We have to move towards automated testing really, really quick!”

In the early days of our adoption of automated testing, this was the clarion call that rang within Arrk that got us starting a program in earnest. This story explains how we went about making a success of it.

Some time ago, as with many organisations, Arrk Group’s main testing focus was on manual activities. However, we quickly realised the benefits of automating areas where automated functional testing would provide significant advantages.

To break down the wall between manual and automated testers, we set-off with a transformation programme called ‘Manual2Auto’ which covered structured training, self-learning, collaborating and climaxing towards teams delivering mini-projects. At Arrk, experiential learning forms the core of any programme which is catalysed by challenging goals to extract the best from the individuals and teams.

The big mission upfront for all testers was to “learn to code” or even “don’t fear to code”. We were aware that not all testers like to code or they became testers in the first place because they did not want to code. This mindset needed to be both understood and corrected if Manual2Auto had to succeed. When the program was rolled out, we carefully reasoned that given the demands of the time, the aversion to programming/scripting or being misfits would not only impact Arrk but also hurt the tester cause. We allegorically urged them to discard the saw in favour of a chainsaw. The testers saw it and understood that learning to be friendly with Java was way better than being a relic in the testing museum.

We started the program by reviewing the composition of the team, mindset, and technical competence levels, to ensure the transition to automation competent test engineers. We customised the Dreyfus Model to create our own categorisation levels for test automation. We set Manual2Auto goals for the team to move up the chain. We used gamification to get the competitive juices flowing along with the lure of rewards for the high-achievers.

We had the team divided into focus groups for two languages which are commonly used across projects at Arrk; Java and Ruby. We formed a dedicated trainer group comprising champion testers (having sound technical knowledge) and the Guruji Group (comprising passionate senior development personnel willing to impart technical skills within testers). The Champions and the Guruji’s conducted several sessions on pseudo-code programming, OOPs concepts and language specific aspects. These sessions required the team to invest in self-study, assignments and presentations.

Formal in-depth training was also conducted on Java and Ruby by external expert trainers. The Guruji Group played a pivotal role in customising the training content and in the selection of the trainers. Both the internal and external training were followed by tests to evaluate the progress in the respective learning groups. These tests amply communicated to the testers where each one stood individually and vis-à-vis the automation objectives. The scores were never intended nor used to beat up anyone. We had a periodic catch-up and pep-talk sessions to inform and focus the team. We made use of the gamification points ranks to highlight the stand-out performers from the rest.

After the success of Phase-1, we started Phase-2 with gusto intended to consolidate and implement the learning and skills acquired. We formed multiple work-streams for the purpose. All the work streams had reasonably steep testing-come-technical objectives, to assuage project demands/problems and serve future needs. For example, we formed work streams focused on:

  • Designing automation approach for a multilingual website
  • Optimising a very large but bloated automation suite
  • Developing a mobile automation framework
  • Presenting Groovy’s capabilities
  • Demonstrating capabilities on security testing e.g. OWASP, tools
  • Development of a mobile app to track happiness quotient of Arrkitects

The mini-projects symbolised a rallying conscience call for the tester-teams to achieve what they had never thought they will be involved with, leave alone achieve given that these were technical work-streams and most were resigned to think they will be manual testers for the rest of their lives. But the initiative took root and spread, quite rapidly. The testers conferred with the technical experts about database design, technical nuances, got them to review code and so on. The techies were only keen to help since the testers were, for a change, interacting on a level playing field. The blossoming interactions indirectly helped the relationships as well and mutual respect got strengthened along the way.

The work-streams were demonstrated to an audience comprising the testers, senior management and the Guruji Groups. The show-and-tell sessions were well-received and applauses filled the room at times. The mood was infectious, the feeling upbeat. Many testers were now well and truly on their way to being technical, quietly confident how to use a tool or a script to produce results faster and better.

Two Significant take-away’s from the Manual2Auto program

Khushi Mobile App – Testers turn developers

Khushi literally means happiness. Khushi Android app (iOS app in the works) is designed to pulse-check the happiness quotient of Arrk employees. Easy-to-use and administer, the app determines overall happiness and that in itself represents a significant input for Arrk. The mobile app may have been built by a few testers but is really a shining beacon to all Arrk testers of what can be achieved if you put your mind to it.

JavaScript Testing Framework

The work-stream was aimed towards study and analysis of open-source Javascript-based testing tools and frameworks. After detailed analysis, a framework was created based on Protractor (AngularJS framework) and Jasmine. The framework enabled quick functional and UI testing of Angular and non-Angular applications. The proof-of-concept done on an existing project established the fact that the framework indeed enabled quick automation.

Manual2Auto represented a breakthrough journey for testers befriending the machine more than they were used to. It provided an impetus for testers’ first-hand realisation of the benefits of technical learning and the outcomes they can help generate. At another level, many testers also demolished a few demons in their minds to transform themselves into more confident, superior, efficient beings. We would call Manual2Auto a successful initiative but the joy of learning will carry on.

Share this article








Submit
Originally Published:

Authors

and