Safety, Testing and Self-Driving Cars

Tesla S Autopilot [Photo credit: Marco Verch, used under CC BY 2.0]

Any system where erroneous behaviour can lead to serious injury or a potential loss of life is classified as a safety critical system. This is true for self-driving or autonomous vehicles where a vehicle malfunction can lead to the injury or death of the driver, passengers or others outside the vehicle. The potential for injury or death is why it is paramount that the developers of self driving vehicles ensure the systems works safely before deploying them to users on public roads. In the field of self-driving vehicles, it is not clear if this best practice is always being followed. While self-driving vehicles are testing extensively using computer simulation and closed circuit test tracks, they are also tested on public roads. For example, driver assistance systems like Tesla’s Autopilot have been beta-tested by real users. Fully autonomous vehicles such as Uber’s self-driving car have also been tested outside of controlled settings on public roads. In cases where testing occurs in public, the vehicle-under-test is surrounded by pedestrians and drivers who may be completely unaware that their interaction is helping to test and improve an autonomous vehicle. This was the case on March 18, 2018, in Tempe, Arizona when Uber’s self-driving car, with a human driver present, hit and killed a pedestrian (see SFGate).

Continue reading

Automating Software Development Using Artificial Intelligence

This week I gave a research seminar at Dalhousie University and at Mount Allison University on “Automating Software Development Using Artificial Intelligence (AI).” The intersection of AI and Software Engineering is an active research area and has lead to a number of effective and novel applications of machine learning, metaheuristic algorithms and deep learning. Many of these applications of AI to software development can be categorized as:

  1. Automation of software development activities including the creation of software artifacts (e.g., software test generation)
  2. Recommendation systems to assist software developers improve their performance (e.g., recommended code for review)

Not all Software Engineering research problems can be suitably addressed by AI techniques. A good first step to determine if a given software development problem can be addressed with AI is to see if it can be re-framed in terms of optimization, classification, prediction, etc. That is, can it be re-framed in terms of the type of problems that AI methods are effective at solving?

To find out more about the Software Quality Research Lab‘s work in this area please see the abstract and slides from my talk below. Continue reading

Adaptive Serious Games for Computer Science Education

PhD student and SQR Lab member Michael Miljanovic was selected as a finalist in the  2017 Three Minute Thesis (3MT) competition at UOIT. Michael’s 3MT talk discussed his PhD research into the use of adaptive serious games to improve Computer Science education. The goal of his research is to adapt games to an individual player in an effort to improve learning and engagement.

Predicting Mutation Scores

Last week my MSc student, Kevin Jalbert, presented his early thesis results at the Workshop on Realizing Artificial Intelligence Synergies in Software Engineering (RAISE 2012). The workshop took place in Zurich Switzerland and was colocated with ICSE 2012. The title of the presentation (and the paper that appears in the proceedings) was “Predicting Mutation Score Using Source Code and Test Suite Metrics.” The paper was awarded the Best Paper Award at the workshop.

Mutation testing can be used to evaluate the effectiveness of test suites and can also be used as an oracle during the creation or improvement of test suites. Mutation testing works by creating many versions of a program each with a single syntactic fault. These program versions are created using mutation operators which are based on an existing fault taxonomy (i.e., a set of known fault types that we are trying to find during testing). One mutation operator, Relational Operator Replacement (ROR), could create a new mutant version of the program in which one of the instance of a relational operator (e.g., <) is replaced with a different operator. For example, line 3 of the following Java source  code: Continue reading