Nov 202011

A short post to announce  an upcoming series of posts describing the project Jinfeng.

Jinfeng is a Chinese name meaning “Golden Phoenix”.

This is the name I chose for the integration and testing platform that I am currently building-based open-source tools and scripts written in Python / Jython.

This platform is mainly based on following tools:  Jenkins / TestLink / RobotFramework / Selenium / Sikuli, working together with the Jenkins plugin/Testlink of Bruno P. Kinoshita and scripts of my own.

A 0.2 version  is already packaged but I don’t find it’s mature enough to be released.
I also took a little late on writing articles describing the platform, for “professional” reasons. But all will soon return to normal. In the meantime, here’s a general diagram of the architecture of the Jinfeng platform.

 JinFeng platform

See you soon for more details.


Nov 062011

TestLink is an open source test management tool.

It allows you to create test project, composed of test plans, test suites, test cases.

It also manage requirements, and builds, Platforms …

Finally, it can generate a set of metrics and reports to track test coverage, test campaigns, found defects…

TestLink offers the ability to automate a number of transactions through an API that uses the XML-RPC protocol.
For the Jinfeng project, I had the need to use the TestLink API with the Python language, which is one of the components chosen to develop Jinfeng.

The main idea of Jinfeng is to create a testing platform for performing all stages of the industrialization of testing (deploys environments, installation of AUT, testing documentation management, testing execution management, load / functional / technical / etc …, metrics and reporting, defect tracking), all of this automatically, and if possible by using natural language commands. Each of these tasks being performed by different open source tools, the link is achieved by a “core” written in Python. Use the same language for all of the platform seems to be one of the conditions essential to the success of this project.
I was unable to find a complete open source library in Python to access the TestLink API, so I was forced to start the development myself.I make it available as open source on github for anyone who wants to improve their use of TestLink by automating tasks with Python.

The library ( is available here:

I also provided an example of using, to create:

– A new project

– A test plan

– 3 test suites

– Two test cases, each consisting of 5 steps test

In a future article, I will detail the contents of the library and its operation.

Thanks to:Bruno P. Kinoshita (for its development of the API in Java)

James Stock (for the ‘draft’ which inspired me: Testlink-api-python-client R7)

Sep 272011

For a number of reasons, you may want to see the object tree of your vCenter (Hosts, Datacenters, VM, Pool, Resource Pool, etc. …). For example, if you want to automate some, you need to find the path to point to a template, a resource pool …

It is an action quite easy to achieve, but how?

Simply open a Web browser, with the following URL:

https://xx.xx.xx.xx (with xx.xx.xx.xx equal to the IP of your vCenter).

You will get the home page as follows:


Bottom left, you can click on the link “Browse objects managed by vSphere” 


You will get an Authentification popup (you must use a user account from your vCenter VM):

If the connection is correct, you will get the following “Home”:

To browse the objects in your vCenter, you can then click on “content”:

We then get the page “ServiceContent”, which is like the highest level of the vmware object model, from which we can begin the exploration.

A little further down this page, we have for example rootFolder which is our “Data Center”. Its internal identifier is “group-d1 ‘.

Click on “group-d1 ‘and you can list your vCenter data centers:

From a datacenter, you can list all the objects attached to it: datastore, host etc …

Browse such group “host” (group-h23), we get the list of clusters in our Datacenter:

Continue the exploration of our objects tree, via the cluster “domain-c95” (this is always the Id and not the name of the cluster as seen in vCenter).

In the items listed in our cluster, we’ve got a “Resources” (resgroup-96) which seems interesting:

We are seeing then our Pool of resources! Clicking on any of them (the resgroup-237 for example) confirms this by displaying a list of the VM that are associated with our resource pool  (“resgroup-237”).

Is this really useful ?

A concrete example is the deployment of a VM from a template. One parameter in the function cloneVM needs to define the ResourcePool which the new VM wiil be connected.

Thus, the previous example allows us to determine the path describing the access to the resource pool:

Datacenter / Host / Resources /

 I will show you, in a future post, how to automaticaly clone a VM from a template  with a little piece of code (Jython/Python) and VIJAVA API.

Thanks. Olivier

Sep 202011

In a series of article “Getting started with …” I’ll show you how to install and use a tool (or concept) in 5 minutes (sometimes longer).

This article will address robotframework.


What is robotframework ?  This is a test automation framework, respecting an approach “Keyword Driven Testing“. You will be able to write your automated test cases with a fonctionnal approach, not only in a technical way.


The strength of robotframework is that this technical implementation can be performed in many languages ​​and tools. This can be Java, Python, scripts, Selenium … etc..

I chose to present robotframework because it is a major component of the Test Automation Platform Open Source I am creating and to which I devote a long series of articles.


In this article, I propose an implementation in Python which is probably the fastest way to a POC (Proof of Concept).


The following steps will be conducted on a Windows environment, but can  also be performed on linux, you just select the installation packages to suit your preferred environment (and may have to change paths and some scripts).


 Download the various elements that will be needed::

robotframework 2.6.0 (windows 32b)

python 2.7.2 (windows 32b)

jython 2.5.2

JDK Java (like 1.6u27)

 (Note: Java 7 has been available since late July for those who were on vacation and missed the info!)

 Start the installation of the Java SDK if you do not already have it on your computer. And we can begin.

Getting Started … (trigger the chrono)!

1 – Start by creating a directory. For example c:\Tapos (Test Automation Platform Open Source).

2 – Start the installation of Python 2.7.2, in the directory created earlier. Follow the installation as below:


2 – Start the installation of Jython 2.5.2, in the directory created earlier. Follow the installation as below:


4 – Start the installation of Robotframework, it will position itself directly in the Python installation directory.


(note: look at the screen 4 … there will always need experts in software quality assurance!)

5- Update your environnement variables JAVA_HOME, CLASSPATH ainsi que PATH.

To have :

CLASSPATH = C:\Program Files (x86)\Java\jdk1.6.0_27;

JAVA_HOME = C:\Program Files (x86)\Java\jdk1.6.0_27;

PATH = (votre PATH existant) + C:\Program Files (x86)\Java\jdk1.6.0_17;C:\tapos\jython2.5.2\;C:\tapos\Python27\;C:\tapos\Python27\Scripts;

6 – Create a subdirectory “core” in the “Tapos” directory

7 – Create a subdirectory “lib” in the “core” directory

 You must obtain the following tree:

 At this point, we installed the “engine” of our test platform, as surprising as it may seem !

Now te next phase, which will allow us to see if the engine is running correctly.

8 – Create, in the directory “c:\Tapos\core\lib”, a file “” which will contain the following lines :

#Created on 17 sept. 2011

#@author: sqaopen

import subprocess

from socket import gethostbyaddr

def lookDNS(ip):

      lDNS = subprocess.Popen([‘nslookup’,ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]


      return DNS

def lookPING(ip):

      lPING = subprocess.Popen([‘ping’, ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]


      return PING

9 – Create, in the directory “c:\Tapos\core\lib” a file “” which will contain the following lines :

#Created on 17 sept. 2011

#@author: sqaopen

import TechLib

class Tools(object):


  def checkComputer(self, *args):

      ip = args[0]

      print ‘DNS: %s’ %(TechLib.lookDNS(ip),)

      print ‘perte: %s’ %(TechLib.lookPING(ip),)

 10 – Create in the directory “c:\Tapos\core\” a file “TestSuites.txt” which will contain the following lines :


Library  Network.Tools  WITH NAME  Tools

***Test Cases***

Check the computer “” with ping and nslookup

      check Computer

 10 – Create in the directory “c:\Tapos\core\” a file “launcher.bat” which will contain the following lines:

@echo off

set JYTHONPATH=C:\tapos\jython2.5.2\Lib

jybot –pythonpath=lib –outputdir=results –loglevel=DEBUG %*

And now it’s over. We have implemented our first keyword tests!

How to run our test?

Open a command line, go to the core directory and type the command:

> launcher.bat TestSuites.txt

You should get the following result:


Now you just made your first test BDD oriented, or “Keywoard Driven Testing”.


The file “TestSuites.txt” describes your test case, using a set of keywords as well as data you want to use for your tests. In this example, we have one test case which consists of a single step test, whom the aim is to control the computer with IP = “” (ie the localhost, yourself).

The file “” is a kind of dictionary. This is the “technical” description of your various keywords. In this “first step”, we have defined a single keyword (to have the simplest example ever). But it is clear that automated test platform must have hundreds if not thousands of keywords available. Our key word “check computer” is designed to write (‘print’), the result of the ping and nslookup on the IP address contained in the test case.

The file “” is the technical library, ie the actual implementation of automated testing. In our example, it is simply the call of two OS commands and processing of their return. For the ping, it retains only the % of lost packets, and for nslookup, it takes the DNS name of the computer.

The structuration proposed here allows to separate the responsibility of writing the various components of our automated testing platform. Thus, we can appeal to developers for writing the technical library, expert in test automation for the dictionary, while functional business experts can now write automated test cases, independent of any tool (they are constrained by the existing dictionary, but they can ask for modifications).

Finally, note that Robotframework generated log file / report that can be accessed with a Web browser. It contains all the information written by our script:

 Stunning, is not it?

Conclusions: test automation keyword can be easy to implement with an open-source tool as robotframework. We will see in a future article how to improve our “engine” to give it the ability to manage our test environment (SSH, vmware VM, etc …) always in a mode keywords mode.

Sep 192011

🙂 Please, let me a comment or an email (, or click on a ‘like’ button, to let me know if this post was helpful.It takes time to write this kind of literature and comments are the reward!  Thanks.  🙂

Having a testing platform including VMware virtualization, and used for testing softwares with different Operating Systems like Windows, Linux (Red Hat, Debian, Solaris …), ubuntu, I want to deploy as soon as possible new OS on Virtual Machines.

For example, I recently added an ESXi vSphere 5 server (available since the end of August 2011) to enhance my architecture, which currently includes ESX 3.5, ESXi 4.1 and ESX 4.0.

And this week, with the release of Windows 8 developer preview, I have some work to do.

But like a lot of people, I’ve started by a failure, before finding a method which allows me to achieve my goal: to run a windows 8 on a 4.1 or 5.0 vSphere server (both of which been tested on ESXi).

I present below the unsuccessful attempts and the one that worked, and which ultimately will seem obvious.

Step 1 : get the installation files (ISO). They are simply here in 32-bit and 64 bit (respectively 2.8 GB and 3.6 GB). Note: a third version with more tools developers, sized 4.8 GB.

My advice: Save the files (ISO) on a NAS, accessible from any PC / VM on your network. Download the ISO at least for the 32 bits version.

Step 2 : Create a VM on your ESX 4.1 or 5, based on the guest OS ‘Windows 7’ (32b or 64b depending on the ISO you downloaded). Then start the VM, attach the ISO to Windows 8 via the “Connect” button and start the installation. I do not write more details because this is the standard procedure that you probably know.

 And then … It’s the drama: a beautiful screen of death that we thought gone forever:


Then you can restart the VM, redo the installation, 32b or 64 b, change the settings vmware … Always the damn HAL_INITIALIZATION_FAILED. Note one hope: on vSphere 5, you must choose “Windows 7” at the initial creation of the VM but you see “Windows 8” in the list of guest OS if you edit the parameters of an existing VM . Unfortunately, nothing change … Still the same crash.

I’ve browsed the web without finding any providential relief  about it. But lucky enough, it allowed me to know about the release of VMware Workstation 8, which supports the installation of «Windows 8».  Let’s go to the next step:

Step 3 : Download VMware Workstation 8. This product is not free, and to download it you must log in to your vmware account. The good news is that you can create a free account for those who do not have one, and you can get a vmware workstation 8’s trial license for one month. So on the download page, you will see first the license and three versions: the installation packages for 32 and 64 bit windows, linux 32 b and finally linux 64 b.

My advice : download the “windows 32-bit and 64” (474 MB) on your network and create a text file in which you will copy / paste the license.

Step 4: Install “Workstation 8” on your PC or on an available physical server . The sequences are:

Start the install, choose the mode “Typical”, installation is working. then enter the license (use the text file above), and confirm the license agreement. 

Step 5: Install “Windows 8”.

Again, the steps are simple. The approach is similar to what you used to do on vSphere 4.1: create an “envelope” of the VM, connect an ISO and start the installation. There is just one “fundamental” step to do. Let’s go:

Start by running vmware Workstation 8, and the temporary license will be displayed first.

After validation, you will get the HOME :

Click on “Create a New Virtual Machine” and you will have :

Click on “Next”…

And on the following screen, select “I will install the Operating System later”. This is the “fundamental” step that I mentioned previously. If you keep the default option and start the installation directly, you will get errors about a license file and you will not go further.

After a click on “Next”, you will see :


Then, select “Windows” and «Windows 7» or “Windows 7 (x64)”.

Click “Next”, et define the size disk and the kind of file.

My advice : at least 25 GB seems necessary, and select “Store as a single disk size”, we shall see the usefulness of this option. Click “Next”.

Here we are … Click “Finish”.

You get your VM in the list of available VM (I have two in this example, I make several kind of tests).

If you click on “Edit Virtual Machine Settings”, you will see the screen below which allows you to adjust settings, including those of the allocated memory (it lloks like the familiar environment of vSphere).

But click on the “CD / DVD (IDE)” and select “Use ISO image file:” then click “Browse” to connect the ISO file of “windows 8” you want to install:

Confirm with “OK” which takes you back to the HOME and the list of available VM. Then click on “Power On this virtual machine.” The VM starts and will boot from the ISO …


Let the initial setup (creating a user account), it is not the subject of this article.

You get your first glimpse of the new user interface of “Windows 8” Metro!

At the end of this long “step 5”, we’ve got a “Windows 8” installed (and which works) in a VM. But we do not reached our goal because if you remember, the VM is running on a physical server with the “Workstation 8” and not an infrastructure based on a vSphere 4.1 or 5.0. Continue our quest.

Step 6 : Move our VM “Windows 8” which runs, from “Workstation 8” to VMware vSphere 5.

I thought (naively) that, given the close dates of releases between “vSphere 5” and “workstation 8”, there was a good chance that the VM created under “Workstation 8” can also function under “vSphere 5”. For this, the most natural is to use “vmware converter” which as its name suggests, allows you to convert a VM between different vmware products.

So here you download converter, install and configure. Installation is in standalone mode on the computer that runs Workstation 8. You select your source VM “Windows 8” and then provide the connection information to your vCenter 5 (vCenter, not the ESX!) and start the conversion / migration. this is a “magic” tool, it converts and copies the VM on your vCenter 5.


I pass over the steps and settings. Because, as you guessed, when I started the “Windows 8” VM in my vCenter 5, it  boots but not finally started. So this step 6 is failed “as is” (unless someone knows about specific manipulations to lead to the end).

Step 7: Despair … There, I had come prepared to do anything. So I tried replacing the virtual disk.

Basically, the approach was as follows:

Create on a vCenter 5, a similar VM to that used to mount the “Windows 8” VM on the “workstation 8” :

– Same basic guest OS (Windows 7), same features for memory and disk

– Deleting the virtual disk on the datastore of the vCenter 5.

– Upload the virtual disk of the “Windows 8” VM, from the physical server to the vCenter 5  datastore (hence the need to select “Store as a single disk size” in the original creation of the VM, as it is easier to move a single large file!).

– Use the command “vmkfstools” to import the virtual disk on ESX

Not surprisingly, the start of the VM on the vCenter 5 did not give better results than previously. We see a message “Windows Developer Preview” but the VM stops during boot. Perhaps the study of the logs would allow an admin to find vmware configuration changes? I myself have given up this way.

Step 8 : The upgrade of version. I thought that was the easiest way to upgrade an existing VM to “Windows 8.” So I took one of my “Windows 7” test VM which I think is technically the closest to the “Windows 8” version . And I made a simple upgrade after connecting the ISO installation.


I confess that, reaching the fourth screen, I was hopeful. Then the “blue screen of death”.       🙁

Step 9: A good night’s sleep. Sleep on it… I finally combined what worked:

– install  «Windows 8» in a VM under “Workstation 8”.

– install “Workstation 8” in a VM under vSphere 5.

Yes, it’s so “simple” than this. In vSphere 5, first build (or reuse) a “Windows 7 32b or 64b” VM. However, change the settings for:

– Increase the memory to 4096 MB

– Allocate significant resources  for memory and CPU (as much as you can allow your ESXi)

– Assign 2 CPUs

– Have at least 20 GB of free (resize disk  if necessary)

Turn on your VM, and reboot again if needed to apply the new parameters. Now, follow previous steps 3, 4 and 5 on your “windows 7” VM. Install a version of Windows 8 32-bit, you may not be able to deploy 64-bit depending on the characteristics of your physical servers.

You will get a “Windows 8” running (in a “Windows 7” VM) on your ESXi 5.0.

My advice : for all the operations on the “Windows 7” VM, connect previously on it with mstsc -console, and not using the vmware console!


Finally, we’ve reached our goal  : to run a “Windows 8” on an vSphere 5 infrastructure. Although it is encapsulated in a “Windows 7”, you do not need to monopolize physical resources other than your vmware infrastructure.

Step 10 : Do the same on a vCenter 4.1?

The simplicity with which this took place over a vCenter 8 pushed me tried the same operation on a vCenter 4.1, which represents the majority of my qualification platform, and is currently the most common (vSphere 5 having just out). So I applied the approach of step 9 (but without the sleep’s night) but I ‘ve got an error when creating the VM in “Workstation 8”

Thanks to this post, I could solve the problem. We must change the settings of the VM that runs “Workstation 8” to activate a specific mode. To do this, turn off the “Windows 7” VM and on the vCenter 4.1, click “Change settings” for that VM. Go to the tab “Options”, line “Advanced” / “General” and then click on the “Configuration Settings …” which will appear in the lower right.


 On the new window, click on “Add Line” and insert the following three lines (or modify the value if the line exists):

deploymentPlatform = “vmkernel”

monitor_control.vt32 = “TRUE”

monitor_control.restrict_backdoor = “TRUE”

Close everything, restart the “Windows 7” VM, restart “Workstation 8” and there you should see new messages when creating a VM:


That it works! You can start the installation of “Windows 8 Developer Preview” on your ESX 4.1.

We have reached our goal of deploying a “Windows 8 Developer Preview”  on both vSphere 4.1 and 5.0. This installation is standard enough that everyone can use this VM for testing even if it is encapsulated in a VM Windows 7.

And now ?

I guess that VMWARE will “soon” communicate a workaround on how to run a “Windows 8” VM directly on a vCenter, bypassing the mechanism described above. While “Windows 8” is not officially released (the GA should not take place until a good year), interest in virtualization seems to me particularly in the ability to be able to quickly and easily create new test platforms taking into account the latest technical developments, without waiting for everything to be fixed.

If you enjoyed this post, please come back often because this site should soon be enriched by new items.

Sep 032011

Here we are, since the time that I think about it I finally launching this web site whose main theme will be the quality of the software, specifically raised at an angle “open”.

So what explains its title: SQA Open.

For neophytes, SQA = Software Quality Assurance.

Why “open”? Because I want to “popularize” this field and make it accessible to as many people and this will include the presentation and use of concepts and open tools, open source, everyone can use easily.

The field of software quality is a vast and extensive, and I hope to be your guide for you to discover some interesting aspects..

This site will certainly have to evolve significantly in the weeks and months ahead so please come back often, make contributions and / or comments.