Author: Bill Echlin

In this module we start to put together some API tests to check the REST Api that is delivered as part of a Rocket Chat install. The moment the Selenium tests complete Jenkins will trigger SoapUI to run a number of REST based API tests from one of the Windows AWS client machines. In setting this up we’ll cover a few key areas: 1. Looking at the Rocket Chat API calls 2. Installing and writing SoapUI REST API tests 3. Driving SoapUI from Jenkins 4. Using the Jenkins xUnit plugin to display test results We’ll run in to a few small challenges whilst setting this up. For example the rocket Chat Api returns some security credentials after the initial login....

As we look at driving a Windows client machine from Jenkins, to run Selenium based browser tests things get a little bit more involved. In this 3rd module of our Building The Test Automation Framework course we step things up a little bit. Nothing we can’t handle though as we take you through each step in detail. We’re going to cover four key areas: 1. Setting up a Windows Jenkins salve machine 2. Install the test software on the slave machine (e.g. Python and Selenium) 3. Creating a basic Selenium script 4. Running the Selenium Scripts from the Jenkins Master Machine Once you’ve completed all of these steps you’ll have setup a client Windows AWS machine that will run Selenium...

We have the test environment in place (if you don’t check here) and we know enough to be dangerous with Amazon Web Services. Next step is probably the most important. We need to get Jenkins installed, configured and running. Jenkins has to be one the testers most useful tools. It’s not just handy for kicking off automated tests it’s indispensable for automating all sorts of processes you have to complete day in day out. We’re going to cover 4 main areas here… 1. Jenkins Installation 2. Installing Jenkins Plugins 2. Jenkins Configuration 3. Deploying and Building the Application Under Test By the time we’ve completed the module we will have Jenkins running on our Windows Master machine. The Jenkins configuration will...

Our 6 module course on Building the Test Automation Framework starts with Amazon Web Services (AWS). We’re going to use AWS, and more specifically, the Elastic Compute Cloud (EC2) to build our test environment and automation system. It all starts with configuring and running up the virtual machines we need to run everything on. If you haven’t read our introduction to Building the Test Automation Framework you can read more here: An Introduction to Building the Test Automation Framework This first module is all about understanding Amazon Web Services (AWS) and Elastic Compute Cloud (EC2).   We’re going to cover six key areas: First, creating an AWS account (you can skip this part if you already have one) Secondly, configuring two...

Welcome to Building the Test Automation Framework. A 6 part course that takes you step by step through the process of building a test automation framework. A test automation framework we’ll build completely from open source tools. Each of the 6 modules is a short course in it’s own right. Each module covering tools like; Amazon Web Services, Jenkins, Selenium, Git, SoapUI and JMeter. When we’ve finished we’ll have a distributed test automation framework. A framework based on the principals of Continuous Integration and Devops. This is about building a framework at the system level that gives you the platform to automate much of what you need to do on a day to day basis.   To build this platform we...

One of the stand out moments in 2015 has to be the high profile fall out in one of the biggest sports in the world. A fall out between one of the most successful partnerships of all time in Formula 1. A fall out that had many parallels with the way testers are treated in our industry. The Chairman of Renault, Carlso Ghosn, stated publicly that he wanted to sever ties with Red Bull. One of the most successful F1 partnerships of all time, Red Bull and Renault, fell out. Why? Carlso explained that… “Unfortunately when we were winning championships the Renault name was never mentioned. It was the [Red Bull] team that was winning”. And when things weren’t going so...

It’s the start of a new project. Everyone is throwing in design ideas. Lot of excitement. Bit of a buzz. High level architecture is taking shape. Wire diagrams for the GUI are nearly finished. ‘This’ system will talk to ‘that’ system. You know which systems are storing the different pieces of data. Front end will be mobile iOS and Android. We’ll use a REST api to talk to the back end. The design is looking good. And everybody’s off. All beavering away. All building their own little bit of the system. Won’t be long before we put all the different parts of the system together for the first time. See it all working as a system. Sure… we’ll find a...

Chesley Sullenberger, the pilot who landed an Airbus A320 on the Hudson explained in an interview that “Everything we know in aviation, every rule in the rule book, every procedure we have, we know because someone somewhere died…. We have purchased at great cost, lessons literally bought with blood that we have to preserve as institutional knowledge and pass on to succeeding generations. We cannot have the moral failure of forgetting these lessons and then having to relearn them.” How would our practice of software testing improve and our discipline be enhanced if mistakes we made resulted in people dying? For some of us they can and do result in people dying. In many industries like medical devices and air...

Cross browser testing is always a bit of a challenge for test teams that are trying to keep up with the ever increasing combinations of browsers, platforms and operating systems. Add mobile browsers into the mix and you may as well forget traditional approaches testing. Testing manually just isn’t going to cut it. One approach worth looking at for cross browser testing using TestComplete’s browser emulator feature. Depending on your website or web app you may well be able to write a test once then just scale up using emulations of browsers on a single machine. Alright, nothing really replaces testing on the real device with the final release of the product. That’s an approach that’s time consuming, requires lots...

You’ve configured your test hosts (Bringing Manual and Automated Tests Together) and you’ve set up and run automated tests from QAComplete (Setting Up Automated Tests in QAComplete). Now we’re running these automated tests how do we track the results and how do we follow the traceability back to our requirements? Traceability For many of our automated tests we’ll want to track traceability back to the requirements they are providing us with test coverage on. From an QAComplete implementation point of view automated test cases are no different to manual test cases. Automated test cases are defined in QAComplete and linked back to the requirement. This traceability can be seen and modified when you view the test case in the test...