Профессиональное: Статья: Тестирование "встройки"
Наткнулся тут на пару интервью с человеком который занимается "встройкой" и ее тестированием.
Целиком пихать не буду приведу лишь некоторые избранные места.
SSQ: Another difference with embedded software is the ability to test. How can you test this device without actually putting it in someone?
Well, you test the requirements so you have to write requirements that are A) testable and B) that are truly going to give you what you need in terms of an end product. We set up automated testing here. We use a bunch of open source tools to do all of our automated testing. And what we try to do is we set things up so all the automated tests are traceable back to every single requirement and test case.
SSQ: So what kind of methodology do you use with software development?
We started off with waterfall and we recently pushed over to doing a Scrum style.
SSQ: Right, that’s why people are switching to agile. What are the reasons you think you wouldn’t be able to 100% switch to Scrum?
I think when you have a closed system, you’re designing something like an implantable device that’s got a closed set of requirements you need to have a vision for all of those in terms of setting up an architecture before you start to implement. I look at Scrum as more of setting up process than a design process. But if you’re doing a website where you’re adding functionality, then Scrum works really well because you can pick and choose and put what you want in that.
SSQ: I’m curious how you test requirements that are dependent on a human. So if one of the requirements is something like determining when a person feels full, how would you test that?
That would be a marketing requirement that would be way up high on the level. So that marketing requirement would come down into 10 engineering requirements, which would come down into 30 different test cases. Each of those test cases would then be implemented in terms of verifying that they were across all boundaries, across all inputs
Источник 1, источник 2
Целиком пихать не буду приведу лишь некоторые избранные места.
SSQ: Another difference with embedded software is the ability to test. How can you test this device without actually putting it in someone?
Well, you test the requirements so you have to write requirements that are A) testable and B) that are truly going to give you what you need in terms of an end product. We set up automated testing here. We use a bunch of open source tools to do all of our automated testing. And what we try to do is we set things up so all the automated tests are traceable back to every single requirement and test case.
SSQ: So what kind of methodology do you use with software development?
We started off with waterfall and we recently pushed over to doing a Scrum style.
SSQ: Right, that’s why people are switching to agile. What are the reasons you think you wouldn’t be able to 100% switch to Scrum?
I think when you have a closed system, you’re designing something like an implantable device that’s got a closed set of requirements you need to have a vision for all of those in terms of setting up an architecture before you start to implement. I look at Scrum as more of setting up process than a design process. But if you’re doing a website where you’re adding functionality, then Scrum works really well because you can pick and choose and put what you want in that.
SSQ: I’m curious how you test requirements that are dependent on a human. So if one of the requirements is something like determining when a person feels full, how would you test that?
That would be a marketing requirement that would be way up high on the level. So that marketing requirement would come down into 10 engineering requirements, which would come down into 30 different test cases. Each of those test cases would then be implemented in terms of verifying that they were across all boundaries, across all inputs
Источник 1, источник 2