MeeGo wiki - User contributions [en]

Quality/QA-tools/TCMS

2011-08-17T12:39:59Z

Heliacorreia: Adding link to QAtoolproposal document

= TCMS =
This page is a brief insight regarding the suggestion for a new test cases management system.

== Motivation ==
As of now, [http://meego.gitorious.org/meego-quality-assurance MeeGo Quality Assurance project on gitorious] is the place where MeeGo community can get to know the existing testing material for a component whereas it is not the place where test cases are first created. In fact test cases are created on [http://tl.meego.com Testlink], the current TCMS for MeeGo but there doesn't seem to be a lot a activity on this tool.

== Functionalities to consider ==
The tool to be chosen should allow the following actions:
* Import/export of test cases (from and to *.xls, *.xml formats for instance).
* Make test cases reports and charts based on any criteria (test area, test type, ...).
* Export test cases reports and charts (to at least *.xls format).
* Link test cases with their related feature(s).
* Link test cases with their related bug(s).

== Miscellaneous ==
The following document also exposes a detailed list of features [http://wiki.meego.com/images/QAtoolproposal.pdf QAtoolproposal.pdf] among other things.

Brief git guide

2011-07-28T12:28:02Z

Heliacorreia: Fixed a typo

Git is handy version control for collaborative development and testing. This guides you briefly through basics to get started. Only terminal usage under [[GNU]]/[[Linux]] is covered, for graphical user interfaces please refer guides available at web.

'''Note''' - this was not placed under developer nor testing because it's common for all MeeGo contributors.

== Concepts ==

Please open the [http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf excellent git cheat sheet]. Work flow is illustrated in the upper-right corner of cheat sheet. The most basic flow with an existing repository goes like:

=== 1. Create ===

git clone <repository>

Example:

git clone git://gitorious.org/meego-quality-assurance/handset-ux-tests.git

=== 2. Change ===

<edit or create files with your favorite tools / editors>

=== 3. Commit changes ===

git add <newfile> (if you created new file)
git commit -a

Your default editor is opened and you need to write description of changes.

=== 4. Push changes to share ===

git push (this assumes you have commit rights to repository, please check with repository admin)

''' That's it! Congratulations! '''

== Pre-steps ==

=== Mandatory - Make sure you have git installed ===

[[Debian]]/Ubuntu:
sudo apt-get install git

=== Optional - If working behind ssh-proxy ===

If you are working with corporation you might need to resolve ssh-proxy challenge.

Make sure you have following $USER/.ssh/config for your user account

host proxy
HostName '''<yoursshproxyhere>'''
user '''<youruseraccounthere>'''
Compression no
LocalForward 2227 gitorious.org:22
host gitorious.org
User git
HostName 127.0.0.1
Port 2227

Run the following command:
ssh -f -N proxy
<type password for your account, if required>

''Please note that you need to open proxy connection every time you change network or disconnect/connect from network''

Now you can clone and push over ssh proxy to '''gitorious.org''', test as follows:
git clone git://gitorious.org/meego-quality-assurance/handset-ux-tests.git

== How to use gitorious to do a merge request ==
There are as many ways to do a merge request as there are coders, so this guide just aims at helping at the beginning.

=== Register on gitorious ===
Go to https://secure.gitorious.org/users/new to create an account.

Then define a SSH (secure shell) key to enable secured communication between your Linux PC and gitorious. Tap below commands to generate such a key from Linux:
$ ssh-keygen
Follow your terminal instructions.
$ cat ~/.ssh/id_rsa.pub
Copy the result of "cat" command. 
Then go to your user space on gitorious (example: https://gitorious.org/~heliaco), choose "Dashboard > SSH Keys > Add SSH Key", paste your clipboard's content, and save your update.

=== Make a personal clone of a gitorious repository ===
Go to the main page of the project you want to contibute to (example: https://meego.gitorious.org/meego-quality-assurance/auto-ux-testlib). 
Click "Clone repository" button, change your clone name as you wish, and confirm your action.

Now you should see the SSH url of your clone which is like the following example: git@gitorious.org:~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib.git.

=== Set up your Linux's working environment ===
From your Linux PC, clone the repository you just made:
$ git clone git@gitorious.org:~<username>/<project group>/<your clone name>.git
Example: git clone git@gitorious.org:~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib.git

You need to define a name and email within git. For this you can either use a global .gitconfig file or specify these settings within a particular repository.

To create a global file, tap below command:
$ gedit ~/.gitconfig
Then add below section into it, mentioning your name and email:
[user]
name = <Your name>
email = <Your email>

Finally, save and close the file.

To configure name and email within a repository, tap below commands:
$ git config user.name "Your Name"
$ git config user.email "Your email"

Now, one possible way of working is to make development on a master branch, and use another branch called "upstream" in the process of merging requests.

To create a branch called "upstream", tap below command:
$ git checkout -b upstream

Then define the remote server path for "upstream" branch:
$ git remote add upstream git://gitorious.org/${project_group}/${project_name}.git
Example: git remote add upstream git://gitorious.org/meego-quality-assurance/auto-ux-testlib.git

And switch back to "master" branch:
$ git checkout master

=== Commit patches ===
In order to track the files you modified and/or added in the project, tap below command:
$ git add <modified and/or added files names>

Commit your patch using below command:
$ git commit
-m parameter allows you to comment your patch.

Then you have to sync the "upstream" and "master" branches.

Switch to "upstream" branch:
$ git checkout upstream

Update "upstream" branch:
$ git pull upstream master

Switch back to "master" branch:
$ git checkout master

Merge your "master" changes into the "upstream" branch:
$ git rebase upstream

Prior to push your patch, you can display your changes which are now in the "upstream" branch:
$ git diff upstream

Then, update the remote branch:
$ git push origin master

=== Perform a "merge request" from gitorious web UI ===
Go to http://meego.gitorious.org/~<username>/<project group>/<your clone name> (Example: https://meego.gitorious.org/~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib).

Click "Request merge" button in the right column. 
"Create a merge request" window appears, fill in "Summary" and "Description" fields, set your project name as "Target Repository" and select your commit(s). 
Finally, click "Create merge request" button at the bottom of the page.
 
 
[[Category:Tutorial]]

Quality/QA-tools/TCMS

2011-07-11T08:39:44Z

Heliacorreia: Detail about getting a new TCMS.

Quality/QA-tools

2011-07-11T08:09:29Z

Heliacorreia: New tool suggestion.

= Quality assurance (QA) tools =

''' We moved our discussion to #meego-qa IRC channel as of March 24th 2011. Please join us there. '''

[[File:Tool_meegon.png|400px]]

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for quality assurance.

* "Open source tools – available for all, available for development and contributions. Make people accountable for quality."

'''Please note''' that developer-oriented content has been moved to [[Quality/QA tools development|QA tools development]] page. We apologize for any inconvenience. The target is to make this page clearer and more informative for the actual users of QA tools.

== Overview ==

QA tools support test planning, test execution and test reporting. The most important tool offering relating to this is illustrated in the figure below. In addition, there are also a couple of concept videos available at our [http://www.youtube.com/user/meegoqatools YouTube channel]:
* [http://www.youtube.com/watch?v=WdXBqGdLz8I Tool offering for manual testing]
* [http://youtu.be/Ry4MM-CX2b8 Test automation]

[[File:Meego-qa-tools.png|600px]]

== Tools and other utilities ==

If you want to contribute to the development of the following tools, test suites and utilities, please visit [[Quality/QA_tools_development|QA tools development page]].

'''Test tools'''

Each wiki page will contain more detailed description, installation instructions and tutorial on the basic usage. For now, please [[Quality/QA-tools#Collaboration spaces|contact us]] if you need help. Currently, you can install Testrunner, testrunner-lite, test-definition, Testplanner, OTS, Meego-ai, libcqpid, eat and MIN from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| Crash Reporter || On-device graphical front-end for sending core dumps produced by rich-core to core dump data base
|-
| [[Quality/QA-tools/OTS|OTS - open testing system]] || Test automation system
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||Command line tool for test execution
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || Comprehensive tool for UI testing
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || Reporting tool for publishing test reports
|-
| [[Quality/QA-tools/CrashReports|Crash Reports Web UI]] || Web UI for Crash Reports
|-
| [[Quality/QA-tools/QADashboard|QA Dashboard]] || Quality at a glance
|-
| Application Monitor || Monitor runtime indicators - CPU, memory, power for specified apps
|-
| Video performance || Collect FPS, CPU information when do video playback
|-
| [[Quality/QA-tools/QmlUITestlib|MeeGo QML GUI Testlib]] || Test cases and Cucumber steps for MeeGo QML UI applications
|-
| [http://wiki.meego.com/Testkit_Howto testkit-lite] || python based test framework, command line tool, supporting test definition xml
|-
| [http://wiki.meego.com/Testkit_Howto testkit-manager] || web based test tool with fancy UI, supporting both manual and auto testing remotely
|}

'''Other utilities'''

{| border="1" cellspacing="0"
|+
|'''Name (link to wiki page)''' ||'''Short description'''
|-
|[[Quality/QA-tools/Test-definition|test-definition]]|| XML schema for test plan and result files
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] || Test automation configuration packages
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||
|-
| [[Quality/QA-tools/rich-core|Rich core dumper (sp-rich-core)]] || A tool to collect core dump and context data from process crashes
|-
| Crash Reporter settings || Settings package for Crash Reporter
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] ||
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] ||
|-
| Service OS based Flasher || Flasher to support Intel netbook/tablet
|-
| Environment collector || Collect detail system environment information
|-
| [[Quality/QA-tools/Corelysis|Corelysis]] || A daemon to process rich core dumps in the back-end server
|}

'''Tools and utils not in active development'''

Tools listed here are in maintenance and no new features are planned to be implemented in the near future to them.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || Test execution tool with graphical UI
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] || Simple tool for creating and editing test plan files
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] ||
|-
| [http://min.sf.net/ MIN Test Framework] || Advanced test framework
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] ||
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] ||
|}

== Feature requests and bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla instructions:
* [[Quality/How To Report Bugs|How to report bugs]]
* [[Quality/Bug Life Cycle and Handling|Bugzilla workflow]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://www.youtube.com/user/meegoqatools YouTube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]

== Nice to have ==

None of the existing tools answer your needs? Here is where you should enter any suggestion.

* Relieve localization testing effort by automating all or part of it ([[Quality/QA-tools/Automation of L10n testing|Detail]]).

* We may consider the need to have a fully functional test cases management system that could be widely used by the community to create/update test cases ([[Quality/QA-tools/TCMS|Detail]]).

 
[[Category:QA]]

Main Page

2011-07-06T12:50:10Z

Heliacorreia: Adding potential useful links.

== MeeGo Project Functions ==
* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Handset_Program | Handset UX Program]]
* [[In-vehicle | In Vehicle Infotainment - IVI]]
* [[Product Management]]
* [[Quality]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]
* [[Architecture]]
* [[Meego IT]]

= User =

* [[MeeGo Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo on your netbook]
* [[Devices|Supported devices]]
* [[Install MeeGo from Hard Disk]]

= Developer =
== Developer Guide ==

* [[SDK/Docs/1.1|Developer Guide for MeeGo 1.1]]
* [[SDK/Docs/1.0|Developer Guide for MeeGo 1.0]]
* [[Build_Infrastructure | Build Infrastructure]]
* [[MeeGo Porting Guide]]
* [[QML tutorials]] - Some tutorials to help get started with QML, the Qt Modelling Language.
* [http://mxr.meego.com/ MeeGo cross reference] - Index of MeeGo source code
* [[Brief_git_guide|Brief git guide]] - An overview of git as well as an example about how to use gitorious to do a merge request.

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, BeagleBoard, PandaBoard, Snowball)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Process|Release process and work flow]]
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

== MeeGo Components ==
* [[MeeGo_UX_Components|MeeGo Components]] - Supported common QML components

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], [[Gitorious_guidelines|Gitorious guidelines]] and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].
* [[Build_Infrastructure/Community_Builder|Building applications]] for MeeGo

See also [[Who's who]].

== Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Office/Meetings|Community Office meetings]]
* [[Localization team]]

Regional Activities.
* [[Local MeeGo Networks]]

== Bi-Annual MeeGo Conference ==

'''Upcoming Conferences'''
* [[MeeGo Conference Spring 2011|Spring 2011: May 23 - 25 at the Hyatt Regency, San Francisco]]
* [[MeeGo Conference Fall 2011|Fall 2011: November Date TBD in Europe]]

'''Past Conference Wrap-Up Information'''
* [[MeeGo_Conference_2010|Fall 2010: November 15 - 17 in Dublin]]

== Structure and Governance ==

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]
* Bi-weekly [[Technical Steering Group meetings]]
* [[Working Group Process]]

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

[[Category:Top level]]

Kernel patch guidelines/git for starters

2011-07-06T12:28:05Z

Heliacorreia: Adding potential useful links.

''' The Tao of [http://git-scm.com/ Git] OR how I stopped getting scared of [http://git-scm.com/ Git] and started using it OR Why the hell aren't you using [http://git-scm.com/ Git] yet ;) ?'''

= Did you Git it? What the hell is git? =
Long, long, long time ago, a cool hacker named Linus was faced with a dilemma - the Linux kernel that he and lot of other world wide hackers were using and working on, was hosted on bitkeeper and the owners of bitkeeper were pulling the plug on hosting Linux kernel. Linus knew that without a source code management system which could handle global collaborated code development, the Linux kernel was more or less kaput! Linus rolled up his sleeves and in the ancient respected hacker tradition, wrote a brand new version system - called GIT. [http://en.wikipedia.org/wiki/Git_(software)#Early_history more history]

''NOTE'' even though git was developed for the Linux kernel, it is still a source code management system. You can use it for just about everything.... In fact, folks maintain documents, images, and god knows what else with git. Anything that needs version control involving multiple developers across multiple geographies, git is pretty good at it.

= Is there a full form for GIT? =
Linus Torvalds has quipped about the name "git", which is [http://en.wikipedia.org/wiki/Git_(British_slang) British English slang for a stupid or unpleasant person]:
"I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git."
But then, [http://en.wikipedia.org/wiki/Git_(software)#Name what's in a name huh?]

= Ok great.. I have to learn git, so where do I start? =
It is pretty easy to learn git - there are only 3 fundamental concepts to understand:
# Tree
# Branch
# Patch

== Patch, patch everywhere, but not a code to see. So, what did you say a patch was? ==
A patch is a set of changes (may include multiple files) doing one logical step only.

Lets say Alice has file x:
hello wrold
mama mia

Bob gets this file and notices the typo ''wrold''. He has two options:

option 1) Bob walks over to Alice's desk and sees Alice editing file x and tells Alice:
Alice, you have a typo in line 1, change wrold to world.

Option 2) Bob sends Alice a new file x.new with a note that he fixed the typo
hello world
mama mia

Well, computers are not too good at English and we have people involved, also, so we need a format which can easily be understood by computer applications, as well as read and shared by humans for humans.

Welcome to [http://en.wikipedia.org/wiki/Patch_%28Unix%29 Patch]. Bob edits file x and fixes the typo and emails the changes to Alice.
diff --git x.old x.new
index 835e1c2..f75f149 100644
--- x.old
+++ x.new
@@ -1,2 +1,2 @@
-hello wrold
+hello world
mama mia

''Explanation:''
--- x.old
old file name
+++ x.new
new file name
@@ -1,2 +1,2 @@
this is called a chunk -> each chunk is a change with a bit of code above and bit of code below to give you a context. The -1,2 +1,2 tells you that the changes were made between lines 1 and 2.
-hello wrold
the '-' prefix shows that this line was deleted
+hello world
the '+' prefix shows that this line was added (so in conjunction with the above, shows that no change occurred).
mama mia
the ' ' prefix tells us that no change occured.

Now, Alice can see immediately that there is one file changed, one line changed in that file and the exact change, as well ;).

''How did this magic happen?''
There are two unix utilities from ancient times, diff and patch. They are opposites, diff generates the diff between files and patch applies the diff to the file to be modified.

In our example above, Bob uses the diff program to generate the diff and Alice uses thepatch program to apply the patch.

Good things:
# only the change is sent across
# pretty concise and saves a little on network bandwidth, and no confusion where the change happened.

Bad things:
# Alice should know the file x to understand the change, or at least have access to the file x to see where the change occurred.

Now back to git - git works with patches:

A git commit is a single patch, here is the git patch if Bob was working on git. Yeah, we will discuss how to generate and work on patches in later sections, but hold on to your horses for a minute here.

From dd392da509bec9f7cd3a8b282c0386f8fcbc35d8 Mon Sep 17 00:00:00 2001
From: Bob <bob@somwhere.com>
Date: Fri, 7 May 2010 13:34:20 -0500
Subject: [PATCH] fix typo of world

world has the wrong spelling
---
x | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/x b/x
index 835e1c2..f75f149 100644
--- a/x
+++ b/x
@@ -1,2 +1,2 @@
-hello wrold
+hello world
mama mia
--
1.6.3.3

Aah, more information than an ordinary git file. Git patches are designed to be:
# Emailed - so should be readable by a program - most opensource programs are developed by exchanging emails rather than telephone calls and meetings ;)
# Read by patch program - so should have a compatible format
# Informative enough to be readable by humans

Lets do a line by line explanation here.
From dd392da509bec9f7cd3a8b282c0386f8fcbc35d8 Mon Sep 17 00:00:00 2001
This gives an commit ID for this patch.
From: Bob <bob@somwhere.com>
Who is this patch from? the format is Name <email id>
Date: Fri, 7 May 2010 13:34:20 -0500
Date when the patch was generated
Subject: [PATCH] fix typo of world
The subject [PATCH] says the type of email. Presto, you've got a patch, and ''fix typo of world'' tells Alice what this patch is about.

world has the wrong spelling
This is the detailed message or the body of the patch - explanations of what we do are good idea to have here. (we learn more of this later on - we use the term commit message in git context)

---
patch uses the -- as a sectional thing. the first --- till diff is considered the diffstat section - things added below this line till the first diff are not committed into the git repository when merged

diffstat is diff statistics -> essentially the statistics information of files changed, lines deleted and added, etc.

x | 2 +-
file name | file change statistics histogram - shows total lines changed (deleted and inserted) and a +- based ascii graph.. usually with large number of files changed, this is a handy thing to see which file was largely impacted.

1 files changed, 1 insertions(+), 1 deletions(-)
Ok this is too obvious right?

diff --git a/x b/x
index 835e1c2..f75f149 100644
--- a/x
+++ b/x
@@ -1,2 +1,2 @@
-hello wrold
+hello world
mama mia
we already dealt with this previously.
--
1.6.3.3
Another git ignored section information ;). This just gives you an idea which version of git was used to generate the patch.

Voila! And that is all that a patch is, diff information organized in a certain way.

=== Related commands ===
* git add file - get this file ready to be committed into the repository -note it is not done yet..
* git status - show how commit status
* git commit - commit my patch into repository (try to use this with -s option)
* git format-patch - generate a well formatted patch out
* git send-email - send my patch in email.
* man git-add , man git-status, man git-format-patch, man git-commit, man git-send-email - learn all about these commands..

== What is a branch? ==
A branch is a simple concept. It is a version of the original s/w, on which a specific feature/operation is being done.

There is one exception though, the master branch -> This is the branch which has everything integrated. You can have multiple branches inside a single repository, each branch can have multiple patches independent of the other branch. Typically, a git repository looks like the following

master
|-- for-next-opp
|-- sdp-fix
| `-- gpmc-test
`-- wip-smartreflex
OR represented as a directory form it'd look like:
origin/master
origin/master/for-next-opp
origin/master/wip-smartreflex
origin/master/sdp-fix
origin/master/sdp-fix/gpmc-test

But you get the picture. Each branch does something, you spawn off to do something else, like me working on 4 different things at the same time on the same tree, so i can switch whichever git branch that I fancy to work on and commit my changes there, then switch somewhere else and do something else altogether, etc.

origin -> the branch from where everything came from. We could even have the same repository contain multiple trees. Ok, that is a bit too much for the moment. Let's keep it simple and understand the naming conventions. There are a few generic ones in kernel community:
# master - main branch
# next - candidate branch, which is planned to be merged to master at some point ahead
# wip - work in progress branch, usually related to something.
# all other names - you are free to choose what ever names you like, just use something that does not confuse your, or confuse other people, if it a public branch!!

''TIP'' We all work on multiple things at the same time and interruptions to work on something else is normal (even though not desirable).. ALWAYS use git branches to organize your work, it is meant to make your life easier. ;)

===Related commands:===
* git branch - list branches
* git branch my_branch - create a branch from whereever I am
* git log show the log of all commits i have in my branch
* git checkout my_branch - switch to my_branch - this should pre-exist
* git checkout -b branch_name --track origin/some other_branch - create a branch and checkout to that branch
* git merge - merge one branch to another
* git rebase - rebase current branch to the latest on another branch. usually useful if you want to move your current changes to the latest in the parent branch OR switch to another branch altogether.
* man git-checkout - aha, plenty of options to do whatever you like
* man git-branch - see magic, such as deleting branch, etc.

== What is a git tree? ==

Do this:
mkdir test_dir
cd test_dir
git init
Voila! You now have your own git repository, a.k.a tree. Tom, Dick, Harry, Alice, and Bob can have their own tree. They can clone (or copy) from each other's tree. Each repository(tree) will have multiple patches as commits on it and contributions can take place towards every other tree.

In general, in a community working on a common software, there is usually a primary tree (repository) or a final tree. In the example of Linux kernel, it is [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary linus' tree]. All code has to get there eventually. How is this decided? Essentially, it is a community consensus to have one person maintain the final code, or the final integrated code. Obviously, there is no point in Tom, Dick, Harry, Alice, and Bob all having their own changes without integrating in a central point.

There are lots of kernel trees, but main trees are usually hosted [http://git.kernel.org here]. To take TI OMAP kernel trees as an example, it tends to be a little complex, as follows:

OMAP Specific code: Tony -> Linus
OR
ARM Code: Russell -> Linus
OR
Power management core: Rafael -> Linus

etc. Tony, as a platform maintainer, maintains his own tree, so do Russell and Rafael.... You can also maintain your own tree [http://gitorious.org here] if you like. ;) But the point to note: there are community accepted maintainers, just another smart engineer who usually takes the pain to align a bunch of similar folks chattering around with code ;)

git can understand git(yeah git) protocol, http/https protocols, ssh, ftp, and bunch of other protocols and can even make a copy from one local directory to another local directory. the git tree is visible using normal commands such as ls, or you can view your tree with a tool like qgit, gitk, etc., or even over the web, like gitweb. For command line fans, you can use tig, which lets you study a git tree in a GUI-like environment using just the console.

Someone sends you a link like http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary and tells you platform X code is out there, clone and build it. Open the link and you will see:

URL
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

To clone (or download/copy) the tree, just do a ''git clone link''. voila! You now have a copy!

'''Important thing to remember with git -> every repository is a complete repository''' - You don't need a network (unlike clearcase dynamic views, if you've used it) or anything other than your own machine. Any patch from Alice to Bob should be shared by either exposing the git repository over one of the protocols (like setting up your own apache webserver and exposing your git repo there) or generating and sending out your patches from your repo to other users by email. If you cloned the tree, you have your own tree now. But try not to keep your changes in your tree forever. The rule in opensource is "release often, release to upstream" (ok that was a plagarized version of [http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html this] ;) ).

=== Related commands ===
* git clone link_to_remote_branch - clone a remote repo to my local machine
* git fetch - fetch blobs (or repository data)
* git pull - pull latest changes from remote repo to my local machine (that is, first it fetches all changes from remote, and then merges them in your local tree)
* git push origin branch - push my local branch to the remote branch
* git push origin :branch - delete the remote branch

= HANDS ON - Send a kernel patch to a mailing list like MeeGo mailing list!!! YAAAY.. Finally =
Alright, time to stop the blah blah and do some coding. So, let's actually go hands on from cloning a tree, modifying it, generating a patch, getting it ready, and posting it upstream.

'''Remember the MeeGo rule: If a patch is for a project that has an upstream version, post it there first!'''

==Objective==
Let's try and do something tricky -> We are going to enable missing ethernet GPIO mux for SDP3630 and send the patch to the MeeGo Mailing list.

== Installing git ==
on Ubunto 9.10:
sudo apt-get install git-core git-email qgit

To set up the environment so that you can clone a git tree inside your organization

== Pulling a tree ==
That is rather simple: just do
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

once this is done,
cd linux-2.6

You will be in the repository.
$ git branch -va
* master 5fe8321 Merge branch 'x86-x2apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
remotes/origin/HEAD -> origin/master
remotes/origin/master 5fe8321 Merge branch 'x86-x2apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

We did a git branch -va here. The -v shows a verbose description of where the branches are (commit ID of the HEAD, or topmost commit in a branch), and the commit message. The -a shows all hidden branches, by default the remote branches are usually hidden, so you need a -a to show them.

Notice how the * points to master -> the * points to the branch you are currently on.

In other trees maintained by maintainers, you'd see additional branches in remote, as well. To pull a similar branch gpio_development that a maintainer has, do the following:
git checkout -b gpio_development --track origin/gpio_development

This means the following:
-b (create a local branch)
--track -> keep track of remote branches, so that next time you do a pull, the local branch will reflect all changes in remote branch. :)
So now, I have a local branch for gpio_development, which is in sync with remote gpio_development branch in maintainer x's tree ;). It is no longer required to use --track in recent version of git, since it is now the default behavior, when doing a checkout of a remote branch.

'''Exercise:'''
git branch -v
git branch
git checkout master
git branch -v
git checkout gpio_development
git branch -v
See how these commands differ and the resulting behavior, use the man pages to better understand how these commands work. (such as, ''man git-branch'' or ''man git-checkout'')

== Branching off to a working branch ==
Next, I create a sub-branch to work in. This is where I will make my changes.
git checkout -b ether-mux
ether-mux does not exit in my tree, so -b will create a branch called ether-mux and git checkout will ensure that I am on that branch. I can alternatively do the following:
git branch ether-mux
git checkout ether-mux

Essentially, both do the same thing, but the -b is a wee bit faster since you don't need to type too many commands. :)

==Writing clean code==
Before we write code, let's read a bit on what the ancient masters tell us from their collective wisdom.

''Disclaimer: I have borrowed this from [http://omapedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails here]''
===Linux Documentation===
The following Linux documentation must be read before anything:
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD Documentation/SubmittingPatches]
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle;hb=HEAD Documentation/CodingStyle]
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingDrivers;hb=HEAD Documentation/SubmittingDrivers]
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmitChecklist;hb=HEAD Documentation/SubmitChecklist]

===Checking tools===
====checkpatch.pl====
scripts/checkpatch.pl is a script that facilitates better kernel code, and can be used to check many coding style rules.

This script applies on patch files by default, but can also process complete source files using the <tt>-f</tt> option. To get a list of options, run:
checkpatch.pl -h

This ([http://omapedia.org/wiki/File:Run-checkpatch.tar.gz script] is an example used to easily call the checkpatch.pl script on a series of files (to run periodically during your development, for example).

You can also set up GIT to run checkpatch automatically before each commit (and reject it on failure). You need to copy the attached [http://omapedia.org/wiki/File:Pre-commit.tar.gz script] into your GIT repository under <tt>''$GIT_DIR''/hooks</tt> directory (normally as <tt>.git/hooks/pre-commit</tt>). This script also runs <tt>git diff --check</tt>, plus as an added benefit, it sets file permissions for common files (c, h, makefile, README) to 0644, and executables (directories, shell scripts) to 0755. This is a common issue when editing files in Windows.

If you want to bypass the check (for example, if the failure is intended), use the -n flag for commit to ignore the checks. Just be sure that you still resolve any failures that were correct, and there really wasn’t a better, proper way to write your code without checkpatch errors. Now there is a whole set of discussion about the 80 character limit that sometime forces less understandable code (you can read about the pros/cons [http://lkml.org/lkml/2009/12/15/490] and find a patch [http://lkml.org/lkml/2009/12/15/508] to checkpatch to make this optional) BTW, Linus prefers [http://lkml.org/lkml/2009/12/17/208] in many cases, to ignore the 80-char-limit warnings.

But wait! You can do even more. Since you are already modifying files, why not run checkpatch on the whole file (and not just on the lines you are changing)? To see if there are any already existing checkpatch errors in the files that you modified, set up these two bash aliases that will run checkpatch on the whole files that are about to be committed (just run ‘chkp’):

alias gitd='git rev-parse --show-cdup'
alias chkp='`gitd`scripts/checkpatch.pl -f `git diff --name-only HEAD | awk -v i=$(gitd) "{print i\\$0}"`'

'''Note''': It is always recommended to run checkpatch.pl with --strict to get better warnings.

====sparse====
[http://kernel.org/pub/software/devel/sparse sparse] is a static code analysis tool that shall be run on all source files heading a kernel release.

Luckily, sparse is integrated into the kernel build-system and can be easily invoked.

Example for a single file:
make C=2 drivers/hsi/hsi.o

Example for a complete folder with some filtering on some error messages:
make C=2 drivers/hsi/ 2>&1 | grep -v __cold__

== Do your development ==

Now that we know some of the terms, let's write some code. In my case, I am editing the file arch/arm/mach-omap2/gpmc-smc91x.c
I added mux.h inclusion and add the following logic:
if (omap_mux_init_gpio(gpmc_cfg->gpio_irq, OMAP_PIN_INPUT)) {
pr_err("%s: Unable to init mux for smc gpio\n", __func__);
gpio_free(gpmc_cfg->gpio_reset);
goto free3;
}
Since I wanted the mux to be done for the provided gpio number.

Remember the golden rules:
* Always plan how you modify code. First, figure out what changes need to be done, then divide them into logical chunks. Remember each logical piece is a separate commit/patch of it's own. Even a bug fix might involve doing two or three logical steps. Split your patches as needed, but use common sense when to split and when not to ;)
* Absolutely NO [http://en.wikipedia.org/wiki/Sparse sparse] warning addition (to install sparse on ubuntu, just run '' sudo apt-get install sparse''), at least due to your changes. In my case:
rm arch/arm/mach-omap2/gpmc-smc91x.o; mymake C=1 arch/arm/mach-omap2/gpmc-smc91x.o
* Be compliant with the coding style. A good idea will be to read through the Documentation/ directory links provided above in the Linux kernel.
* Test it with omap3_defconfig to ensure your code is built for multi-omap case. Might be a good idea to build for other platforms which use your code. At least build it, even if you don't have the platform. Others get pretty pissed if your code breaks their platforms!
* Test your change on as many platforms as you can.

$ git branch -v
* ether-mux e1fc6fa Linux-omap rebuilt: Updated to -rc6, merged updated for-next
master e1fc6fa Linux-omap rebuilt: Updated to -rc6, merged updated for-next
$ git status
# On branch ether-mux
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: arch/arm/mach-omap2/gpmc-smc91x.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
[...]
no changes added to commit (use "git add" and/or "git commit -a")

Ok, so I am ready for the next step.

== Committing your changes ==

If you are modifying multiple files, you have various options, but mainly organize the changes in logical order per commit. Remember each commit is a separate patch, each patch can modify more than 1 file, but should be a single logical change. Here you have two options:
git commit -a -s
commit all changes that you did in the code in a single shot. OR
git add file1 file2...
git commit -s
This will commit only the files which you add with git add. Note: The -s will add a signed-off-by with your details automatically.

===Note on git commit comments===

You must have seen that the git comments are used to populate the patch file header in the format-patch phase:
* The 1st comment list is used as the patch subject
* The rest of the comment is copied in the patch file comment area

But pay attention that the comment will be integrated to the email sent by git-send-email, only if there is a blank (empty) line between the 1st line comment (used as subject) and the rest of the comment lines.

Example of a commit comment:
This is the 1st line, that will be used as patch subject

This is the 3rd line of comment (intentionally left 2nd line empty so that this part of comments are integrated into the emails).

'''Suggestions for Commit messages''': Commit messages are informative for reviewers and maintainers. Remember, once the patch is submitted, it has a long way to go through various maintainers and mailing list members before reaching kernel.org. You need to put yourself in the shoes of maintainers and reviewers who may or may not be familiar with all the internal details after a few months of time, but still need to understand the motivation for a change.

A commit message is structured:
# What is the problem this patch is trying to solve, that is why is the existing code not correct.
# The strategy by which this patch attempts to solve the issue. Remember people can read code, so giving "introducing variable x solves issue", instead describe the gist of how you solved the issue.
# What is the impact of the change when there are dependent modules, that is, if you change an function entry which may be used by others modules, you may want to document it here, rather than get the other person discover it when he/she builds their module.
# Optionally, you may state what testing you may have done to ensure the issue is solved.

Some of the above points might be self evident and could be skipped, but it is usually a good idea to be descriptive enough. Again, it is a fine balance between being informative and going overboard. Community members and maintainers are usually kind enough to help guide a patch in.

Read [http://who-t.blogspot.com/2009/12/on-commit-messages.html this] and [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html this] for more detailed rationale.

Note: in the case of MeeGo, ''DO add:''
* If the patch is already upstream:
kernel.org status: upstream | commit ID: eda345
* If the patch is merged to maintainer's tree:
kernel.org status: accepted | link: link to patch
* If the patch is under discussion
kernel.org status: under discussion | link: link to the public discussion
* If the patch is not planned to be published
kernel.org status: wont be published | reason: state reason here (such as, temporary hack)

In my case:
omap3: smc: enable mux for ethernet

Enable mux mode for GPIO pin for the interrupts to come in. This is
specifically useful for bootloader-less kernel booting using
configuration header as the u-boot does not exist for configuring
mux values before hand for the system.

kernel.org status: wont be published | reason: demo only

Signed-off-by: Bob someone <bob@somewhere.com>

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch ether-mux

Note: If you committed anything and forgot to update/need to change the previous, don't panic. :)

git add new_changed_file
git commit --amend

This will re-commit the last committed patch with the changes you just did, that is, it replaces the previous one.

==GIT patch creation==
Now that we have committed our changes, time for us to send this patch out!

===Useful links:===

* http://linux.yyz.us/patch-format.html

<cite>Subject: [PATCH $version $n/$total] $subsystem: one-line summary

(keep the one-line summary < 50 chars)</cite>

* http://userweb.kernel.org/~akpm/stuff/tpp.txt (Patternity, do’s and don’t, ...)

* Linux [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD Documentation/SubmittingPatches] contains detailed info on signed-off, acked-by, maintainer, reviewer, ...

* [http://www.youtube.com/watch?v=LLBrBBImJt4 Video Tutorial: Write and Submit your first Linux kernel Patch by Greg KH]

=== Generating Patches Notes ===
first create a temporary directory where you want the patches to reside:
mkdir ../smc-patches
The easy part -> here, based on the number of commits, you have multiple options:
If there is a single commit:
git format-patch -s -M -o ../smc-patches master..
this generates the patches, where
* -s adds your signed-off-by if it is not present
* -M generates diffstat with the proper depth - no truncation
* -o ../smc-patches - tells it to generate patches to this output directory
* master.. tells the git format-patch script to generate all patches in my current branch from master branch onwards. note, there are multiple other ways: a -1 here says last one patch, -2 will generate last 2 patches.. commitId.. will generate patches since commit id etc.. see man ''git-format-patch'' for further information

If there are multiple commits:
# you need to add a cover letter - this explains what the patch series will do (done with --cover-letter option)
# you need to add -n option to generate numbered patches. (in reverse - you '''DONOT''' need to add -n for a single patch)

Example:
git format-patch --cover-letter -n -s -M -o ../smc-patches

you will find a patch 0000-cover-letter.patch -> this has to be manually edited. example:
From e5d1394f93b2f972a516daaf55967871b4bf8c0e Mon Sep 17 00:00:00 2001
From: Bob someone <bob@somewhere.com>
Date: Fri, 7 May 2010 20:23:46 -0500
Subject: [PATCH 0/2] *** SUBJECT HERE ***

*** BLURB HERE ***

Replace the subject and BLURB with enough detail, and leave the rest of the file mostly intact, unless you'd like to edit information there.

== Check if your patches meet linux kernel coding style guidelines ==
As we discussed earlier, Linux kernel includes a script called scripts/checkpatch.pl - use it to ensure your patch has no problems
$ scripts/checkpatch.pl --strict ../smc-patch/0001-omap3-smc-enable-mux-for-ethernet.patch
total: 0 errors, 0 warnings, 0 checks, 19 lines checked

../smc-patch/0001-omap3-smc-enable-mux-for-ethernet.patch has no obvious style problems and is ready for submission.

This is what you want to see: 0 error, 0 warning. :) If all is good, you are ready to send the patches out.

== How to send a patch to a mailing list ==
First set up your Linux PC to send the patch. For example, in your organization, you may want to follow [[https://git.wiki.kernel.org/index.php/GitTips#Using_msmtp_to_send_your_patches | this]]

== Using git send-email to use msmtp ==
* Use an alias like gsend, instead of typing full options of git-send-email
alias gsend='git send-email --smtp-server /usr/bin/msmtp --from "My Name <someone@somewhere.com>" --envelope-sender="My Name <someone@somewhere.com>"'
'''WARNING''' of course, you need to change the My Name and someone@somewhere.com to something that represents you :)
Here:
# --smtp-server /usr/bin/msmtp : tells the git-send-email that msmtp is the email server (which you have already told to forward to your email forwarding server when you edited ~/.msmtprc).
# --from : shows the email name and address as it appears to the entire mailing list and recievers
# --envelope-sender : ensures that mailing lists are happy by ensuring the right reply-to email headers are part of the email. some mailing lists will refuse to post to the full list without this.

''Remember by default, git send-email will add all folks who are in From:, Cc: Signed-off-by: tags to the email Cc:''

== Other useful options in git-send-email ==

# --to "Some guy <anotherguy@sometime.com>" this will explicitly send the email with to set to this guy, you can repeat --to for every specific person you want to add
# --cc "Some guy not in patch <from@some.place.else.com>" will add this email to Cc list. Again, you can repeat --cc for each person you want to Cc to.
# --suppress-cc (see man git-send-email for all options this has) This will remove the automatic additions. This is specifically good when you want to send patch for review, for example, an accepted patch for review to meego-kernel@meego.com it is safe to use specific --to and --cc and add --supress-cc=all (to prevent auto addition of anyone including the From: or CC: tag) .. '''NOTE''' some old git installations (on older ubuntu distro installations, as an example) don't have --suppress-cc options, but new ones do.

''Tip'': It would be wise to modify the gsend alias in your ~/.bashrc or ~/.bash_aliases file as needed to automatically add it on login.

''Tip'': Send this patch to yourself first with --suppress-cc=all. Review it as if a third party, who has no clue what you did, is reading your patch. Remember, when you send a patch to a list, you are asking folks to read and agree to your changes. Linux is a community thing. We all own responsibility for the resulting code :).

== Who should I add as CC for a patch? ==
When you are posting upstream for the Linux kernel, you have a script called scripts/get_maintainer.pl, use it ''scripts/get_maintainer.pl 0001-my-patch.patch'' (just like you'd use it with checkpatch.pl). It spits out a list of email IDs. It is usually a good idea to add most folks and selectively include the mailing lists, based on what audience you seek. Recently however, the suggestion has been to use ''get_maintainer.pl --no-git'' to reduce the spam in public mailing list. This option will choose from just the MAINTAINER file the email IDs to post to.

So good luck, and let the patches roll :)

= Other links =
You may also want to visit the following wiki pages: 
[http://wiki.meego.com/Gitorious_guidelines Gitorious guidelines] 
[http://wiki.meego.com/Brief_git_guide Brief git guide]

Web infrastructure/Meego.gitorious.org

2011-07-06T12:14:35Z

Heliacorreia: Adding potential useful links.

This page details the best practices for MeeGo community members working within the Gitorious code repositories.

== Projects ==
Projects are the highest level organization within Gitorious and all MeeGo projects are listed on the http://meego.gitorious.org landing page. Projects in general are organized by the [http://meego.com/developers/meego-architecture MeeGo architecture] diagram. There are some deviations from this, but we are trying to align projects with the diagram as much as possible and have additional community support projects where needed.

==== Adding a new project to meego.gitorious.org ====
If there is a need to add an additional project within http://meego.gitorious.org, submit a bug request: http://bugs.meego.com/enter_bug.cgi?product=meego.gitorious.org first. If it is determined that none of the existing MeeGo projects will serve your repository needs and the MeeGo project needs, then a new project can be added. After the project is created, a request is submitted to the Gitorious administrators who will flag the project to be listed at: http://meego.gitorious.org/.

==== Adding an existing project to meego.gitorious.org ====
Follow the steps above and detail why this project should be added.

==== Project naming ====
Most projects are being named in a consistent way to help with search and clarity. New projects should be named with the MeeGo title at the beginning, in both the title and slug. Examples are:

* http://meego.gitorious.org/meego-handset-ux
* http://meego.gitorious.org/meego-developer-tools
* http://meego.gitorious.org/meego-platform-security

== Repositories ==
Where projects are largely for organizing, repositories are where all the activity happens. Repositories can be created in any project and each have their own commit rights, merge configurations, and administration.

==== Adding a repository ====
To add a repository to an existing project, submit a bug request at: http://bugs.meego.com/enter_bug.cgi?product=meego.gitorious.org. Please include the following details in your request:

* Project name: where to create repo
* Repository name: what to call it
* Admin: Gitorious username or team who will administer this repo

'''Example:''' http://bugs.meego.com/show_bug.cgi?id=6239

== Collaborators ==
When each repository is created it should have a person or team designated as the owner or admin. This individual or team has the ability to administer their own repository, including adding collaborators. Individuals or teams can be added to the repository from the committership page and be given '''Read''', '''Commit''', or '''Admin''' rights. Example: http://meego.gitorious.org/meego-handset-ux/meego-handset-dialer/committerships

It is up to the admin to determine their collaborators list and maintain it.

To get added to the collaborators list in a particular repository, contact the individual who has admin rights in that repository. Gitorious allows you to send messages directly within it's interface to any other user by visiting their page and selecting the "Send Message" button.

== Teams ==
Groups of developers can form a team to help manage collaborator rights within repositories. As with a repository, a team has individuals who are designated as "admins" and control who is a member of their team. It is up to the team admins to control their own membership to the team, which will translate into repository rights. Be sure to understand fully the repositories your team has access rights to, so you are not adding members to a team who shouldn't have access to a particular repository.

==== Creating Teams ====
Anyone can create a team and add members to it. No special permissions are required.

==== Requesting to be added to a team ====
As with repositories, contact the individuals in a team who are designated "admins" to be added to a particular team. It is up to the team admins to then determine if you should be added.

==== Teams listed at http://meego.gitorious.org ====
Teams working on particular meego repositories will show up on the http://meego.gitorious.org landing page under the "Teams involved in MeeGo projects". This list is automatically created based on team activity in the meego repositories.

== Merge Requests ==
The [http://wiki.meego.com/Brief_git_guide Brief git guide] provides further information about git as well as an example about [http://wiki.meego.com/Brief_git_guide#How_to_use_gitorious_to_do_a_merge_request How to use gitorious to do a merge request].

Brief git guide

2011-07-05T13:27:08Z

Heliacorreia: Minor formatting updates.

Git is handy version control for collaborative development and testing. This guides you briefly through basics to get started. Only terminal usage under Linux is covered, for graphical user interfaces please refer guides available at web.

'''Note''' - this was not placed under developer nor testing because it's common for all MeeGo contributors.

== Concepts ==

Please open the [http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf excellent git cheat sheet]. Work flow is illustrated in the upper-right corner of cheat sheet. The most basic flow with an existing repository goes like:

=== 1. Create ===

git clone <repository>

Example:

git clone git://gitorious.org/meego-quality-assurance/handset-ux-tests.git

=== 2. Change ===

<edit or create files with your favorite tools / editors>

=== 3. Commit changes ===

git add <newfile> (if you created new file)
git commit -a

Your default editor is opened and you need to write description of changes.

=== 4. Push changes to share ===

git push (this assumes you have commit rights to repository, please check with repository admin)

''' That's it! Congratulations! '''

== Pre-steps ==

=== Mandatory - Make sure you have git installed ===

Ubuntu:
sudo apt-get install git

=== Optional - If working behind ssh-proxy ===

If you are working with corporation you might need to resolve ssh-proxy challenge.

Make sure you have following $USER/.ssh/config for your user account

host proxy
HostName '''<yoursshproxyhere>'''
user '''<youruseraccounthere>'''
Compression no
LocalForward 2227 gitorious.org:22
host gitorious.org
User git
HostName 127.0.0.1
Port 2227

Run the following command:
ssh -f -N proxy
<type password for your account, if required>

''Please note that you need to open proxy connection every time you change network or disconnect/connect from network''

Now you can clone and push over ssh proxy to '''gitorious.org''', test as follows:
git clone git://gitorious.org/meego-quality-assurance/handset-ux-tests.git

== How to use gitorious to do a merge request ==
There are as many ways to do a merge request as there are coders, so this guide just aims at helping at the beginning.

=== Register on gitorious ===
Go to https://secure.gitorious.org/users/new to create an account.

Then define a SSH (secure shell) key to enable secured communication between your Linux PC and gitorious. Tap below commands to generate such a key from Linux:
$ ssh-keygen
Follow your terminal instructions.
$ cat ~/.ssh/id_rsa.pub
Copy the result of "cat" command. 
Then go to your user space on gitorious (example: https://gitorious.org/~heliaco), choose "Dashboard > SSH Keys > Add SSH Key", paste your clipboard's content, and save your update.

=== Make a personal clone of a gitorious repository ===
Go to the main page of the project you want to contibute to (example: https://meego.gitorious.org/meego-quality-assurance/auto-ux-testlib). 
Click "Clone repository" button, change your clone name as you wish, and confirm your action.

Now you should see the SSH url of your clone which is like the following example: git@gitorious.org:~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib.git.

=== Set up your Linux's working environment ===
From your Linux PC, clone the repository you just made:
$ git clone git@gitorious.org:~<username>/<project group>/<your clone name>.git
Example: git clone git@gitorious.org:~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib.git

You need to define a name and email within git. For this you can either use a global .gitconfig file or specify these settings within a particular repository.

To create a global file, tap below command:
$ gedit ~/.gitconfig
Then add below section into it, mentioning your name and email:
[user]
name = <Your name>
email = <Your email>

Finally, save and close the file.

To configure name and email within a repository, tap below commands:
$ git config user.name "Your Name"
$ git config user.email "Your email"

Now, one possible way of working is to make development on a master branch, and use another branch called "upstream" in the process of merging requests.

To create a branch called "upstream", tap below command:
$ git checkout -b upstream

Then define the remote server path for "upstream" branch:
$ git remote add upstream git://gitorious.org/<project group>/<project name>.git
Example: git remote add upstream git://gitorious.org/meego-quality-assurance/auto-ux-tests.git

And switch back to "master" branch:
$ git checkout master

=== Commit patches ===
In order to track the files you modified and/or added in the project, tap below command:
$ git add <modified and/or added files names>

Commit your patch using below command:
$ git commit
-m parameter allows you to comment your patch.

Then you have to sync the "upstream" and "master" branches.

Switch to "upstream" branch:
$ git checkout upstream

Update "upstream" branch:
$ git pull upstream master

Switch back to "master" branch:
$ git checkout master

Merge your "master" changes into the "upstream" branch:
$ git rebase upstream

Prior to push your patch, you can display your changes which are now in the "upstream" branch:
$ git diff upstream

Then, update the remote branch:
$ git push origin master

=== Perform a "merge request" from gitorious web UI ===
Go to http://meego.gitorious.org/~<username>/<project group>/<your clone name> (Example: https://meego.gitorious.org/~heliaco/meego-quality-assurance/heliaco-auto-ux-testlib).

Click "Request merge" button in the right column. 
"Create a merge request" window appears, fill in "Summary" and "Description" fields, set your project name as "Target Repository" and select your commit(s). 
Finally, click "Create merge request" button at the bottom of the page.
 
 
[[Category:Tutorial]]

Brief git guide

2011-07-05T13:26:11Z

Heliacorreia:

Brief git guide

2011-07-05T13:24:41Z

Heliacorreia: Adding steps as to how to do a merge request on gitorious.

Quality/QA tools development

2011-06-23T08:11:01Z

Heliacorreia: Completing Tools and Maintainers section.

= QA tools development =

This page provides information on the development activities and practices of QA tools. The focus is on presenting things that are relevant for people interested in developing the tools. The main page for the end users is [[Quality/QA-tools|here]].

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://meego.gitorious.org/meego-quality-assurance/ git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Gitorious'''||'''Maintainer''' ||'''Substitute'''
|-
| [[Quality/QA-tools/Test-definition|test-definition]]||[http://meego.gitorious.org/meego-quality-assurance/test-definition Gitorious] || Sami Lahtinen || Timo Härkönen
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||[http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Gitorious] || Sami Lahtinen || Kyösti Ranto
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || [http://meego.gitorious.org/meego-quality-assurance/testrunner Gitorious] || Kyösti Ranto || Timo Härkönen
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] ||[http://meego.gitorious.org/meego-quality-assurance/testplanner Gitorious] || Kyösti Ranto || N/A
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] ||[http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing Gitorious] || Timo Härkönen || Timo Mäkimattila
|-
| [[Quality/QA-tools/OTS|OTS - Open Test System]] ||[http://meego.gitorious.org/meego-quality-assurance/ots Gitorious] || Elias Luttinen || Ville Niutanen
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||[http://gitorious.org/qa-tools/meego-ai Gitorious] || Timo Härkönen || N/A
|-
| [[Quality/TestSuite/MCTS|MeeGo Core Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mcts/ Gitorious] ||Matti Salmi || Jeff Zheng
|-
| [[Quality/Netbook Test Suite and Utilities|MeeGo Netbook Test Suite]] || [http://gitorious.org/qa-tools/mnts/ Gitorious] ||Jeff Zheng || N/A
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] || [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Gitorious] || Riku Halonen || N/A
|-
| [http://min.sourceforge.net/ MIN test framework] || [http://meego.gitorious.org/meego-quality-assurance/min Gitorious] || Joonas Kylänpää || Timo Mäkimattila
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || [http://gitorious.org/TDriver Gitorious] || Petri Kiiskinen || Tatu Lahtela
|-
| Rich Core dumper || [http://meego.gitorious.org/meego-quality-assurance/rich-core Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter settings || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter-settings-public Gitorious] || Carol Rus || Raimo Gratseff
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] || [http://meego.gitorious.org/meego-quality-assurance/hat-control Gitorious] || Marko Junttila || Riku Halonen
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || [http://meego.gitorious.org/meego-quality-assurance/qa-reports Gitorious] || Sami Hangaslammi || Jarno Keskikangas
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] || [http://meego.gitorious.com/meego-quality-assurance/scripts-and-utils Gitorious] || N/A || N/A
|-
| [[Quality/TestSuite/handset-test-suite/handset-ux-test_Releases | handset_ux_tests]] || [http://meego.gitorious.com/meego-quality-assurance/handset-ux-tests Gitorious] || JessicaJi || N/A
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] || [http://meego.gitorious.org/meego-quality-assurance/meego-testing-hudson-plugin Gitorious] || Alexey Kuznetsov || Timo Härkönen
|-
| Service OS based Flasher || [http://meego.gitorious.org/meego-quality-assurance/meego-ai-serviceos Gitorious] || Jing Wang || N/A
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] || [http://meego.gitorious.org/meego-quality-assurance/libcqpid Gitorious] || Sami Lahtinen || N/A
|-
| [[Quality/QA-tools/QmlUITestlib|MeeGo QML GUI Testlib]] || [http://meego.gitorious.org/meego-quality-assurance/auto-ux-testlib Gitorious] || Shao-Feng Tang|| Helia Correia
|-
| [[Testkit_Howto|testkit-lite]] || [http://meego.gitorious.org/meego-quality-assurance/testkit-lite Gitorious] || Jing Wang|| N/A
|-
| [[Testkit_Howto|testkit-manager]] || [http://meego.gitorious.org/meego-quality-assurance/testkit-manager Gitorious] || Shao-Feng Tang|| N/A
|}

If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

=== Overview ===

The figure below tries to summarize the relations and tasks of the tools when used in test automation context.

[[File:testautomationtools.png]]

xfig file:[[File:qatools.fig]]

== Release Practices ==

Here is the workflow for QA tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file: [[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to tools:testing and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management. (If the package belongs to both repositories, we let the Release Management set bugs fixed by the package to RELEASED state).
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not. (Follow meego-packaging and meego-commits.)

''' YouTube videos '''

YouTube is a good way to communicate new features. You can find existing demo videos on [http://www.youtube.com/user/meegoqatools meegoqatools channel on Youtube].

If you shoot a video to YouTube, promote it on meego-qa mailing list!

You can find some hints how to shoot, edit, and upload a video here: [[YouTube_Hints]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Roadmap ==

These are the items that we're currently working on.

The features in the roadmap are followed with META FEA bugs. The features are split to small tool specific FEA:s that block the feature META bug. The META bug is then the last bug to be closed when the feature is finished. You can also follow the tool bug progression from the dependency trees of the META bugs.

Adding a new feature to the roadmap:
# Add a feature bug describing the main purpose of the feature with META and FEA tags.
# Add separate bugs for each tool specific change
# Add correct dependencies between tool specific bugs (e.g. testrunner bug depends on testrunner-lite bug that depends on test-definition bug...)
# Make all of the bugs block the META bug

{| border="1" cellspacing="0"
|+
|'''Feature'''
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12980&hide_resolved=0 Measurement support]
|-
| [[Quality/QA-tools/OTS/Roadmap|OTS releases]]
|}

== Future development ==

The focus is currently on [[ARM/N900/QA|N900 Developer Edition QA]]. Hence the N900 related list below doesn't have a comprehensive information about target builds or priorities. The items listed here are not currently worked on but are planned to be implemented in the long run.

A list of defined features:

{| border="1" cellspacing="0"
|+
|'''Feature'''
|-
| [https://bugs.meego.com/show_bug.cgi?id=12810 Easy install]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12454&hide_resolved=0 Parallel testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12981&hide_resolved=0 Events feature in automatic testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12937&hide_resolved=0 MCTS coverage support]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12833&hide_resolved=0 Test environment validation]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=13092&hide_resolved=0 Test equipment control]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12971&hide_resolved=0 Qt Creator integration]
|-
| [https://bugs.meego.com/show_bug.cgi?id=13190 A tool that combines Testrunner and Testplanner]
|}

== Design/ Planning ==

* [[Quality/QA-tools/MCTS test automation design|MCTS Test Automation]] (QA Tools support for MCTS)

== Documentation ==

Please make sure that all the relevant documentation regarding the tools is kept up-to-date whenever you update any of the tools. Please consider the end users of the tool as the primary readers of the documentation and make the documentation task-oriented for end user needs. Separate developer documentation can exist as well.

'''Wiki guidelines'''

Every tool should have a wiki page that contains at least 1) Overview of the tool and its benefits 2) Installation instructions 3) Basic use tutorial 4) Contact information.

Make sure that you are familiar with [[Wiki contribution guidelines|MeeGo wiki contribution guidelines]] before creating new content. Currently, there are quite a lot problems relating to e.g. page names, wiki links, deep hierarchies and obsolete pages in our wiki section.

'''Documentation checklist'''

The following table lists the tool-specific documentation that should exist (marked with 'x'). These should be checked frequently and more in depth in the future. Bugs will be filed for the missing or inaccurate documentation (marked as 'NOK' i.e. "Not OK").

{| border="1" cellspacing="0"
|+
|'''Tool''' ||'''Doxygen'''||'''Help''' ||'''Man pages''' || '''Wiki'''
|-
| test-definition || || || || x Checked: asinnela 2011-03-03
|-
| testrunner-lite || x || x Checked: asinnela 2011-03-07 || x Checked: asinnela 2011-03-07, NOK [http://bugs.meego.com/show_bug.cgi?id=14074 Bug 14074] || x Checked: asinnela 2011-06-07
|-
| Testrunner || x || x Checked: asinnela 2011-03-07 || || x Checked: asinnela 2011-03-07
|-
| Testplanner || x || x Checked: asinnela 2011-03-10 || || x Checked: asinnela 2011-03-07
|-
| eat - enables automated testing || || || || x Checked: asinnela 2011-03-08
|-
| OTS - Open Test System || x || x || x || x Checked: asinnela 2011-03-25
|-
| MIN test framework || x || x || x ||
|-
| Scripts and utils || || || || x Checked: asinnela 2011-03-11
|-
| MeeGo Fast Feedback Testing || x || x || || x Checked: asinnela 2011-03-11
|-
| Qpid C wrapper library - libcqpid || x || || || x Page created, content to be added.
|}

'''Other documentation'''

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]
* [[Quality/QA-tools/How_to_set_up_repositories|How to set up the repositories that are needed to install QA tools]]

== Meetings ==

All meetings will be held in <code>#meego-meeting</code> on <code>irc.freenode.net</code>.

* Team meetings
** QA-tools weekly meetings are held on every Tuesday 08:00 UTC in #meego-meeting2 on irc.freenode.net (please note the "2") from May 3rd 2011 onwards.
** [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

* Architecture meetings
** Architecture meetings will be held on-demand basis.
** [[Quality/QA-tools/Arch-Meetings|Meeting agendas and minutes]]

* Workshops
** Face-2-face meetings within the team.
** [[Quality/QA-tools/Workshops|Meeting agendas and minutes]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
** [http://timoph.fi/qa-tools-stats/ Old #meego-qa-tools statistics]
** [http://timoph.fi/qa-tools-logs-archive/ Archived #meego-qa-tools logs]
* Gitorious team, http://meego.gitorious.org/meego-quality-assurance/
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

== Team members ==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Alexey Kuznetsov || Team member || Digia || alkuznet
|-
| Daniil Chuiko || Team member || Digia || dachuiko
|-
| Jarmo Savinen || Team member || Digia || jasavi
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Jarno Keskikangas || Team member || Leonidas || jakeskik
|-
| Janne Hietamäki || Team member || Leonidas || _janne
|-
| Sami Hangaslammi || Team member || Leonidas || sahangas
|-
|}

 
[[Category:QA]]

Quality/QA-tools/Automation of L10n testing

2011-05-13T13:12:28Z

Heliacorreia: Adding title

= Automation of L10n testing =
This page aims at giving more background and detail about the suggestion to automate all or part of Localization testing work.

== What is Localization testing? ==
L10n testing implies 2 main areas of testing.

=== Linguistic review ===
* Ensure translations are adapted to the target device (netbook, tablet, handset...) and audience, they are meaningful, culturally sensitive, and thus follow some defined style guidelines.

When performing linguistic review from translated files, every translations are indeed reviewed but a poor or missing context puts this work at risk as some translations may seem correct out of the context, and not that suitable when in situation.

When perform runtime testing, testers have a full context but one can hardly guaranty that every translation will be displayed, as scenarios leading to display certain error messages may be very difficult to reproduce.

=== UI review ===
* Ensure the UI rendering is optimal in a locale, translations do not break any functionality, there are no truncations (text being too long to display correctly), no widgets overlapping (some UI frameworks have the ability to adapt their widgets’ size to the text they display) nor any other cosmetic issue.

This work is relieved when applications were designed in the perspective of being localized (which is relevant to Internationalization/i18n). Translating from English is known to often increase text length and widgets should be organized in such a way that they favor a clean display.

For both linguistic and UI review, a good knowledge of testing scenarios is required in order to perform runtime testing (miscellaneous configurations, testing data presets…).

== Investigation ==
So far, we didn’t find any open-source tool to handle automatically all or part of L10n testing, but TDriver offers the ability to do rendering verification through screen captures.

== Links ==

[http://wiki.meego.com/Category:Localization Collection of wiki pages related to Localization]
 
[http://en.wikipedia.org/wiki/Internationalization_and_localization About internationalization/i18n and localization/L10n]

Quality/QA-tools/Automation of L10n testing

2011-05-13T13:04:56Z

Heliacorreia: Created page with "This page aims at giving more background and detail about the suggestion to automate all or part of Localization testing work. == What is Localization testing? == L10n testing ..."

This page aims at giving more background and detail about the suggestion to automate all or part of Localization testing work.

== What is Localization testing? ==
L10n testing implies 2 main areas of testing.

=== Linguistic review ===
* Ensure translations are adapted to the target device (netbook, tablet, handset...) and audience, they are meaningful, culturally sensitive, and thus follow some defined style guidelines.

When performing linguistic review from translated files, every translations are indeed reviewed but a poor or missing context puts this work at risk as some translations may seem correct out of the context, and not that suitable when in situation.

When perform runtime testing, testers have a full context but one can hardly guaranty that every translation will be displayed, as scenarios leading to display certain error messages may be very difficult to reproduce.

=== UI review ===
* Ensure the UI rendering is optimal in a locale, translations do not break any functionality, there are no truncations (text being too long to display correctly), no widgets overlapping (some UI frameworks have the ability to adapt their widgets’ size to the text they display) nor any other cosmetic issue.

This work is relieved when applications were designed in the perspective of being localized (which is relevant to Internationalization/i18n). Translating from English is known to often increase text length and widgets should be organized in such a way that they favor a clean display.

For both linguistic and UI review, a good knowledge of testing scenarios is required in order to perform runtime testing (miscellaneous configurations, testing data presets…).

== Investigation ==
So far, we didn’t find any open-source tool to handle automatically all or part of L10n testing, but TDriver offers the ability to do rendering verification through screen captures.

== Links ==

[http://wiki.meego.com/Category:Localization Collection of wiki pages related to Localization]
 
[http://en.wikipedia.org/wiki/Internationalization_and_localization About internationalization/i18n and localization/L10n]

Quality/QA-tools

2011-05-13T12:38:32Z

Heliacorreia: Link to more detail regarding my suggestion.

= Quality assurance (QA) tools =

''' We moved our discussion to #meego-qa IRC channel as of March 24th 2011. Please join us there. '''

[[File:Tool_meegon.png|400px]]

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for quality assurance.

* "Open source tools – available for all, available for development and contributions. Make people accountable for quality."

'''Please note''' that developer-oriented content has been moved to [[Quality/QA tools development|QA tools development]] page. We apologize for any inconvenience. The target is to make this page clearer and more informative for the actual users of QA tools.

== Overview ==

QA tools support test planning, test execution and test reporting. The most important tool offering relating to this is illustrated in the figure below. In addition, there are also a couple of concept videos available at our [http://www.youtube.com/user/meegoqatools YouTube channel]:
* [http://www.youtube.com/watch?v=WdXBqGdLz8I Tool offering for manual testing]
* [http://youtu.be/Ry4MM-CX2b8 Test automation]

[[File:Meego-qa-tools.png|600px]]

== Tools and other utilities ==

If you want to contribute to the development of the following tools, test suites and utilities, please visit [[Quality/QA_tools_development|QA tools development page]].

'''Test tools'''

Each wiki page will contain more detailed description, installation instructions and tutorial on the basic usage. For now, please [[Quality/QA-tools#Collaboration spaces|contact us]] if you need help. Currently, you can install Testrunner, testrunner-lite, test-definition, Testplanner, OTS, Meego-ai, libcqpid, eat and MIN from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| Crash Reporter || On-device tool for sending core dumps to core dump data base
|-
| [[Quality/QA-tools/OTS|OTS - open testing system]] || Test automation system
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||Command line tool for test execution
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || Comprehensive tool for UI testing
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || Reporting tool for publishing test reports
|-
| [[Quality/QA-tools/CrashReports|Crash Reports Web UI]] || Web UI for Crash Reports
|-
| [[Quality/QA-tools/QADashboard|QA Dashboard]] || Quality at a glance
|}

'''Other utilities'''

{| border="1" cellspacing="0"
|+
|'''Name (link to wiki page)''' ||'''Short description'''
|-
|[[Quality/QA-tools/Test-definition|test-definition]]|| XML schema for test plan and result files
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] || Test automation configuration packages
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||
|-
| Rich Core dumper ||
|-
| Crash Reporter settings || Settings package for Crash Reporter
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] ||
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] ||
|-
| Service OS based Flasher ||
|}

'''Tools and utils not in active development'''

Tools listed here are in maintenance and no new features are planned to be implemented in the near future to them.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || Test execution tool with graphical UI
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] || Simple tool for creating and editing test plan files
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] ||
|-
| [http://min.sf.net/ MIN Test Framework] || Advanced test framework
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] ||
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] ||
|}

== Feature requests and bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla instructions:
* [[Quality/How To Report Bugs|How to report bugs]]
* [[Quality/Bug Life Cycle and Handling|Bugzilla workflow]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://www.youtube.com/user/meegoqatools YouTube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]

== Nice to have ==

None of the existing tools answer your needs? Here is where you should enter any suggestion.

* Relieve localization testing effort by automating all or part of it ([[Quality/QA-tools/Automation of L10n testing|Detail]]).

 
[[Category:QA]]

Quality/QA-tools

2011-05-11T10:47:40Z

Heliacorreia:

= Quality assurance (QA) tools =

''' We moved our discussion to #meego-qa IRC channel as of March 24th 2011. Please join us there. '''

[[File:Tool_meegon.png|400px]]

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for quality assurance.

* "Open source tools – available for all, available for development and contributions. Make people accountable for quality."

'''Please note''' that developer-oriented content has been moved to [[Quality/QA tools development|QA tools development]] page. We apologize for any inconvenience. The target is to make this page clearer and more informative for the actual users of QA tools.

== Overview ==

QA tools support test planning, test execution and test reporting. The most important tool offering relating to this is illustrated in the figure below. In addition, there are also a couple of concept videos available at our [http://www.youtube.com/user/meegoqatools YouTube channel]:
* [http://www.youtube.com/watch?v=WdXBqGdLz8I Tool offering for manual testing]
* [http://youtu.be/Ry4MM-CX2b8 Test automation]

[[File:Meego-qa-tools.png|600px]]

== Tools, test suites and other utilities ==

If you want to contribute to the development of the following tools, test suites and utilities, please visit [[Quality/QA_tools_development|QA tools development page]].

'''Test tools'''

Each wiki page will contain more detailed description, installation instructions and tutorial on the basic usage. For now, please [[Quality/QA-tools#Collaboration spaces|contact us]] if you need help. Currently, you can install Testrunner, testrunner-lite, test-definition, Testplanner, OTS, Meego-ai, libcqpid, eat and MIN from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| Crash Reporter || On-device tool for sending core dumps to core dump data base
|-
| [[Quality/QA-tools/OTS|OTS - open testing system]] || Test automation system
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||Command line tool for test execution
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || Comprehensive tool for UI testing
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || Reporting tool for publishing test reports
|-
| [[Quality/QA-tools/CrashReports|Crash Reports]] || Reporting tool for automatic crash reports
|-
| [[Quality/QA-tools/QADashboard|QA Dashboard]] || Quality at a glance
|}

'''Other utilities'''

{| border="1" cellspacing="0"
|+
|'''Name (link to wiki page)''' ||'''Short description'''
|-
|[[Quality/QA-tools/Test-definition|test-definition]]|| XML schema for test plan and result files
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] || Test automation configuration packages
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||
|-
| Rich Core dumper ||
|-
| Crash Reporter settings || Settings package for Crash Reporter
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] ||
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] ||
|-
| Service OS based Flasher ||
|}

'''Tools and utils not in active development'''

Tools listed here are in maintenance and no new features are planned to be implemented in the near future to them.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || Test execution tool with graphical UI
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] || Simple tool for creating and editing test plan files
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] ||
|-
| [http://min.sf.net/ MIN Test Framework] || Advanced test framework
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] ||
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] ||
|}

== Feature requests and bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla instructions:
* [[Quality/How To Report Bugs|How to report bugs]]
* [[Quality/Bug Life Cycle and Handling|Bugzilla workflow]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://www.youtube.com/user/meegoqatools YouTube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]

== Nice to have ==

None of the existing tools answer your needs? Here is where you should enter any suggestion.

* Relieve localization testing effort by automating all or part of it (suggested by: helia_co, detail to be added).

 
[[Category:QA]]

Quality/QA-tools

2011-05-11T10:44:27Z

Heliacorreia:

= Quality assurance (QA) tools =

''' We moved our discussion to #meego-qa IRC channel as of March 24th 2011. Please join us there. '''

[[File:Tool_meegon.png|400px]]

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for quality assurance.

* "Open source tools – available for all, available for development and contributions. Make people accountable for quality."

'''Please note''' that developer-oriented content has been moved to [[Quality/QA tools development|QA tools development]] page. We apologize for any inconvenience. The target is to make this page clearer and more informative for the actual users of QA tools.

== Overview ==

QA tools support test planning, test execution and test reporting. The most important tool offering relating to this is illustrated in the figure below. In addition, there are also a couple of concept videos available at our [http://www.youtube.com/user/meegoqatools YouTube channel]:
* [http://www.youtube.com/watch?v=WdXBqGdLz8I Tool offering for manual testing]
* [http://youtu.be/Ry4MM-CX2b8 Test automation]

[[File:Meego-qa-tools.png|600px]]

== Tools, test suites and other utilities ==

If you want to contribute to the development of the following tools, test suites and utilities, please visit [[Quality/QA_tools_development|QA tools development page]].

'''Test tools'''

Each wiki page will contain more detailed description, installation instructions and tutorial on the basic usage. For now, please [[Quality/QA-tools#Collaboration spaces|contact us]] if you need help. Currently, you can install Testrunner, testrunner-lite, test-definition, Testplanner, OTS, Meego-ai, libcqpid, eat and MIN from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| Crash Reporter || On-device tool for sending core dumps to core dump data base
|-
| [[Quality/QA-tools/OTS|OTS - open testing system]] || Test automation system
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||Command line tool for test execution
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || Comprehensive tool for UI testing
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || Reporting tool for publishing test reports
|-
| [[Quality/QA-tools/CrashReports|Crash Reports]] || Reporting tool for automatic crash reports
|-
| [[Quality/QA-tools/QADashboard|QA Dashboard]] || Quality at a glance
|}

'''Other utilities'''

{| border="1" cellspacing="0"
|+
|'''Name (link to wiki page)''' ||'''Short description'''
|-
|[[Quality/QA-tools/Test-definition|test-definition]]|| XML schema for test plan and result files
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] || Test automation configuration packages
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||
|-
| Rich Core dumper ||
|-
| Crash Reporter settings || Settings package for Crash Reporter
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] ||
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] ||
|-
| Service OS based Flasher ||
|}

'''Tools and utils not in active development'''

Tools listed here are in maintenance and no new features are planned to be implemented in the near future to them.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || Test execution tool with graphical UI
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] || Simple tool for creating and editing test plan files
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] ||
|-
| [http://min.sf.net/ MIN Test Framework] || Advanced test framework
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] ||
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] ||
|}

== Feature requests and bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla instructions:
* [[Quality/How To Report Bugs|How to report bugs]]
* [[Quality/Bug Life Cycle and Handling|Bugzilla workflow]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://www.youtube.com/user/meegoqatools YouTube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]

== Nice to have ==

None of the existing tools answer your needs? Here is where you should enter any suggestion.

* Relieve localization testing effort by automating all or part of it (suggested by: helia_co, detail to be added).

[[Category:QA]]

Quality/QA-tools

2011-05-11T10:43:27Z

Heliacorreia: Added a "Nice to have" section in order to list QA tools currently missing (agreed during IRC QA tools weekly meeting of May-10-2011)

= Quality assurance (QA) tools =

''' We moved our discussion to #meego-qa IRC channel as of March 24th 2011. Please join us there. '''

[[File:Tool_meegon.png|400px]]

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for quality assurance.

* "Open source tools – available for all, available for development and contributions. Make people accountable for quality."

'''Please note''' that developer-oriented content has been moved to [[Quality/QA tools development|QA tools development]] page. We apologize for any inconvenience. The target is to make this page clearer and more informative for the actual users of QA tools.

== Overview ==

QA tools support test planning, test execution and test reporting. The most important tool offering relating to this is illustrated in the figure below. In addition, there are also a couple of concept videos available at our [http://www.youtube.com/user/meegoqatools YouTube channel]:
* [http://www.youtube.com/watch?v=WdXBqGdLz8I Tool offering for manual testing]
* [http://youtu.be/Ry4MM-CX2b8 Test automation]

[[File:Meego-qa-tools.png|600px]]

== Tools, test suites and other utilities ==

If you want to contribute to the development of the following tools, test suites and utilities, please visit [[Quality/QA_tools_development|QA tools development page]].

'''Test tools'''

Each wiki page will contain more detailed description, installation instructions and tutorial on the basic usage. For now, please [[Quality/QA-tools#Collaboration spaces|contact us]] if you need help. Currently, you can install Testrunner, testrunner-lite, test-definition, Testplanner, OTS, Meego-ai, libcqpid, eat and MIN from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| Crash Reporter || On-device tool for sending core dumps to core dump data base
|-
| [[Quality/QA-tools/OTS|OTS - open testing system]] || Test automation system
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||Command line tool for test execution
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || Comprehensive tool for UI testing
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || Reporting tool for publishing test reports
|-
| [[Quality/QA-tools/CrashReports|Crash Reports]] || Reporting tool for automatic crash reports
|-
| [[Quality/QA-tools/QADashboard|QA Dashboard]] || Quality at a glance
|}

'''Other utilities'''

{| border="1" cellspacing="0"
|+
|'''Name (link to wiki page)''' ||'''Short description'''
|-
|[[Quality/QA-tools/Test-definition|test-definition]]|| XML schema for test plan and result files
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] || Test automation configuration packages
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||
|-
| Rich Core dumper ||
|-
| Crash Reporter settings || Settings package for Crash Reporter
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] ||
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] ||
|-
| Service OS based Flasher ||
|}

'''Tools and utils not in active development'''

Tools listed here are in maintenance and no new features are planned to be implemented in the near future to them.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Short description'''
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || Test execution tool with graphical UI
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] || Simple tool for creating and editing test plan files
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] ||
|-
| [http://min.sf.net/ MIN Test Framework] || Advanced test framework
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] ||
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] ||
|}

== Feature requests and bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=Fast%20Feedback%20Testing&component=hat&component=libcqpid&component=meego-qa-reports&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=Testrunner&component=testrunner-lite&component=Others&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla instructions:
* [[Quality/How To Report Bugs|How to report bugs]]
* [[Quality/Bug Life Cycle and Handling|Bugzilla workflow]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://www.youtube.com/user/meegoqatools YouTube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]

== Nice to have ==

None of the existing tools answer your needs? Here is where you should enter any suggestion.

* Relieve localization testing effort by automating all or part of it (suggested by: helia_co, detail to be added).

[[Category:QA]]

Quality/QA-tools/TDriver/Getting Started

2011-05-09T12:16:15Z

Heliacorreia: Removing redundant information ("driver" and "sut_qt" are installed following steps of "Other platforms" section)

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

Getting Qt source-code:
<pre>
git clone git://gitorious.org/qt/qt.git
</pre>

Then the installation procedure depends on our platform. Full detail is available at the following link <nowiki>http://doc.qt.nokia.com/<Qt_version>/installation.html</nowiki>, in which we replace <Qt_version> by our git cloned Qt version (i.e. 4.7).

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this is our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it.
Build requirements for Ubuntu:
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>

Fedora:
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install:
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator:
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer:
<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [http://doc.qt.nokia.com/ Qt Online Reference Documentation]
* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial for test creation]

Quality/QA-tools/TDriver/Getting Started

2011-05-05T15:41:41Z

Heliacorreia:

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

Getting Qt source-code:
<pre>
git clone git://gitorious.org/qt/qt.git
</pre>

Then the installation procedure depends on our platform. Full detail is available at the following link <nowiki>http://doc.qt.nokia.com/<Qt_version>/installation.html</nowiki>, in which we replace <Qt_version> by our git cloned Qt version (i.e. 4.7).

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this is our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

Driver:
<pre>
git clone http://git.gitorious.org/tdriver/driver.git
cd driver
sudo ./update
</pre>

Sut_qt:
<pre>
git clone http://git.gitorious.org/tdriver/sut_qt.git
cd sut_qt
sudo ./update
</pre>

Installing Driver and Sut_qt requires to also have Rake build program installed into our platform (we can do with "sudo apt-get install rake" from Ubuntu or "yum install rake" from Fedora).

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it.
Build requirements for Ubuntu:
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>

Fedora:
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install:
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator:
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer:
<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [http://doc.qt.nokia.com/ Qt Online Reference Documentation]
* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial for test creation]

Quality/QA-tools/TDriver/Getting Started

2011-05-05T15:40:33Z

Heliacorreia: Adding a few infos for things to be more obvious.

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

Getting Qt source-code:
<pre>
git clone git://gitorious.org/qt/qt.git
</pre>

Then the installation procedure depends on our platform. Full detail is available at the following link [http://doc.qt.nokia.com/<Qt_version>/installation.html], in which we replace <Qt_version> by our git cloned Qt version (i.e. 4.7).

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this is our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

Driver:
<pre>
git clone http://git.gitorious.org/tdriver/driver.git
cd driver
sudo ./update
</pre>

Sut_qt:
<pre>
git clone http://git.gitorious.org/tdriver/sut_qt.git
cd sut_qt
sudo ./update
</pre>

Installing Driver and Sut_qt requires to also have Rake build program installed into our platform (we can do with "sudo apt-get install rake" from Ubuntu or "yum install rake" from Fedora).

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it.
Build requirements for Ubuntu:
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>

Fedora:
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install:
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator:
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer:
<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [http://doc.qt.nokia.com/ Qt Online Reference Documentation]
* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial for test creation]

Quality/QA-tools/TDriver/Getting Started

2011-05-05T15:34:23Z

Heliacorreia:

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

Getting Qt source-code:
<pre>
git clone git://gitorious.org/qt/qt.git
</pre>

Then the installation procedure depends on our platform. Full detail is available at the following link http://doc.qt.nokia.com/<Qt_version>/installation.html, in which we replace <Qt_version> by our git cloned Qt version (i.e. 4.7).

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this is our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

Driver:
<pre>
git clone http://git.gitorious.org/tdriver/driver.git
cd driver
sudo ./update
</pre>

Sut_qt:
<pre>
git clone http://git.gitorious.org/tdriver/sut_qt.git
cd sut_qt
sudo ./update
</pre>

Installing Driver and Sut_qt requires to also have Rake build program installed into our platform (we can do with "sudo apt-get install rake" from Ubuntu or "yum install rake" from Fedora).

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it.
Build requirements for Ubuntu:
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>

Fedora:
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install:
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator:
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer:
<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [http://doc.qt.nokia.com/ Qt Online Reference Documentation]
* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial for test creation]

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:48:04Z

Heliacorreia: OK, think I'm done :)

= Testability Driver - Tutorial for test creation =
This page describes how to automate a simple test.

== Pre-requisites ==
TDriver and tests/calculator applications are installed.

In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We should ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
We get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

And update the file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents:

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

The following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
* Defining the SUT (system under test) TDriver should interact with
* Defining the application to run and test
* Defining the tests to be performed within the application
* Finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
* We don't forget to close calculator as our script will launch and stop it itself.
* From Code Editor, we click “File > Save” menu item.
* Then we click “Run > Run with Ruby” menu item.

Through this first test, we could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try and check the snapshot's display.

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
* Is there a way to list every buttons at once?
* Do numbered buttons have something in common?
* Do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
* https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
* https://projects.forum.nokia.com/Testabilitydriver/wiki
* http://www.rubyist.net/~slagell/ruby/
* http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:44:42Z

Heliacorreia:

= Testability Driver - Tutorial for test creation =
This page describes how to automate a simple test.

== Pre-requisites ==
TDriver and tests/calculator applications are installed.

In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We should ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
We get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

And update the file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

The following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
* Defining the SUT (system under test) TDriver should interact with
* Defining the application to run and test
* Defining the tests to be performed within the application
* Finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
* We don't forget to close calculator as our script will launch and stop it itself.
* From Code Editor, we click “File > Save” menu item.
* Then we click “Run > Run with Ruby” menu item.

Through this first test, we could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try and check the snapshot's display.

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
* Is there a way to list every buttons at once?
* Do numbered buttons have something in common?
* Do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
* https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
* https://projects.forum.nokia.com/Testabilitydriver/wiki
* http://www.rubyist.net/~slagell/ruby/
* http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:43:48Z

Heliacorreia:

= Testability Driver tutorial for test creation =
This page describes how to automate a simple test.

== Pre-requisites ==
TDriver and tests/calculator applications are installed.

In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We should ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
We get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

And update the file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
* Defining the SUT (system under test) TDriver should interact with
* Defining the application to run and test
* Defining the tests to be performed within the application
* Finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
* We don't forget to close calculator as our script will launch and stop it itself.
* From Code Editor, we click “File > Save” menu item.
* Then we click “Run > Run with Ruby” menu item.

Through this first test, we could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try and check the snapshot's display.

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
* Is there a way to list every buttons at once?
* Do numbered buttons have something in common?
* Do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
* https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
* https://projects.forum.nokia.com/Testabilitydriver/wiki
* http://www.rubyist.net/~slagell/ruby/
* http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:39:32Z

Heliacorreia:

= Testability Driver tutorial for test creation =
This page describes how to automate a simple test.

== Pre-requisites ==
TDriver and tests/calculator applications are installed.

In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We should ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
We get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

And update the file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:

- defining the SUT (system under test) TDriver should interact with

- defining the application to run and test

- defining the tests to be performed within the application

- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:

- We don't forget to close calculator as our script will launch and stop it itself.

- From Code Editor, we click “File > Save” menu item.

- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:

- is there a way to list every buttons at once?

- do numbered buttons have something in common?

- do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:33:38Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We can ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
We get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

And update the file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
- defining the SUT (system under test) TDriver should interact with
- defining the application to run and test
- defining the tests to be performed within the application
- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
- We don't forget to close calculator as our script will launch and stop it itself.
- From Code Editor, we click “File > Save” menu item.
- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
- is there a way to list every buttons at once?
- do numbered buttons have something in common?
- do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:32:52Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We can ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
Get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

Update your file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
- defining the SUT (system under test) TDriver should interact with
- defining the application to run and test
- defining the tests to be performed within the application
- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

Then from Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
- We don't forget to close calculator as our script will launch and stop it itself.
- From Code Editor, we click “File > Save” menu item.
- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
- is there a way to list every buttons at once?
- do numbered buttons have something in common?
- do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:32:00Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We can ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
Get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

Update your file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
- defining the SUT (system under test) TDriver should interact with
- defining the application to run and test
- defining the tests to be performed within the application
- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

From Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
- We don't forget to close calculator as our script will launch and stop it itself.
- From Code Editor, we click “File > Save” menu item.
- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
- is there a way to list every buttons at once?
- do numbered buttons have something in common?
- do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:31:28Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We can ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
Get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

Update your file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open your Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
- defining the SUT (system under test) TDriver should interact with
- defining the application to run and test
- defining the tests to be performed within the application
- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

From Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
- We don't forget to close calculator as our script will launch and stop it itself.
- From Code Editor, we click “File > Save” menu item.
- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug since what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display. So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}
</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
- is there a way to list every buttons at once?
- do numbered buttons have something in common?
- do numbered buttons have differences?

Below is an example of a way to write such a script:

[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T14:26:39Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<pre>
<sut id="sut_qt" template="qt">

</sut>
</pre>

For guidance, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started.

We can ensure everything is ready for further actions by launching qttasserver, TDriver and calculator applications:
<pre>
qttasserver &
tdriver_visualizer &
calculator -testability
</pre>

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_0.png|800px|Visualizer's default view (click to enlarge)]]

== Get a copy of Ruby script template ==
Get a copy of the template ruby script available under /etc/tdriver/visualizer to your /home/$USER folder for instance, renaming it as my_script.rb:
<pre>
cp /etc/tdriver/visualizer/plain_tdriver.rb.template /home/$USER/my_script.rb
</pre>

Update your file's execution attributes:
<pre>
chmod ugo+x /home/$USER/my_script.rb
</pre>

== Open your Ruby script in TDriver ==
From Tdriver, we click “View > Docks and toolbars > Code Editor” menu item.
Code Editor window appears at the bottom of TDriver, we click “File > Open...” menu item and browse to select my_script.rb, we should get the same view as below:

[[File:TDriver_Tutorial_for_test_creation_1.png|800px|Ruby script into Code Editor (click to enlarge)]]

== Contents of Ruby script template ==
Now let's have a closer look at the script contents.

[[File:TDriver_Tutorial_for_test_creation_2.png|800px|Template Ruby script (click to enlarge)]]

The first two lines mention:
<pre>
require 'tdriver'
include TDriverVerify
</pre>

“require” method loads the mentioned file whereas “include” method embeds the specified module into the current module (it can be used to enhance a class). More detail can be found [http://www.tutorialspoint.com/ruby/ruby_modules.htm here], [http://stackoverflow.com/questions/318144/what-is-the-difference-between-include-and-require-in-ruby here] or [http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ae718697e28e2568?pli=1 here].

Following lines are preceeded by commented lines beginning with # character that help understanding their purpose, and we can see that the structure of a Ruby script basically consists of:
- defining the SUT (system under test) TDriver should interact with
- defining the application to run and test
- defining the tests to be performed within the application
- finally closing the application

== Writing a test using TDriver's graphical interface ==
So let's say we want to automate a test that clicks calculator's numbered buttons only, and takes a screenshot of the whole application after each click.

First thing to do is update the application name, by completing existing line like below:
<pre>
@app = @sut.run( :name => "calculator", :arguments => "-testability")
</pre>

From Code Editor (bottom of TDriver), we place the cursor after the "# Add your interaction and verify code here..." like below:

[[File:TDriver_Tutorial_for_test_creation_3.png|800px|Writing a test from TDriver UI - 1 (click to enlarge)]]

From Image View (right part of TDriver), we drag the mouse over “9” button for instance. A red line displays arount it, and “sut” item unfolds to display selected button:

[[File:TDriver_Tutorial_for_test_creation_4.png|800px|Writing a test from TDriver UI - 2 (click to enlarge)]]

We right-click and from the contextual menu, we select “Insert into editor” item:

[[File:TDriver_Tutorial_for_test_creation_5.png|800px|Writing a test from TDriver UI - 3 (click to enlarge)]]

The following line is added to the script, as shown below:
<pre>
@app.Button( :name => 'nineButton' )
</pre>

[[File:TDriver_Tutorial_for_test_creation_6.png|800px|Writing a test from TDriver UI - 4 (click to enlarge)]]

Now we need to append the method corresponding to a button click. From Properties (left part of TDriver), we select “Methods” tab, and browse its contents. To get more detail about an item, we simply drag the mouse over it:

[[File:TDriver_Tutorial_for_test_creation_7.png|800px|Writing a test from TDriver UI - 5 (click to enlarge)]]

“Tap” method seems to answer our needs, so here again we right-click the desired method and select “Insert to editor”:

[[File:TDriver_Tutorial_for_test_creation_8.png|800px|Writing a test from TDriver UI - 6 (click to enlarge)]]

Tap method will be appended to our button line:

[[File:TDriver_Tutorial_for_test_creation_9.png|800px|Writing a test from TDriver UI - 7 (click to enlarge)]]

Now let's save our script and test it so far:
- We don't forget to close calculator as our script will launch and stop it itself.
- From Code Editor, we click “File > Save” menu item.
- Then we click “Run > Run with Ruby” menu item.

We could quickly see that calculator opened, 9 number displayed in the editor, then the application closed. A new window called Script Console opened along with calculator, it displays traces resulting from our script's execution:

[[File:TDriver_Tutorial_for_test_creation_10.png|800px|Writing a test from TDriver UI - 8 (click to enlarge)]]

Now to complete the test, we will take a snapshot of the application. From the center part of TDriver, we select “Application Calculator” line, then we browse Methods tab to find the appropriate method to use, that is "capture_screen". Finally, we write below line into Code Editor:
<pre>
@app.capture_screen("PNG", "./calc_snapshot.png")
</pre>
The method's arguments are the snapshot's format (i.e. “PNG”), and its path and name.

Seems we are done?! Let's give our script another try...

Well, despite the Script Console not showing any error, instead of displaying number 9 the snapshot may show 0. As a result, this “issue” has more to see with asynchronicity than with a bug: what we observe here is that we kind of took the snapshot too early, and the edit had no time to refresh its display.

So before taking the snapshot, we should take some time to verify our input, adding below line right after the call to button 9's tap method:
<pre>
verify(12, "The taped number should display") {@app.QLineEdit( :"displayText" => @app.Button( :name => 'nineButton' ).attribute("text"))}

</pre>

[[File:TDriver_Tutorial_for_test_creation_11.png|800px|Writing a test from TDriver UI - 9 (click to enlarge)]]

We set a timeout (12 seconds) during which the edit's display value is compared with the text value of taped button. If both values correspond, script continues and snapshot is taken. But if values don't match before timeout expires, then script is halted and exits with code 1, and this information is reported into Script Console. 12 seconds is an arbitrary delay and we assume it is enough for the edit to show up correctly.

== Improving a test based on TDriver's features and Ruby syntax ==
In order to test every numbered button, we could duplicate the lines we have and just update the buttons and snapshots' name. Or we could take advantage of the functionalities offered by TDriver as well as by Ruby scripting language, and in order to prepare to write a program a bit more abstract, we can try to answer some questions like:
- is there a way to list every buttons at once?
- do numbered buttons have something in common?
- do numbered buttons have differences?

Below is an example of a way to write such a script:
[[File:TDriver_Tutorial_for_test_creation_12.png|800px|Ruby script example (click to enlarge)]]

== Sources and useful links ==
https://projects.forum.nokia.com/Testabilitydriver/wiki/FeatureVisualizerCodeEditor#WritingaScriptwithCodeEditor
https://projects.forum.nokia.com/Testabilitydriver/wiki
http://www.rubyist.net/~slagell/ruby/
http://www.tutorialspoint.com/ruby/index.htm

File:TDriver Tutorial for test creation 12.png

2011-04-29T14:25:20Z

Heliacorreia: uploaded a new version of "File:TDriver Tutorial for test creation 12.png"

File:TDriver Tutorial for test creation 12.png

2011-04-29T14:19:45Z

Heliacorreia:

File:TDriver Tutorial for test creation 11.png

2011-04-29T14:04:14Z

Heliacorreia:

File:TDriver Tutorial for test creation 10.png

2011-04-29T13:59:56Z

Heliacorreia:

File:TDriver Tutorial for test creation 9.png

2011-04-29T13:57:51Z

Heliacorreia:

File:TDriver Tutorial for test creation 8.png

2011-04-29T13:57:09Z

Heliacorreia:

File:TDriver Tutorial for test creation 7.png

2011-04-29T13:55:30Z

Heliacorreia:

File:TDriver Tutorial for test creation 6.png

2011-04-29T13:53:52Z

Heliacorreia:

File:TDriver Tutorial for test creation 5.png

2011-04-29T13:51:47Z

Heliacorreia:

File:TDriver Tutorial for test creation 4.png

2011-04-29T13:50:21Z

Heliacorreia:

File:TDriver Tutorial for test creation 3.png

2011-04-29T13:47:46Z

Heliacorreia:

File:TDriver Tutorial for test creation 2.png

2011-04-29T13:42:04Z

Heliacorreia:

File:TDriver Tutorial for test creation 1.png

2011-04-29T13:40:06Z

Heliacorreia:

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T13:36:07Z

Heliacorreia:

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T13:32:58Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed.
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:

<sut id="sut_qt" template="qt">

</sut>

For detail, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started

We can ensure everything is ready for further actions, by launching qttasserver, TDriver and calculator applications:
qttasserver &
tdriver_visualizer &
calculator -testability

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:http://wiki.meego.com/File:TDriver_Tutorial_for_test_creation_0.png|800px|Default view (click to enlarge)]]

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T13:31:44Z

Heliacorreia:

== Pre-requisites ==
TDriver and tests/calculator applications are installed
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<sut id="sut_qt" template="qt">

</sut>

For detail, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started

We can ensure everything is ready for further actions, by launching qttasserver, TDriver and calculator applications:
qttasserver &
tdriver_visualizer &
calculator -testability

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:

[[File:http://wiki.meego.com/images/TDriver_Tutorial_for_test_creation_0.png|800px|Default view (click to enlarge)]]

Quality/QA-tools/TDriver/Getting Started/Tutorial for test creation

2011-04-29T13:28:27Z

Heliacorreia: Adding a tutorial for test creation.

== Pre-requisites ==
TDriver and tests/calculator applications are installed
In file /etc/tdriver/tdriver_parameters.xml , “sut_id” section is empty like below:
<sut id="sut_qt" template="qt">

</sut>

For detail, see http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started

We can ensure everything is ready for further actions, by launching qttasserver, TDriver and calculator applications:
qttasserver &
tdriver_visualizer &
calculator -testability

Then clicking TDriver's “File > Refresh” menu item should lead to get the same view as below:
[[File:Tutorial_for_test_creation_0.png|800px|Visualizer - default view (click to enlarge)]]

File:TDriver Tutorial for test creation 0.png

2011-04-29T13:24:59Z

Heliacorreia:

Quality/QA-tools/TDriver/Getting Started

2011-04-29T13:17:53Z

Heliacorreia:

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it:
Build requiremens for Ubuntu
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>
Fedora
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer.

<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial for test creation]

Quality/QA-tools/TDriver/Getting Started

2011-04-29T13:17:14Z

Heliacorreia: Adding link to "Tutorial for test creation" page

= Testability Driver Getting Started Guide =

This page describes the installation of the Testability Driver (TDriver) on your host machine.

== Installing required packages from repositories ==

We provide repositories for Fedora 13 and Ubuntu 10.04/10.10, and more will be added as soon as it's possible from OBS. For other platforms and versions you will need to compile the Qt components from source.

First wee need to enable the Testing:Tools repository. See the [[Quality/QA-tools/How_to_set_up_repositories|How to set up repositories for QA-tools]] guide.

For Ubuntu:
<pre>
sudo apt-get install qttas testability-driver-host visualizer # This can take several minutes
</pre>

Fedora:
<pre>
yum install qttas testability-driver-host testability-driver-visualizer
</pre>

Start a new shell and you should have all the required environmental parameters set.

== Other platforms ==

TDriver components can be installed on most Qt and Ruby supported platforms. The ruby components can be found from rubygems.org. You will need the following packages, or their equivalents installed:
<pre>
rubygems ruby1.8-dev libxslt-dev libxml2-dev
</pre>

Then install the gems:
<pre>
sudo gem install testability-driver testability-driver-qt-sut-plugin
</pre>

=== Building Qt components ===

Build requirements for ubuntu 10.04:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev
</pre>

Build requirements for Ubuntu 10.10:
<pre>
sudo apt-get install libqt4-dev x11proto-xext-dev libxtst-dev libqtwebkit-dev
</pre>

Build requirements for Fedora:
<pre>
sudo yum install libxtst-devel libqtwebkit-devel qt4-qmake gcc-c++ libqt4-devel
</pre>

=== Compilation ===

Compile and install qttas-server:
<pre>
git clone http://git.gitorious.org/tdriver/agent_qt.git # Note that this our development master. See the list of available tags if you want to checkout a released version.
cd agent_qt
qmake -r CONFIG+=no_mobility
make
sudo make install
</pre>

Visualizer:
<pre>
git clone http://git.gitorious.org/tdriver/visualizer.git
cd visualizer
qmake -r
make
sudo make install
</pre>

== Testing the installation ==

Everything should now be installed. We need an application to test it with, so let's get one. Let's use a classic calculator application that is used in TDriver tests.

Let's get it from git and compile it:
Build requiremens for Ubuntu
<pre>
sudo apt-get install git-core qt4-qmake qt4-dev-tools build-essential
</pre>
Fedora
<pre>
sudo yum install git qt4-qmake gcc-c++
</pre>

Compile and install
<pre>
git clone http://git.gitorious.org/tdriver/tests.git
cd tests/calculator
qmake # in Fedora qmake command is qmake-qt4
make
sudo make install
</pre>

Now we are ready to start the qttas-server and the calculator
<pre>
qttasserver &
calculator -testability &
</pre>

You should see a simple calculator application. Next, let's start the visualizer.

<pre>
tdriver_visualizer & # If you compiled visualizer from source, it will be under /opt/tdriver_visualizer
</pre>

In the visualizer, select File->Refresh. You should see a picture of the calculator application. If you hover your mouse above the picture, the visualizer will highlight the object that is currently under the cursor.

[[File:Visualizer.png|800px|Visualizer window (click to enlarge)]]

Right click on an element, for example "1" button, and select "send tap to SUT". The calculator should receive a click to the "1" button. If so, congratulations you have a working TDriver environment!

== Running Automated Tests ==

We are ready to run an automated test. We will need [[http://cukes.info Cucumber]], so let's install it:
<pre>
sudo gem install cucumber # This will take a few minutes and require gherkin-2.3.2
</pre>

We still need to edit the tdriver parameters. Add the following line to <tt>/etc/tdriver/tdriver_parameters.xml</tt> inside
<tt><parameters></tt> tag:
<pre>
<parameter name="default_sut" value="sut_qt"/>
</pre>

We can use the tests repository we got the calculator from as an example. From there, we will run one test:
<pre>
# cd <wherever you cloned the tdriver/tests repository>
cd test/
cucumber features/qt_widget_tap.feature:8 # Run one scenario from one feature
</pre>

Something like this should be displayed on the console:
<pre>
~/tests/test$ cucumber features/qt_widget_tap.feature:8
@qt_linux @qt_windows @qt_symbian @qt_meego
Feature: MobyBehaviour::QT::Widget#tap
As a test script writer
I want to use tap method to simulate user tapping or clicking an object,
so that I can test the MobyBehaviour::QT::Widget behaviour

Scenario: Tap a QWidget button # features/qt_widget_tap.feature:8
Given I launch application "calculator" # features/step_definitions/feature_common.rb:65
When I execute "@app.Button(:name => 'oneButton').tap" # features/step_definitions/feature_common.rb:165
Then The calculator display says "1" # features/step_definitions/feature_common.rb:235

1 scenario (1 passed)
3 steps (3 passed)
0m1.598s
~/tests/test$
</pre>

Everything should be up and running now. You are ready for test development!

=== Testing Your Application ===

If your application is a Meegotouch application, the qttas plugin will be loaded automatically. If it is a standard Qt application, pass "-testability" as a command line parameter.

=== Connecting to your MeeGo device ===

Note: If you used the "testability-driver-host" package to install TDriver, the ip address is set automatically to the "sut_qt_maemo" device.

You need a working network connection to the device. For the N900, see the [[ARM/N900/Tips and Tricks/N900 USB Networking|N900 Networkig Guide]]. TDriver works over TCP/IP, so any device in the network can be tested.

As an example, connection to the N900 we add the N900 ip address into /etc/tdriver/tdriver_parameters.xml:
<pre>
<sut id="sut_qt" template="qt">
<parameter name="qttas_server_ip" value="192.168.2.15" />

</sut>
</pre>

On the device, make sure the package "qttas-server" is installed and "qttasserver" is running as user. If you just installed the package, you will need to restart the applications to make them load the qttas plugin. On the N900, the qttasserver should start automatically and all supported applications should be available.

If you refresh the visualizer, you should see the application content that is running on the N900. Note - If you edit the configuration file, the visualizer must be restarted.

== What's Next ==

=== TODO ===

* Making your application load the testability plug-in
* Making your application testable

=== Links ===

* [https://projects.forum.nokia.com/Testabilitydriver/wiki/ TDriver wiki]
* [https://projects.forum.nokia.com/dav/Testabilitydriver/doc/api/qt_linux/ API Documentation]
* [http://gitorious.org/tdriver/ Gitorious project]
* [http://wiki.meego.com/Quality/QA-tools/TDriver/Getting_Started/Tutorial_for_test_creation Tutorial/ for test creation]