are multiple customers with the request came to me, to automate all tests without worrying about the cost. Two examples I will illustrate how different is the cost of test automation and why the alternative or not to automate targeted, sensible.
In the first example, consider I'm developing or module tests. This refers to the tests that are implemented by a developer to test the code written by him. A common framework for this is JUnit , known under Extreme Programming (XP) by Kent Beck . This method has the following characteristics: known
- free Framework
- programming language, because the tests are implemented in the same language as the product
- low maintenance
The Test First approach, the tests are written before the functionality is programmed. In this case, can the time required to create the tests deduct from the problem analysis phase. The second example deals
functional tests at the level of the user interface. Known tools for this are eg Rational Robot and Mercury WinRunner. The following characteristics of these tools I have observed:
- high cost of software
- specialist required
- Record & Replay: the sales pitch very impressive enough in practice but not as costly reworking is necessary
- high maintenance requirements
happy It is pointed out that test scripts are recorded and played back again easily be (Record & Replay). Unfortunately such a recorded script in the rule is rarely executed again without intervention. There are elaborate reworking necessary. Furthermore there is a large maintenance requirements, if the user interface changes only slightly. To point out to you that an appropriate modularization of the tests gives relief. This requires extensive experience and is also associated with an increased effort for the test design.
The total costs consist of costs for software licenses and the costs of creating and maintaining the tests (or test scripts) together. The gain in automatic test lies in the much shorter execution time of the tests, but is bought durch einen großen zeitlichen Aufwand bei Erstellung der Tests. Erst eine entsprechend hohe Wiederholungsrate führt zu einem Kostenvorteil.
Bei den Modultests sind die Gesamtkosten recht gering, hier ist eine breite Automation sehr sinnvoll. Im zweiten Beispiel entstehen sehr hohe Kosten, die nur bei gezieltem Einsatz und mit entsprechender Erfahrung kompensiert werden können. Hier rate ich, nur Teile zu automatisieren, die sich besonders leicht automatisieren lassen oder eine hohe Wiederholungsrate haben und gleichzeitig entsprechend einfach in der Funktionalität sind (Bsp.: Anlegen von 400 Testusern, die für jedes Release neu erfasst werden müssen).
Andernfalls ist das Geld in menschliche Tester besser investiert: automated tests focus exclusively on test points defined, the man is also outside the test specification errors.
more information about this topic:
0 comments:
Post a Comment