開発
Testing
sascha
Testing software increases in importance with the effects the software has on its environment (financial, people, health, etc.) and with the size of the software itself. The bigger the product, the more important repeated testing in a variety of scopes becomes. Failure to implement proper test cases due to outside pressure or schedule should therefore be avoided as much as possible.
Unit Testing
A lot is written about unit testing your code, and this is the part of the test suite that is executed most often and in the tightest loop. They might be running hundreds or thousands of times throughout the day while writing code. And when pushing code to its repository where it will be reviewed and merged into the base software, executed again by the CI tool of your choice making the work of the code reviewer much easier.
Component Testing
If the product consists of several components, these components need to be tested on their own. Do they work as expected with the defined inputs and outputs to and from other systems or system components?
A bigger set of tests and test procedures need to be created. Interfaces to other components can be mocked to verify responses. Scripts be written to simulate inputs to which our component needs to respond to. Similar to writing unit tests potentially a wide range of scenarios need to be imagined and implemented. Because also like unit tests, these tests need to be able to be re-run as repeatedly (e.g. when a change was made) and easy as possible.
Integration Testing
After testing all components by themselves, the point where we need to put them all together to form the full product will come. As was already said for the component tests, as many scenarios as possible have to be thought of and implemented in a way to make easy (re)testing possible.
User Testing
As the person having written the code in the first place, it is an incredibly hard task to user test the software. Because of the understanding of its inner workings, most people are not able to disconnect truly and use the software in an “innocent” way. This is where people unfamiliar to the product become very valuable in using and giving feedback. Because of their unfamiliarity and likely different thought process they might try things the developers didn’t intend, and with this find bugs and give valuable feedback for improvements.