Tutorial videos

Mihai tells you about handling intaQt^® studio

Hi, I am Mihai from QiTASC. I am a Software Engineer here and today we are going to work together to do some basic functionality of intaQt studio, our product which assists us in developing our test cases and maintaining them. We will start right away. I will just start our intaQt studio. You can do this multiple ways, I prefer doing it by the command line. I am a more technical guy and I think it is the fastest way to do it with this command here ./qitasc start intaQt-studio. Of course assuming you have all the products and the setup done for the platform. If not, please check out our other videos on installation and setup of the products we offer.

Great – intaQt studio started. It usually opens up the latest project you worked on. Now I have no other projects, so I go ahead and just create a new intaQt project. You have to select the project type to be ‘INTAQT’ and the ‘intaQt port’, just leave it to default. I will just create it under my ‘Qitasc’-folder, in the ‘home’-folder under the projects. This is our guidelines, this is how we usually do it here at Qitasc and I will just call it ‘demo’. Of course I have to select a folder and give the name of the project demo. Finish it, and yes – the project is created. You can see this. It is very important: The icon of the intaQt project is this white notebook here and you see in the bottom right corner the status of the connection to our intaQt Server. Currently it is disconnected. This means we have to start the intaQt Server in order to be able to work and run this, so I have to start intaQt-server. Actually, it is both, intaQt Server and ADM, if we want to work with phones also. We have to wait a bit. As you see the status of the connection changed to ‘Connected’ and now we can start working.

Our focus today is to see how we can work in intaQt studio, how to create basic test cases, how to run them and how to interpret the results. I go ahead and just create a new directory to host our features that we are going to implement and just create a basic feature file. I call it ‘MyFirstFeature’, just to showcase how we can implement the feature. I call it ‘initial feature’. While we create the new feature, the intaQt studio generates a template for us. This is the structure of our test cases. It starts with the feature keywords and inside a feature we have multiple scenarios, which contain a set of steps. These are the parts of the tests that are going to run and do something for us. It is split across three blocks. Prerequisites when we expect something before the test case. Those are the preconditions that we have to meet in order to run our test. Then the execution of the test, what we do in our test. And then the final is the result verification. After we did that we have to check that our expectations are met. The basic step that we can write is to do a simple assertion. I just go ahead and write Then verify. As you see, ‘verify’ is a Built-in step, as described here. The platform itself offers us suggestions about the steps that we support, which is of great help when developing. Otherwise we have to search through the manual and all those steps that are suggested here – when pressing for example contra space, it will trigger us a list of suggestions – and all those steps are found in our manual which are also open. It is installed under QiTASC/manuals and contains all the functionality that intaQt Server provides.

So, we are talking about this verify step and I will just write the simplest assertion that we can do. This step takes an expression as argument and evaluates it. If the result is true, then it is o.k. If the result is false, then the test will fail. Of course, in reality we will do more complex assertions, but this is just to showcase the basic functionality of the platform. I rename this with passing scenario. Now we can run it and see that it works. With rightclicking on the editor ‘Run MyFeature’, it will just start the test case. It connects the intaQt Server in the backend and gives it the instruction to run this test. This opens up a test council, which contains the result of the test case. We see here our step ‘verify true’ started and completed successfully, of course, and on the right side here, we have the log so that we can monitor what happened during the test case. We can have also our own log messages to be able to better understand what happened during this step.

One important aspect here: After the execution of the test case, intaQt itself generates a report which contains more detailed information. It can be found under intaQt-server/reports. This is the default configuration. Of course, it can be configured to store the reports in other places, but this is a good default and it generates an index html, which again shows us the result of this test with all scenarios we run during this test. We can click on it and see the steps. In this case it is all passed, we have a 100% successful rate. Additionally, it has multiple formats for showing the results as an xml. Also the log of the test is included here and that is pretty much it for the report.

Let’s continue. As I said, the features can contain multiple scenarios. Let’s see what happens if we implement the scenario that is failing – failing scenario. We do the same here and add just an assertion and say false. And if we run this feature, it will run all the scenarios inside the feature and as we see here by this yellow icon, this step failed and we see that it was an assertion error, which in our case is pretty much what we expect. Let’s assume now we have multiple steps inside the scenario. Let’s take a more complex one – multiple steps – and we have multiple verification steps. I just use verify true twice. It will run the test as expected sequentially, one after the other. But the interesting part is, what happens if during the test one of the steps is failing. If I run this one, I expect the first step to be failing and all subsequent steps in this case will be skipped. It is marked by this icon here and I know, this step was skipped. If a step is failing during the test, all others are no longer executed. The test is marked as failed and will skip all the others. Assuming now we have a scenario that is constantly failing, and for some reason we know that we have a problem in our system and that’s why the scenario is failing, we want to ignore it – ignore scenario – Then verify false. Assuming this is a scenario that is always failing, we can ignore it by tagging it. If I tag it with @ignored, this will not be executed. It will be taken out of the execution and we won’t know about it. Actually, in the results we won’t see it. We have passing, failing, multiple, but not the ignored szenario, because we just annotated it. Again, when the system comes up and we know we have to test this scenario again, we can just take out this line and if we run it again, we will see it is here. Of course it is failing, because it is verified false.

What happens with this execution is that the platform, whenever we are running a new feature, it generates a default configuration for this feature. Here on the top right corner, we can seal the configurations of the features that we run. By default, the platform itself keeps track of the last five executions, unless we specifically save it. If we save it, it remains here. This is useful when you have an execution with a custom configuration. You see here this tag, this means ‘not ignored’. It will select all the features and scenarios and execute them, unless they are annotated with ‘ignored’ and this we can modify here. We can change it and say, I want now to execute all the tests that are ignored. So, if I apply here and go back to the annotated ‘ignored’ step, what we expect is that all the other steps are ignored, the three above here, and only the last one is executed, because we explicitly asked to execute all ignored scenarios by modifying this default configuration. O.k., I will switch it back. Additionally, we can also have multiple intaQt instances, so we can instruct Studio to use another port for a separate intaQt instance, but we won’t use it that much. It is an advanced feature for now.

Assuming we want to test now a scenario that is more for the real life situation. Let’s say we want to test ‘addition’ operation. We can’t just say here verify 1 + 1 == 2, because this would not cover all the cases. We want to see more examples inside the test to confirm that our operation is working. If we were to write a scenario for each combination, then we would end up with too much duplicated code and what we can do is to just use scenario outlines and feed it with data as example. We have here, apart from feature, there is also a feature with scenario outline, which I will call ‘AdditionalOperation’, because this is the feature we want to test and the scenario itself I will call ‘addition of integer numbers’. Again, the template that is generated by the platform for us has almost the same structure as a normal scenario with exception that here below we have an additional construct for the examples. We want to check now that addition is working properly. We say verify and instead of 1+1==2, we want to use variables here. I name it here <op1> + <op2> == <result>. And this construct contains here a placeholder. This is a variable which we will specify inside our examples. This table syntax is how we do it. This is just for formatting what I am doing now, but it is nice to have it properly organized. For each example that we will give here, intaQt will generate a test case by replacing all the examples here into the test itself. So we will have, as expected, two execution when we execute this feature with the parameters. You see here <op1> is replaced here by 1, <op2> again by 1 and the <result> by 2. And in the other execution, it is the other values that we specify in this other example.

Of course, this verify step and all the others are Built-in steps. That’s very nice, but we want to be able to specify our own custom steps. Let’s assume we have our own service http, REST interface, service that we want to test with intaQt, so of course, we can’t use only the Built-in in steps, because it is a custom service, so we have to be able to implement our own custom steps. I will showcase that now with the ‘CustomStep’ feature, I name this scenario ‘custom step’. Let’s assume we need a step that prints us something on the council and I will just print „Hello World”. This is the known program that everyone starts with. We want to print ‘Hello World’ on the council and see the message here, somewhere in the log of our test run. As you see, the platform itself inspects for known steps and it marks it as an unresolved step invocation. Usually, whenever we have a problem in our files, this will be somehow marked in red. On the right side here, we see where the problem occurs and also this red label here indicates that we have a problem. We have to define this step, and this we do inside our backend languages. I create a folder ‘lib’ to store all our custom implementations. Again, this is our guidelines, this is how we do it here at Qitasc. You can find a structure that fits your project. Not that you have to do it like this, but it is the recommended way of doing it. In order to define the step, we will create a ‘Soaptest’-file. This is the type of file that we use to implement our custom steps. Why soaptest? Because we use it in the early stages just to test soap services, but now we can use it to test multiple services. It is not limited to soaptests. We said we want to have a step that prints something. The step definition – I leave this model for now, we talk about it later – the step is defined using this stepdef keyword, which opens the definition for a step and what follows afterwards is the text that identifies the step. These curly brackets here mean we have a parameter here. It is a placeholder that will be bound to this name here. If we had multiple parameters like print { } and { }, we will have to add another parameter here, name it text1, text2. The order matters, so whatever we feed in here will be bound to this argument. It will be available for us to use inside the step definition. So I am printing the (text). Again, println in our case, as you see is the only suggestion that we have. That’s why it autocompletes it immediately. The same as for the feature files. We get autocompletion for the functions that we can use internally here, so we can use println and print the text.

Going back to the features, we expect this step now to be found by intaQt, which it is not already, because we have to configure. intaQt cannot know where to search for the definition of this step, so we will have to configure it. This we do by creating a configuration file which we – again, by our own guideline – we name it ‘project.conf’ and place it inside the root of the project. For the binding, from feature file to soaptest for the files to work, we have to provide a Glue.path definition, which is a list of relative paths, starting from the project root. This means as to instruct intaQt to search for all the definitions that it can find under the ‘lib’ folder inside the root of the project, so it will recursively search for all stepdefs. The structuring inside this folder can be nested as you want, intaQt will recursively search for all the definitions and make it available inside our feature files. Why Glue.path? Because it is like a glue. It binds the feature files to the definitions in soaptest. As you see now, we have a ring mark here. This  means we have no other problems in our feature file and the step is resolved. We can now use more advanced functionality like jumping to the declaration of this step. I am doing it by keeping ‘control’ pressed when I am clicking on the step, it jumps directly to the definition. The other way around, if I am on the declaration side and hover with the mouse and ‘control’ pressed over this element, then I can jump to its usages. Let’s run and see what we get. We have our print “Hello World” step and as you see inside the log, we have the “Hello World” message as we expected to be.

Another thing now is, if we have this “Hello World” message here across multiple features and if this string is important for us, like let’s imagine it would be a user name or a password that we want to share across multiple features and we don’t want to change it every time, if the user name changes, we have to store it somewhere. We have to make it as a variable like, I name it here helloWorld and we want this variable to be accessible from all the feature files. If I run this now, of course it won’t work, because we have no definition of ‘helloWorld’. It will say: ‘Hey, I don’t know who this helloWorld is. I am trying to resolve it, but it cannot find it.’ And this we can define inside our context objects. This is a separate configuration section – ContextObjects. We can place here whatever types we need, whatever identifiers that we want to share across multiple features. It is a shared state. If I define a helloWorld here and store it as a string containing the “Hello World” text. If I run the test again now, then intaQt will search through the context objects for this ‘helloWorld’ instance and it will find it here. We will replace it with whatever content I placed in there, in our case it is “Hello World”.

That’s pretty much it. I hope you enjoyed our little introduction into our intaQt studio platform and this was just a basic part. We will cover more advanced work flow and features in future videos. I hope you liked it.

 

Mihai shows you: Starting your first intaQt^® project

Hello there, my name is Mihai and I am part of the development team here at QITASC. In this video, I am going to show you how to create your first intaQt project.

First things first. I am going to start intaQt studio. Assuming you have all the related intaQt products already installed, I’ll just use the QiTASC command line tool to start intaQt studio. If not, please check out our installation video. It shows you how to install all the required intaQt products that you need.

Now, when we first start intaQt studio, you will see a welcome screen and for some of you, this might already look familiar. Yes, intaQt studio is built on top of the IntelliJ IDEA platform and the good thing is that it inherits all the excitement features that this platform has. For those of you who don’t know IntelliJ  – don’t worry, it is a rather simple and enjoyable platform to work with. We also have a video that shows you some ‘Tips & Tricks’ about useful editor shortcuts and features that will definitely become handy when you want to develop or maintain your test cases.

Back to our initial projects: We have to click on the ‘Create New Projects’ button to start our new project. On the left side here, we have to choose the type of the project that we want. By default, it is intaQt, so it is exactly what we need. On the right side, we have the project specific configuration which, in this case, is the host name and the port of intaQt server, to which we want our intaQt studio to connect to. I will leave the defaults for now. This means I will just use my local intaQt Server, that runs on the default intaQt port.

The next step is for us to, of course, set the name of the project and its location. We recommend storing all your intaQt projects under the QiTASC folder inside the project’s directory and I will just name this one ‘MyFirstIntactProject’. Hitting finish, the platform will generate a project for us. You can tell that it is an intaQt project by the white notebook icon that sits next to the project name. When we expand the structure of the project, we see a bunch of files that were generated inside our project. Basically, this .iml file and all the other files under the .idea folder, they are just platform files that are generated and managed by intaQt studio itself. They are used to store project specific configuration and basically information that is relevant for the platform. Keypoint here: don’t manually touch them! Just let them be in the project – o.k.? The source folder src we don’t need, so we can delete it for now.

One important thing here is, below – on the right side – we see a ‘Disconnected’ widget. This basically tells us the status and the connectivity to the intaQt Server that we configured when we created our project. So, this usually happens, that it is disconnected when the intaQt Server is not running. So, I am going to start intaQt Server – again, using the QiTASC command line tool. After this starts and initializes, we should see ‘Connected’. Yes – now it is connected, and this means we are already to go, the set-up is completed and we can start writing our first test case, which I am going to do next.

So, test cases in intaQt are written in the form of ‘feature files’ and our recommendation is to store all your feature files under a common directory. We call this ‘Features’ and, under the features directory, I will create a new feature file. I just name it ‘MyFirstTestCase’ and the scenario I am testing is ‘my first test case’. Clicking ‘OK’ will generate the feature file out of the template. For now, the structure is not important, we don’t need all those steps for now. I just write the simplest test case that I can think of right now, which is to verify 1 + 1 == 2. Simple, right? What we want to do now? Of course, I just write test cases, but to execute them. And I am doing this by right-clicking inside the editor and running the feature file Run ‘MyFirstTestCase.feature’.

So, we have our first successful test. This pretty much ends our session for this video. I really hope you enjoyed it and I encourage you to check our other videos as well. Thank you!

Mihai explains Phones Plugin

Hello there, my name is Mihai and I am part of the development team here at QiTASC. In this video, I am going to show you how to work with the phones plugin.

So, usually when we have an intaQt project we work with phones and there is a plug-in in intaQt studio that helps us manage those phones and see which phones are available for our project. In order to see the phones that we have for our project, we just have to click on this side button here, named ‘Phones’ and it will open us a panel which shows which phones at which location we have available. For this instance, we just have this local tagged location, which means it is our local intaQt Server. If I open this, I see ‘No phones available at this location’. This is expected, because I did not yet connect any phone to my computer. So, let’s go ahead and connect one phone. We just have to wait a bit, until the connection initializes and intaQt detects the phone. I just unlock the screen for now. And if I refresh here, we see, there is an Android Phone, this is the series number and the number for the sim card.

Now, when I double-click on this phone, I see on the right side a list of the list of the properties that are available for the phone and, on the left side, it is a capture of the screen. This is configurable for now. At the moment it does not refresh, but I can choose, scrolling ‘interval’. So, for example, if I want my screen to refresh every 1 second, then I do some changes here, it will automatically be reflected on the screen capture here. We will extend this in future, to stream the screen, so this is already on our road-map to have a life capture of the screen and also to be able to interrupt by clicking on the surface here and doing the action on the actual phone.

One part here, for the properties, you can sort them, for example by name, ascending or descending or by value. By default, they are sorted in alphabetic order by their name, and we can also search. So, for example, if you want to see the network property of the phone and want to have quick access on it, I just focus on the table and start typing ‘network’ and it will search me through the list of properties and I see, o.k., this phone has a network 3G and there is another property ‘network type’ that has a value of 10.

Usually when you have a project, you don’t have only local phones, but we have remote phone services that are assigned to a project. So, if we have configured some remote phone services into our project like this:

RemotePhoneServices {

“qvie-rpo1.qvie.qitasc.com:6000”: “qvie1”

“qdus-rpo1.qvie.qitasc.com:6000”: “qdus1”

}

So I have a remote phone services in Vienna and one in Düssedorf. I first have to save the configuration file, of course, to make the changes available to the file system and then, after I refresh, I see the two locations got shown in here. And those are the phones that I have available. So, I see in Düssendorf there are 30 phones available to use, and the same: if you click on one of them, you see the screen and their properties.

Another thing that is useful from this plug in is that, when we have a feature file that works with phones – let me create one: ‘PhoneProperties’ for example, and I create the scenario ‘check a phone property’. I aquire a phone, an Android one as ‘A’:

Given an Android phone as A

And, then I want to check its property. So, I want to check its network to be for example ‘2G’

Then verify A.network == “2G”

When I run this test, I see here the step of acquiring the phone was successful and the verification failed. This is what I wanted to achieve in order to show you that, when a phone acquisition step is successfully executed, we get here the phone that was acquired for this specific test instance. So, whenever we have problems in the subsequent steps, we can easily debug what happened. In this case, the network is not 2G. I can also see this in the log, the network is actually 3G. But I can also double-click on this phone and go to the network property and say ‘oh, this is in fact 3G!’ I see immediately and don’t have to check through the logs and everything. So, I can either adapt my test case or know what the actual problem was.

These are all the capabilities the phone plugin offers. I hope you enjoyed this video and see you next time. Thank you!

Mihai demonstrates an SMS test case with intaQt^®

Hi there, my name is Mihai, I am part of the development team here at Qitasc and in this tutorial we are going to learn about SMS steps. What we are going to do today is to automate the sending and receiving of short messages. What we need for this set-up is two Android phones, which are already connected to my laptop. We use this phone to send SMS and the other one to receive them.

I go ahead now and create a feature file which I name ‘SMS’. And our scenario, as already stated, is ‘send’ and ‘receive’ SMS. First step is to acquire our phones. So, I need Given an Android phone as A And an Android phone as B.

There is a problem, if we use it like this: We don’t know which phone will be A and which phone will be B. I want to make sure that this is the sending phone, so I have to specify a query to target this specific phone and I´ll use its number. Its number is written on the app, but I can also copy-paste it from our debug page, because intaQt opens a webserver. The default board is 8080, in my case it is 8089 – I changed it. And under the path /phones, I see all the properties of the phones that are connected to my intaQt. So I go ahead and copy the number. This is the number of this phone and paste it here.

For the execution part, A has to be the phone that sends the SMS, so I type When A composes a short message and A types “Hello World!” And within 10 seconds, A sends the short message to B.number. So, the first step ‘A composes a short message’, this starts the workflow, then additional type steps can follow in which we specify the text that we write in that short message, and then in the end we need to send that to a number. In this case it is B.number. This number is a property of the phone – the same one we have seen here, so it will be this number. We can access the properties of the phone with this dot, and after the dot we can place whatever property of the phone we need. Why we need this time-out of ten seconds is because, for example, if the networks rejects the short message, then this step will fail, because the sending was not successful.

In the verification part, we want to check that the receival of the SMS is complete. So I go ahead and type the step for that. Again we need a time-out, within 20 seconds, B receives a short message from A.number as SMS. We expect that within 20 seconds, the SMS is received from this number, in our case from A.number. We can specify other numbers, if we have this use case, but in our case we want to check if the SMS is received from A and we store a reference to this short message with this SMS identifier. This will be available for our next step, when we want to verify that the text we received is exactly ‘Hello World!’ and the network did not change it for us. And verify SMS.text is ‘Hello World!’. Again, this field here text something that is available on the instance of the received SMS, there are more fields available, which you can check in the manual for.

Now, let’s go ahead and run the test. So, it requires the first phone, it sends the message and as you can see it receives it, the phone rings and the text is ‘Hello World!’.

O.k., this was one way of testing the sending and receiving of short messages. I will show you another way. I create a new scenario, which I will call again send and receive SMS. This time we make use of compound steps. You will understand what this is about in a few seconds.

This is o.k., but we extend our steps to be a bit more flexible and also nicer to read. So, this is the old way of doing it. The new test should be done, in our opinion, with a new approach that I show you now. I mark this scenario as ‘ignored’ for now, because we don’t want to execute it again when we start our test and, again our prerequisites. It is the same, we have to acquire the two phones. I will do this with a separate step, not like above, and say Given phones as A and B of type Android. This is nice again. It is a compound step for when you want to acquire multiple phones which share similar characteristics and you don’t want to write it for all of them, like Given an Android phone as A, Given an Android phone as B. You just write it once. That much for prerequisites now.

For the execution part, again, we want to send the message from A to B and we will write Then A sends a short message to B as SMSSend. And for this steps, this supports the details, so those are the compound steps that I was talking about and we have a bunch of them. For example, with text 1 I specify the text that our SMS contains. In this case it is ‘Hello World!’ again’. Why not? And we want to check delivery confirmed to sender within 10 seconds. This timeout here is a 1 to 1 mapping from within 10 seconds, A sends the short message to B. So we expect that within 10 seconds the delivery of the message is confirmed.

For the verification part, we have to wait for the sending of the message. For this we have the following steps: Then within 20 seconds, expect the short message SMSSend – this is how I named my SMS – to be received. This will wait for 20 seconds, that this workflow of sending the SMS completes. Because again, compound steps means it is starts in the background, it does not wait for this action, we have to wait later for it to complete and it gives us the nice advantage that we can do other stuff in between, like sending other SMS or make some queries into the data bases if the SMS arrive there, or whatever.

With this set up we have just tested the sending of the SMS, we don’t know anything about receiving. This is what we will test now. For this we have to specify an additional step here, a step detail, and say check reception within 10 seconds. Again, this timeout from here marks this one from here, and we want to store the received message as SMS received, so that we can do our checks on it later on. So, the SMS was sent, the receival is stored under this identifier which we can check with the verification step that we have verify SMSRecv, so the text of the received SMS is expected to be ‘Hello World!’.

If we run it now, it will acquire the phones, it will start the sending of the SMS, it got the SMS within 20 seconds it finished it and it successfully verified that the received text is ‘Hello World!’. So if I was here on ‘Hello World 2!’, I would expect it to fail, because the text does not match. Just wait for a second. And yes, we have an assertion there. This is marked as failed.

That’s it for the SMS steps that we have. Thank you for your attention. I hope you enjoyed it.

Mihai demonstrates a step-by-step Webtest guide

Hello over there! I am Mihai, part of the Development Team at Qitasc and today it is about Webtest. We are going to automate together a Google search. Let’s start.

I have here on my screen already created a project and named it with this demo and I have intaQt Server already running. Please check our other videos if you don’t know how to start a platform or our products in order to start testing. I will create a feature file first and name it ‘AdvancedGoogleSearch’ and the scenario will be to ‘search for qitasc on google’. Since we want to automate webtest and perform something on our website, we first need to open a browser. Inside our prerequisites first do it, the other steps now.

We first need to open a browser. So inside our prerequisites just delete the other steps for now. We first need to open the browser, so I will just say open browser chrome. I do my testing on Chrome. Apart from chrome, we also supports Firefox and for Windows Internet Explorer. But Chrome will do fine for now as web. So, open browser chrome as web. What this web means is, that after I open the browser, I have access to it in order to be able to automate what I need via this context variable named web, because I can also open multiple browser instances. I need to have a way to reference the browser that I want to automate my things on. Running this step now, will fail because we need to configure Chrome. we need for this the Chrome driver, which I will download from the github releases. So, search for ‘chrome driver download’. It is advisable to use the latest version of the Chrome driver. In this case it is Chrome Driver 2.33. Just download it from the releases. I am on Linux, so I download the Linux version. I just store it under my project. Open this and unzip the file of course, so I have the Chrome driver executable. We at Qitasc like to store our resources under a folder named ‘resources’ and the drivers that we use for a webtest automation under drivers. So I just copy this here, put it under ‘resources/drivers’, delete the other parts that I no longer need. And, of course, I now want to point the intaQt Server to the Chrome driver that will be used to automate the test. For this I need a configuration path named ‘project.conf’, because it is project specific configuration and configure Selenium and under Selenium configure the chromePath. This is the path where from the project route I can copy the relative path very simple here and put it right under the chromePath configuration.

So, now when we run our test, what will happen is intaQt will open a browser and have it available for us to continue with our use case. I will just quickly put a wait step here for 20 seconds. Otherwise it will be too fast, it will open and close it instantly and we won’t see anything. Let’s run it and as you see, the browser window opens. This is Chrome and this is our start and now we are going to navigate to the Google page. I will leave the wait step here. We will need this to see what happens each time after the last step we execute. After we open the browser, we want to navigate to Google, right? We can have a step When on web, navigate to google. Of course, this is a custom step. We will do such a custom step for each entry point, for each website that we want to test and we have to define it.

We define all our steps that interact with websites, with applications on phones and stuff inside the webtest language. So I will create a new ‘Webtest’ language, name it ‘google’, because it relates to this website specifically, and after creating a webtest, the platform generates us a template, so it has stepdefs inside, models and views. I will just leave the model and views for now and focus on the stepdef itself. We will cover the other topics as well during this video. So, no worries about that. My step now is called navigate to google. I copy this, paste it here. I have no parameters, so I can delete this one. Of course it is still red, because I have to configure the Glue.path in order for intaQt to know where to find my steps, so the gluepath will be bound to this folder. Meaning, intaQt will search for this step definition under this ‘lib’-folder here. Why we need this ‘on web’-prefix? It is something webtest specific, because we need to know on which browser instance we want to do the action that we want to do. So inside this context, we have access to the functionality of that specific browser. We have the open statement and we just pass it the URL that we want to open – http://www.google.com. This is the step definition, we don’t want to do more things here, let’s just run the test and see that it navigates to Google. So, as you see, we have Google here.

Our next step is to go to the advanced settings and this is where it becomes interesting. So, what I need to do now is to define a way to interact with the elements on the page and we do this via view definitions. So, what is a view? You saw it already. Here we had view. I call it for now SettingsView. It is a subset of the elements that are of interest for us inside this webpage. When we automate the webpage we are interested in some specific elements on this page, so we want a way to address them. How intaQt solves this is by Xpaths. It is the query language to find elements under html or xml. Go here, click on ‘Settings’ and then go to ‘Advanced search’. This is what we want to automate. Now that we have seen it, we need a way to address this ‘Settings’-button. We do this by inspecting it and trying to find the Xpath of this element that will help us interact with it. In this case, I see here the element has an ID, so I can make use of it. I can provide an Xpath that searches for whatever element under this html that has an ID – this ‘fsettings’, whatever Google named it. Google Chrome is very cool helping us finding those XPaths. It has this intelligent inspector and we can search for elements under this tree with the Xpath and in this case I see I find 1 out of 1 results. So, this means this XPath will uniquely identify this guy here, this ‘settings-guy’, which is exactly what I want. Don’t worry about this XPath, it is an open source standard, so we will find lots of support for it on Google, if you don’t yet know how to work with it. settingsBtn – this is how you define an element inside of ‘view’ and we say, we will use its XPath to target it.

Now, that I have my element, I want to interact with it. My manual action was to click on it and this is what I want to specify my code here as well. I want to add an action on the (settingsBtn) to clickSettings and this is a click-action. This is the syntax we use: We first defined the element that we are interested in this view, then we have an action on this element, on the settingsBtn, the name of the action – the action, of course, you can choose freely. I find ‘clickSettings’ o.k. for now – and the actiontype. We have multiple action types for different types of elements. For buttons you have click, for input fields you have ‘type’ for example, which of course won’t work in this case, also clear, toggle, untoggle, check for checkboxes and many others that you will find in our manual.

After I have this settings view, I need a stepdef to navigate to advanced search page. I will start it with the definition of the stepdef. We will add it later inside the feature file. We have a special construct for us, a special statement called ‘await’-statement where we can say await a View and what intaQt does in this case, it will start searching for this view under that webpage that is currently active and we will try to locate all those elements that are specified here. As soon as it finds all the elements that I am interested in, this await-statement terminates and it will restore the view instance at the v-variable, so I can use it later and do my actions on it, like click it. The other scenario is that the webpage does not load or somehow we don’t find the elements that we are interested in. In this case, await has a timeout – by default it´s 60 seconds – which will fail the test saying: “You ask me to find a view, but I cannot find it.” It means there is either a problem with your implementation that you did not give me the correct XPath or there is an actual problem with the webpage itself. But in our case, we don’t stop at the settings button.

After clicking on the ‘Settings’, we have another action to click on this ‘Advance search’. So we need again an XPath to identify this ‘Advanced search’. Again it has an ID. It is very useful when elements have IDs because it is the easiest way to target them via Xpaths. So, I will just use the ID again. The advanced search is here, this is an ‘a’-link, which does not have an ID, but fortunately, the parent of this element has an ID, which I can use in my XPath. Again, it is one out of one results, so this is good, it means it is unique. As I said, IDs are always good but you have to check that they make sense. There are webpages that for example use automatically generated IDs which are not unique – when you access the page multiple times, it will be different, so, this does not help you. Or there are pages which don’t use unique IDs, which semantically is not correct, but we have to find our way through it. In this case, we have our new element, which will be advancedSearchBtn and I just copy the XPath that I have just seen. It is working here. The problem now, when I open the page and I say await SettingsView, I told you before, if we don’t find all the elements that we are interested in inside a view, the ‘await’-statement will fail after 60 seconds. And this is the case because by default, unless we click the ‘Settings’-button, the ‘Advanced search’-button won’t be visible on the page, so it will fail. That’s why we have element visibility modifiers. If we specify that this element is [ dynamic ], which is very useful for client that generated pages, like pages built with Angular or React framework. This element visibility modify here instructs intaQt to not wait for this element, while we are waiting for the view, but as soon as we want to interact with this element, it should be present. If it is not present, if it cannot find it, it will fail whenever we want to interact with it. If we add additional action here on the advancedSearchBtn, call it clickAdvanceSearch with a ‘click’-action. Put it here under our step definition. As soon as we hit this point and intaQt cannot resolve this element, again, it will do it with a timeout of 60 seconds by default. If it cannot find it, it will fail. Let’s see what we achieved so far. We just need to add here the step that we just defined on web, just navigate to advance search. Let´s run it. It was pretty fast but it did what we want it, so it navigated to the ‘Advanced search’-button. I don’t know if you have seen it, because the Chrome driver is fast. That’s why I added this wait for 20 seconds here. I can stop the test now. I have to wait for it to finish and move to the next step.

After navigating to the settings, we have this big form here. I won’t type everything in all the input fields, but I will show you how you can automate such a big form. What I am interested in: I would like to search for ‘qitasc’ here, so ‘Find pages with… all these words:’, and also, I would like to choose the ‘language:’, it will be English, and ‘site or domain:’, this will also be interested, just type ‘qitasc.com’ and then press on ‘Advanced search’. If I go back, we are already accustomed with the view definition, so maybe you will already know it. We will define a new view for this form and we name it view AdvancedSearchView and we need first of all for all these words input-fields. The form itself has a name; this input field. We can use it. Usually we have forms, the name does not change that often, so it is a good start for the XPath. We can search here by the name attribute. This means ‘search’ need the element that has name attribute ‘as_q’. I see one result, that means it is unique and I can pretty much use it. I will name the element queryInput and paste the XPath I just found.

Then we said we are interested in the language. This looks like a select box, but it is not. Unfortunately, it is something accustomed. An accustomed select box that Google made, so we need to find our way around it. I see here, I can address this element and when I click this element, it opens a pop up. So if I inspect this element, I see it has an ID which I can use and search for it here: element which has an ID ‘lr_button’. Again it is one of one, so I can start using it. It will be elem langSelectBox and just paste the XPath here. After I click on this element, I am interesting into finding the ‘English’-button. So, can I press it? It disappears as soon as it loses focus. So, I go back to the original element and see what changes under here. It will open this one. It is a list containing all the languages that I can choose from and somewhere here I can see the element with language English. Let’s search for an element which has a value. This should be a list element to be more specific in this case. A list element which has a value ‘lang_en’. It finds it for us. Unfortunately, we have to take care here. This element will not be visible in the first place, so we have to make it again dynamic – englishLangBtn with this XPath which has to be [ dynamic ] in order for the test to work.

And the last step is to fill in the ‘site or domain’. Again, we inspect this element with the inspector and we see it has a name and we can search for this name here. It finds no results, because it is a list element, so of course it is an input, but we don’t care. We just say a star *, which means: “Find me whatever element which has the attributed name I search.” I can copy this XPath and define my new element which is domainInput and paste this here. This element is already present, so I don’t need any visibility modifiers. I will start implementing the actions that I am interested in. My first action is to type something in the (queryInput). I will say writeQuery and is of type type. The next action is to click on the (langSelectBox) clickLangBox and the action is of type click. After I selected the LangBox, I have to click on the ‘English’-button, so the action will be (englishLangBtn) clickEnglishButton, again of type click. And the last step is, we just type the domain that I want to restrict my search for. So (domainInput) writeDomain. This will be again type. Now that I have my view defined, which you can see in Webtest. This is where the whole magic happens. This is the difficult part so to say, because you need to work with all those XPaths and stuff, but as soon as you have this definition, you can reuse it across all your step definitions and if in the future the page structure changes, you won’t be touching the logic that you have in here. You will maybe just adapt a few of the XPaths which, again, if you try to be as flexible as you can with your XPath definitions, it will not happen that much.

stepdef – Let’s say we want to keep it generic and be able to search for more than just ‘qitasc’, so I will just type search for { } and leave it open as a parameter and I will name it query. And it is important to close the block. The next step is to await on the view I am interested in – AdvanceSearchView. Under this view I just want to write my query, which is the parameter here. Then I want to select the language, so for this to work I have to click first on the LangBox and then click on the English button. The order matters here, because I cannot click on the English button unless I have clicked before on the Language box. In the last part, I will just writeDomain restriction to be “qitasc.com”. Again, you can make this as a parameter as well. It does not matter for the sake of our example. I just leave it like this. Let’s go back to the Feature and call this step And on web, search for – I just give it a string here – “qitasc”. It is important that this is a string, because parameters for stepdefs are not just simple values, they are expressions here. So you can also have more complex stuff like string-concatenation or context object references. This will be interpreted as a string. If you write it like this, it will try to resolve it as a reference inside the context and of course, it will fail. Let’s run our test and see what happens. Good, now we see here, the automation happens, so it added the values we are interested in. So, ‘qitasc’ here, then it selected the English language and it wrote something in the domain restriction input field.

However, we are not ready, we have one more step to do. Let’s confirm the search and select this button and click on it. I will inspect on that, check what I can use as XPath here. It has ‘class’, ‘style’, this does not help. I can search and work on ‘value’, but this might not be the best option we have, because if it is internationalized, for example if it is the German language or something else, maybe the valuable will change here. I will try to work with this button type. It is a ‘submit’-button type. I know this button is inside the form, so maybe I can just address the form. If go up, I reach the form and I see the form has a name, which is very good, I can use that. I search for a form element with name ‘f’ and under this form, I search for button of type ‘submit’. It cannot find it. Let´s check why. Let’s see what it suggests us, so ‘Copy XPath’. Sorry, this is not the button, it is an input. It found it. Now we can use this one and define a new element here. And very important: elements come before the actions, so we cannot interleave them, we have to put all our elements before our actions. This is the advancedSearchBtn with this XPath. It is already visible, no need for any visibility modifiers. The action on it would just be to click it. So, on the advancedSearchBtn I have to clickAdvancedSearch button and click. I will extend the stepdef here, v.clickAdvancedSearch( ) and run the test again. Now we are on this page and we want to check here that the first link contains this ‘Qitasc – The Magic of Testing’ title. So we go and define a new step, call it “expect first link to have title { }” Leave it as a placeholder so we can automate whatever search we need, not just for Quitasc – / title/ end. As you already expected, we need a way to identify the first link. So again we go on this page, inspect on the element and check what we can find out for our XPaths. We see that we don’t have any IDs on this element, so we go on one step above. We have classes, so we can check if we can make use of the classes. If I am searching for example for an element which has class=’rc’, it found us ten results, as we see here, and all those results map to each link that it found. We can make use of it. We want the first link, so we can rub this around parenthesis and take index one, because we are interested in the first link. And inside this element, we just want to check the content of the title. So, exactly under this element we have a header element <h3>. In this case and we can use it. We will define a new view, call it LinkView. We define a new element and call it firstLink with the XPath that we have just seen in there and the action on it is to just to read its content. The (firstLink) element we will call getContent and the action type is content. After we did our advanced search, we await for this link await LinkView and we will do an assert v.getContent( ) to be equal to the title. Otherwise we just print an assertion “Title of the first link did not match”. Inside the feature file we call this under the expectations block and say on web, expect first link to have title “Qitasc – the Magic of Testing”.

At this point, we are ready with our test case implementation. Let’s run it once, see what happens. It is a success! If we were to have something else, like “Qitasc – the Magic of Testing 2”, we would expect it to fail, because the content of the first link will of course not match. When this is the case we see the message here: “The title of the first link did not match.” We can extent this a bit here, if we don’t want to be constraint only by this first link and we want to check the third link also, we can add view parameters, like call it (nth) – so which one? Instead of having the one hardcoded here, we can use this parameter and say I want the nth LinkView and this is done with this constraint. It is @ and under curly brackets { } you type the name of the argument. This here will be replaced by whatever value we give into the LinkView here and when we use it in the ‘await’-statement, we have to specify it. So we want here the first link. Run it again, to check everything works, and yes, it is pretty much what we expected.

That’s it guys. That’s how we did our first web test. I hope you enjoyed it. See you soon!

Hi, my name is Mihai. I am part of the development team here at Qitasc and today we are going to learn about data test cases.

Whenever we want to start a new test case, we have to create a new feature file, so I will do this right away and we want to automate download on the phone, I name it ‘Download’. And the scenario that we are going to look into today is to download data over data connection.

The first step here is to acquire a phone on which we want to test the download capability. So, I will just go ahead and type Given an phone. It will complete what I need, Given an Android phone as A. It is very important that we have to have a phone attached to our computer, Developer options have to be enabled on the phone in order for this to work. We see that our intaQt^® application is already running on the phone and the status is ‘online’, this means that intaQt^® detected the phone and the two services communicate with each other. So, if I am running this test now, it should be green, which means that intaQt^® could acquire the phone. Next step here, because we want to test the data connection, is to just enable data connections on the phone. So I go ahead and type – it is still in the prerequisites – And enable date connections. We need a timeout for this, because intaQt^® will wait for some seconds. I just say Within 10 seconds, A – which is our phone – enables data connection.

In some cases, for example if the phone does not have a sim card, or for some reasons it cannot enable the data connections within 10 seconds, then our test will fail. However, if we leave this step like this, at the end of our test case, the data connections will remain active, so we might want to do some clean up. Therefore we have the deferred steps, which are right here. Before our enable data connection step And deferred disable data connections. Again, we have a timeout here, I just put 10 seconds. ‘Deferred within 10 seconds A disables data connections’. What the deferred steps do: They will not execute when the main part of the test runs, but will be scheduled to execute after the test ends and do whatever cleanup we need. In our case, after the test ends, we want to make sure that we disable data connections, whatever the status of the test is. Even if the test fails, those steps will be run one after another and we will do the cleanup that we need.

Next step here is our execution. I will write a comment here to know that it is about execution. And we want to download something. I will just write When download. We have our steps here. You see, auto completion is pretty helpful, I can search to the list of the available steps that I have and just select the one I need. In this case I don’t need the ‘deferred’, it just starts download from { } as { }. So, When A starts the download from – what I need to put here is an URL, from where to download our data. It can be whatever, like http://www.google.com/ it will just download the html-page there, but for this purpose we have a dedicated service: We can specify exactly how much data we want to download from there. In this case, from http://testdata.qvie.qitasc.com, and the path for it is /data and exactly under this path we can specify how much data we need. Let’s specify /100MB. We need to identify this download session later, so I give it the name DOWNLOAD in this case. We have the step ‘When A starts a download from’ this service and we see here, we want to download 100mb and we identify this download session as DOWNLOAD. We now have a bunch of steps details and constrains that we can specify. We mark this with a star * and when I trigger autocompletion, you see what I can use here. So I will not specify how many reconnects we need, I will just say it stops after and I can say a time limit or an amount, a size limit, how much data I want to download. I will just say after 2 seconds. Great.

And after the execution steps, of course I want to do some verifications and I will expect the download to finish at some point. So I say Then expect download – that is what I need. Within 5 seconds, A – it is my phone – expects the download – which I identified with this DOWNLOAD identifier – to finish. Within 5 seconds I expect my download to finish. The reason why I need to put here this identifier is that I can start multiple download sessions. This execution step here does not block. It starts the download and this runs in the background and our execution continues. What I can do is to start another download or do something in between and in the end I have to wait here with the timeout of course, because if the download does not finish or something inbetween happens, I need a way to stop it and not to wait indefinitely.

Let’s run our test and see what happens. It acquired a phone, now it enables the data connection. You saw that this step starts download. It took very fast, so we did not block, it starts the download and then, it expected the download to finish within 5 seconds, which it did, and, in the end of course, the deferred steps, where the data connection got disabled. So our phone remains in a clean state and we know what we expect for our next steps.

An interesting part here is, the report that gets generated in the end, I show you very fast. Under ‘Qitasc’, in the ‘intaQt-server’ installation directory, under ‘reports’. Just take the last report that got generated, so the ‘Download’. You see here a graph that’s generated after the test case. This is a plot that shows us the speed, in this case it is in bytes per second, depending on the time. We can analyze how fast the download was. In our case it´s just for 2 seconds, so we can’t analyze that much, but if you observe it over a longer period of time and if you want to test some limits on the sim card. For example, if you have only 50mb of download available with 4G speed and you need to see that after this 50mb, the speed drops to 3G You can observe this behavior in this graph. Of course, this can also be automated with steps, but this is a more advanced topic for now.

We will just show a simple check that we can make, because in the download, we have some data that´s persisted. And it is available for us to check some details about the download session. In our case, we have to verify the download is under the result object. It stores here some bunch information, which is very useful for the verification step. It is all documented in the manual. So, please check that out if you need some special information what to test. In my case it is the summary.nrOfBytes. I want to see that I at least downloaded 1024, so that I at least downloaded 1kb. Let’s run this again and see that it behaves as I expected. In this case it is more than 1kb, but let’s say we want to put more pressure on it and say, I want it to download 10mb. So I will just write the multiplication for that, which means 10mb in the size of bytes. When I run it, maybe it can’t make 10mb, let’s see. And if it can’t do 10mb – no, it did more than that, in 2 seconds. Let’s increase this a little bit to 50. And in this case, in 2 seconds, the download of 50mb is a bit too much. So as expected, our verification step fails.

Now, that we have seen how a download scenario works, let’s go ahead and try to upload as well. I create a new feature file for that, name it ‘Upload’ and we want to test ‘uploading data over data connection’. This is very similar to what we have here, so I copy our content for now and we will adapt it step by step. For the first step, for sure we need an Android phone for this to work. The enabling and disabling of the data connection, of course, has to be here, because we need to make sure, before we start uploading that we have the data connection. This is what we want to test. What needs to be changed here is the execution. We won’t use the download step, but we will use the upload step, and this is called ‘upload random data’, ‘starts uploading random data’. We don´t need the timeout, we just use A starts uploading random data. Of course, here we need again an URL where to upload and we need a name for the upload session. I just call it UPLOAD in our case. A starts uploading random data to { } and here you can specify an URL to where to upload the data. In our case, our dedicated service is similar to here, also covers this scenario, so we copy the link and instead of /data, we have the /upload, the upload path that you can use for your test. This just eats up whatever you give it and ignores it, it is just an upload random data.

For this step, again we support multiple details. Autocompletion says us again we can use reconnects and we can stop after some amount of time or after bytes that we uploaded. I go ahead and stop it after 1MiB. So it will upload 1MiB to this server and it will end. For the verification steps, it is also similar, but we don’t expect download to finish, but upload, and this is identified by the UPLOAD identifier. Now we said, it stops after one MiB, we can check that the upload time did not take more than 3 seconds – durationSeconds. I want to check here that my upload duration is shorter than 3 seconds, or let’s make it 4. We don’t know what the data speed on the sim-card is.

Let’s run it, see how it works. It started the upload and now it waits for it to finish. It seems like it is too much. So it did not finish within 5 seconds. Let’s go a bit lower with our upload size like uploading 100kb and check what happens now. O.k., now it is finished. It seems like this MiB was too much to finish within 5 seconds. 100kb, it could easily manage it and also our duration was shorter than 4 seconds. If we, for example, expect it to finish immediately, like less than one second, I think this might fail. Let’s see – no it is still o.k. I think 100 kb is too few, but you get an idea.

So yes, we have seen now how to do some download and upload test cases. Those are the basic scenarios that you can use to test a sim card data connection and I hope you enjoyed it. Thank you very much for your attention.

IoT test case with intaQt studio

Hello, my name is Bernhard from the electronics department of Qitasc. Today I would like to present an IoT project with an IoT test case.

The system we are testing consists of a system that is installed at home, a smart hub from the company Samsung in this case, and a door-window-contact as example. We can also use other devices, but in this case I would like to demonstrate a test case with a door-window contact. And a mobile phone.

We want to test the behaviour that you have at home. You have attached the door-window-contact to a window and want to receive a notification on your mobile phone as soon as someone opens the window.

Now we want to test both ends automatically. We do this by not mounting the door-window-contact on a window, because how do you open a window automatically?

We have mounted the door-window contact on a device that has a servo motor attached to it and this servo motor can open the window, so to speak. It folds the door-window-contact away from the magnet. Here is the magnet, here is the door-window contact. This part can be folded away and closed again.

The door-window-contact is connected to the Samsung smart hub via the Zigbee radio protocol and the Samsung smart hub is connected to a backend server at Samsung via the internet.

The phone, on which an app is installed, is also connected to the backend server at Samsung and via this connection, the connection to home is established. When the sensor detects that the window is opened, the information is transmitted to the backend server at Samsung. The phone is then notified that the window has been opened and is supposed to display this on the app.

That’s what we want to test. In order to do this, we have this servo motor. This servo motor is controlled by our electronics.

This is the board with the electronics. Of course, it can do much more than just control the servo motor; all the functions are also integrated. It is important to know that there is a Raspberry Pi in the background. This Raspberry Pi is also connected to the network and can be controlled by us. It then controls the functions on this board. I can connect four devices to this board.

In this case, only the first device is connected, here this door-window-contact. Via this platform that I have here, I can not only control a servo motor, I can also control many other functions.

For example, I can also simulate the battery here. So, there is no battery inserted in this sensor, but a battery dummy is inserted. This battery dummy is supplied by this circuit board.

With it I can also test, for example, the case when the battery becomes empty, that the device tells me that I have to replace the battery. I can also use it to switch relays and perform many other functions, adapted to the application, which is needed for the automation of a smart home.

The test case is processed via the intaQt studio as usual, which is our platform. Various steps are carried out in this test case, which are formulated almost naturally in terms of language.

We start by wanting to get the phone: Give my phone as A. Here even the serial number is given. That means I get a phone that has to be connected to my machine with this serial number.

And insert a full battery into the device multipurpose sensor demo. The device here, this door-window-contact is a multipurpose sensor. It can do more than just door-window-contact, that’s why it’s called a multipurpose sensor. And I put a full battery into that.

Then I open the app on the phone. And close the window monitored by the sensor MultiPurposeSensor_Demo. I make sure that the servo motor brings the door-window-contact into the initial position “closed window”.

Then on A – That’s the phone, we got it and called it A. Then on A, select the device MultiPurposeSensor_Demo from the devices menue. So on the phone the app is opened and in the menu of this app we go to the sensor we want to look at.

And on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”.

We have previously set the sensor to the initial position “closed window” and now also want the app to indicate that the window is closed as an initial condition. And then the actual test begins.

Then open the window monitored by the sensor MultiPurposeSensor_Demo. This means that with this command, the servo will swing the sensor away from the magnet. This will look to the system as if the window is open.

Then we give the system three seconds to wait. And wait for 3 second, so that there is really enough time for the sensor to notice this and for it to be transmitted. That’s often a problem with automated test cases, that you don’t expect the machine to be that fast. Much faster than you would be as a human being.

So the automat can do that almost simultaneously, but that would go wrong. So you have to give the sensor the opportunity to react, to transmit it all, to play through to the backend server at Samsung and then down to the phone. And that’s why there’s a three-second pause It’s also easier for us to observe what’s happening that way, because it’s slower.

And on A, assert that the contact sensor on the MultiPurposeSensor_Demo says “Open”. That means we want to see after three seconds that the app shows that it is open.

And again we wait for three seconds: And wait for 3 seconds. Then close the window monitored. That means we shut down the sensor again. This time we even wait for six seconds and then we see that the app again shows that the sensor reports closed.

I will now start the test case:

The phone is now received from our test machine. The test case name is already displayed. Then the app is started. The sensor is navigated to in the app. And then it is verified whether the initial condition is correct. It said “Closed”. It opened, now it says “Open”. After a waiting period, it then moves back to “Closed” and we also want to see that it says “Closed” again.

This is the case. Test case is green and has the state “Passed”. So it worked.

We want to look at what would happen if the test case went wrong. Would we notice that?

I will start the test case again and then I will intervene so that the window cannot be closed. The sensor will continue to report “Open” even though the window is supposed to close.

Now it has moved to the initial position “Closed”. It is navigated to the sensor. The sensor must show “Closed” as initial condition. That is the case, it is “Closed”. Now it is opened.

Now I hold my finger inbetween and make sure that the servo motor can no longer move the sensor back to the “Closed” position. This means that it continues to display “Open” even though it has actually closed the window, and that is an error.

And this error has also occurred here and has been detected, in this case: on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”. But it still showed open. It is an error. It has been detected by our machine and displayed accordingly.

Interested in more? Visit us online! www.qitasc.com

Hi, I’m Jamie from the QiTASC development team. I just wanted to give you a quick tour of the cheQ UI to show you the basic features.

Within cheQ we have these 3 tabs on the left:

TRACES lets you look at the traces that have been uploaded to your system. It gives you an interface very much like Wireshark where you can navigate through traces. You can perhaps filter traces based on certain features, such as here I use a SIP call ID showing only the SIP packets with this call ID. But this is all that TRACES functionality gives you. It’s just like a mini Wireshark.

The real power within cheQ comes when you create a cheQ test case.

Now cheQ TEST CASE basically says how a comparison will happen and refers to what we call the Golden Trace, which is a PCAP trace, that is how you expect the behaviour to be. Here our standard SIP call test case says that the golden call trace is our golden trace. We are going to filter it just to show the SIP packets.

Then we have some more advanced features, like for example you can group the SIP packets into transactions and compare transaction by transaction, or you can just compare packet by packet.

We also have the ability to assign name mappings to fields.

IP addresses from a trace captured on one system can be correctly matched to an IP address in another system. Even though the IP address might be different, if the underlying meaning of the IP address is the same, then it will be compared.

And finally, we have of course the COMPARISONS.

A comparison is basically a brand-new trace coming in, which is shown on the right here, compared against our golden trace shown on the left. When you click it, you get a breakdown, showing you all the different packets that have been matched up by cheQ, whether or not they match.

If they don’t match, you have the option to exclude them, inspect further, or do more advanced features like for example add name mappings.

That’s a quick tour of cheQ.

Hi, I´m Jamie from the development team at QiTASC. I’d like today to show you how you can use intaQt and our comparison tool cheQ together to see how network messages are sent as expected when a test case is run.

If we are running a test case in intaQt where a PCAP file is generated, it will look something like this, where we have steps, taken phone, we have acquired two phones, we make a call, some time. As part of this we will be capturing a PCAP trace.

What happens when you do this is after your test case has run and has been sent to our conQlude reporting tool, conQlude will then forward that trace to our cheQ tool and let it do a comparison between the expected behaviour and that trace.

Let’s take a look at how we can configure a comparison in cheQ first and then we’ll run a test case and do an actual comparison.

This is our cheQ comparison tool. It’s a web-based tool which gives us an interface similar to Wireshark. You can load traces and filter them.

Inside cheQ you can create a test case and this is simply a golden trace, which is our trace of expected behaviour, and some filter. There’s also some more advanced features that we won’t show today like groupings where we can group SIP transactions for example together and then compare by group.

And there is also name mappings where for example if you have servers in one network for one trace and servers on another network in another trace, you can map names to these servers. As long as they have the same name, when the comparison happens, it will compare the names and say yes, they are identical, even though the IP address might be different.

So here you can see we have a test case or comparison in cheQ set up with ID 25. And now back to intaQt studio we can see, we are linking to this test case in our test. Then once we run this test, the PCAP file captured as part of this will be sent with our test report to the conQlude tool. Then conQlude will take the PCAP file, send it to cheQ and make a comparison.

Once cheQ is finished with the comparison, it will be sent back to conQlude and the report here will be updated with the status if the comparison passed or failed.

So, let’s run this now. I’ll right-click in the window to run this test.

Our example test case is finished, the PCAP file has been sent to conQlude. We can see it’s in pending status, because it’s in a process of being sent to cheQ to be compared.

Now you can see the trace, it says it’s pending. If I refresh now you can see it’s failed. And the reason it’s failed is because this is a completely separate trace.

We would expect it on the first comparison to not pass because for example checksums, time stamps, call IDs will all be different.

You can see the intaQt steps all passed, but it is the cheQ comparison which has failed. Because this has failed the overall test case has failed.

Now we can click here in conQlude to jump straight to cheQ to see why the comparison failed. You can see actually all the packets are the same. The call happened just as we expected. But things like checksums, headers, maybe ports will be different.

With this first comparison, what we can do is tune how the next comparisons will happen. We can select all the fields that we want to ignore, for example call ID, checksum, from-tags, to-tags, the authenticate.

If we select all those that we know will be different with each trace and redo our comparison, you can see we get a green check mark to say that everything starts to match up. And finally, everything is green.

Now is a good time to talk about why we do the cheQ comparison separate to the test case.

A question you might have is why not just simply do the comparison as part of the test case and then send the result to conQlude. The reason is, the phone call that might happen could be multiple phone calls. The trace collection could be multiple traces that then are merged together on different servers and then it maybe takes time to be sent to the test case. This can take a long time, this can take hours. And if there is some problem with the comparison, we don´t want to have the to run the whole test case again, make the phone calls again, capture the trace again, send the trace to a server where it´s accessible again. What we want to do is just rerun the comparison.

By doing that via conQlude, what we can do once the trace is tuned, is go to the DETAILS tab here and just say: “Update conQlude report with this comparison”. Now we don´t need to rerun the test case. We just click here, now this success condition has changed, it´s now passed, the overall state of this test case is now passed, and you can see by clicking here, this is the comparison that’s passed. So now, any future runs of a test case where we capture a new PCAP trace will automatically ignore the things we just ignored.

Now I’ll give you an example if we run a trace which I know should not match. Once again, we’ve run it, but this time the trace that has been sent has something unexpected in it.

If we go to conQlude and look at this test report – it’s still being checked by cheQ – and it’s failed.

Now the question is, has it failed for a valid reason, something we can ignore, or is this a real problem that we found?

By looking, because we have already ignored the key things that we know are ok to ignore, we can skip over these packets immediately. We know they match.

The very first thing is that is red here and doesn’t match, we can see there’s a problem. Because the call has been unable to negotiate and agree on a codec, this test has failed, because the call has not been accepted.

This has been a quick tour of how our test case in intaQt via conQlude can leverage the cheQ tool to make PCAP comparisons in a very efficient way.

What you see here is our acceptance test environment. We have different tables with different functionality.

Let´s start here with our analogue and ISDN infrastructure.

As you know telecom operators don’t need analogue and ISDN telephony any more. But there are a lot of CPEs in the market which still have this technology inside and people use it. In order to test it end to end, we would need to connect an analogue phone to this CPE and automatically dial, but unfortunately these old phone types don’t support remote control.

Therefore, we have implemented analogue cards and ISDN cards in this tower PC. This is connected to our test infrastructure and from there we can control this PC and these cards. This emulates an analogue telephone and an ISDN telephone.

So, we can do everything with this PC and these cards that a human being can do with an analogue phone or ISDN phone.

And we can test the CPE. We can also connect some Voice over IP phones and so on and we can test everything.

There are also some configuration activities which can be done here on this CPE. Therefore, we have a UI automation of web services where we can also control the graphical user interface.

Here, as you see, we have iPhones and Mac minis. This is the Apple environment, the Apple infrastructure.

Here we also remotely control these devices and can make calls and send SMS and this kind of stuff.

This table is used for Android phones. Here we have Android phones. They have an open interface, and we can do everything a human being can do with these phones.

We can automate everything. We can run apps, we can make basic calls, we can send SMS, we can do the USSD activities. Everything that is possible can be automated.

We have an IPS here, this is the intaQt phone service.

Like the Mac mini there, we can control this environment via the gateway. We can also connect some IT systems to this box and then remotely control and do something with the IT infrastructure as well.

Then we have here our own phone hub. This is our own hardware. With this we connect to the audio jacks of the phones so that we can inject audio, or we can record announcements and tones in order to validate the speech channel on one side, and on the other side we have the capability to control the charging of these phones.

We can control the signal, the charging strength and limit it, so the phones do not permanently charge, and the batteries are not destroyed.

The newer models of Android don’t support an audio jack, they don’t have it any more. They work purely with Bluetooth.

In order to overcome the missing audio jack, we have also developed a small box which we call Bluetooth adapter where we have three Bluetooth antennas inside, so we can connect to three different Android phones.

We don’t need the audio jack any more; we can do the audio via Bluetooth.

Finally, this is the environment which we use for Voice over IP testing. Fix network functionality is covered here.

All these phones also have an HTTP interface and via this interface we can control these phones.

We have a Raspberry Pi-USB combination in order to record announcement, tones in the same way we did with Android. So, we can call from here to a mobile device and verify the speech channel in both directions.

And finally, we have here our SIM array. This is a box where the SIM cards are stored in these boards and the SIM information is mapped via internet to one of these boxes and from these boxes it goes into this phone. The phone thinks there is a SIM card inside one time rebooting and the phone is available for service. Without touching the phone, we can change the SIM cards inside these boxes.

And here you also see some Bluetooth modules. These are single adapters where you can also connect it with one single phone and do audio exchange.

So, this is basically our acceptance test environment.

Interested in more? Visit us online! www.qitasc.com

Remote lab: IoT setup

Acceptance Test Environment for IoT Tests

This is our test acceptance environment for the IoT testing.

Here we have several devices which are connected to hardware which is developed by us. We have four different devices.

Here we have a smoke detector. On the back you see the hardware which we have developed.

We have a microphone which is installed here. This part is also connected to the servo motor which can press some buttons on the smoke detector.

And what we also do is we have real oil inside and we burn it. We generate temperature here which burns real oil and this goes into the detector and an alarm is generated immediately.

On top we have a fan. With this fan we take the smoke out and then we expect that the alarm vanishes. We can trigger all the conditions which are necessary in order to handle these devices.

Here we generate smoke. We detect, we have a microphone inside, we record the signal strength, and everything is then automatically controlled by our test infrastructure.

On the bulb here, we have an RGB-sensor connected to this, so we can measure the colour of this bulb. Automatically, it changes. We can trigger it from our test infrastructure. So we change the colour, we measure it, and then we compare the measurement if it really fits to what had happened here.

Here we have movement detection. We generate with this bulb some infrared signals and with the servo motor we can move it.

And here is the detector. If it detects motion in combination with heat, it also generates an alarm. And here we have a magnetic sensor which acts on a window. If the window is opened, the magnetic contact is broken and then it generates an alarm.

We can trigger all these events independently. And you also see here the place for the battery. This is also one of ours.

With this thing we can control the current in the battery. If we have a low battery status – or we can trigger it as if it has a low battery status – then these sensors have also some specific tones. There is also a microphone integrated here in the bottom. We measure then the low battery signal. We can create any use case a customer normally has with these devices.

We can generate and emulate it with our environment.

Interested in more? Visit us online!

This is our mobile testing centre.

It’s in a case because we want to send this testing centre everywhere in the world. The only thing you need to do is to connect the LAN cable and power in order to get it up and running and to connect it to our test infrastructure where we run our test cases.

This case is equipped with six mobile phones. They are connected to the intaQt phone service which is our gateway into this environment.

And we also have an intaQt phone hub inside this box. Via this phone hub, we connect the phones to the audio channel of the phones. One reason is to record the announcement and tones which come from the network.

Another option is to inject audio into the phones to create a scenario where you say something or send some information into the network. In parallel we control the power supply for these phones.

The phone hub gives us the capability to control the strengths of the power signal, so the phones do not charge permanently. When they charge permanently, it happens that the battery is destroyed after six months.

What kind of test cases do we do here?

So currently, we run some data test cases where we measure download quality, upload quality and latency of the sessions. We can run them individually one by one, or we run them in parallel and compare different SIM cards and brands with each other.

Of course, any other test cases can also be applied. You can run app test cases, you can run other voice or SMS test cases. It’s up to the test scenario.

When the test cases are finished, we push all the results into an elastic database. This big database gives us the capability to create nice dashboards so we can see all these activities which happen here in a graphical, representative format.

Interested in more? Visit us online! www.qitasc.com

IoT suitcase. An explanation of the components.

Here we have a demonstration of automated end-to-end testing using our intaQt software. For this we use two smartphones with the app installed and a door sensor, smart plug, motion sensor and smart bulb as our devices with a Zigbee Sniffer to monitor backend traffic.

The human interaction with the devices, such as opening and closing a door or pressing buttons, and other movement, is simulated using servo motors.

The usage of the phone is directly emulated by our intaQt software.

The backend traffic is symbolised by LED strips and monitored by the Zigbee Sniffers. The setup of the devices themselves, such as the RGB sensor for the light bulb and the status of the phones, is also monitored.

Everything else occurring in the test case is then logged and uploaded to the server so that if any error occurs the technicians and programmers can easily find out where it comes from.

Interested in more? Visit us online! www.qitasc.com

Hello! This is Can from QiTASC. I would like to introduce our international roaming box. It is a wooden box with electronic equipment inside. Let me open it!

It has a front and a back. The front has some stickers on it, the back has no stickers. We have some additional equipment inside.

What do you see here?

In front, we have the phones, then we have a Linux computing element, a QiTASC Phone Hub, which is similar to a USB hub, a Raspberry Pi KVM, a router and a power strip that is remotely controllable and provides power to this equipment.

What do we do with that?

Let’s start with our computing infrastructure. To control the phones, do test automation and stream user interfaces, we have a computing element here – a Linux PC. We run our software on it.

Next, we have the Raspberry Pi KVM, which allows us to expose the monitor, keyboard and mouse of this box to anywhere in the world. So, if you’re in Germany and the box is in the UK, you can remotely see the monitor of this device.

Then we have the QiTASC Phone Hub version 3, which provides audio capabilities. It contains Bluetooth cards, allowing us to connect to the mobile devices via Bluetooth.

We have a cable connection to the USB connector, allowing us to control the devices fully automatically. We also control the power supplied to the phones.

We can emulate a real-time scenario where we power them down – controlled by this system –and once the battery level drops to 20%, the system will automatically power them up and begin recharging.

With this environment, we can run any kind of testing services and any kind of test cases.

One big advantage is – because if these phones are abroad we cannot insert SIM cards because we work with different customers – so we use a SIM array integration.

You see the brown cables here, which connect to where we would normally place SIM cards. They look exactly like SIM cards. These cables connect to a small electronic component, which is connected to our SIM array via the internet.

The SIM cards in this box are in Germany. We can push the SIM information via the internet into this electronic box behind the phone, and from there it is transmitted via cable to the front. So the phone believes there is a SIM card inside.

We can switch SIM cards easily. If, for instance, we have a Vodafone SIM card, we can send the Vodafone SIM information to this here, and from there it is transmitted via cable to the front. The phone reboots and is fully functional with the Vodafone SIM card.

After five minutes, we want to switch to an A1 SIM card from Austria. We follow the same procedure: We push the A1 SIM information, the phone reboots, and it recognizes the A1 SIM card. This allows us to switch SIM cards.

With this setup, we can call from Vodafone to A1, we can call from here to a local number, perform IVR testing, do voicemail testing and run any kind of test. We can also do data sessions, we can open WhatsApp and send messages, we can send SMS and browse the internet.

All of these scenarios will be accessible to anyone around the world via this box.

Thanks a lot! Have a good day!

Interested in more? Visit us online! www.qitasc.com

Getting started with the QiTASC international roaming box.

Firstly, make sure where you want to install the box you have access to your modem and a power supply of at least 150 watts.

Secondly, take your package. Open it carefully along the top, taking care not to damage the internals. Then remove and dispose of the filling.

In your package, you´ll receive the box itself, a black power cable and a red LAN cable.

The rear of the box has no stickers. The front of the box has clips so that it can be removed.

Make sure when you place your box, you leave at least 40 cm in front to allow room to pull out the extendable drawer.

On the side of the box, we have both the LAN port and the power cable port.

Step four is plugging in the LAN cable to the box. Plug one end of the cable into the port on the box and the other into your modem. Plug one end of your power supply cable to the box, and the other to your socket. If you have a switch on your IR box, turn it on now.

Step six is turning on your IR box. For this, we need to check that the components within are running.

Firstly, remove both the rear and the front covers. To check if the components are running, you can check for lights on the front of the IPS and in the rear, lights on the phone hub. If you don’t see lights it could be that the internal main power switch is off or secondly, that the circuit breaker underneath here has tripped.

If the main switch is activated, press the large orange button to reset the trip switch. If you have accidentally made contact with the yellow switch, simply press the big orange switch again to reactivate.

You may have been provided with three or four phones in your box. To turn them on, hold the power button for three seconds. The phones will start.

No other actions are necessary, everything is preinstalled for you. Your setup is now complete.

To finish, close up your box and confirm to QiTASC via email that your setup is ready. Your box is now part of the QiTASC global remote testing network.

Interested in more? Please visit us online! www.qitasc.com

I will now show you how to restart your IR box.

To do this, the IPS should be shut down first by holding down the power button for three seconds. And wait 30 seconds for it to finish shutting down. Once the IPS is shut down, you can then turn off the power to the entire box.

To restart the box, turn on the power. And then, check that the lights are active as shown in the get started guide. Both on the IPS and on the phone hub.

If you need to, you can then restart any phone as required.

Interested in more? Visit us online! www.qitasc.com

Hello, my name is Can Davutoglu, and I am the CEO of QiTASC. I would like to give you an introduction to international roaming.

We are a test automation company, and we have developed an international roaming service. We place our international roaming boxes in different countries, including Norway, Belgium, Turkey, the UK, and more.

Let’s talk about the reason why we offer this service and why it is needed.

Let’s assume we have an Austrian operator with subscribers who are travelling, for instance to Norway or Belgium. Once they are there, they expect the same services they have in their local country to be available in these countries as well.

In Norway, there are different operators: Telenor, Telia and Ice. These operators provide telecommunication services, and the Austrian operator has a contract with one of them or sometimes with all three. The services they provide are the same as those available in Austria: 2G, 3G, 4G, 5G, VoLTE maybe, VoLTE WiFi, and so on.

To make phone calls, once they travel to Norway, they need first a contract and, second, a signal. This means that before you leave the airplane you switch on your phone and it registers, let’s say, with Telenor. Then you then receive a welcome SMS, and the Austrian operator tells you that you are now on the Telenor infrastructure. There are certain tariffs that are now valid for you.

Now, you expect the same service quality that you would have in Austria.

However, the Austrian operator has no idea if these services are working well or not. That’s why we have international roaming testing.

This means, we register on the operator’s network, make voice calls, conduct data sessions, send and receive SMS, open apps and use them. If this is successful, everything is fine.

Then, we have a SIM array infrastructure. Via this system, we can tell the device to use Telia as the next operator. We do the same tests on this operator. Then, we test with Ice, determining the quality of the services in Norway.

The same applies when we travel to Belgium. Again, we have a contract with the local operators: Proximus, Orange and Base. We use the same services and run the same test cases in Belgium. This is for quality assurance, but there are also other factors to consider.

Let’s assume the subscriber base in Austria is growing. They have NDCS, national destination codes. These can be three, four, or even five digits. And there can be new ones, such as 662. These new national destination codes also need to be tested.

So, we insert a new SIM into the SIM array in Austria, simulate our trip to Norway, and check if the new NDC works with the Norwegian infrastructure. We then do the same in Belgium, then in Turkey, the UK, the United States, India, and so on.

Another scenario is when the Austrian operator introduces a new service, such as a prepaid card service. This means we now have a new service, the prepaid card service. This is introduced.

Again, we have a new SIM card, and the SIM information is put into the SIM array, pushed to the phone, and the phone is activated with operators like Telenor, Telia and Ice. And we check if the prepaid service is running well. Again, we repeat this process in Belgium and so on.

Then, of course, there can be new devices or a new operating system that have to be installed on these devices, and network changes may be applied. This also has to be tested. It’s not just about introducing new services – the networks in Austria and Norway are constantly changing. Once it has changed, we need to check if it is still working or not. This is also done with international roaming testing.

So there are many reasons why we need to test international roaming features and their quality.

With this information, operators can determine which roaming partners they want to work with and whether the service quality is given.

I hope I provided some useful insights into international roaming.

If you are interested in our services, please contact me. Feel free to call me anytime. Bye!

Interested in more? Visit us online! www.qitasc.com

Hello. My name is Can Davutoglu, I am the CEO of QiTASC.

We have developed intaQt, which is our test automation framework. I would like to give you some insights related to international roaming in comparison to our competitors.

We use real devices. Real devices have a lot of benefits. They have built-in features and functionalities.

Our competitors use modems. This requires additional software development in order to provide basic functionality.

We can run apps on the mobile devices, modems don’t. There is no UI streaming on the modems. We have implemented UI streaming and audio streaming so we can see what is happening on the calls. So, this is one major benefit.

With our mobile devices, we are much closer to the user behaviour than when you program a modem.

A second important topic is that the code writing is totally different. We have prepared our solution with a low-code environment, we have integrated Cucumber, and we use emi-sentences to describe our scripts.

When you do modem coding, you normally have Python coding or graphical coding, building blocks which you put together. It is quite complex to integrate such a solution with new open-source tools. Data exchange between the modules is much more difficult. You need to develop additional code. And reporting also becomes complicated.

On the other side, with our solution with a built-in reporting environment we can easily generate reports, we automatically collect evidence and stick everything together. We even do automated verification of the evidence. This is also triggered automatically by the environment.

Another big difference is that our solution can handle really complex use cases. So, for instance, if you have a multi-SIM environment, with 10 SIM cards belonging to one person, and you have a call to this group, and this group performs call forwarding to another group of 10 devices. Then you have in total 21 mobile devices in one use case. We can handle this kind of complexity in our use cases. If you have multi-ringing, we identify that one phone is ringing and the other is not, and so on.

So, it is really a big advantage to have an out-of-the-box solution which can handle this. If you want to do something like that with a modem solution, it will be a real pain in the arse.

Another functionality is that we can view older activities which are ongoing during a test case. We have created this environment where you have the locations with the roaming boxes and where you have different devices. You start test cases and you see exactly what is happening with your SIM card in Paris, for instance, when you make a call.

Or if you are running an app or use WhatsApp in order to do some messaging. This is also one major difference to the modem solution.

Another big advantage is that we have implemented multitenancy. This means we have a big environment of hundreds of devices and we can assign a certain group of devices, SIM cards and IPSs to a project and to a tester.

The others will not see what this guy is doing with his devices. They will not even know that they exist. So, this is a major thing which makes projects much easier to run and helps testers to do their work.

Another important topic is the integration, the easy integration. We have a solution which is capable of controlling the devices and so on, but we also have the integration layer for integrating it with a telephony application server, with an intelligent network solution, so that we can create a subscriber from scratch, we can create the tariffs from scratch, assign it, and run the test cases. On the other side, when the reports are written, we push them automatically to Jira or to ALM.

Another big advantage is that we have implemented a calendar. With this calendar you can book your testing resources, the locations and the project beforehand. Then, the testers can run their test cases exactly in that time window, and they will not be disturbed by others with this multitenancy feature. You also have the capability of booking and controlling your project in advance with your testers for a given test topic or test object.

Last but not least, we have also built in out-of-the-box dashboards and reporting of the solution. So, we have pie charts, we have heat maps, out of the box and linked to the project. When you click on one of these red boxes which indicate that there was a failed test case, you will be directly linked to the report, which is in our reporting solution, and the report will be opened. You have all the evidence, and everything needed to analyse your test case.

These are the main topics of what we have in comparison to our main competitors.

I hope you like it. Please contact us if you need more information. You can call me anytime! Bye bye!

Interested in more? Visit us online! www.qitasc.com

Test automation with QiTASC

Hello, this is Gamze from the Sales Department. I will introduce our company to you and also introduce our smart system test automation.

QiTASC is the initial soft quality-improving tools and services company. We stress that our key task is providing and keeping high quality. We automate and validate digital processes and scenarios end to end. For this we develop the necessary tools.

We have developed intaQt, the intelligent test automation and quality assurance tool, and there are many possible areas of working with intaQt.

We automate mobile devices, PC clients and MacOS, apps in tablets, apps in Android, trace integration, attenuators, VoIP phones, remote accesses, roaming, IoT devices, backend systems, web and app user interfaces, reporting, data correlation and verification, protocol and network simulation, and we also automate apps in iPhones. Therefore, we call intaQt the Swiss pocket knife of automation.

Smart infrastructures need smart testing. This is why we do test automation.

For companies who are developing digital products and services, continuous integration and continuous development is required nowadays. There is great demand for increased technical abilities from the customers which leads to more complicated systems to be tested.

On the other hand, time to market is tighter. This leads to a phenomenon called quality at speed. There is the need to increase the efficiency of testing. Therefore, test automation is essential.

Now I will talk about IoT test automation. There are two goals in IoT test automation. First of all, we have to ensure that the IoT devices work properly. Secondly, we have to ensure that they communicate with the apps properly. And there are challenges of course in IoT test automation.

First of all, IoT devices automation requires physical interaction which is hard to automate. And secondly there is a multicontext framework which is hard to automate end to end within one scenario.

We have IoT devices, apps, web user interfaces, backend systems, gateways, network elements and so on to be automated in one test scenario end to end.

How do we overcome these challenges?

We developed a framework to automate IoT sensors. We developed housings in which we integrate actuators, sensors, motors, fans to enable physical interaction with the IoT devices.

The actuators are put in housings that we design and develop to trigger the IoT devices. These actuators are connected to intaQt via an electronic layer. This is the phase where we developed these housings. And then we put these housings on a platform and at the same time we can test hundreds of IoT devices, which is very efficient.

In this scheme we see the basic setup for testing three IoT devices. These actuators are connected to intaQt via a Raspberry Pi unit. These actuators trigger the IoT sensors and IoT sensors communicate with the apps in the smartphone via device and gateway domain and network domain.

In this structure we automate the actuators, we automate the app, and we also automatically collect all the data in the backend systems. Therefore, we automate the traces and log collection. A failure in this system can occur in various parts and there are hundreds of combinations of tests to be done which cannot be done manually.

Automation is essential in this framework. Once we set up this framework it is easier to repeat the tests. It is quicker to find the defects and it is quicker to go to the market. Therefore it is very convenient for the companies who are developing such smart systems.

This framework can be enhanced to various areas like wearables, smart cameras, smart meters, smart payment technologies, smart surveillance, mobile and desktop applications, broadcast streaming and signal quality, face recognition technologies, non-touch solutions, kiosks and various other areas.

There is a very nice example of our IoT test framework which is a small detector automation. You see a demo video here.

Our very innovative test automation frameworks which can be used in many different areas – this can be telecommunications, IoT systems, finance or health care systems – are preferred by lots of customers in various countries in Europe.

Some of the names of our customers are in this chart.

Thank you for listening. I hope you ask for a demo or if any questions arise, please contact us. Thank you!

www.qitasc.com

Use case: Airport

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC. I would like to show you the telecommunication infrastructure at an airport and how we test it.

Let´s have a look at the airport.

We have a passenger who comes to the airport. There are different phases he is going through until he leaves the airport by flying away. He comes to the check-in and there he leaves his luggage and has some activities to do there. Then, there are of course different scenarios which happen at the airport: The luggage is put on a belt or taken from the belt, there is maybe info, there is transport of luggage, and of course there are all the people working here. Maybe there is some construction work, or there is the fuel truck, which provides fuel to the plane, there are people who clean the plane, there is security somewhere. And all these people need to communicate with each other. This is done via a very, very big communication infrastructure.

We have 2G, we have 3G, we have 4G, some airports handle it on 5G infrastructure, we have Wi-Fi, we have IP telephony, we have analogue telephony, some of them have 450 MHz networks, some of them have Tetra, and some still use high-frequency communication via UHF-VHF, and so on.

You see different communication technologies. Somehow, they have also gateways to the outer world, or they have PBXs inside the airport. They also have gateways where one technology is transferred to the other. You have maybe 4G telephony coming in and then IP telephony going out into the gateway. All this happens at one airport.

We from QiTASC have developed intaQt, which is a software. With this software you can control the devices.

What do we do? When we have a mobile device which uses 2G, 3G, 4G, we connect ourselves via USB to this mobile device. From then on, we can control this device in any manner. Everything a human being can do we can do with that.

At the check-in for instance, you have maybe a normal desktop phone and this has an HTTP interface. We can control these IP phones via HTTP. We can also have for instance analogue telephony. Some airports still have analogue telephony. Here we have an emulation, and we can connect our emulation controlling the analogue phones. Maybe here we have some Tetra devices which are slightly different than normal mobile communication. Here you have push to talk and this kind of applications – we can control that.

But some of these devices are very proprietary. They are maybe built in in some construction and you need to press these buttons in this environment. What do we do? We make a 3D housing around it, where we have some servo motors inside and some electronic components. We can press the buttons as requested and even control this kind of device and speak to it.

The construction workers have some devices, the transport company has some devices, the fuel truck has some devices. All of them are connected to our system. We can generate any use case which is done in the airport. We can connect telephony from the outside into the airport, from the airport to outside, within the airport with different devices. Everything is done fully automatically.

intaQt provides this automation infrastructure. We script our test cases. We have integrated Cucumber, so it is native English sentences. The phones are integrated. You can even integrate some APIs. If there are gateways which have to be configured, we have SOAP and RESTful API integration. We can also configure these systems.

We can control anything and build any use case which is relevant to the airport and can test it end to end. This is the important information: We do end-to-end testing with all communication at the airport.

Use case: Critical infrastructure

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC. Today, I would like to present how we test critical infrastructure.

We have a 450-MHz network, this is how our critical infrastructure is designed, and we have the main three use cases. One use case is the communication between 450-MHz devices. The second use case is that we have some smart meter and that we have some sensors or equipment which also uses the 450-MHz network. For instance, there are sensors at, let´s say, a chemical plant and sensors measure the air quality, or something like that, and we need the data communication.

The network is provided. We have different kinds of devices and equipment, and we have developed intaQt. intaQt is our test automation infrastructure. It is software-based, and we control the devices.

We integrate ourselves to the mobile devices, for instance. We connect ourselves via USB. We can do everything that a user, a human being, can do with these devices. We can make phone calls, we can make data sessions, and so on. Fully automatically and even with kind of a remote control, so that a tester that sits somewhere in the world can remotely access these devices, see what happens on the device, and interact with his mouse.

We also integrate ourselves in an environment where a smart meter is available. We have some electronic components, with which we can also control power. For instance, we can activate the TV. The power consumption of the TV starts and what you consume you will see here in the smart meter. This information will go to a backbone. We have backbones for certain applications. This is a 450-MHz data communication, and here in the backbone there will be a database where the power consumption of this smart meter is entered. We can also integrate ourselves in this backbone: On the one side we control the TV, which generates power, the measurement is done, it is transmitted via the 450 MHz, and we check in the backbone that everything went fine.

You also have some other test use cases. For instance, you want to change the tariff at the smart meter. We also control the OTA, we apply the tariff and again run our power consumption, measure the data, and in the backbone we also collect the charging information and verify that everything went fine.

In a similar way we act with other sensors. We have electronic components which we connect to this, or this is a LAN router running some applications. One of the applications can be some measurement. We also control these measurements and trigger them. Then again, the measurement somehow goes to the backbone and triggers some interaction with the backbone. On that side, we check if the data transfer has been established and everything was fine. We do more measurements and process them. In the same way we do it with some other sensors.

What we do is: We try to collect all the end points. These end points are triggered by us, or we trigger something which is close to these end points. We take the measurements, we check the charging, we can collect the traces in the network and verify the signalling. We do everything end to end.

This is the most important thing: That such a critical infrastructure really works end to end, within the network and together with the application which makes use of the existing 450-MHz network.

Use case: Emergency Service

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC. I would like to show you how we test hospital information systems end to end.

Here we have some equipment which is available in the hospital. Let´s start at the nurses’ desk. We have a desk. We have some desktop applications running here. We have a TV. We have some smart devices on the wrist. We have some equipment. We have the doctor who has a tablet. We have some equipment here. We have a patient. We have a nurse here. We have some remote controls. Maybe she has her mobile device with some apps on it. Maybe the hospital provides an app to remotely control the TV, the channels, or something like that. It is a complicated environment with different types of devices, and so on.

We at QiTASC have developed intaQt. intaQt is a remotely controlled end-to-end test environment. For instance, we can control with intaQt some web services running on the desk. We can integrate with the tablet via USB and ADB in order to do anything a human being can do with this tablet. We can integrate with 3D housings, cameras, and sensors in the smart device. We provide some additional equipment. There is a camera inside which reads the information and can use it automatically. We can integrate with the TV infrastructure. We can integrate with the mobile device again via USB. If there is some equipment, we can integrate with that. And of course, with the remote control. Again, maybe a housing is needed here with some servo motors in order to press some buttons on the remote control.

We have a complex environment and there are different use cases related to the patient, related to the nurses, related to the doctors, related to the infotainment infrastructure, related to the services and applications. With intaQt, we can control all these end points and create use cases which are capable of testing this solution end to end. And this is the most important part: Any kind of use case which you think about in a hospital, even some processes which are not related to the patient but to the administration or to the organization of a hospital, can be tested end to end.

Use case: Automotive

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC and I would like to show you how we integrate car communication and infotainment with our testing solution.

Here we have a car. We have some components which are built into the car. This is the infrastructure, where you can communicate with the car. We have a board computer. We have a mobile device with some apps which are linked to the car. And we have a simulation infrastructure for cars. There are many on the market and you can simulate for instance that a car is driving at 40 kilometres per hour, automatically closes its doors and this kind of stuff.

We from QiTASC try to automate different use cases in order to test the infotainment infrastructure and the communication with the app.

As I said, we have the app which is relevant for the car. Here, we have the dashboard where we have our services in the car, like playing music, having the coordinates where we have to drive to, and these kinds of things. We have a board computer, and we have this simulation infrastructure.

What do we do?

We have developed intaQt, which is our test tool. With intaQt we can integrate ourselves into a phone. We are connected via USB. Once we are connected, we can do anything on an Android device that a human being can do. In the same way, we integrate ourselves into the car communication system. Many of them are based on Android. Like we did here the app automation, we can automate every function which is available in this environment infrastructure.

We can connect intaQt to the board computer. Of course, this requires some integration where the car provider has to help us. Here, we also have some information. We take information from the computer, like logs and these kinds of things. And, of course, we integrate ourselves into the simulation environment for the car.

With this setup, we can now generate any kind of use case that happens in a car. For instance, with the simulator we tell the system: Ok, now you start to drive. You reach a certain speed. While we do that, we press here some buttons and enter the destination and prepare the sound for the kids in the back so that they can hear something. And before we enter the car we could use the app.

All these use cases which are relevant to this infotainment infrastructure and to this car control environment we can test end to end. This is the most important thing: that these tests are done end to end in an automated environment, in an automated fashion. We can script thousands of scenarios and run them within a few hours.

Use case: Voicebot

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC and I would like to describe how we test any kind of voicebots in real conditions end to end. As you know, AI-driven voicebots are becoming more and more interesting and more and more used.

Let´s assume we have a telephony environment which is connected to a Telco switch where you have incoming calls. Here, you have your AI chat-/voicebot. You have your database and applications: You have your speech-to-text and text-to-speech application. When a call comes in, there is a reason. The AI chatbot tries to answer it. It writes some data into the database. Sometimes it retrieves data out of the database to answer the question. It writes some logs in order to have proof of what it did. This is the environment we want to test. This is the system we test.

At QiTASC, we have created a fully automated test environment for telephony applications. Regardless of what you have, if you use mobile devices with 2G, 3G, 4G, 5G, or if you have some special handsets with 450 MHz, or if you have a desktop phone with a touch pad with buttons and so on for IP telephony, or if you even have an old analogue phone. You could have a fax machine. In Europe it is still used. Even if you have these kinds of things where you have some communication needs to a call centre, you have these different kinds of devices. In the middle, you have the telephony network.

What we did was to create intaQt. intaQt is our solution. intaQt is capable of controlling all these devices. We connect ourselves to these devices via USB. In some cases, we connect ourselves with http. Sometimes we do emulation of analogue lines. We can control fax machines. Even if you have something else which works with data, we can also control an environment where you have a monitor with an application and control that.

This is done fully remotely. The tester can sit anywhere. You can have it in a lab, or you can have it in a real environment. We can trigger telephony calls to this environment. What we also did: We use Cucumber with the Gherkin syntax. We have also developed some specific step definitions. These step definitions also deal with an AI infrastructure.

We have our AI infrastructure. This can be set up at Google or Asia. Here, we have our own bot. There is a QiTASC bot. We can tell this bot to act in a certain way. We also have our text-to-speech and speech-to-text engine, also provided out of this environment. With plain words we can describe the task and tell: “Please call!”, and the bot starts that.

This functionality is combined with the controlling functionality of all these devices. We can initiate the call from here to here. This part picks up and says: “Hello, welcome! Can I be of service somehow?” The bot starts: “Yes, I would like to have a meeting arranged for a certain time. Can we book that?” And they talk to each other.

While they do that, on this side we collect these logs. On our side, we collect our logs. All the transcripts, everything that has been done by these two bots, is available. We can measure the MOS quality of these activities. We can verify if there is silence in the communication, how many seconds this silence is. We can identify what this part says and how often they make mistakes. If there are some fillers used on this side.

We have created a score to measure the quality of such a communication. For instance, 30% of the score is fulfilment. This means, if the calling bot finally gets his arrangement, his meeting dates, then it´s fine. If the quality is bad, then the score will be slightly less. If there are no fillers, the score will be slightly less. We have a scientific approach to creating a quality score for such a combination.

Network testing: Ensure a functioning telecommunications network with automated testing of the whole infrastructure

Hello. Today I would like to give you some impressions how we approach test environments and how we try to ensure that the network is working as it should work.

We are focusing on the telecommunications infrastructure.

In the telecommunications infrastructure we have different network layers:

We have the transport and run, we have the radio access network with 2G, 3G, 4G, 5G, Wi-Fi but we have also services like IP, where we then have Voice over IP devices. So this is a basic, very fundamental infrastructure where we make phone calls and so on.

Then we have of course the core network. This could be an IMS core, this could be a classical mobile switching system with HLR/HSS and so on. Without having very complex services like conversion charging services, we have only this layer.

On top of this we have enablers like PCRF, user repositories, AAA or DNS service.

And on top we have the service platforms like intelligent network, convergent charging systems, multi SIM services, voice mails, payment services and so on.

In the lab environment we are on the move. Therefore, it is important that we know what works in our lab and what does not work. To identify this, we have a very simple approach.

First we use phones – 2G, 3G, 4G, 5G, Wi-Fi – and we check them without having any services. We only have this radio access to the IMS core, making calls from A to B. Very simple, very basic.

In the next step we create test cases where we also require AAA functionality, PCR functionality, user repositories functionality, and where we make some slight changes to these parameters and see if our services are still working, if our calls, our data access, our SMS actions are still working.

We can do this either for the whole network infrastructure or we can pick out some test cases which focus especially on certain functions.

And once we have this, we can go to more complex environments where we test the service platforms, for instance a virtual office. We can add some provisioning and load and stress test activities, or we make some checks on payment services where we do some real-time transactions. Or we can only verify if CPEs are working correctly.

We connect the CPE or IoT devices to a test infrastructure, trigger the CPEs and see the responses what is happening on the CPEs. Even app testing can be automated.

We use the full range of our services: We have connectivity to the network, we have an app which interacts with some service platforms like the online charging platform.

We make a call for these converging charging services, and then with the app we verify if the app was able to give back the charging parameters, to show us the account, the money we have on this service, and if this is correct or not.

This are the different layers of the networks, the way we can ensure that certain features are working or not.

At the end you have approximately 100 test cases. By running them in a regression on a daily basis or maybe twice or three times a day – approximately you will need 40 minutes to run these test cases – you can identify which parts in your network are working and which parts are not working.

Interested in more? Visit us online! www.qitasc.com

Test Automation in IoT

A theoretical example of intaQt in an IoT infrastructure

Hello, I am the CEO of QiTASC and I will try to explain to you how we deal with IoT environments in order to test them. For this purpose we have selected a smart meter use case.

As you know, a smart meter is a very important device, especially in these times of energy crises. A smart meter gives a lot of valuable information to people in their homes, and to the power companies.

Let´s say we have a smart meter. This smart meter provides in the whole city. And we have a backend infrastructure with some IT systems that interact with this smart meter. This is the main thing happening and of course we have our house with different devices inside. We have a washing machine which is switched on and other devices like a TV and so on.

These are of course all connected to electricity supply. In the smart meter, this generates some information.

Now we want to test all this infrastructure. What do we do?

We set up an intaQt which is our test automation infrastructure. We have the intaQt server. We connect the intaQt server to one of these devices which we can control. Later, we will generate some activity here with power consumption.

On the other hand we have some devices which can read the smart meter. And we connect intaQt to these devices as well. This already lets us get the information between the smart meter and what is generated.

Then we are also connected to the IT system which is communicating with the smart meter.

On intaQt studio we write a script. First we trigger an activity, we start the washing machine. We know exactly how much power it will consume, so we can say that after one hour we have power consumption of x kW. This is recorded by the smart meter.

Then, as a second step, we read this power consumption information and while we are doing this there is an interaction between the smart meter and the IT system.

In the third stage, we will go into this IT system and read the data which has been generated in the IT system. Then we will correlate all this information and will know when the appliance was used, how much power was consumed and finally which data has been generated in the IT system.

Fourthly, we will correlate all data. And this will be done automatically.

As you may imagine, there are hundreds of thousands of variations. You can change the software on the smart meter which could be an additional activity and then run the requestion test cases.

The smart meter also generates some other power-related functions. You can read them, correlate them, check in the IT system, do some provisioning tasks in the IT system. So all this can be done automatically.

Let´s say 1A and 1B because provisioning is done first and correlate everything with each other.

So this is the setup we have in the IoT infrastructure. We set up the infrastructure as close as possible to the real world. We use real devices which are also used by the technicians at the power plants and power companies, we connect to them, we access their databases and correlate all the data automatically.

This is mainly what we are doing in IoT.

Interested in more? Visit us online! www.qitasc.com

History of intaQt
The history of the QiTASC test automation framework

Hello, my name is Can Davutoglu, I am the CEO of Qitasc, and I would like to give you some information about the history of our framework development.

We started our test automation framework by developing intaQt.

intaQt is an automation tool. It is designed to grow. This means it can be improved by new interfaces and new features.

We have designed intaQt in order to control a bunch of devices. We control mobile devices, we control Voice over IP phones like Yealink, Snom, Polycom. We control various CPEs. We control web UIs, tablets.

But we have also generated hardware or developed hardware which is capable of controlling IoT devices and different other devices where you need manual interaction. And this we do via intaQt.

intaQt is connected to an environment where these devices are connected. And everything that a human being can do with these devices, we can do by controlling them with intaQt.

We write step definitions. We have integrated Cucumber. And with Cucumber with the Gherkin syntax you write the test cases, and step by step you can control these devices and do actions. You can integrate it later with the trace information, you can collect evidence, screenshots and these kinds of things. And everything will be copied into a directory where the test case evidence, where the reports, where the screenshots are stored.

sQedule is another development by us. sQedule is an intelligent scheduling or smart scheduling environment where you have multiple intaQt instances. So this means you want to execute a lot of test cases in a very short time and you have limited resources in your lab.

Sometimes a test case requires different resources. And sQedule checks the availability of the resources and selects the test case according to your resource infrastructure. And when some resources are free and there are some test cases which can be run with these resources, then sQedule does an intelligent rescheduling of the test cases in order to get through as many test cases as possible in a very short time.

intaQt studio is an IntelliJ-based user interface in order to write test cases which are executed in intaQt. So we can say it’s a client-server architecture: intaQt is the server, intaQt studio is the client, the test cases are written there.

So we have also fancy features in intaQt studio like auto completion, colour coding and this kind of thing.

And we have also integrated GitLab, so all the test cases you write are under version controlled and secured too.

So with intaQt studio you write your test cases and you have also graphical user interface where you can see these devices in reality which are somewhere on another location. You can see them in your intaQt studio. This means we stream the user interface of the phone for instance into intaQt studio.

You can see what’s happening on these phones and you can interact with them. By mouse clicking and so on you can control the device which is for instance somewhere else in the world.

After we have developed these parts, we are capable now of executing hundreds of thousands of test cases in a very short time. But you know, now you need to do some reporting.

You have your JIRA environment and or CI/CD environment or you have an application life cycle monitor or something like this. And you have thousands of test cases which will be executed with thousands of evidences, reports, locks, traces and so on. And you need to bring it to here. Again, you will require some automation functionality and this we do with conQlude.

conQlude is our reporting environment where all the information which is collected here by intaQt is copied in a smart way. And from here, using the automatic APIs which are available in JIRA, for instance, or in CI/CD environments, we push this information into this environment automatically. With one click you can copy hundreds of thousands of test cases of the persons who have executed it, of the evidence which has been collected, you can push it into that environment. And this is also one important step in the automation activities.

Then we have some information which has to be collected from other network functions, from other IT systems, from other directories and databases. In order to do this in real time, we have developed also a small service which is called colleQtor. It does real-time processing and collects this information which is needed for some verification actions.

We have automated things but now we have some evidence, and this evidence needs also to be verified. And before verification, you need to collect it. Therefore, we have developed the colleQtor.

We come from the telecommunications business and in telecommunications the most important part is the CDR verification. Everything related to charging is the most important thing because this brings money. Therefore, we have also developed CDR-linQ which is a standalone module.

CDRs are sometimes written much later than the test case is executed. For instance, in some lab environments you get the CDRs once a day at midnight. And with CDR-linQ you are copying them and you are providing, you are doing of course some analysis of the data, reformatting of the data.

CDR-linQ offers the data in a way that can be used for verification purposes. This means that the test cases are executed using these devices, in the network we have the CDRs which are written, and the test cases executed, the test cases finished, and now we wait to verify the CDRs.

So in order to free the resources, in order to make these independent from each other, we have created meta steps.

And in our reporting environments, test cases where we need CDRs and they are not available yet, we mark them. And the test cases are set to pending. Once the CDRs are copied into our CDR-linQ – let’s say a few hours later – then a trigger indicates that CDRs are available and conQlude starts, gives the trigger for final CDR verification. And once this is done then the test case is set to successful or failed, depending on the CDR verification. This is also an important part of being able to verify things in a lab environment.

Now, as I mentioned we do telecommunications and IoT.

In the lab environment sometimes you have your own signalling environment. You have your own 2G, 3G, 4G, 5G, Wi-Fi signals and you need to put your phones into a shielded box. Once the phones are in the shielded box, there are attenuators where you say, “Ok, I need a 3G signal in the box!”

In order to make it available to these phones, you need to control these attenuators. We have integrated also this, so we are capable of controlling attenuators from MTS Systemtechnik, from JFW from the United States, Highthon used mainly in Europe. We have integrated them and we can control automatically the signal field into these shielded boxes.

This is one point. Another point is the integration of a SIM array. SIM arrays are boxes where the SIMs are physically located in this SIM array and via internet or intranet, the SIM information is to be copied to an electronic device and from here you have a flex cable which goes into the phone and the phone thinks that there is a SIM inside but in reality, this SIM is in the SIM array.

And in order to provide this functionality to the intaQt service, we have created a service which is called reloQate.

So, intaQt is integrated with reloQate and with this we can seamlessly manipulate the SIMs which are required for test cases. The tester writes his test case without having any information about the setup and if a SIM card is required which is in the SIM array and is not provisioned for these phones, it is done via reloQate automatically. Then the SIM is copied to the device, the device is rebooted and then it is available for the next test case.

This is also something very important: We have really zero touch. With zero touch we mean that we do not touch this hardware, regardless of what it is.

If we need to press a power button of this CPE for instance, we create 3D housings with a servo motor and we can trigger really this activity. If we need to identify the lights of this CPE, if they are blinking red, green or something, we put RGB sensors on top of it and identify the status of the devices and so on.

It is really a very fancy environment and we can deal with any kind of hardware.

Now due to the security requirements, we have been asked if it is possible to have an user interface which is not based on IntelliJ, where you do not need to install it on your notebook. We have therefore developed intaQt web-ui, which is a web-service-based user interface where nearly all functionality which is provided in intaQt studio is also provided in the web-ui. Especially the parts we need for our testing.

Then, as a next step we have implemented three different verification features which are also fully automated. The first one is trace compare. Once we are running our test cases we collect the traces, for instance Wireshark traces or some snoops for network functions. And we put them into the directory where we handle these traces. The traces are decoded and then we have a rule engine where we can apply trace rules.

So we can verify the headers of the action, we can verify the logic of the trace, the order of the messages which are coming in and we can combine packets and compare them with different other packets which already have been run and where we have decided that they are ok.

This is trace comparison. The same we do with CDR verification.

So the CDRs which have been collected are matched against some rule sets and we do the CDR verification. And in order to do protocol verification we have also a logical and functional verification of the protocols used in that environment.

So, there are 3GPP specifications which we use. We generate a rule set where we verify the test cases. For instance, a standard, let’s say SIP-based use case, where A-party is talking with B-party. If we do the protocol verification for that we generate approximately 70,000 rules and verify the 3GPP documentation for that.

Of course, when you do test cases there is also some provisioning function required. For this we have subsQriber-db. This is an asset management and network function provisioning environment.

Why asset management?

In some test cases you also use one-time-data like a voucher or some access criteria which is required for the test cases. This is stored in our asset management database. Once it is used it is invalidated and it generates another code. The test case does not need to be touched.

In order to create, let’s say, groupings of subscribers or similar things then you can use the subsQriber-db.

Finally, we have our CI/CD infrastructure.

intaQt offers you a command-line interface from where you can trigger intaQt from another environment like, let’s say, from Jenkins. We offer CI/CD and we provide also documentation and results which can be used by this CI/CD infrastructure.

Sometimes, when you have a network and you have a lab, the lab is always on the move. This means sometimes it does not work properly but you need to finalise your project, and some device, some load, some IT systems are not available.

In these cases we have mimiQ which is our simulator.

With mimiQ you can then simulate the missing load and the network does not recognise that the load is missing. It generates a request and mimiQ is configured in such a way that it answers these requests and the network works as expected.

And mimiQ has a second functionality. It can generate a lot of requests in a very short time. So you can use it also as a load and stress test infrastructure which generates hundreds of millions of requests in a very short time.

This is the framework we have developed. From the very beginning where you execute test cases, to collecting data, to analysing data and verifying it also in an automatic need by adding some, let’s say, simulator-related functionality.

It gives you everything that is needed in a modern environment to run your test cases automatically.