embedded software testing
I have got a chance to work at previous www.aitecs.com, now Moog as software tester for five months. Worked with software for infusion pumps. It was a great experience for me as a tester and want to share with some impressions.
1. Same rules. The first lesson I learned that same rules for testing apply everywhere. Embedded software frightened a little. I thought it should be very different, and I do not know how to test. I learned that all the rules that apply to web site test, application testing, also apply to embedded software testing. Testing the software of infusion pump got me back to pure testing. Analyzing the new functionality, applying mixed of black and some white box methods, searching through requirements made me feel real tester.
2. Validation. For me verification and validation used to be only theoretical expressions. And not clear enough what they mean. I have been testing a few IT projects and mainly worked with verification. Used to verify the software is made according to requirements and conforms to the analysis documents. The certified medical device required to prepare software validation reports. Validation report states that users may use the software, it is safe to use and does what is intended to do. Every small project of new or changed functionality should end with validation report.
3. Higher regression testing. I called it higher with intention to show more wise way to do the regression testing. In my experience regression testing would mean test the main functions of the product, having checklist in my head. OK, sometimes short word document. What I discovered to be a great help – testing procedures. That is a list of test cases, created using software requirements and grouped according to logical division of functionality. In any need of regression testing, the tester evaluates the scope of it, selects certain procedures and follows them step by step.
4. I love pair testing. Two eyes see a lot, but four eyes have a chance to see more. Usually I would find an ‘interesting’ functionality and show it to a developer. He would start thinking creatively, linking things together, and suggesting other issues to check. The results sometimes were great. Also it was really cool just to express loudly opinion about certain function, button, message etc of the program and hear the person thinking. Those dialogs usually end with new issues in test track system, and I believe, a chance for improved quality.
1. Same rules. The first lesson I learned that same rules for testing apply everywhere. Embedded software frightened a little. I thought it should be very different, and I do not know how to test. I learned that all the rules that apply to web site test, application testing, also apply to embedded software testing. Testing the software of infusion pump got me back to pure testing. Analyzing the new functionality, applying mixed of black and some white box methods, searching through requirements made me feel real tester.
2. Validation. For me verification and validation used to be only theoretical expressions. And not clear enough what they mean. I have been testing a few IT projects and mainly worked with verification. Used to verify the software is made according to requirements and conforms to the analysis documents. The certified medical device required to prepare software validation reports. Validation report states that users may use the software, it is safe to use and does what is intended to do. Every small project of new or changed functionality should end with validation report.
3. Higher regression testing. I called it higher with intention to show more wise way to do the regression testing. In my experience regression testing would mean test the main functions of the product, having checklist in my head. OK, sometimes short word document. What I discovered to be a great help – testing procedures. That is a list of test cases, created using software requirements and grouped according to logical division of functionality. In any need of regression testing, the tester evaluates the scope of it, selects certain procedures and follows them step by step.
4. I love pair testing. Two eyes see a lot, but four eyes have a chance to see more. Usually I would find an ‘interesting’ functionality and show it to a developer. He would start thinking creatively, linking things together, and suggesting other issues to check. The results sometimes were great. Also it was really cool just to express loudly opinion about certain function, button, message etc of the program and hear the person thinking. Those dialogs usually end with new issues in test track system, and I believe, a chance for improved quality.
Comments
Software Testing Tools
This blog provides a brief overview of the boundary-scan architecture and the new technology trends that make using boundary-scan essential for dramatically reducing development and production costs. I also describe the various uses of boundary-scan and its application.
Embedded Software Development
Vee Eee Technologies
automateandvalidate