Category: TestComplete

As you’ve probably realised what’s underlying all of this automated test case development is code. Behind the scenes your Key Word tests are really code. The artifacts like projects files, checkpoints and name maps are all xml files. Ultimately you’re writing code to test code. And if there’s on thing code has it’s bugs. Yes you’re automated tests will have issues that you’ll need work on to debug. Which is why TestComplete has some debugging tools built in. So that’s what we’re about to look at in this module. We can break these tools down into three distinct areas…. the context sensitive menu in the Keyword test work space the debugger toolbar the debugger panels We’ll go through each of...

Probably the most critical aspect of any automation project is the ability to reliably identify the objects you need to interact with. Fail to identify the objects at all and you’re dead in the water. End up with unreliable identification and you’re probably in an even worse position. When it works some times and not others you’ll spend inordinate amounts of time trying to work out why tests have failed…. is it your scripts or is it a bug? You have to get to a point where you can reliably identify application objects every-time. In this module we’ll walk you through how you can approach this with TestComplete. Key to object identification in TestComplete is a feature called the Name...

There’s no point in going to all this trouble of creating tests unless you can see the results of those test runs and see what’s passed or failed. Test logging in TestComplete is quite simple to get to grips with. Yet this logging capability provides a powerful way for you to easily navigate through mountains of test data that get generated as part of lots of test automation runs.     In this module we’ll look at * How test logs are organise and stored * What the test log window shows us * How to filter the logs to see what you need * Exporting logs in different formats * How we can add log messages to our scripts...

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....

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...

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 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...

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...

In the last module, Module 3, we looked at the TestComplete user interface. In this module we’re going to look in detail at how TestComplete manages projects and projects suites. In TestComplete there is a hierachy of items that you’ll create and work with as you implement your automation project. That hierarchy starts at the top with the ‘Project Suite’.   The Project Suite is just a container for 1 or more projects. Each project being a distinct group of test items that go together to make up a particular test automation effort. For example you might have an application to test that has, desktop, mobile and web client applications. It may also have a server component that’s accessed via an...

In module 2 we looked at creating our first key word automated test project. In that module we touched on a number of key areas of the user interface like the Project Workspace and the Object Browser. Each of those key areas giving us the ability to develop our tests and examine the applications we’re testing. In this module we’re looking at some other key aspects of the user interface. Key components that you’ll find yourself using on a regular basis to help you develop, debug and run your automated tests.     In the next few paragraphs we’ll go through some of the most useful components within the user interface.     First up then the view menu. In...