Embedded Software Quality Assurance (QA)

[ad#Google Adsense – Wide Banner]

As for every software there needs to be quality assurance testing for embedded software with a special focus on reliability since this is often key in embedded systems.

Software testing / QA may be a very controversial subject as everybody may have very diverging and strong opinions on how it should be done, and the way it is done also depends on the company culture (and size).

So here’s the way I personally see the different steps to testing, please let me know if you feel otherwise in comments.

Unit Testing: This is the lowest type of test (white box testing) where the developer should check the implemented functions work as expected

Functional Testing: Although the software team should check if the main functionalities of the software work properly before committing the code (assuming you are using a version control system and you should), QA team ought to check all possible scenarios including border case to check the implementation match the software requirements.

Interoperability Testing: This obviously depends on the type of product developed and if your device must inter-operate with other equipments for example VoIP phones or ATA devices must be able to communicate with at least the main SIP servers (e.g. asterisk) ) on the market or/and any server that is required by your customers. This team would be performed by the QA test after the function tests passed.

Performance Testing: The QA team should perform performance test either based on product requirements or competitors performance to check the performance of the device is appropriate. e.g. hard disk speed, USB mass storage speed, (wired and wireless) network download/upload, etc…

Reliability / Burn-In Testing: Once of the above test passed, you ought to perform some burn-in test with different scenarios and possibly worst case scenarios. Depending of the type of product you are using, you may consider 7 days reliability test to be long enough.

Developper Testing vs. QA Testing.

There are also different opinions on who should write the test procedure:

1. The software engineer should write a draft test procedure for the code he wrote and the QA team should improve it.

2. The QA team should be responsible for the test procedure.

I personally prefer solution 2. because the QA team would them be able to pinpoint more easily incorrect implementation by the software team due to incomprehension of the software requirements. This can also help improving unclear software requirements, whereas solution 1. may influence the test team into following the software team judgment.

I also understand the point of view of other persons that explain that testers are doing black box testing and may not fully understand how the software works.

The other reasons one might give a larger responsibility to the QA team is that the software engineers generally costs more than software testers, So it ought to reduce the total project cost.

Here’s an interesting thread about software engineer vs QA team testing.

Support CNX Software - Donate via PayPal or become a Patron on Patreon

4
Leave a Reply

avatar
4 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Ip PhonesSoftware quality assurance - Topic Research, Trends and SurveysThe Consumer Tips for Kodak KLIC-5001 Battery | Quality Digital CameraMicrosoft Dynamics Gp Implementation For The Chain Of Restaurants | Home Brewing Beer Equipment Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
trackback

[…] CNXSoft – Embedded Software Development » Embedded Software Quality Assurance (QA) […]

trackback

[…] CNXSoft – Embedded Software Development » Embedded Software Quality Assurance (QA) […]

trackback

[…] comments. Unit Testing: This is the lowest type of test (white box testing) where the developer … Read More RECOMMENDED BOOKS REVIEWS AND OPINIONS Software Quality Assurance 101: Part […]

Ip Phones
Guest

Quality Assurance, or QA, is often given short shrift in a software development organization, especially when budgets are tight.