Blog

Export of test design to Excel for HP Quality Center

Written on January 30, 2012

Since the implementation of version 1.0 of the DTM tool, we have been busy with developing new features. One of these new features is the ability to export the test design to an Excel format. This is because an existing customer of the DTM Tool, documents the test requirements into HP Quality Center. This was for us the reason to give this feature a high priority. After a short test phase the current version 1.1. of the DTM Tool is implemented with this new feature included. Therefore, it is now possible to export the test designs to an Excel format that can be read by HP Quality Center (see example below this blog post).

Right now we are busy developing new features and doing some bug fixes. An important new feature is to make drawing a test model more simple. In particular, to draw the connecting line between two components. Simply by clicking on the first component and then the secondcomponent, the line is drawn.

We still have many plans to expand the DTM Tool with new features. We also think about connections with existing test tools. We will write about this in a later blog post.

 

Dialogues Test Methodology (DTM) and positioning of DTM tool

Written on January 11, 2012

Dialogues Testing Method process flow

Product risk analysis on the test model

Written on January 9, 2012

The algorithm which the DTM tool uses to automatically generate test cases, has a veryhigh test coverage. Any combination of two test paths will be tested at least one time. But,when using the DTM test tool it is still possible to test those test cases in priority of importance. This is called risk based testing.

After the test model is drawn and the test cases are automatically generated, within the DTM test tool it is possible to highlight the entire test path of a test case. Simply byclicking on the various test cases, the entire test path for the relevant test case becomes green. In consultation with the business, you can now specify the priority of the test case; low, medium or high. After generating the test design, you now can test the test cases in order of priority.

So get the product risk analysis done on the test model itself.

Learn more about the DTM tool or try the 7 day trial version, visit www.dtmtool.com

A new approach to test automation in Agile development world

Written on January 9, 2012

According to predetermined specifications and the various test design techniques,  the tester develop test cases and check if the current version corresponds to the required status of the test object.

With the increase of various Agile development methods, we see that functional testers no longer necessarily have a place within the team, but that testing is often performed by developers (unit and integration testing) and business (acceptance test). This is a missed opportunity and can influence negatively the final quality of the project. Testing is an art and it must be also be integrated within Agile processes.

Unit and integration testing performed by the developers happen often based on Test Driven Development. Also, these tests are often automated. This is a very good development, but what exactly is tested? The code that has build? But when this is working correctly, it is still debatable whether this is in line with expectations / wishes of the customer and whether any exceptional circumstances also works correctly. Because we don’t want to answer this question during the acceptance test, just a dedicated tester in Agile projects is required. The work of the tester is designed to assess what is needed to be actually built. In addition, not only the so-called happy-flows, but also all exceptional circumstances will be tested, which are prepared in accordance with the requisite test specification techniques.

Within Dialogues Technology we go one step further and we see that the tester has an even more prominent role within the team. The tester is involved already from the start and will begin to unravel the test basis (often brief description). Are there any possible inconsistencies, open-ended, impossibilities, filtering etc.? This is a dialogue with the client, where we ensure a more concrete test basis. The advantage is that the test start from a very early stage (static test) and it becomes clear what is to be built and so what has to be tested (dynamic testing). All this before the software is even built. This will also prevent the client from surprises and it is possible to get a clear business case. Since quality in agile processes is characterized by a higher satisfaction and business value, makes the role of tester only more important.

Model Based Testing (MBT) makes this possible. Based on business requirements and / or (additional) input from the business, the tester will build a test model, which includes all possible conditions and paths. Through a special testing technique all these paths, the happy-flow and non happy-flow are linked. For the automatic generation of test cases and a complete test design from the test model, we use the DTM test tool. Using this tool establishes test model is no longer a static model, since it can be repeatedly adjusted as needed, because we know that the requirements change with new insights from the business. With one click, the tool can generate automatically test cases and test design, over and over again.

The DTM test tool provides much more flexibility of Agile test approach and it minimizes the manual work, allowing greater focus for testers on the modeling of the test flow (testbasis). The DTM test tool facilitates the dialogue with the business.

Silvio Cacace, Dialogues Technology