Testing the innovation funding service

Published

October 27, 2017

Jessica ‐ Head of Creative Services

In this post, Head of Creative Services, Jessica Cullen, sits down with Eftychia Thomaidou to explore the world of testing at Worth. Robot Framework, Python Code, Github, Innovation Funding Service and working at WORTH.

JC : TELL ME A BIT ABOUT YOURSELF EFTYCHIA: HOW LONG HAVE YOU BEEN AT WORTH?

I have been at Worth since August 2015 and consider myself to be an all-round developer. This is because I not only have experience in backend development, which I compliment with my work as a tester, but I also try to learn as much as I can about different programming languages and to develop my skills further. I continually challenge myself to create new things.

JC : WHERE DID YOU GO TO SCHOOL / WHAT DID YOU STUDY?

My bachelor’s degree is in IT and business management, which I obtained in Greece, and I also completed a master’s degree in Bioinformatics at the Delft University of Technology. My studies combined computer science with biology, so my background, like my experience, and my approach to development, is also multifaceted.

JC : THAT IS QUITE A DIVERSE BACKGROUND, WHAT BROUGHT YOU TO WORTH? AND WHAT DO YOU DO HERE?

I find myself at Worth, because I guess you could say I was headhunted. Although I joined as a backend developer, I am currently a tester; however, I test from a developer’s perspective. I find I really enjoy interacting with customers and working alongside them to build things that have immediate impact on their work. As a tester for the IFS project, I interact a great deal with InnovateUK staff, and since I am quite social, I enjoy this.

JC : THAT LEADS ME TO MY NEXT QUESTION: YOU HAVE BEEN HEAVILY INVOLVED IN THE INNOVATION FUNDING SERVICE PROJECT, WHICH IS QUITE A SIGNIFICANT DIGITAL TRANSFORMATION. CAN YOU TELL ME A LITTLE BIT ABOUT THAT?

The Innovation Funding Service (IFS) project team is a pretty large one so from that you can imagine the size and the significance of the project itself. IFS is an initiative of InnovateUK which enables UK businesses and research organisations collaborate in their applications for grant funding, and at the same time, it also helps InnovateUK’s personnel create competitions, and facilitates easy assessment and communication with applicants.

To get an idea of how complicated this project is, try to imagine a day working on a project that is continuously developing. Pull requests are constantly being merged by our large team of developers, and the program’s functionality is constantly expanding and improving. We need to ensure that what is being build works as expected, and what is already built still functions. At the same time, security and performance are crucial. Therefore, the importance of testing the IFS project cannot be underestimated.

JC : IFS IS OPEN SOURCE. CAN YOU EXPAND ON WHAT THAT MEANS FOR YOU, AND HOW THAT AFFECTS THIS PROJECT?

In my opinion, when you write code for a project, you can choose to release it to anyone, even people who do not have direct involvement with the project. These individuals--expert developers--then contribute to and enhance the quality of the code, to the continual benefit of the project. In my experience, everybody has a different point of view, and thinks differently, so the work is actually made more robust.

JC : WHY DO YOU THINK THE IFS PROJECT HAS BEEN SO REVOLUTIONARY?

To begin with, we have facilitated the transition from a paper-based system to a digital system, but we have also made it possible for a wide-variety of people, even people with disabilities, to participate in research applications by building a user-friendly website. This helps them access funding that is relevant to their ambitions. This also makes it easy for different sectors to collaborate within any given application, and ensures that both assessment of these applications and correspondence with applicants, is much more efficient.

The IFS project is not only revolutionary from a user’s point of view, but also from a developer’s perspective. That is because we are a large team and we peer review each other’s code every day to ensure quality. Additionally, we practice continuous delivery, which means that our code is deployed to production and is actively utilised. This factor makes us especially careful of what we are about to deliver. Because we work this way, we can adhere to UK Government Digital Standards and requirements with every delivery.

JC : SPEAKING FROM A TESTER’S PERSPECTIVE, CAN YOU OUTLINE THE STRATEGY AND APPROACH TO THE WORK FOR IFS? WHAT KIND OF TESTS ARE IN PLACE?

As you can imagine, we have many different testing strategies and they are used on a daily basis and at different stages, namely:

  • Unit Tests: are automated tests written by the backend developers in the java code to test the smallest testable parts of the application
  • Manual Tests: verify that what is built satisfies the Acceptance Criteria. In our daily manual testing we include ZAP in order to double check that all the requests amend the intended values
  • Smoke Testing: is manual testing, which is completed after large deploys. At this point, we do not focus on a single aspect, but instead verify that everything is in place and working
  • Accessibility Testing: usually done by the front-end developers, and it also includes the use of Screen readers.
  • Performance Testing & Security Testing: these also play a significant role in our testing process.
  • User Testing: is done by a group of people who are not directly involved with the project. Some individuals in this group might have special needs like restricted vision, or have an old version of Windows computer, or be accessing the site from a mobile device. Alongside our User Experience designers, these individuals test and “travel” through the whole journey and provide feedback
  • Acceptance Testing: is the means by which we evaluate that the software we build meets the client's needs and assess whether it is acceptable for delivery. Acceptance tests serve as a verification that the implemented functionality meets business requirements, and simulate the end user’s interactions across the IFS platform. There is a sensitive line that we need to draw here, as we are trying to use the minimum amount of code in order to comprehensively cover functionality (all the actions that a user undertakes, as well as both the financial values being generated, and the queries to the database).

JC : HOW ARE ACCEPTANCE TESTS APPLICABLE TO YOUR WORK FOR IFS?

In a project like IFS, where we are improving functionality every day, it is crucial that we automate testing. And when I say every day, I literally mean every single day, because our work is constantly being evaluated either by the client or by the user testing group. Meanwhile, the Government Digital Service (GDS) guide style (external) gets improved and we must be up-to-date.

Automating Acceptance Testing ensures:

  • Development of a robust system
  • Prevention of human error
  • Additional verification
  • Detection of flaws

The more immediately you identify issues in your system, the more efficiently they are addressed and this ultimately leads to a more secure project.

So, one of the most important parts of my tasks is to write/amend acceptance tests. For the IFS project we have used automated Acceptance Tests, written with Robot Framework. If you would like more details this, check out the Python Code included in the Postscript of this blog.

JC : WHAT IS ROBOT FRAMEWORK AND HOW HAVE YOU ENHANCED IT FOR THE IFS PROJECT?

Robot Framework is a generic test automation framework that is pretty easy to grasp, even if you are not a developer. This is due to its simple syntax. Behind the scenes, all the code we write is parsed by Robot Framework and executed as Python Code. Robot Framework has its own Integrated Development Environment that is called RIDE and is also quite easy to use. However, on the IFS project, we prefer to use IntelliJ as we keep our code in the same repository as the Java Code. In order to make your IntelliJ behave like RIDE, there are some plugins you might wish to install. These plugins include: IntelliBot and Robot Framework Support.

As with almost every other framework, Robot Framework is a generic tool that of course has some limitations and requires some additional customization to meet an individual project’s needs.

In our case, we have written some small scripts in Python in order to extend the functionality of our code. If you would like to check these out, click postscript for some examples and explanation.

POSTSCRIPT: A GLIMPSE INTO THE PYTHON CODE AND ROBOT FRAMEWORK WE USE FOR IFS

For the Innovation Funding Service project, we use Python to:

Read a csv file. When a user has provided all his financial information, we convert this into a csv file for governmental employees archive. We use Robot Framework to verify that the content of the generated file is the same with that of the user’s input. Since reading a csv file is not provided out of the box by Robot Framework, we:

import csv

def read_csv_file(csv_file_name):
 f = open(csv_file_name, 'r')
 csv_file = csv.reader(f)
 csv_data = []
 for row in csv_file:
   csv_data.append(row)
 f.close()
 return csv_data

To exit the tests on demand instead of waiting for a suite to finish. This is very useful for debugging your code, or to continue with manual testing after actions have been completed.

import sys

def exit_tests():
   sys.exit();

Here, the keyword exit tests does not anticipate any argument and can be used at any point inside a test case, to terminate the execution of tests.

You have probably have noticed that the Python code contains a lot of underscores, while in Robot Framework they are rarely used. Robot Framework turns the spaces in robot test cases into underscores before the execution of the Python code. This way, the above defined function read_csv_file can be used as a keyword named read csv file in Robot Framework, which expects one argument.

For example: ${contents} = read csv file ${DOWNLOAD_FOLDER}/name_Of_File.csv

In another example we are using Python to query the MySql database. As you could perhaps imagine on the IFS project, we have many applicants that they visit their application(s) on one or more competitions. Thus, a url on our platform would look like:

https://domain/application/ ~or~ https://domain/competition/

In Robot Framework, we often use these urls to simulate the action of a user visiting a direct link. However, in a Continuous Delivery project like IFS, this approach is problematic. Every time we generate extra Testing Data, IDs change! In order to overcome this issue, we create an array with Python that uses the titles of an application as indexes and returns their ID. This is similarly done for competitions. Now this array is imported in the global variables of our tests and can be used everywhere. The reason that we query the database at the beginning of the execution and not within the test cases is in order to minimize the execution time of the tests.

Following, is this piece of code:

config = ''

# configure the database connection
def connectToDb():


   # Open database connection
   db = pymysql.connect(**config)

   # prepare a cursor object using cursor() method
   cursor = db.cursor()

   return db, cursor

db, cursor = connectToDb()

# execute SQL query using execute() method, to fetch the Competitions
cursor.execute("SELECT `id`,`name` FROM competition")

# Fetch all application records and add them in an array
# The array will look like [application Id, application Name]
# Like this we will be able to retrieve the id by using the name as index
application_ids = {}
for app in cursor.fetchall():
   applicationId = app[0]
   applicationName = app[1]
   application_ids[applicationName] = str(applicationId)

# disconnect from server
cursor.close()
db.close()

If you are interested in more examples of our code, view our work on: Github.

Get in touch

We'd love to hear
from you

This field is required
This field is requiredThe email address is invalid.
You must consent to the Privacy Policy

Thank you

We will get back to you as soon as we can.