Category: Training

On to tags and branching then. Tags allow us to give a more human-friendly name to a specific revision of our folders/files. Branching gives us the capability to create a copy of the folders/files in our repository and have a different copy to work on – without fear of corrupting our main copy. As you’ve probably already grasped every time you commit a changed file to the repository SVN gives the repository a new, incremented by 1, revision number. In a reasonably sized project, over a year or two, it’s not long before those revision numbers get into the thousands or even tens of thousands. So you’re likely to get to the point where you have a stable set of...

We know how to create a repository. We know how to set up our SVN client and import our initial set of files. And in the 3rd module in this series, we saw how to check out and commit changes from/to the SVN repository. All pretty straightforward and easy to follow while just one user is working on one file. It won’t be long though before you start getting warning messages from SVN that you have a conflict. It’s how you should go about handling these conflicts we’re looking at in this module.   What you’ll find is that two people will be working on the same file and try to commit changes to the same file to the repository...

In the first tutorial we looked at why we need SVN and setting up our own Visual SVN server. When working with your team at work or collaboratively over the net, you probably won’t need to setup the server. This will probably already be in place and you’ll be given an account that allows you access. We’ve setup our own Visual SVN server instance because it’s the quickest way to get started and to help us learn. Your own SVN server gives you an environment in which to practice and experiment. ` Once the server and repository are configured we need to setup our client to access this repository. The client allows us to pull files out of our central...

In this set of tutorials, we’re going to take you through the basics of Subversion with Visual SVN Server and Tortoise SVN. Subversion (from here on in referred to as SVN) is a centralized Version Control System. That is, it’s a tool that allows us to version control files and collaborate on files. SVN deployed with Visual SVN Server gives us a server environment within which to maintain our files. Add to this a graphical user interface called “Tortoise SVN” and this gives us the simplest and quickest way for individuals to collaborate on files and version control those files.   SVN has been developed by CollabNet and is currently maintained by the Apache Software Foundation. It’s open source project...

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