We covered Projects and Project Suites in our last module. Next up then we have Checkpoints and Stores. Checkpoints to check something at a point in our test execution. Stores to store things. Obvious really.
There’s no point in building out these projects and keyword tests if you don’t have some way of checking the expected results against the actual results you see. Check points do exactly that.
You can think of check points as the manual testing equivalent of defining your expected results and then checking what actually happens against them. The result being either a pass or a fail.
The Stores component in TestComplete is linked in quite closely with check points. Essentially the TestComplete Store is a place to keep some of those expected results.
For example you can keep images in your Store to do comparisons against when you run a test and call the check point. You can keep details about objects (like a list of the objects properties) and compare these properties during test execution against a baseline stored in the Stores.
Both of these concepts, Checkpoints and Stores, we’ll cover in this module. To start with though lets see how we can create a checkpoint and examine some of the different types of check points.
First off then lets look at how we create Checkpoints. There are two ways to do this:
1. As part of the recording process
If we go back and use one of our existing test cases we can use the append to test recording feature. We’ll append to the end of the test…..
Then as part of the recording we use the Checkpoint button in the recording bar
This presents us with the wizard for creating the property check point. Here we’ll specify the object we want to check, the property of that object we want to check, the expected value of that property and the condition it needs to meet.
In the test this gives us the Property checkpoint test item:
When, during the test execution, we get to this test item it’s here that TestComplete takes the object, property, value and condition and compares what we record with what is seen during the run. If everything matches then the checkpoint passes. If anything doesn’t match we get a fail.
2. Using the Operations panel
The other approach to creating Checkpoints is using the operations panel. You can select a Checkpoint type from the operations panel and drag it on to your test case.
Once you’ve done that you’ll be taken through the Checkpoint wizard screens where you can specify the object, property, value and condition for the Checkpoint. Remember though that you’ll need your application under test open, with the specific object visible if you’re going to complete this process.
So what Checkpoints do you have at your disposal? And how best are they used? Well the most important, most commonly used ones are listed below for you.
XML Checkpoint – allows you to define and save a base line XML file along with details about the parts of the xml file you want to compare. Being able to mask out parts of the comparison xml allows you to get quite creative with what you need to check for.
File Checkpoint – allows you to define and save a base line file. TestComplete can compare files. You can specify text files (along with a tolerance on number of bytes differences) or just do a direct like for like comparison if it’s a different file format.
Object Checkpoint – allows you to save property details about an object in the TestComplete store. Then on test replay compare the stored properties against the actual properties at run time. Again you get to select the properties you want to store and do the comparison on.
Property Checkpoint – this one only saves and checks one particular property of an object. Slightly different to the Object checkpoint where you can select a range of properties to check but you’ll find most of the time you only need to check one property. So this ones quick to setup and work with.
Region Checkpoint – this is the only check point that allows you to compare images. It comes with some clever features allowing you to mask areas of the image you want to compare and the capability to set some tolerances. We don’t recommend using image checkpoints (just because the whole concept of comparing images is a difficult one) but this is a good choice if you have no other options.
Those are the most important checkpoints. You may come to use Table, Database and Web Service checkpoints over time. The five we’ve outlined above will get you started though and support you for the majority of your test cases.
What you might have grasped though is that many of the checkpoints depend on having objects, images, properties etc saved in the TestComplete store. The Store entity in TestComplete can be thought of as a repository for other test items that aren’t your typical Keyword tests or scripted tests. It’s designed to hold objects like files, images, database connections, table data and xml data. It’s not just for objects related to Checkpoint expected results. It can be used else where in your test cases and scripts too.
To add new entities to your Stores you’ll first need to add particular Stores sub containers. You can do this by right clicking on the stores node and selecting ‘Add’. And from there in the dialogue box select the type of Item you want to store.
This will add the item type node to the Project Explorer under the Stores node.
From here you can double click on the object type node (in project explorer) open the work-space. In the work-space you can right click to add new objects and view/modify existing objects.
So you’ll either add items to the stores automatically as you create Checkpoints or you’ll add new objects manually to your store following the process above. When you create Checkpoints you’ll identify objects in the stores as part of the process.
But you can also use objects from the stores as you create test steps. Many of the operations you add to your tests will allow you to select and act on Stores objects. For example the ‘Call Object Method’ operation gives you this wizard that allows you to pick objects such as Files, DB connections, etc (e.g. object types found under the stores node).
We’ve covered the topic of comparing expected and actual results in this modules. As part of that we’ve touched very briefly on the fact that the results from these comparison are displayed in the test logs that are generated in the test execution runs. In the next module we’ll look at these test logs in more detail.
We’ve already come across the basic concepts of the Project Suite and the Project. Remember that one Project Suite is the container for multiple Projects. Beyond this though we find a few further levels in this hierarchy. A project can then contain multiple test cases. A a test case can have one or more test steps.
In the image below we see the top level project suite called ‘CalcProject Suite’. Under the ‘CalcProject Suite’ we find 4 projects.
CalcAPI, CalcDesktop, CalcMobile and CalcWeb are all projects contained within the single project suite. Then we can take the ‘CalcDesktop’ project and we can see that this project contains two test cases (Test1 and Test2). Drilling further down we could then examine the tests themselves and see that these each had multiple test steps within the test. When it comes to executing our tests we can execute at all of these levels.
At the Project Suite level we can click the ‘Run Project Suite’ button. This will then run all the projects that are enabled within the ‘Project Suite’ work-space. Running each project will in turn run all of the tests enabled within that project too.
Or alternatively we could run just a specific project. When we click on the run button for the project we execute all the enabled test cases that are listed at Test Items within the project work-space.
If we want to run individual tests then we can open the test and use the right hand context sensitive menu option to pick ‘Run Test’. If we want to go a level deeper then we can select the ‘Run Selected Operation’ or ‘Run from Selected Operation’. The first one only executing the selected test step, the second one running the selected operation and all subsequent test steps.
The Project Suite concept, as you’ve probably raised, is quite a simple concept and just acts as a container for multiple projects. It’s at the project level where things start getting interesting. We’ve seen how you can run all the tests contained within a project but how do you select those tests within the project?
Well once you have the Project work-space open you can build your test project up by dragging in test cases from the Project Explorer pane….
Note that not only can you drag a test in, but you can drag it in multiple times in order to repeat the test and/or construct complex workflows by dragging in multiple tests from your project.
You can also organise and construct logical workflows by using the folder and test manipulation buttons to create hierarchical structures and groups of tests. In this way you can reuse and organise your tests as you need to create logical structures of tests. All part of the powerful test case reuse capabilities provided by TestComplete.
Next then it’s worth talking about the columns you’ll find in the project work-space. You’ll see column titles and fields for Name, Test, Count, Timeout, Stop on Error, Stop on Exception and Parameters.
Name is a custom name you can give to this instance of a test item in the list. Test is the actual test name (as seen in the Keyword Tests list in Project Explorer). Count is the number of times you want to run that test and timeout is how long the test will run for before TestComplete moves on. The Stop on Error and Stop on Exception values tell TestComplete what to do if it encounters and error. And the Parameters field allows you to set the parameters fed into the test as it starts (so the same test case can be feed with different parameter values each time it runs).
The only other thing to quickly mention on the project front at the tabs at the bottom of the work-space panel. You’ll see the Test Items tab is selected by default, which is what we’ve just been looking at. We also have Variables, Issue Tracking, Logs and Properties.
Variables allows you to define and set project level/scope variables (more about this in a future module). Issue tracking templates allows you to create issues and build templates for creating those issues. Logs gives you visibility of test run results when the run was started at the project level. Then most important is the ‘Properties’ tab. This is where you can specify the ‘project level’ properties. We talked a lot about this in the Options and Settings module.
And that’s about it on the Project and Project Suite side of things. In short these entities are just repositories used to help you organise and manage all of your test artifacts. How you split these artifacts and test efforts across your projects and project suites is one of those “it’ll come with experience” aspects of learning TestComplete. One that we’ll touch on in later modules.
Finally we get to the point where we can start looking at the creation of automated tests with Keyword Testing in TestComplete. We’ve looked at some of the key components like Managing Projects, Options and Settings. We’ve also seen how Objects, Properties and Methods are critical to the tests you write. All of these components and concepts are part of the foundation you need in order to start creating automated test cases. You have that foundation now. From here on in it’s all about creating tests.
You may or may not have figured out that you have two ways to create automated tests in TestComplete. Scripted (e.g. Python, VB, Java Script, etc) or Keyword graphical drag and drop. We’re looking at creating Keyword tests here but if you’re keen to jump ahead you can record Scripted tests by clicking on the ‘Record Script’ button. Scripts you record are then stored in the ‘Advanced’ folder under the script element in the file or unit you chose.
Anyway, that’s not why we’re here. We’re here to look at keyword tests. This is the graphical, drag and drop approach to creating tests. There are two ways to create these types of tests.
1) recording tests (either appending or creating new)
2) using the operations panel to build or modify your tests by hand
The record approach is straight forward enough. Click the record button, complete your actions on the application under test and stop recording. Then view the test items/steps listed in the Test.
Whilst that’s the simplest way to go about it you’ll probably learn more about what’s going on if you build your tests from the Operations panel. Certainly if you want to modify and manipulate existing tests then learning to use the Operations panel is going to be important.
From the operations panel you have the ability to add all sorts of operations or actions to your tests. Just drag and drop the operations into the appropriate parts of your existing tests. When you take this approach you see what makes up a test item/step in more detail. For example one common operation you’ll work with is the ‘On-Screen Action’ operation.
When you drag this item onto your test you’ll be taken through a few steps:
1. Select object you want to interact with
2. Select method you want to call for object
3. Specify the Values or parameters required for the method
It breaks down quite simply to selecting the object you want to interact with, specifying the action/method you want the object to carry out and then define any values/parameters required (this might be the coordinates you want to click a button at or the text content you want entered in a text box).
Once you’ve gone through this it’s easier to understand the data displayed on the test case work-space for each of the test items/steps.
For each test item/step you see the columns:
1. Item or Name of the object you want to interact with
2. The Operation / method or action
3. Time you’ll wait for the object to be displayed (optional)
4. Parameters and/or values to use
5. Free format text description
All of this information is displayed on the ‘Test Steps’ tab in the Test Case workspace. You’ll also find tabs for Variables and Parameters that can be defined for a Test Case.
Variables contain values that can be used at run time and that can be changed at run time (e.g. whilst the test is running). So for example you might set a variable that’s used to count the number of times that you loop through steps repeatedly in a test. There are many uses for variables but the important thing to remember is that they are set when you are running the test and can be modified during the execution of the test.
Parameters can be thought of as values that are fed in at start of the test execution. They are not modified during the running of the test. Just set at the start and then used during the execution. Typically you might have a test that has parameters and then call the same test multiple times, each time with a different parameter value. So you follow the same test steps/actions each time just use different values each time you run the test. Just remember that Parameters are fed in at the start of the test and don’t change whilst the test is running.
Those are the key concepts to grasp when creating keyword tests. Either record your test steps or build them up using the different operations from the operations panel. Each test step has an object it interacts with (i.e. a button object), an operation or method that it completes (i.e. clicking the button). Sometimes there’s also a value that is set (i.e. entering a text string in a text box).
As part of the test you can also set variables and parameters. Variables are values you can use during your test run and values that you modify at run time. Parameters are values that you feed in as you start your test. So you can run the same test multiple times with different parameters. Parameters can not be changed or modified during the run of the test.
Remember those concepts and everything else will start falling into place as you build more and more complex test scenarios. In the next module we’re going to look in a little more detail at Projects and Project suites. We’ll also see in the next module how we can utalise the power of test case Parameters at the project level.
We covered Options and Settings in the last module (Module 5). Whilst there are probably over 100 options and settings we’ve focused on the most important ones you’ll need to know about as you start out with TestComplete. Probably a bit of a tall ask to remember all of the settings we covered there. However, if you just get a feel for the key settings and project properties it’ll make your life easier as you progress with implementing TestComplete. What you will need to grasp in detail though is an understanding of Objects, their properties and their methods. And it’s Objects, Properties and Methods we’re going to take you through below.
If you don’t grasp the concepts of Objects and Methods you’re not going to get far with TestComplete. It’s absolutely critical to grasp these concepts. These are concepts that go much wider than just TestComplete. Grasp them though and a lot of TestComplete concepts will fall into place far faster.
If you’re wondering what Objects and Methods are in the first place then here’s a repeat of our very basic overview (from Module 1). You can skip this if you’re already happy with these concepts and move on to how to work with them in TestComplete if you’d prefer.
Objects can be thought of as processes, applications, windows, browsers, etc that are present on your system. They are things that are present on your system at any point in time. Some of these objects may be visible on your system (e.g. a window displayed on your desktop) or they may not be visible (e.g. a process running in the background). All objects will have properties and methods.
Properties can be considered as characteristics of the object. For example you ‘System (sys)’ object will have a property called ‘Hostname’. That property would have a value (e.g. The host name of your system).
Methods can be considered as actions that the object can carry out. For example if you have the CalcPlus application/object running on your system, this object could have the ‘close’ method. If this method is called then the object would be closed on your system.
If you’re still struggling with the concept of objects, properties and methods read the following analogy (slightly daft analogy but hopefully gets the point across):
Objects and child objects: You can think of yourself and your body as an object. As an object you have lots of child objects. You have a head, you have arms, you have legs, etc. These child objects have their own child objects. For example an arm has child objects like shoulder joint, elbow joint, wrist joint, forearm, top arm and hand.
Properties: Each object will have a number of properties. You have a height property. That property could have a value (for example 1.6 meters). You body will have a list of properties and each of it’s child objects will have it’s own list of properties too. Take your ‘arm’ object. We’ve seen that the arm has a list of child objects. The arm itself could then have a property called ‘Number of child objects’. The value of this property is 6 (the six child objects for the arm being the shoulder joint, elbow joint, wrist joint, forearm, top arm and hand). Other properties for the arm could be things like colour, texture, etc. All of these properties could have values.
Methods: These are the actions that the object can carry out. Your overall body object might have methods, or actions, like Sleep, Run, Walk, etc. Each child object may have it’s own set of methods too. So your arm object may have methods like bend, twist, raise, lower, etc
These principals apply in exactly the same way to everything on your computer or laptop. The top level object can be considered your computer system. This system has child objects which might be processes (like the notepad process running on your system). The notepad process then has child objects which can be windows that are displayed on your desktop. If we take the notepad window this window will have properties; like height, width, colour, title, etc. This window will have methods too. These methods are likely to include actions like ‘minimise’ and ‘maximise’.
First off it’ll help if you know what the object browser in TestComplete can do for you. The object browser is TestCompletes view of your system. It’s how TestComplete see the structure and relationship between those objects. And it’s where TestComplete shows you the different aspects of those objects (their properties) and what those objects can do (their methods). All of this information is displayed and interpreted with a few key panels in the Object browser view. Those key panels are:
The Object Tree shows the list of objects, their relationships and hierarchy. Everything starts at the top with the ‘Sys’ object which represents your PC or Laptop System. Everything else is a child of this Sys objects. Child objects are either Processes, Windows or Browsers. Typically under the Sys process everything will be a process (e.g. your Calc process) and then under this the Calc process will have a load of window objects. It’s these window objects that are usually displayed on your desktop.
When you click or select an object the panel on the right allows you to look at the properties and methods for that object (selectable with the tabs). The Properties tab lists all the properties associated with the object you’ve selected. Properties can be read-only or read/write. If you see a little ‘o’ symbol next to the property then this means its a read and write property. You can actually click in the property value text box and modify the value (that value then reflected and changed in your application).
The methods tab lists all the actions that the object can carry out. Actions typically include things like click, focus, drag, etc. All the sorts of actions you’d carry out when you’re working with your application. You’ll also find more obscure methods that are specific to different object types. For example the Calc Plus process object has a WaitSwingObject method. I’ve no idea what that method does. And this highlights a good point. Each object will have a lot of methods. You’ll probably only find that you need to use 4 or 5 of those methods. There’s no point becoming familiar with all the different methods, just get familiar with the core methods. Which brings me on to the next point…
You’ll notice when viewing properties and methods that there’s a link to view more members (advanced view). TestComplete hides a lot of the properties and methods that it doesn’t think you’ll be interested in. However, if you need, or want, to see everything then click this link. You’ll see 10 times as many properties and methods for the object that you’re looking at. Best to stay in ‘Basic’ view for now though.
Another useful thing to know is the object browser context menu. Right click on an object and you’ll see a context menu with lots of useful options. These include:
Refresh – Reloads the object tree.
Map Object – Name Maps the selected object.
Show Object in Name Mapping Editor – Navigates to the Name Mapping Editor and selects the current object.
Store Object – Saves the object and its children in the Store.
Highlight on Screen – Places a highlight border on the selected window if the window is visible.
View Object – Captures a window in the Image Viewer.
Add Process to TestedApps – Adds the selected process (or parent process if a window is selected) to the TestedApps node.
Terminate Process – Immediately shuts down the selected process (not recommended)
Copy – Makes a copy of the text for the selected node in the Windows clipboard.
Panel Options – Navigates to the main menu’s Tools | Options page for the Object Browser.
Whilst we’re looking at objects and methods it’s worth saying a little bit about object naming conventions in TestComplete. In it’s simplest form we just need to use ‘dot notation’ to describe the path from the top of the object hierarchy down to the object we’re interested in.
For example when we’re looking at the full path to an object we’ll start at the top of the hierechy which is the Sys object. Then we’ll pick the next object down and add that to our path notation with a dot separating the two objects. Then repeat. So we’ll end up with something like this…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Static”, “”, 2)
Okay so that looks a little more complicated than I made out above. Let’s break it down.
If we start out like this…
Then all we’re talking about is starting with the Sys object, then below that there is a ‘Process’, below that is a ‘Window’ and below that is another ‘Window’. However, if we take it like this you’re probably thinking there’s a lot of objects in my system that could match that naming. Word or Excel for example are processes running under the system object that have a window and underneath that another window.
If we were to use this naming convention we wouldn’t be able to uniquely identify an object. What we need is to fill in some detail in the brackets that narrow down what we’re trying to identify. Take this bit…
Well that uniquely identifies the ‘CalcPlus’ process running on our system. That helps. Except it doesn’t help if we have more than one instance of CalcPlus running. In that case we need to identify the CalcPlus object with a unique index Id too. If we had two open instances of CalcPlus we’d see something like this…
You can see here that with two instances of CalcPlus running we’re uniquely identify the two different instances with an attional attribute in the brackets which identifies the instance by an ‘index’ value. Index value 1 for the first instance (which isn’t needed in the brackets) and index value 2 for the second instance.
As we take this a step further down the hierarchy we’re using exactly the same principals. In the brackets define some properties of the child object that help to uniquely identify the object among other similar objects.
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1)
So in this case we identify the “Window”, that’s a child of the process, by using the property of the window which is ‘SciCalc’. We also use a 2nd property that contains the value “Calculator Plus” and the “1” which indicates the index (or instance) of CalcPlus that we’re running. All of this together means we can uniquely identify this window amongst other windows that might be similar.
We can just keep going with this process to identify another windows under this with the following…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Static”, “”, 2)
Now we see another final child object, again a Window object, identified with some unique properties (“Static”, “”, 2).
Everything we’re doing here is based on meeting 3 key criteria to identify the object:
1. identify the object hierarchy (e.g. to find a specific object you need to identify the parent objects)
2. identify unique properties of that object (e.g. the WndCaption property which could be ‘Calculator Plus’)
3. and if that still doesn’t uniquely identify the object (because there are identical objects at the same level in the hierarchy) then use an index value to pick out the correct instance of the object.
So this provides us a way to uniquly refrernce objects and a naming convention that allows us reference those objects in our scripts. For example if you want to click the a button in CalcPlus you can define the button object name with this….
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Button”, “2”, 11)
And then to click the ‘2’ button add the click() method to the end…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Button”, “2”, 11).Click()
or even if you script it in a Python script you can do something like this…
Try it. As long as you have CalcPlus open you’ll be able to identify the object and click it.
Just to take this a step further you ought to be aware that this is just one way of naming your objects. There are two others. We can refer to this one as …
1. The ‘Sys.*’ naming convention
And the other two ways are….
2. ‘NameMapping.*’ naming convention
3. ‘Aliases.*’ naming convention
All are legitimate ways to refer to objects in your scripts. We’ll talk about the other 2 (Namemapping and Aliases) in later modules. Grasp this first method and understanding the other two will come quiet easily.
We made our way through Module 4 which covered the fundamentals of managing projects. Now we move on to look at some of the important options and settings you’ll find in TestComplete.
When it comes to options and settings in TestComplete there are 4 distinct areas you need to know about. These areas are:
Options: [Click ‘Tools -> Options’ in the TestComplete menu bar] the settings that configure how TestComplete works and operates. These are like global settings that affect your general usage of TestComplete. They are independent of projects so that the options you select will apply regardless of the project that is open.
Project Properties: [double click the ‘Project’ node in the Explorer then select the ‘Properties’ tab at the bottom of the Project Workspace] these are settings that apply ONLY to the project that you are setting them for. So each project you open will have the same set of properties but you can set the values independently for each different project.
Project Suite Properties: [double click the ‘Project Suite’ node in the Explorer then select the ‘Properties’ tab at the bottom of the Project Suite Workspace] these are settings that apply ONLY to a Project Suite (remember that one Project Suite can contain one or more Projects). Each project suite will have the same set of properties but again you can set the values independently for each different Project Suite.
Default Project Properties: [click ‘Tools -> Default Project Properties’ in the TestComplete menu bar] when you create a new project it picks up a set of ‘default project properties’. It’s the same set of properties that every project contains. You can just think of the ‘Default Project Properties’ as the template that every new Project bases it’s initial Project Properties on.
That’s the four different areas of settings, properties and options you’ll find within TestComplete. In the next few paragraphs we’re going to highlight the most important of these. There are literally hundreds of others that we don’t mention here, but the ones we do mention are the ones you’ll find yourself coming back to time and time again.
Engines/Log/Activate after test run – Automatically opens the test log tab when a test run finishes. Switch this off if you get annoyed at always been shown the log file at the end of a test run.
Engines/Log/Open logs in the same panel – un-select this and TestComplete will open every Log file in a new tab. Usually best to keep this option on so that TestComplete only displays one set of logs at a time.
Engines/Log/Show Log on pause – if you’re in the middle of a test run and pause the run this option allows you to display the log file during the pause.
Engines/Log/Store all logs – You can get TestComplete to delete some log files automatically (useful as they do tend to build up). Or alternatively you can opt to keep all your log files and delete them manually when you don’t need them.
Engines/Name Mapping/Update Name Mapping during test run – if TestComplete cannot identify a mapped object during the test run then it’ll try to add an entry automatically
Engines/Name Mapping/Map object names automatically – Automatically generates custom names for objects that you are working with where they have not yet been mapped.
Engines/Name Mapping/Use extended find when possible – tell TestComplete to look down through the hierarchy of objects if it can’t find an object at the level it first expects to find it at.
Engines/Recording/Automatically add applications to the Tested Applications list — automatically add applications started during recording to the Tested Applications list of your project.
Engines/Recording/Always start a new test – start a new keyword test or script routine when you initiate recording by selecting Record Keyword Test or Record Script on TestComplete’s toolbar or main menu.
Engines/Recording/Real-time mode – record the actual time intervals passed between user actions and insert them into the recorded test as the Delay operations
Engines/Recording/Record text input into simple editors as – TestComplete can enter text into your application in two ways. Keys which simulates you typing in the object. Or just setting the text property of the object. Pros and cons to both (which we’ll discuss later). If in doubt chose Keys.
Source Code Control – This allows you to configure integration with source code control tools like SVN and Git. Thus you can make sure all your project artefacts are maintained in a controlled manner. Check out on open, Check in on close, Bind new items to SCC, Show provider messages and SCC provider all options you can configure.
General/Record user actions over tested applications only – Make sure TestComplete only records actions on applications that are in the tested applications list.
PlayBack/Stop on error – Execution will end the moment an error condition is encountered and an error message written to the TestComplete log file
PlayBack/Stop on warning – Execution will end the moment a warning message is encountered and a warning messages written to the test log.
PlayBack/Error dialog – If this option is enabled, TestComplete will ask whether to stop the test run on critical errors.
PlayBack/Disable mouse – Disables the mouse before playing back script. Pressing Ctrl + Alt + Del enables the mouse.
PlayBack/Auto-wait timeout, ms – Milliseconds to wait for an expected object to become available, or for an unexpected window to close, before posting a timeout error.
PlayBack/Delay between events, ms – Milliseconds of delay between each command during execution.
PlayBack/Key pressing delay, ms – Specifies the number of milliseconds between each key press event.
PlayBack/On unexpected window – What to do if an unexpected window shows up during play back (options include Ignore unexpected window, Stop execution, Click on focused control, Press Esc or Press Enter).
Project Suite Properties
The only option found here currently is the definition of the location that TestComplete should write the Project Suite execution log files to. Not really worth worrying about as the default setting here is rarely changed.
Default project properties
As already mentioned these properties include settings that are used by default for new projects and project suites created in TestComplete. The key settings and possible values are the same as discussed in above under Project Properties.
These are the core properties and settings that you’ll find useful when you start out with TestComplete. It’s worth becoming familiar with these as they will help you run your project smoothly. There are lots more to discover but stick with these to start with until you’re ready to go further.