What topic interests you? Automatic vs
Help me and send me comments with topics related to quality in software development, you are particularly interested in this blog but have not been treated. Thank you!
Thursday, January 6, 2005
Invitation Each Person Pays
. manual testing
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:
Wednesday, January 5, 2005
Have You Masterbated In Public Shower
Traceability Matrix
As part of the development of tests is the traceability matrix to establish a connection between the test cases and to be tested or required functionality to establish and document the fact that at this level a full coverage exists.
These are usually the requirements to test cases compared in tabular form. Useful tools range from simple office applications (eg MS Excel) to large software development tools (eg Rational Test Manager, Mercury TestDirector). The use of these tools is dependent, inter alia from the demands and complexity of a project.
test team's work is greatly facilitated if the requirements are present well structured. The example can be Rational RequisitePro requirements with record structure, and connect it to the test cases in TestManager. In a separate opinion can represent the traceability matrix in table format. The advantage of this approach is the redundancy compared to the separate maintenance of a table.
suitable for smaller projects, a simpler method by which the coverage is established implicitly. If the requirements are structured appropriately (eg as specifications), can be easily deduced from a naming scheme for the test cases. The comparison of the contents of the specification and the list of test cases provides adequate transparency about the coverage.
I should point out that a full traceability matrix is \u200b\u200bnot sufficient to find all the fault of the software. However, it can ensure that all areas will be tested.
Subscribe to:
Posts (Atom)