Test Automation in a Modern Automotive Product Development

Part 1 of the blog series on Test Automation
Note: Test Automation covers several distinct areas of testing a product, and can entail anything where a test is completely or partially automated. The reasons for automating testing include e.g. increasing testing performance, minimizing human error and performing complex or cumbersome tests or measurements not feasible in manual testing. This article focuses on functional and regression testing, where the main target is to respond to the needs of modern software driven product development by increasing testing performance. The target here is not to completely replace manual testing, only the parts with most to gain.


Two disruptions that are ongoing in the modern automotive world are the ever-increasing role of software and the need to get product features out faster and closer to final integration. Software is understood as the enabler for rapid feature development and updates, without the need to change the actual car hardware or even bring the car in for service. This separates the software development and release timeline from the rest of the car’s development and integration timelines. So, software is more complex, it is expected to be able to provide new features quickly from planning to delivery, and work on an already designed hardware platform (“the car”). Still, as the end-product sold and its customer experience are a result of both car hardware and software working together, the expected rapid software development cycle cannot cut corners in testing compared to the more HW-oriented working modes.

Software Driven Product Development 

Software development in other product development areas has used Agile methods successfully – sometimes more, sometimes less – in shortening the long lead time development models. The main driver has been the inevitable changes identified during development, and the cost of setting things in stone early in the project. The later the plans need to be fixed, the better information the planners have about the final product they want to produce. In order to replicate the success seen in other software development areas with regards to speeding up the feature development cycle, the automotive industry is looking into ways of integrating Agile methods as part of automotive development.

There is much to like in software driven product development. The promises of a faster product cycle with low effort variants, faster feature development, later “feature freeze” deadlines, easy after sales updates and maintenance without servicing the car. However, unlike, e.g. consumer electronics, the automotive field has a much larger body of legal and quality related standards. Integrating the same methods will require considerable adaptation both in the methods and the mindset of the people working with the product development. Traditional testing models are based purely on the existing legal and quality standard framework of the automotive industry. As the new development models are adapted to fit the framework, but not all the traditions, new testing models must follow.

The primary conflict with traditional thinking in testing and new development models is having the testable product defined early in the project. If only we had the product requirements defined early, both product development and test automation development could proceed their own ways. Both would have their targets set, and both would target implementing the full requirements coverage of code and tests according (roughly) in the same schedule. Unfortunately, that is no longer possible. Both product development and test development must instead follow a short-term plan with a high-level overall picture of the final target, to allow all the benefits of e.g. Agile-style development. In such a project, changes are the new norm.

Lesson learned: Automated test development for agile-style projects requires close co-operation and communication between product development teams and test development. Going as far as having functional automated tests implemented by the product development teams themselves. Having separate teams handle product software and test development resulted in agile changes to product development only becoming visible once tests failed. Finally, new test development ground to a halt because all of the team’s effort was spent just tracking and reworking tests based on any changes to the product software. Testing cannot be ready in time to test the software, if it has to constantly play catch-up.

Test Interfaces

Small changes in product development constantly breaking automated tests highlight another aspect of test automation and agile-style development models. Traditional development emphasizes interface control in SW development to make sure any changes do not cause uncontrolled effects outside the modified components. As with all other changes, interface changes are more rapid and common. Control is still important, but its role is more communicative and less blocking.

Automated functional tests have several possible interfacing levels, for example, in the UI. Tests can interface with any combination of the actual display and control hardware (test robots), UI elements programmatically (cuTeDriver, Squish, Selenium) or via a lower level API. The higher the interaction level, the more completely the test system tests the full product stack, but also the more fragile the test system and tests are to any changes in the product UI. When working with multiple variants of the same product family, the harder it becomes to use the higher layers. When working with an unstable UI – colour themes, small changes requested by the customer, unfinished features and so on – test development on the highest level suffers. Capable manual testers can overcome such minor changes, but test automation very rarely can. Even when product development knows the limitations of test automation, trying to work with unstable test interfaces will incur a considerable risk and cost to the project. Both in testing and in development.

Lesson learned: Test automation lives or dies with the stability of the test interfaces. Finding the right balance for the test interface level is crucial. It should be as high as possible to cover as big part of the product as possible, but not too high to either prevent test automation sync to product development or stifle product development capability to respond rapidly to change needs. This interface decision needs to be part of the product development architecture and design work to provide the suitable interfaces for testing. Again something that needs to be considered when any changes’ impacts are analyzed.

Automated testing is now practically intertwined in the product architecture, design and implementation. Having a test development team separated from product development is not practical. It’s not important, how the work is organised. Tests can be implemented just as well by a dedicated test team members assigned to work closely with product teams, by dedicated test developers inside product teams or even the product developers themselves. The – critically – important part is planning and implementing tests and product code together.

Link Motion and Irdeto Join Forces to Provide Automobile OEM’s a Complete Security & Safety Technology Platform for New Lines of Connected and Autonomous Cars

Link Motion integrates Irdeto’s new smartphone-based secure vehicle access and safety solution, Keystone, into the Link Motion CarBrain platform. Automobile OEMs that implement Link Motion’s CarBrain will now provide consumers with the simplicity they expect to safely manage and operate today’s connected cars and autonomous vehicles, especially in new ride-sharing business models. From controlling the speed limit of the car, time of use, geolocation, trunk or glove box access, number of passengers in the vehicle and much more, car owners have the flexibility and freedom to customize their driving experience by enforcing vehicle usage policies.

“Traditional business models are rapidly changing with the development of the software-defined car and autonomous features,” said Pasi Nieminen, Vice President of Link Motion. “Most OEMs don’t want to source their technology offerings with multiple vendors, but rather integrate one technology platform that can deploy all offerings. By combining Keystone with CarBrain, we provide OEMs with a joint solution they want to ensure their product offerings keep up as OEM business models change. We also look forward to including these features in our own smart ride business as well.”

For further informaton, please read the full press release.

Cybersecurity in connected cars – how do consumers see the rising cybersecurity threats?

The year 2017 saw a steady increase in the number of cybersecurity incidents as well as initiatives aiming to counter threats. Consumers experienced the incidents largely as a nuisance when some operations discontinued. Organizations hit by the incidents experienced the same nuisance as downtime which translated into additional costs.

Developing regulatory actions against cyber attacks

Connected cars are increasingly complex computers on wheels, and valuable objects, thus very attractive targets for both publicity seeking groups and someone seeking to benefit from vulnerabilities. In the article on Forbes “Unsecured At Any Speed: The Cyber Risks Of The Connected Car”, it was suggested that taking all security into a level where it should be is an enormous and a current challenge.

“In US, Link Motion has been working with Irdeto to advance cybersecurity regulation

Regulators are tackling the problem where they see the biggest potential in doing so, in privacy, General Data Protection Regulation (GDPR) being a prime example of that. Private property protection covers cars, but it might not be best suited for cases, in which ransomware renders a car unusable for weeks. Regulators are also stepping up activities to protect their own operations and to respond to threats. In US, Link Motion has been working with Irdeto to advance cybersecurity regulation, “Irdeto and Link Motion about AV Start and SELF-DRIVE Acts”. In essence, regulation will increase the protection level and it will play an important role in making consumers aware of the security risks in the long run.

Taking a proactive approach to cybersecurity a key issue for companies

We see companies taking both passive and active strategies in cybersecurity, with a pendulum swinging towards a proactive planning. The advance of technologies and methodologies makes it easier to implement necessary measures with a shorter implementation span than before. Integration of information security and data security into R&D processes contribute to cybersecurity. Security of data needs to be of equal concern for developers, product designers and marketers. Developers thinking of data security shows that they are thinking of users’ interests.

The security bugs revealed in Intel processors are undoubtedly one of the widest spread incidents in 2017. Taking into account the extent of the breach and the number of impacted devices, the company seems to be walking out of the incident with dry feet. This is only possible because of Intel’s long-term commitment into security technology and careful management of the issue, being a prime example of how to handle serious cybersecurity incidents.

“The awareness of cybersecurity is rising fast. The addition of ever advancing features, such as artificial intelligence, remote control and payment, intensify discussion around the topic.

An outlook on the future trends

The awareness of cybersecurity is rising fast. Consumers will require protection against the latest cyber threats, and manufacturers are expected to provide adequate, up-to-date security protection.

The addition of ever advancing features, such as artificial intelligence, remote control and payment, intensify discussion around the topic.

Carmakers need to be well prepared to be able to act fast and mitigate problems in technical and non-technical fronts. The article on Financial Times “Self-driving cars raise fears over ‘weaponisation’” suggested that the lack of cybersecurity is becoming a big obstacle for self-driving cars, both because the lack of solutions and missing acceptance from general public.

Through-Stack Development in Automotive Systems

Introduction to Through-Stack Development (Part 1)

Building the connected carputers of today and tomorrow is no trivial thing. On one side you have great expectations on new features brought on by vehicles taking a digital leap, a push towards faster time-to-market and expected cost savings from integrating multiple systems into one. On the other hand you have automotive safety standards, increased complexity in the required solutions and a whole new level of security threats. A difficult equation.

The answer, as many companies are finding out, is to introduce isolation measures to segment the carputer systems into specialized domains, some specialized in safety-related functionalities while others produce the rich connected features that the consumers of today expect. However, those isolated systems still need to talk to each other in a secure fashion, co-exist without interference on one device and work in concert to produce a seamless system. Not unlike an orchestra with the themes of multiple instruments weaving a composition larger than the sum of its parts.

“The trick here is that many of the new features that you are developing cut across multiple layers in multiple domains.

Considering the intricacy needed, its unsurprising that trying to actually develop such a system requires some difficult orchestration. Traditionally software is abstractly split into layers, spanning from device drivers, hypervisors and kernels, through middleware and system services right up to user-interface development. These layers together form the software stack. Now, coming back to all those isolated domains, each of them has their own set of layers. The trick here is that many of the new features that you are developing, from FOTA to remote control, cut across multiple layers in multiple domains. And that, is why you find yourself reading about through-stack development.

Horizontals and Verticals

Another juxtaposition can be found in the needs for your development teams. Deep expertise, component ownership and the continuity of work tend to congregate into layers. As such, the most natural team structure for your development is horizontal – for each team to be limited to a specific set of layers in one or more domains. That way, your developers can concentrate on the components & tools they know best, the team can support each other with technical solutions, you do not introduce conflicting changes and you can constantly improve your solutions in a specific area with one team having clear ownership of components.

However, as we already discussed, some of the connected carputer features need to cut through a lot of layers, which would here mean co-operation between a lot of teams. What you need, is a structure to help you develop those features in concert between multiple teams, while still achieving seamless communication and a rapid development pace.

“Our solution has been to introduce vertical, or through-stack, groups to our software development process. We call them virtual teams.”

At Link Motion, our solution to this has been to also introduce vertical (or through-stack) groups to our software development process. We do this using a structure of agile teams & what we call virtual teams. Our virtual teams are feature-oriented, with each one having ownership of implementing a specific feature through the whole software stack. These teams are comprised of at least one member from each team that is needed to implement a specific feature.

The interesting part here is that our virtual teams are transient – once the feature is fully implemented, the team will disband and new ones will likely be formed to implement the next new functionalities needed. Meanwhile, our regular Teams are permanent and their Team Leads are given quite a bit of freedom for choosing the right solutions for their area. If there’s something familiar about this structure, that’s because it’s somewhat been influenced by a similar handling of horizontals and verticals in the Spotify Culture of Squads & Chapters.

Phone Industry Changed Forever. Automotive Industry: You’re Next.

When Steve Jobs launched the iPhone over a decade ago, it surely revolutionized the whole phone industry. It did not only have a well working touch screen, but it had completely rethought the usability from the ground up. If you look at the history of phones from the very beginning (I’m talking about you, Mr. Bell), you can see that until the point iPhone was launched, the progress of phone usability was just evolving slowly. Makers added new features over the old ones: the dial ring was replaced with a 10-Key buttons, added with Call and End-Call buttons, Volume buttons, Menu buttons, Scroll buttons… when camera was added, so was the camera button. Music player? You guessed it: more buttons.

“Automotive space is going through changes similar to the phone industry’s over a decade ago.”

Then there was digital menu, and buttons to control it. Even full Qwerty-keyboard was added to some phone models for business users to type emails quickly. At its peak, there was actually over 40 individual buttons on a pocket-size mobile phone, sharing the front surface with the screen! Apple looked at these “feature rich phones” at the time, listed all the functions this small pocket size gadget would do and figure out how to use it in the most intuitive, natural way.


There are many things we can learn from how phones have been changing, and how people have changed with them. I’m not talking only about the touch screen to add virtual buttons, but the set of gestures and even the orientation and movement of the device itself to control the different functions. Although the difference is magnificent, that all quickly become a new standard that we take for granted today.

Automotive space is going through similar changes right now. We can see a lot of similarities to the phone industry over a decade a go: more advanced features are added over the old ones: a online connection, advanced driving aids, wide array of entertainment, to mention a few. And then there is the end customer. Yes, the person who actually uses the car – She lives with Smartphone. She wants the car to be the same.

So, should we just slap a smart phone or a tablet to the dashboard and call it a day? No. Not even close.


What iPhone did to the phone was not just get rid of the physical buttons, but fundamentally rethinking the way we interact with the device. Just substituting the physical buttons on device with same buttons on the touch screen, the usability do not get any better. It could become even worse, as the screen buttons lacks the only positive thing physical buttons have: the tactile feel.

“Should we just slap a tablet to the dashboard and call it a day? No. Not even close.”

What the phone revolution taught us is how radically we could rethink the automotive usability if we really want to create user friendly “mobile device on wheels”. For example, rotating the vertical shaped phone to sideways is a natural way of watch a landscape movie. Naturally we can not exactly copy this to a car (although a image of somebody flipping the car sideways to rotate the center console on dashboard would be funny idea), but we can rethink the usability of the car in the same radical ways, using natural movement or gestures to interact. In the same way, we don’t necessary need to present the information on the dash as mimicking the gauges in the past – we can rethink how the vital information can be showed to the driver or occupant in simple, user-friendly manner. And then there are the steps to be considered when talking about user experience roadmap towards autonomous driving. There are lots to take in.

I’ll go through these topics in detail with coming blog posts. Stay tuned!

Technical Lead – Automotive UI

Your main tasks is to do hands-on Qt/QML coding and guide other Qt/QML developers in a team. In addition, we expect you to act as a technical team lead for UI team, making architecture design, doing architectural decisions, and making sure that code quality meets given criteria. We want you to be able to challenge architectural decisions we have made. Exact responsibilities will be defined based on applicant’s skills and background.

B.Sc. in Computer Science, math or related field is appreciated

+5 years of QML experience preferable on Linux
Proven track record, open source contributions is a bonus

Excellent team work skills and being able to communicate with people working remotely
Strong knowledge of Qt/QML internals, C+, Linux and cross-platform development
Eye for UI design and interested in good user experience
Understanding how to create UI applications for touch screen devices
Understanding open source and upstream contributions
Skills on OpenGL, Shaders, Qt 3D and Jira is appreciated

Remote work possibility. We also have offices in Tampere and Helsinki.

Send your application and CV to jobs@link-motion.com with reference REKRY: Technical Lead – Automotive UI.

The work starts as soon as we find our perfect candidate, so please apply soon!

Software Tools Engineer DevOps Team

You will join us as a Tools Engineer. In the beginning, your primary focus will in developing and maintaining the Link Motion SDK. The SDK is like Android Studio and XCode, but not yet as complete. It is based on Qt Creator and lxc containers. Later you are expected to expand to developing and maintaining the Link Motion CI. The CI is based on BuildBot and runs on AWS. You are also expected to work with hardware and hardware farms. Exact responsibilities will be tailored based on your skills and interests.

B.Sc. in computer science, mathematics or related field is appreciated.

Few years of experience on related tasks.
Experience in remote working and multi-cultural working environments will be a benefit.

Strong command of Go, Python and shell scripts.
Strong command of Yocto, Linux kernel, sysroots and lxc containers.
Understanding of C++ and Qt development.
Understanding of compilers, toolchains and cross-compilation.
Knowledge of OpenStack, Amazon Web Services, Ansible, or equivalent.
Strong English skills.

Remote work in Europe. We also have offices in Tampere and Helsinki, Finland.

Send your application and CV to jobs@link-motion.com with reference “REKRY: Tools Engineer”

Your application should be equivalent to maximum one A4 of text.

Link Motion will advance its Carputer to CarBrain

Link Motion has released their plans for the next generation carputers. In their technology roadmap, Link Motion’s connected carputer will be developed into “CarBrain”, making vehicles more intelligent part of the traffic ecosystem by supporting the integration of artificial intelligence (AI) and Blockchain applications.

“So far, the digitalization in the automotive industry has been all about replacing existing things in a vehicle with software,” said Pasi Nieminen, CEO of Link Motion. “In the next phase of advancement, vehicles will become an integrated part of a connected infrastructure and more support for network side applications and services are required from vehicle computing. This is how we are positioning Link Motion for the future.”

Read more:

Press release available at http://ir.nq.com/mobile.view?c=243152&v=203&d=1&id=2325970

White paper exploring the Next Generation Smart Car Platform available at http://link-motion.com/papers/link_motion_car_brain_ai_block_chain.pdf

Automotive Linux Software Engineer

Your main responsibility is to join our Services team as a Software Engineer. This role comes with tasks related to C coding (implement Vehicle Network APIs and OTA/USB updating solutions). In addition to Vehicle Network, supporting your team to handle for example OTA, Telematics and USB updater will be an important part of the job. Exact responsibilities will be defined based on applicant’s skills and background.

B.Sc. or M.Sc. in related field

5+ years programming experience
strong C knowledge
Linux knowledge
git experience
experience of embedded systems

rpm experience
some sort of security experience
startup experience (being able to know what needs to be implemented
and what can be delayed in order to deliver on time)
team work skills, able to work with team located remotely

Remote work. We have also offices in Tampere and Helsinki.

Send your application and CV to jobs@link-motion.com with reference REKRY: SW Engineer.

The work starts as soon as we find our perfect candidate, so please apply soon!