Publishing to Ovi Store

July 29, 2010 by ivanferdelja

Ovi, the Finnish word for door, is one of the simplest words in the Nokias home country language. It expresses Nokia’s vision to become the consumers door to the Web. The general goal for Ovi is to offer a single location where users can manage content, services and people they encounter as they’re surfing the Web. That’s definetly a bold goal considering the heavy competition such as Google, Microsoft and Apple they are inevitably encountering in this area.

Ovi Store is the Ovi segment intended to provide users with all kinds of downloadable content such as games, application, music, ringtones etc. Publishing to the store is open to everyone and costs the developer a one-time entry price of 50€ which is about 65$. To compare, entry price for Apple’s App Store is 99$/year and for Google’s Android Market its one-time 25$.

To give some overview of the numbers, Ovi Store had about 12 downloads/sec. in the first quarter of 2010. which comes up to about 1.5M downloads/day. At the same time Apple’s App Store is serving about 350 downloads/sec. so the math is simple. However in Nokia’s defence its important to say that Nokia devices, compared to the iPhone, come preinstalled with bunch of applications, also Ovi Store is not the only place to download applications to your Nokia device and finally the App Store had almost a full year head start considering Ovi Store was launched in May 2009.

Once you have registered as a Ovi publisher you can publish content in the following categories: Symbian application, Java application, WRT (Web Runtime) widget, Flash Lite application, as well as non-app content such as audio files (.mid, .mp3, .mp4, .aac, .amr), video files (.3gp, .mp4), themes, wallpapers and video center streams. We’ll focus only on the apps in the rest of the article. Note that personalization content, wallpaper, video, and ringtones will be available for media account publishers only (this is just a special kind of publisher account that you have to register for).

Packaging and signing

Symbian apps must be published in the .sis or .sisx form and must be properly signed, i.e. fulfill either the Symbian Certified Signing requirements or the Symbian express signing.
Java apps submition requires both .jad and .jad file. They must also be signed either by Java Verified or some other authority such as Thawte, Verisign etc. Flash Lite apps in .swf form are not supported natively on Ovi and they must be packaged either in the S60 or WRT form. Its important to know that no certificate errors of any kind will be allowed to pass through the QA process. So keep that in mind before you submit your app for QA.

Application QA

Formal quality assurance of your app is performed by Nokia after you submit it to the store. Your app must conform to the general legal, country and language properties that you chose during the submition process. More importantly, your app is tested on the target devices that you chose during submition. When choosing the supported devices for your app, it’s required that you choose the level of compatibility of your app on the chosen device. Possible compatibility levels are: Fully tested, Briefly tested, Asumed to work, Might work, Not compatible and Not known. Its important to know that you must specify the Fully tested level on at least one device. List of devices currently supported by the Ovi Store can be found here: http://www.forum.nokia.com/devices/matrix_oviStore_1.html

The QA process usually takes 6-8 days according to Nokia, although in practice this time can vary. What the testers at Ovi Store focus on is the basic or core functionality of your app. They don’t try to cover all possible use cases and leave that to the publishers responsibility. Therefore its highly important to do your own testing before you publish. If you don’t have access to all the devices you can use Nokias highly helpful device testing site where you can remotely test your app on a number of real devices.

http://www.forum.nokia.com/Technology_Topics/Application_Quality/Testing/Remote_Device_Access/

When your app finally does get published, all you can do is hope its gets downloaded many many times. Maybe even payed for ;-)

That’s the basic stuff about Ovi so lets conclude as they would in Nokia’s HQ:
Pitää hauskaa kanssa Ovi! (Have fun with Ovi!)

Posted in Uncategorized | Leave a Comment »

PowerShell tips for bash users, part 1

June 17, 2010 by banovotz

Some software testers often write shell scripts to make life a bit easier. But real power of shell lies in shell itself, in so called “oneliners” which UNIX and Linix admins (and also testers in UNIX environments which I used to be) so much love and use. When transfered to Windows environments, those guys will probably continue to use tools they are comfortable with. There are myriad of UNIX shell ports (for bash shell there is Win-bash) and emulators (Cygwin) out there to help create UNIX or Linux like environments in Windows. However, sometimes one is stuck with pure Windows…

Windows Servers are shipping lately with scripting environment called PowerShell (ex Monad AFAIR). If you use Core installation of Windows server, PowerShell is more or less the only thing you have. I will give here few quick oneliner PowerShell tips for people used to work with bash and UNIX command line in general. In this first article in a series we will be talking about: backticks, command separators, newlines, blanks, xargs, tr and cut.

Backticks, command separators and new lines

In bash, stdout output of every command is text, so commands can be executed inline and operated on its output right away:

$ echo "dir1 dir2"  > dirs
$ for a in `cat dirs`; do mkdir $a; done

This will create directories dir1 and dir2 in working directory. This also illustrate how to write for loop in one line. However, even if “do” and “done” are shell keywords, not commands, semicolon (or new line) is needed for separation as if we have list of commands.

PowerShell equivalent:

PS> echo "dir1" "dir2"  > dirs
PS> foreach ($a in cat dirs) {mkdir $a}

Second PowerShell line is more readable because of the use of brackets and braces and there is also no need for backticks apparently. However, note that we have to separate strings to be echoed to file to force new line. If strings are written in the same line as with ‘echo “dir1 dir2″ > dirs’, mkdir (standard cmd.exe) will create one directory named “dir1 dir2.”

xargs

Xargs is one of the most powerfull UNIX commands. It is used to build and execute command lines from standard input. For example:

$ cat dirs | xargs mkdir

will use cat to take the strings (be it newline or blank character separated) from file ‘dirs’ and pass them through pipe to xargs which will then send one by one line as argument to mkdir which will then create those dirs or complain if those are existent.

PowerShell equivalent:

PS> cat dirs | %{mkdir $_}

There is no ‘xargs’ command in PS, but you can use ‘foreach ‘ loop and pass the piped variable ‘$_’ to the mkdir. Shorthand for ‘foreach’ is ‘%’. This time also only newlines will separate the strings apart. If multiple strings separated by blanks are found in same line, mkdir will create a directory with blanks in the name, while we must quote to have the same in bash:

$ cat dirs | sed 's|^|"|g' | sed 's|$|"|g'  |xargs mkdir

cut

Cut is another useful UNIX command. It us used to cut sections from each line of output or file. For example:

$ echo 'why:me ' | cut -d ':' -f1
why

will print “why” because cut will cut everything behind delimeter “:”

Powershell has no simmilar cmdlet but has a neat function ‘split’ which can do the same:

PS>  echo 'why:me' | %{$_.split(':')[0]}
why

but, mind the syntax. Even if it is completely understandable, it is not handy.

Ever once in a while one must to replace some character of text output with another. Let say slash with backslash:

Bash:

$ echo 'why/not' | tr '/' '\\'

Powershell again has no tr command, but do has a “-replace” parameter which expects input from another PS cmdlet. Piped output is also ok:

PS> echo 'why/not' | %{$_ -replace '/', '\'}

Again mind the synthax. “-replace” used here is not the function which operates on variable, therefore there is no dot (do not confuse this with Replace function in PS). Also, seems we do not have to escape neither of slashes. However, while tr works only with characters, replace can be used on whole strings while on UNIX we would use sed or awk for string replacement.

Posted in Quality Assurance | 8 Comments »

Building cross platform mobile apps

April 30, 2010 by sasabrankovic

If you’re doing any kind of mobile development, chances are you’re targeting a specific platform – you download the platform SDK, use the language and the preferred IDE for that platform. You take time to learn the SDK and sometimes the language (as you probably haven’t done anything with objective-c unless you are an apple developer). When you’re done, you take your work to app store for the world to see.

Some times later (presuming you were lucky not to have your app rejected) you decide to port your app to platform B. Unfortunately, platform B, being a direct competitor, doesn’t share a thing with platform A so it’s back to step 0 for you – download SDK, setup IDE, learn both, submit to app store, yadda yadda. What’s worse, your job of maintaining the app is now doubled.

Now, how about if there was a way to build mobile app in a fraction of time, which could run on all major mobile platform out-of-the box?

Too good to be true? Almost. Basically, the trick is to write a web app, and by web I mean – built atop of web technologies such as HTML, Javascript, AJAX – not necessary that these run on web.

Then, using tools designed for this, turn this web app into an installable off line app. These tools also give you API to access otherwise non-accessible parts of device such as camera, phone, contacts or GPS. And from there, you can treat it like any ordinary application (submit it to app store, for example).

It’s just Webkit embedding

Now, building mobile specific versions of your web sites has been around ages but we’re not talking about stripped to mere basics version of your web sites – mobile phones nowadays usually ship with some flavor of Webkit, meaning HTML 5, CSS 3, local storage, SQL database, hardware accelerated animations with full javascript support. Theoretically these could have native application look and feel.

In a nutshell:

Pros

it’s a web app. Meaning, it runs inside a browser on any platform out there.
it’s built with HTML and Javascript meaning fast development, easy way to prototype your app and try new ideas.
you don’t have to deal with any platform obscurities development or publishing-wise. You don’t event have to submit your app to app store – just give users the URL.

Cons

it’s a web app. It runs on Javascript interpreter inside a browser control, on a device with limited resources. Obviously, you won’t be writing games using this.
there are constraints to API usage via javascript; For example, you cannot access GPS data via Javascript on your Iphone > 3.0. You have to use software as Phonegap to bridge this.
it’s a web app so the way it looks and behaves is entirely up to developer. There are no platform specific UI elements to start with, but there are libraries such as Jqtouch that can provide you some of these.

A few resources to get you started

Javascript libraries – you’ll need one of these:

JQTouch – a JQuery plugin giving you a lot of UI/behavior to jump start your app development.
iUI – The original framework to build iPhone-like applications.
Jquery or Mootools – general purpose Javascript frameworks I’ve found to run well on a mobile device
XUI – A lighter alternative to the above, targeting mobile devices and nothing else. I’m keeping an eye on this one
BaseJS – Some as above, this one more tied to Iphone.

Cross-over application frameworks – you need this only if you’re app makes usage of some platform specific API not accessible via Javascript or you’re releasing it as an offline app:

PhoneGap – Open source and activly developed. Supports Iphone, Android, RIM, Windows Mobile, Symbian, Palm and Nokia WRT. Really, is there anything left?
Titanium - something of a beast compared to Phonegap as it can even be used to build cross-platform desktop apps. It supports larger amount of native APIs and comes with its own UI library, but as of writing this only Android/Iphone are supported.
Rhomobile – this one even more ambitious with its own cloud service to sync data and build apps without even installing the native SDK. Oh yes, and you can write your apps in Ruby too.
MotherApp – the official release of is around the corner say the developers, and it promises a unified Javascript Html SDK called DevEngine that runs on cloud and builds apps for Android, Iphone and Blackberry.

I’d also recommend a book by Johnatan Stark. It has Iphone in title, but it’s really about mobile development using HTML and Javascript.

Should I use it?

If your app is one of those simple display of data kind apps, that doesn’t do much I’d say yes. For else, hold on to your objective-c skills for now. The mobile platform ecosystem seems to be moving into web direction, judging by support from platform owners (more and more APIs being introduced in javascript).

Of course, we at fiveminutes.eu, being so easily hooked on anything that could shorten our development cycles are on that wagon already. Stay tuned for more.

Posted in Uncategorized | 9 Comments »

How do we augment reality with iPhone

April 24, 2010 by kprcela

I was very excited when I heard that the augment reality feature should be implemented in ShoutEm application. But, what is more surprising, at that moment I didn’t have the full idea what all cool things are hidden behind the augmented reality and what powerful role it has. With adding the only one dimension, the whole new space is opened inside many areas of our everyday life. So, let’s enter into and see the incoming future.

About Augmented Reality

For those that are not familiar with it, in short, the augmented reality is ability to see digital information in the real world.

For perfectionists, the more precise is Wikipedia definition:

“Augmented Reality (AR) is a term for a live direct or indirect view of a physical real-world environment whose elements are merged with (or augmented by) virtual computer-generated imagery – creating a mixed reality.”

There are many important real usages of this concept but we probably don’t know that is it. Some examples from the real life:

- pilots are looking through the HUD (head up display) and they can see additional digital informations about landscape

- in museums artifacts are tagged with historical or any other content that can be heard with the headphones

- in medicine by superimposing imaging data from MRI onto patient’s body, augmented reality can help a surgeon pinpoint a tumor that has to be removed

- using the GPS receivers on a trip we got the extra information about surrounding locations.

So, we can see the AR is important. It links the useful or educational data with real locations, the user can percept that data, improve his experience and extend his knowledge in such easy way. On the other hand, the AR system can be interactive so users can share their knowledge and enhance it.

The downside was mainly expensive and complex technology. But today we are witnesses of widespread augmented reality. Now we have affordable phones with integrated all interesting technologies needed for AR realization: Cameras, GPS, Wi Fi, accelerometer and powerful processors.

iPhone & AR

In order to realize AR, first we need to know user position and orientation in real world coordinate system. Thanks to iPhone GPS, accelerometer and compass integration we are able to get such informations.

1.step: Accelerometer

Using the integrated accelerometer we know in each frame which force is acting on the mobile device. When iPhone is in still pose the only force that is acting is gravity force. With gravity force vector expressed in local iPhone coordinates we actually know how the horizontal plane is laying but we don’t know how the mobile is rotated from north in the same plane.

2. step: Compass

Unfortunately, compass is integrated only in 3GS model. With compass we have the value of magnetic induction vector in local coordinate system and this means that now we know the full mobile orientation.

But also we must take in consideration the fact that magnetic north is inclined from real geographic north about 11 degrees. To correct the angle of inclination we must have the global position on world sphere.

3. step: GPS

In open spaces we shouldn’t be concerned about known GPS precision and response issues. The received GPS sphere world coordinates should be transformed to cartesian XYZ coordinates in order to adopt them for iphone rendering system.

4. step: OpenGL scene

The virtual scene is realized with OpenGL ES. The ES stays for embedded systems and actually has many disadvantages and restrictions from standard OpenGL. For example, there are no quads, polygons, 3d textures, writing to front buffers, pixel copying operations, display lists, storing and restoring state variables. All of those extra helper features are removed and only basic functionality is kept. As reference for rendering quality, the iPhone GPU is similar by performances to PC GPUs from directX 7 generation.

The iPhone SDK is very friendly, with tons of documentation with examples, and enables relatively easy OpenGL framework integration into our project. Note, we have multiple rendering layers (from back to top): camera, augmented layer and GUI layer. To allow smooth and multitasking execution it was important to set fixed and proper FPS rate.

Viewer position and orientation and camera FOV angles are used for generating rendering projection matrix in each frame. Context of augmented data is rendered also in this augmented layer where each augmented content is rendered with nearby model matrix calculated from nearby object GPS position.

The AR purpose inside ShoutEm application

Generally spoken, the ShoutEm is a social network client application with large community and with geo-location features like displaying nearby friends and nearby places as items on map. This behavior was ideal for implementation of the AR system that should increase the user immersion and provide a richer user experience. The real nearby places that we can see through the camera can be “augmented” with ShoutEm content: venue name, category, distance, list of friends inside, address, rating or thumbnail photo. Also, in the other way we can see through the camera where are our friends and what are they talking about.

The great value is the fact that AR content is generated by users themselves. Users are able to add venues, rate venues, add related photos, add their real life stories and their knowledge that will be available to all other users. So we have the AR system database that is self sustainable and self expanding.

The Future

The ShoutEm global community should be perceived as consumers for mass media market products. The AR system can be used for presenting such products with real value to customers so they can find it at any time and at any place and with useful detail product review. For example, users can find the nearby restaurant with best customers ratings, they can find nearby bar with the free beer or with the active happy hour.

With allowing users to contextualize advertising message in virtual form the creative possibilities are endless.

Posted in English | 2 Comments »

Developing for the iPad

April 13, 2010 by igalic

Several weeks ago, we were asked to create an iPad application. It was something new and we weren’t sure how it would work out at the time, but being interested in the device we decided to take the project.

The iPad SDK, it turned out, is almost identical to the iPhone one, with only a few additions to the frameworks and APIs. Furthermore, our application was completely OpenGL-based, so those differences practically had no impact in this case.

Creating a new iPad application in the Xcode is the same as for the iPhone, except that the iPad needs to be selected as the target.

The whole development process was pretty much the same too, with one exception: we didn’t have access to the hardware so we were only able to test in the simulator. This problem was further amplified by the fact that the application we were developing needed to push the hardware to the limits — and we had no idea where those limits were.

Were we going to be bound by the number polygons we would be able to push on the screen? The fill-rate? Or perhaps by the CPU which was performing the physical simulation?

With only some vague information published on the iPad hardware specifications, we had taken two steps in order to ensure we would only have to do minor tweaking once we’d get the hardware:

1. We’ve created the application so that it can run on the iPhone 3GS too, on its smaller screen. We’ve used the 3GS hardware as the base line, assuming the iPad will probably be an equal or faster device.

2. The application was designed to allow for easy tweaking of several key parameters affecting the performance, so that once we could test the application on the real hardware we’d be able to quickly adjust those few parameters and have the application use all of the available processing power.

In the end, the iPad turned out to be quite a bit more powerful than the iPhone 3GS, but we were able to scale to the newly found power quickly so the application was ready very shortly after the iPad arrived.

Overall, it was a very fun and interesting project, and I personally can’t wait to work for the iPad again.

Posted in Uncategorized | 2 Comments »

A case for Git

April 9, 2010 by igalic

If you’ve worked on any programming project worth more than a few hours of work, you’ve most likely used some kind of a version control system (VCS). Right now, the popular choices are CVS and Subversion at the free end, with Perforce and Team Foundation Server’s source control (formerly Source Safe) holding strongly at the commercial end.There is a new player in the field however, and it’s rapidly gaining popularity.

A little bit about Git

I’m not going to go into Git’s history and origins here, but let’s instead take a look at what Git is and why you would want to consider it over the one you’re using right now. If I had to give you just one reason, it would be: it’s FAST. Blazingly fast.

Its speed stems from several reasons, the main one being the fact that most of the operations are done locally, because it’s a distributed VCS. It’s also the main architectural difference to the systems listed above, which are centralized.

With Git, you don’t need to set up a server which will hold your master repository. Instead, in Git every repository is created equal — it contains the complete history of the project along with all other information, allowing Git to perform many operations locally without consulting the server, saving time and bandwidth. It’s possible to create a master repository on a remote server for all developers to fetch from and to commit to if you want, but it’s not required. A distributed VCS gives you more flexibility than a centralized one, but ultimately the workflow you’re going to use is your choice.

Aside from huge speed benefits, here are a few other notable advantages to using Git:

Because of its speed, it’s much easier to work with on large projects. You won’t have the time to blink, much less to grab a cup of coffee while it performs a commit :)
Each developer is much more independent from others, and from the central server. You can make a dozen commits while typing something up on the plane, for example. Once you get back online, you can send it to other developers if you wish and nothing will be lost. You can make branches without disturbing the rest of developers and you can share your changes with only some of them if that’s what you need.
Efficient branching and merging. It’s fast and robust.
A lot of common operations are automated, making your life easier.
Its repository databases are surprisingly small.
It’s clean (it only makes one .git directory in the root of the repository) — it won’t leave you with dozens of .svn directories all over the place.
It can work with other VCSes. This is very important — you don’t have to persuade your whole company to switch before you can start using it. Just set aside an afternoon to learn the basics, then delve into the world of Git — and wonder how you’ve ever done without it.
Did I say it’s lightning fast?

A short introduction to Git

Now that you’re armed with good reasons to learn more, let me give you a quick tour.

Git repository:

A git repository consists of commit objects and references to them, called “heads”. A commit object is a set of files representing the snapshot of the project in the given moment, a set of references to parent commits and a SHA1 name — a 40-digit hex number representing the name of the commit. You can visualize the repository as an acyclic directed graph. Its leaves are “heads”, and the main branch is called “master” by default. The head on the currently active branch is called HEAD.

You typically initialize a Git repository in one of the following two ways:

git clone <other repository>

This would create a copy of <other repository> in the current directory.

git init

This will initialize an empty repository in the current directory. You can do this in a directory which is not empty too, and then add the existing files to the repository.

Once we have initialized a repository, we can start adding content to it. In git, a file is always in one (or two) of the following states:

Untracked. This file has not been added to the Git database but exists in the directory. This happens with every new file until you add it to the repository.
Ignored. If the file name matches one of the ignore patterns (specified in .gitignore file), Git will simply ignore it and won’t report it as untracked or modified.
Modified. The file, which had been added to the Git repository earlier, has been modified, but hasn’t been marked for the next commit. It’s also said it’s “unstaged”.
Staged. The file, which had been added to the Git repository earlier, has modifications which are marked to be a part of the next commit.
Unmodified. The file is a part of the Git repository and hasn’t been changed since the last commit.

Once you start creating new files and making modifications, you will ask Git what’s the current status of the repository:

git status

This command will report files which are untracked, modified or staged.

To add a new file to the repository or “stage” the modifications of a new file, you use the following command:

git add <file[s]>

This will take a snapshot of the given files and mark them to be committed. After this, git status command will report them as “Changes to be committed”. Use “git add .” to stage all untracked and modified files.

Once you’re ready to make your commit, you’ll use:

git commit -m “Commit message”

Now all of the changes that were marked for commit will be permanently added to the repository.

If you want to see the changes that have not yet been staged, you’ll use:

git diff

To see the changes which have been changed and will be a part of the next commit, use:

git diff –cached

The “–cached” option can be used with some other commands too as a flag to show the information from the staged portion of the repository (as opposed to the unstaged).

Working with others:

Sooner or later, you’ll want to exchange some data with other developers. There are two commands you’ll use most often:

git pull <other repository>

git push <other repository>

The first command will get the changes from the <other repository> into our own, and the other one will send our changes to the <other repository>. The <other repository> can be on the same machine, local network or a remote server. In case there were any conflicts, they will be reported and you can then use:

git mergetool

which will guide you through the conflicts, calling the configured merge tool and adding the resolved changes to the commit.

Branching and merging:

I’ve mentioned at the beginning how easy and fast it is to branch and merge in Git. There are several commands you will typically use:

git branch

to list the branches,

git branch <new branch>

to create a new branch called <new branch>,

git checkout <branch name>

to switch to the branch <branch name>,

git merge <branch name>

to merge the branch <branch name> into the current branch.

You’ll love branching and merging in Git because it’s fast — as all of these operations are almost instantaneous; it’s user-friendly, because it’s very easy to see the repository branch graph, differences between branches, etc.; it’s robust — in many cases you won’t have to do anything manually beyond telling Git to checkout a new branch or merge from an existing one, for example.

Git consists of a very rich and powerful set of commands, but you’ll be using a small subset most of the time. This article has been a short introduction to Git and there are many details I’ve left out, but by now you should have a basic understanding of how Git works. For more information see:

http://www.eecs.harvard.edu/~cduan/technical/git/

A very nice introduction to Git with examples.

man gittutorial

The official Git tutorial.

man git

Git reference.

Now go enjoy Git, and spread the word!

Posted in English | 3 Comments »

5 reasons why exploratory testing may be better for your software project

April 6, 2010 by banovotz

There are lot of disputes about scripted vs. exploratory testing. Here is a modest attempt to make more obvious some of advantages of later tasting approach.

1. ET is more agile

Even if Agile manifesto is nearing its first decade, “Agile” is word which still sounds like a buzzword in IT business. It sounds so fresh and promising. It is more obvious than ever that modern software development is focused to users rather than code, functionality rather than documentation, customer rather than contracts, response to change rather than rigorous plan.

Since exploratory testing approach liberates the testers from the focus on pre-scripted plan and underlines the effort on productivity – providing the quality information – rather than completing the “hardcoded” test set, this approach is agile in nature. It allows testers to be valuable members of team which can bring in fresh quality related information quickly and efficiently.

2. ET is more cost effective

Exploratory testing uses so called “Charts” where specific assignment for tester is noted but with no designated step by step procedures. In the phase of creating test cases, this eliminates the need for test lead (or one who creates the tests) to focus in detail on steps of performing each test. This is often actually impossible because software test team is oftenly involved in test planning before the actual program for software under test is yet ready to be used. Test creator is depending on user stories and mockups to create a charter. It is not unusual that in this phase no one can predict how software will look and operate in detail so detailed planning of test steps in this phase is actually not possible (even if those tasks are performed because you have to do what you are ordered to ;))

Much more use of valuable time of test creator would be to carefully read the documentation, user stories and mockups and to determine actual usecases of application and write those down. Because exploratory testing is constant test creation, those charters created at the beginning of the project can be instantly used and extended when application becomes testable so no additional efforts are invested in redesigning test scripts which obviously can missing steps or having wrong steps.

3. With ET, tester is involving more time in actual testing

As former chapter suggests, with scripted approach of testing, it is not unusual testers are spending much time in correcting those steps to affect actual application under test. Testcases are written before UI, or testcases are written for previous version of the application and migrated to new version but application undergone lot of changes, there are custom builds but you have to temper with original copied test scripts to fit the custom, branched, builds.

It is not unusual that lot of effort goes to scripts maintenance but it is also not unusual that in some point no one cares of test steps and just switch to some kind of edgy exploratory mode by keeping information of changes in head (popup window is replaced by inline frame in version 2.0, terms & conditions are no longer checked with checkbox but noted with asterisk…) , so there are misleading information in actual test scripts (login form is still in pop-up, terms & conditions still having checkbox…) which are confusing testers that are new to the project. Also lot of unnecessary defects are raised. Not to mention lot of frustration among developers. The worse happens if those misleading information are unselectively copied to new testsets for new versions. Bottom line - you can end up with testsuites which does not suite anything. Efforts (and costs) needed to make such unmaintained suite operative are huge.

4. With exploratory testing “pesticide paradox” of testing is very low

As James Bach colorfully put it “Highly repeatable testing can actually minimize the chance of discovering all the important problems, for the same reason that stepping in someone else’s footprints minimizes the chance of being blown up by a land mine.” If test cases are designed to be rigorously repeated step by step, big bugs can come unnoticed because testers are so focused on going through the steps watching for expected results.

Following the steps, testers can easily went pass the landmines in software simply because step never implied “click this after you did that” or “enter this information after you did that” and maybe the bug just lies in that, not scripted, use case. By executing the scripted testcase, that hidden bug will never be exposed and we have a “pesticide paradox” – old pesticide does not kill new bugs.

By not obliging to following the steps, testers can freshly start with each ET session because charter do not put the designated procedure in front of testers. It just reminds him what to be tested leaving to the exploratory skill of tester to find the hidden mine.

5. ET charters are much more robust than classic test scripts

By definition found in Wikipedia “Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be “robust” if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality.”

As already stated in this article, scripts are very little tolerant to change. And change is not unusual in modern software. Login box is moved elsewhere. Buttons are no longer buttons but images, purchase card is now having one “are you sure” instead of two… If we have scripted testcases, those are immediately defectable upon every minor change.

Scripted testing is often praised as a way of having reliable regression tests. However, what is regression test in high level UI testing? We are not talking about low level unit tests where you test a method which is taking two strings and returning boolean, but about functional testing of user interface. Charter can just take into consideration that login button form is with new version of software under test is in inline frame instead in pop up window. Functionality is not broken if UI has changed with change request. But scripted test is broken. One have to redesign it and this is task for which there is never time, so you have unnecessary flaw in your login script which will be unselectively copied to new version test suite or someone will have to redesign testcase and spend valuable time on maintenance rather than testing.

Posted in English, Quality Assurance | 2 Comments »

Is Quality Assurance agile?

February 16, 2010 by banovotz

Developer’s pet in wonderland

Is there a real business plan or not, when a software project is started it is known to everyone who participate in it that it would eventually become a product. It would not always be developer’s pet – it will become real thing used in real world by real users. It will also gather some new people who will work on it and think of it as their pet. I am talking about sales department, product marketing but also configuration management, documentation team, support, integration teams but also quality assurance team. Some of software vendors, especially smalls, does not have all those teams, but essentially all vendors, even startup teams are profiling different roles of people which respectively works on development, configuration management, marketing, customer support… But those are all inside guys, and when outside guys – users and customers – are getting their hands on product, product becomes a real thing and in real world, wishes of users does not always reflects wishes of company which is developing the product.

Because quality is not only matter of standards but also a matter of perspective, in a software project – especially if it is a startup – QA engagement becomes more important when real customers start to make business with it.

More quality to some, more complication to other

All of these aforementioned groups of people can have different perspective on what comprises quality of a product.

Lot of new features and new versions will make developers busy and their managers happy but integration and documentation teams will have headaches. Myriad of customizing options will make techie users happy but businesses (customers) suffer if average user cannot figure out how to use the software. If product became too bloated by constant patching delivered too early to satisfy unforeseen requirements by customers and marketers push, end users will be unsatisfied.

So, what means more quality to some, for other it means more complication. Do you remember the user’s boycott when Twitter people proudly introduced “powerful” retweet feature? According to lot of seasoned Tweeterers, it turned out that new feature did not reflect user wishes. Why? It simply differed a lot from common understanding of what retweet means. Method of discovering this is called heuristic analysis. Users does not need to know the fancy name, but are mostly doing heuristics analysis when are introduced to new features. They are deciding is the software with new feature remaining consistent with its history, comparative products, intended use and so on.

Agility of Quality Assurance

In order do avoid discontent among users of certain software product, Quality Assurance team plays key role. Those guys are there to conduct tests and analysis of product but most important, to act and think of software as real end users, to anticipate their wishes and become to know their common ways of doing things and assess the odds of new features in product to become something users will use and love or avoid and nag about. Their job is to establish a bridge between different kind of people which are taking part in forming software product and contribute in providing information which will help making software product the right thing for them all.

All those activities of Quality Assurance team, if performed in outlined intense, is in essence agile. Following dry and non communicated but well documented process where requirements are lost behind abstract phrases is not as important as people who develop and use the software. Quality Assurance watch for individual needs and make response to change easier to development seeking results wich will satisfy end users and customers while keeping the product developer’s pet.

Posted in Quality Assurance | 2 Comments »

Software testing adds a value to software

January 21, 2010 by banovotz

What software testing is not?

Every now and then in my daily work I recall wrong definitions of software testing and it’s purpose which Glenford J. Myers used to prologue the chapter “The Psychology of Testing” test purpose in his great book The Art Of Software testing . Here are those bad definitions:

“Testing is the process of demonstrating that errors are not present.”

“The purpose of testing is to show that a program performs its intended functions correctly.”

“Testing is the process of establishing confidence that a program does what it is supposed to do.”

I met lot of software testers, not to mention software developers or project leaders and product managers which would say the similar definition if someone ask them to define software testing. When young and inexperienced tester step into a project to do the testing it is very likely she would get an impression that this would be her job - to prove that software under test has no flaws and to confirm that it works correctly and as expected.

There is at least one wrong thing in that assumption. The wrong thing with this assumption is that it considers software testing to be a burden not a value to the project. Instead of trying to prove the program works perfectly, testers should focus on finding defects in the program in order to improve it. They should work on finding as many defect as they can by presuming there are lot of defects which ought to be discovered.

What software testing is?

So, what is the good definition of software testing? We can start with this one, borrowed from the same book we quoted already, “Testing is the process of executing a program with the intent of finding errors.” The subtle difference in approach leaves us so much more space in our field of operation as software testers. But, if we step even more further and, with another great author – Cem Kaner, define software testing “as process of finding and exposing quality related information to clients”, software testing becomes an activity which brings value to the product as a whole.

If we want software testers to do that – expose quality information – then we want those guys to do much harder work than pure bug hunting is. They are key people on the project for finding problems which can strike the business based on the software under test. Pointing to things which can be changed to improve user experience and usability, becoming to know the product and it’s intended users and purpose are some aspects of the job software testers should do on daily basis. Doing that, testers are not acting as easily replaced mechanical dummies which are there only to prove product is fine, but as people in charge to discover how to put things in order and contribute to product ‘s fineness.

Tags: testing
Posted in English, Quality Assurance | Leave a Comment »

Say hello to our new team members

December 26, 2009 by Viktor

Nine years ago I worked on cutting edge projects for PalmOS and WinCE. Time had passed by but I still find it hard to be excited about new device like I was about my new Handspring Visor. At the time Palm had hold 95% of the market and it looked like it never will stop dominating handheld and smartphone market. But in only couple of years it lost almost all the fame in race with Windows Mobile and since than struggled to survive.

Right now things are again changing lightning fast, iPhone and Android are about to conquer the world and penetrations of smartphones is growing rapidly. My wish is coming true and we can make a living out of mobile/smartphone software development.

In last couple of months we’ve experienced strong demand for mobile apps development. iPhone is definitely most wanted but lately we are starting WebOs and Android development as well.

So going beyond buying tons of newest phones on the market, we thought that it might be a good idea to add some human intelligence to the team :). Saying that, let me introduce you to new members and pillions of our mobile development team Viktor and Ivan.

Viktor Brešan is developer with many years of experience in software development, wide range of knowledge and also a founder of couple of interesting web projects, Lociraj.net i moja-lova.com. He also participated in development of famous augmented reality application Layar. In Five Minutes he will work mainly on development of J2ME and Android apps.

Ivan Galić is known to iPhone development community in Croatia as a guy behind couple of iPhone games developed in last two years. Ivan is still studying on FER but his skils and working habbits are comparable to senior developer. With Ivan our iPhone development had grown to three developers in only six months.

All together there is now six mobile developers and we cover all major platforms like J2ME, Blackberry, Android, WebOs, and of course the king himself, iPhoneOS, which is in my opinion only a very good ripoff of good old PalmOs placed to the market at right time J. Disclosure: I’m emotionally attached to my Palm and still keeping it in the box under the bed. Nothing will ever again be good enough :).