Month: April 2018

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