Any discussion around the connected car ecosystem is incomplete without the mention of Automotive infotainment systems. What used to be a luxury addition is slowly starting to become a must-have feature in cars of different segments.
This is because, Automotive Infotainment systems – are helping the OEMs in realizing their vision of delivering a personalized, connected and safer experience to the end-consumers.
It won’t be an exaggeration to state that the Automotive World is moving towards the era of Digital Cockpits in Cars!
Also read our blog: A Car with a Cockpit: How Digital Cockpit Solutions are Making This a Reality
In this context, the importance of developing a reliable, secure and robust automotive infotainment system cannot be emphasized enough.
This calls for a fool-proof testing process that can validate the automotive infotainment system against any probable functional, operational and usability failure. This blog is a summary of our conversation with our in-house technology and testing experts to understand the different software and hardware testing practices that are followed during automotive infotainment solution development.
First Impression is the Last Impression: Agrees a Software Engineer Testing the UI of an Infotainment System
GUI (Graphical User Interface) , is one of the most important components of an automotive Infotainment System, for embedded software testing teams.
An intuitive GUI is very critical. It dictates how pleasant an end-user’s interaction with your product will be!
Every product development team knows the fact that all the information should be clearly and concisely displayed within the designated space, in a user-friendly and attractive manner; but achieving this is often not easy.
During the infotainment testing phase, the UI of the automotive infotainment system is checked for important parameters such as:
- Screen text and characters
- Font and Formatting styles,
- Widgets/icons and their attributed behavior
- Screen coverage
- Alignment of images and characters
- Image clarity and screen resolution
- Manual Testing – Under Manual Testing, as the name suggests, manual checks are performed to check whether the specified UI parameters of automotive infotainment system, and other specifications conform to the requirements given by the customer (mentioned in design document and SRS document).
- Automated Testing – Under this approach, automation tools like GIMP are used to perform similarity checks and report/log the test results.
When Automation in Infotainment Testing Becomes your Friend in Need!
While it is very thorough, manual testing can sometimes prove to be extremely cumbersome and time-taking.
Hence, there are occasions when one should opt for automation in your infotainment testing process. This helps to make testing activities more efficient and error-free.
So, instead of testing the sync between the vehicle and infotainment system manually, real-time environment can be emulated and tested with specific automated tools and scripts.
A sweeping testing trend these days is to design scripts to run testing complex functionalities without the need of any human intervention (welcome to Automation Frameworks in Testing).
These test scripts are mostly written in programming languages like Python. To make things a bit more clear, let us consider an example. To test the Bluetooth connectivity of the In-vehicle infotainment system (IVI), a software tester will need to connect and disconnect a phone/Bluetooth enabled device several times.
Doing it the manual way would be quite time consuming. So an easy work-around here would be to emulate the actual device (infotainment) environment and test the Bluetooth functionality by running automated test scripts.
But before you get started with the infotainment testing procedure, it is very important to ensure that test environment is stable enough to endure the procedure.
For example, if you need to test if your infotainment system is able to detect and transfer data to a nearby Bluetooth enabled device, you must first ensure that the Bluetooth capability itself is working.
In the context of smart testing practices, that saves up considerable development time, one cannot ignore discussing about the Agile testing, used widely in embedded software development.
What Does Agile Testing Approach Entail?
The Agile Testing Method follows an iterative/continuous workflow rather than a sequential one.
The product under development is continually tested at different stages so that it is as closely aligned to customer requirements as possible.
The Agile Testing approach has several advantages like flexibility and adaptability. It also lets the development team receive regular feedback from the testing team. These feedbacks can be used to further shape the product better.
The agile testing lifecycle consists of the following phases:
- Impact Assessment – Involves gathering inputs from various stake holders and users. This acts as a feedback and guideline for next deployment cycle
- Planning – Involves planning of the schedule of testing process, meeting frequency, and deliverables
- Daily Scrums – Involves everyday standup meetings to catch up with the status of the testing and setting the goals for the current day.
- Agility Review Meeting – Involves weekly review meetings to review and assess the progress against milestones.
- Release Readiness – Involves reviewing the features that have been implemented and if they’re ready to go live.
You should also note that there are several levels of testing performed at each stage of the agile testing approach.
These include Unit Testing, Integration Testing, System Testing, and Acceptance Testing.
Shifting our focus back to Testing the Infotainment Systems; there are some critical aspects of every infotainment solution that should be tested. Let’s find out more in this context.
Key Attributes of an Infotainment System that your Teams Should e Testing
While testing a high-end infotainment system, the development team should ensure that the system is tested for following key attributes:
- Does it have a user-friendly Interface ?
- How accurate the functionality of the system is, as per the SRS document
- Can the Infotainment system deliver information to the driver without distracting him?
- How compatible is the Infotainment system with different platforms ( Android, Linux), file systems, secondary devices ( smartphone, SD Cards, USB) etc.
- Have you ensured seamless integration between various components and interfaces of IVI system as per the SRS
In addition to the above, your team also should verify the infotainment system against certain critical security parameters, in order to ensure reliability and safety.
Key Security Testing Parameters:
As the number of functionalities and features supported by the Infotainment system increases, so does its vulnerability to security threats.
An automotive infotainment system can be easily hacked to hijack a vehicle and cause major damage to the driver and others.
Thus, these security parameters must be tested before a system is deemed as fit to be sold.
- Session Expiry/Session TimeoutThis can be best explained through an example. Suppose that a user has logged into the infotainment application (web or mobile) but haven’t executed any action, leaving it idle for a specific time interval.
Ideally, after this specific interval if the user tries to browse on the app, he should get a pop-up indicating that the session has expired. This ensures that only the authorized used can log-in to the system. This helps in securing the infotainment system against unauthorized access when the user leaves it unattended for a specific duration.
- Security against URL ManipulationAn ideal web application will always require a user to login to the system using valid credentials to access any website page. Even if someone simply copies the URL of a webpage and copies it on a different browser, he must be redirected to the login page. This prevents hackers or unauthorized users to alter the URL to illegally get access to web pages.
If your development team has not anticipated this scenario, then your infotainment system is highly susceptible to data manipulation –which can harm the brand reputation.
- Testing for SQL InjectionUnder this approach, testers themselves try to hack the application by giving SQL commands or other credentials, but what needs to be tested is that the system shouldn’t be vulnerable.
So far we have talked about ideal test practices for testing infotainment system followed by your product testing team. But how do you anticipate and define these test cases? Let us find out:
Best Practices to be Followed When Designing Infotainment Test Cases
- While testing infotainment systems, the following kinds of test cases should be designed and planned for:
- Straight-forward Test cases – Test cases as per the software requirements specification ( SRS).
- Ad-hoc test cases – Additional scenarios anticipated and defined by the testers (without referring to the SRS document).
- Negative test cases –These define situations under which an application can fail, or an abnormal condition arises. These are generally not part of the SRS and are done by the testers on their end, based on their experience and ability to anticipate scenarios.
- Stress Test cases – Under this, the test cases are defined to determine the load capacity of the application. This is to check how much stress or load the infotainment can gracefully handle without crashing.For example, the test case specifies flooding the infotainment system with concurrent multiple inputs. This can help in checking how the system reacts, what are the other consequences and risks involved in such a scenario.
- On part of the testers, they should have a deep understanding of the application architecture, the inherent project requirements – which mean he should be thorough with important specification documents such as SRS and Design Documents. If the testers are confused at any point, they can’t assume things and carry out testing operations. In such a case they can get back to the module owner and clarify the doubts.
- The importance of using appropriate/ efficient testing tools at the right time and in the right scenario can go a long way in future-proofing your final application/end product. Following below is a set of testing tools commonly used for infotainment development projects by our in-house test engineers:
TeraTerm - An Open-source terminal emulator program used for emulating and logging data, sessions etc.
PCAN - Used for monitoring CAN serial bus communication
TestLink - A web-based test management tool used for creating test projects, manage and document test cases.
- Supports manual as well automated test execution
JIRA - Software for Agile Project Management , test case management and issue tracking.
To Conclude:
Testing isn’t a complimentary process in infotainment system development project; rather it is a mandatory part of it.
No system should be considered fit to be released until it has been thoroughly tested under various test cases.
And if the best practices discussed above are closely followed, organizations can make sure they’re rolling out a product that’s reliable in every sense.
