Author: Bill Echlin

We’ve put together a series of 6 training modules that make up an introduction to Jira course. This course is focused on the basics of Jira. We’re covering the core concepts, the building blocks, that makeup Jira. This isn’t focused on any particular development methodology (like Agile) and we don’t go into configuring/using Jira to manage Agile projects here. We’re leaving that for a separate course. What we are doing is going through the core components of Jira and showing you what Jira is built on. It’ll give you the knowledge you need to deal with Issues and see how those issue records can be managed. We’re going to start out looking at what an Issue is (not any specific...

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

At this point, having completed module 1 and module 2, we have an SVN server, a repository in that server and we have files/directories in that repository. The whole point of this is to share files and version control them between different users. The next step then is for you to check out the files from the repository. From here we can simulate another user checking out the files from that same repository. In this way, we can see and learn how SVN deals with two people editing the same set of files at the same time.     In the last module, we created two user accounts (user1 and user2). With your first user account then (the one that...

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