From 1998 to 2004 Florian Prester studied Computational Engineering at the University of Erlangen-Nuremberg. After his degree he worked as research assistant at the Regionales RechenZentrum Erlangen-Nuremberg (RRZE) with special interest on network security and abstraction mechanism. Since 2007 he has been working for the sepp.med GmbH, where since 2009 he is CEO responsible for sales and business development including the MBTsuite. His interests are test conception, modelling and test improvement. This topics are strongly related with the product MBTSuite, which Florian is responsible for.
MBT Community (MBT): Hello Florian! Great to meet you here in Nuremberg, the place where your company sepp.med GmbH is situated. Let‘s start with the first question: Can you shortly introduce what your background in MBT is?
Florian Prester (FP): We are a so called tool vendor. I‘ve started the production of our tooling from version 1.0 to 2.0 with the redesign and then we started to introduce a new methodology called model-centric testing. The main idea is to store all the resources of model-based test design and model-based test execution into models. This way the results of the test execution can be traced back to the model. This is mainly the area where I‘m active on different conferences and events. This way I‘m trying to support the community and push the idea of model-centric testing forward. Modeling is the most important part of MBT. I think that test generation is more „IT homework“. There should always be the possibility to generate the test cases you need for test execution. But the key is modeling!
MBT: Now you‘ve mentioned your MBT tool. Can you tell us something about the domains you‘re focusing on with your tool? Also: What is the experience with customers of your product?
FP: We are pretty much domain independent. Even if the second part of our company name (sepp.med) is focusing on the medical domain 🙂 But because of MBT and our tooling, we are right now active in many other domains from automotive, avionics, pharmacy and also business information systems. Altogether we are concentrating on the modeling of the SUT. And the problem with modeling is very common in each domain. If you start talking with an automotive embedded designer about MBT you will speak about the same things as when you speak with a medical engineer. Because in the end the modeling topics and the modeling problems are the same: How can we cover specific details? And how can we gain the relation from single points to the overview?
MBT: Ok, let‘s talk specifically about the topic of modeling. Many tool vendors in MBT concentrate on a specific modeling notation, modeling method or approach. What is your opinion on that and how do you prefer to teach or coach customers in modeling with your product?
FP: I think that in order to to make modeling successfull within customer relationships you need to reduce the barriers up front as much as possible. We think that people are always modeling. Even when they say they can‘t use MBT. When people sit together and start talking about technical problems they start modeling somehow. You need to catch up those ideas of modeling. If someone wants to avoid UML or some other language and needs to go to „circle and arcs“ then take him there! If someone is very enthusiastic about UML and especiallyUTP or some special things about state machines then take him there. And give him the possibility to stay within his own view of modeling and guide him to use modeling for testing. Show him how he can store information within his models. I think that for MBT we need to adopt those possibilites of modeling. We (sepp.med) are in quite a lucky situation where we are not dependent on a modeling notation or some special kinds of state machines, etc. We can interpret those notations as a tester. We don‘t need to generate tests out of the semantics of those models.
MBT: Ok, I think it is a good idea to be independent of a certain modeling notation. But thinking further, each tool that claims to be a MBT tool can generate test cases. This generation depends on a coverage criterion, which mostly depends on the kind of model which is given as an input. What can be interesting for the MBT community is: How do you handle different modeling notations (e.g. activity and state diagrams known from UML) to generate test cases and measure the coverage?
FP: The main idea is to use an internal meta-model, which to be honest consists only of nodes and arcs. And on those elements we can store each kind of test information. For example a test step, a verification point, etc. We have a naming convention or places where we can store names, author or timing information and even external information (e.g. technical details in order to build test scripts). So, we try to abstract from activity or state diagrams since looking at those diagrams as a tester, it‘s just nodes and arcs. Mostly the actions to be executed during a test should be placed in nodes. People familiar with state modeling try to put the actions in the arcs, but for us it doesn‘t matter at all. We abstract from all those modeling techniques and use a test model with simple nodes and arcs. The interesting question is how to place the information in this model within a test plan. The point is to build a model where people can understand it at first glance.
MBT: Very interesting. Now, let‘s talk about the USP of your company, the model-centric approach, i.e. saying that the model is the center of the whole development and test cycle. What is your experience in that area? How fast do your customers reach the point when the model is the center of different activities? This approach probably requires many changes in the process of developing and testing software.
FP: Not very fast. MBT projects are still in the situation where you don‘t start with a big bang. You get started with the test automation, with requirements engineering. Some people do it by process, but most people do it coming from a tooling view. For example by thinking „We saw this model-based testing solution. It may suite with our test automation tools. Can you do that?“. And then you start projects. But pretty soon they come to the point where they have the results of the test execution, from the process, from requirements and think of the overview. How is the relation between different artifacts? And then they want to have so called management dashboards to see those information and the relations. We mostly start with documentation within a single iteration. But then our customers ask: I want to use this information in the next cycle. Can you show me how to use it with the model? If we have this information about this artifact used within the test run, why can‘t we show it within the model? And the beautiful thing about testing and software engineering is: everything is (theoretically) possible 🙂 And as a consulting and solution provider we are able to collect the input from our customers/competitors and derive solutions to „build bridges“ between different processes, technologies and tools to solve this lack of information.
MBT: What is your opinion as an MBT expert about how far we are with MBT nowadays? What is missing right now? Where do we have problems when applying MBT as suggested on various conferences or based on your experience?
FP: Right now I think MBT is on the edge of becoming really productive. But we are still in the situation that everyone tries to reinvent the wheel. That is why I say we need modeling conventions and modeling solutions. Then we can have tooling providers. Nowadays there are great providers for test generation. But looking at the modeling providers, we are still talking about the UTP (in the OMG, UML area) and it‘s still not very successfull in the industry area. And we have initiatives at the ETSI or OMG side how test models should look like. But we have experienced on customers that wanted to use different modeling notations A, B and C, but always be able to generate tests. In my opinion we are still missing the modeling acceptance because people at conferences like MBT UC are discussing about technical solutions, infrastructure, timing aspects, etc., but they are not focusing on the modeling. Especially because modeling notations strongly depend on the usage domain. A common set of best practices, meta test modeling, etc. is still missing.
MBT: Some people call MBT the „supreme discipline of testing“. Is it also your opinion?
FP: First, I don‘t think that there is a higher and lower class of testing 🙂 In many domains there are still plenty of manual testers, but they have skills and know-how which cannot be automated. That is why I personally would be happy to accept MBT as a practical, industrial approach for testing. Use modeling in the design phase of your project and decide what you want to test. And of course you can‘t model everything and you can‘t generate all tests. That is why in the future you still will have manual tests and manual test engineering. But I think MBT especially helps during the discussions with the different stakeholders in a project. So I think that MBT as a communication layer will be a very good solution in the future – because if you cannot model it you cannot test it!
MBT: That‘s all. Thank you very much for your time and let‘s hope that MBT will be the future of software testing.