10-Dec-2006 - Analogue recording - WinRunner

We all had to use analogue recording once. The problem for us all is when the object changes its position. If we use this kind of recording isn't because we want but because we have no other option. This might happen when our objects aren't recognised, even if we load the appropriate add-in.

The parent window is normally recognised, if I move it, the unrecognised object might not be used.

One way to solve this problem is using a method that moves the mouse to a position relative to the parent window. Here's an example code of it:

# MyWindow

            win_activate ("MyWindow");

            set_window ("MyWindow ", 2);

            win_get_info("MyWindow ", "abs_x", x);                # to get it's absolute position

            win_get_info("Nova Justificação_1", "abs_y", y);

            ax= x+bx;

            ay= y+by;

            move_locator_abs(ax,ay,0);

            click("Left", 2);                           #For example click the object

            type ("Test");                       #Write "Test"

To get the values of bx and by, that are relative we have to:

1-     Press record;

2-     Position your mouse cursor over the objet;

3-     Press F2 (don't touch the mouse, your in analogue record mode)

4-     Press ALT+F6;

5-     Press F2 (so you pass to normal record)

6-     Press CTRL+F3 in order to stop recording

If you go to your test you see that a sentence move_locator_abs (nx, ny, 0) was added and the numbers of the function are the coordinates of your unrecognizable object. So to determine bx and by that you are going to substitute in the code above you just have to had x and y to the watch variables and run the code until ay=… (included)

b1 will be b1=x-nx and b2=x-ny

Substitute the value in your script and erase the move_locator_abs (nx, ny, 0)

Now your code is more robust.

27-Nov-2006 - Planning

As I could see, I got some comments to my Sorry Folks post. The comments led me to write something about planning and its importance.

You can not start a project without planning it. This is a premise for all kinds of project, from a construction engineering project to software development. I don't have to state here the importance of it since you all work with projects and are aware of what might go wrong when planning isn't revised, well done or not done at all.

This post isn't about planning software projects that are beginning but planning new features or changes to an existing project.

In my Shop (to follow what you're used to call it), new developments are decided between Commercial and Development teams. If major changes are implied QA and Direction get involved. Let me illustrate how planning used to be done with a little story that shows what you shouldn't do in a software project.

Direction and Development decided to deliver a functionality that was supposed to be ready in the end of August. This functionality was really complex, never sold to any client and was never delivered to the QA team. According to the developer itself, it wasn't tested for a while but should be OK. QA and the programmer were responsible to plan the project.

From the programmer point of view this was a delicate functionality, very complex and critical to the client. From the QA, this was really hard to test because database and interface should highly protect data. From direction point of view the problem was solved a long ago so they could deliver it the next day. The deadline was decided by Direction and Commercial department. One month to test and rework if needed.

The major problem was, the programmer would be out for 2 weeks, the technical support expert would be in only for 2 days, Development Manager would also be out for 2 weeks and QA (didn't have vacation at all) had only one member who needed support in the issue. In 2 days the technical support expert created the necessary and highly complex resources and the planning meeting took place. QA blindly tested for 2 weeks and the Development Manager wasn't helpful. When the programmer returned, a lot of huge problems were detected and in a week he helped test completion. There was one week left: effort to retest was of one week non-stop (night hours having major database changes running), the application needed to be corrected (I remember this was a very complex functionality) and the deadline was at the end of the week.

It would be impossible. However I detected that the client wouldn’t use the functionality in the end of August (31), they needed to do something huge that day and so they would only use this functionality a month later, for instance three days before the end of September. I got to put commercial team contacting the client, informing them that in order to not loose services they actually needed the function almost one month later (it was true), so we had the delay we needed.

I helped the programmer to understand and redesign the functionality and detected that a part of the functionality needed the intervention of dev manager. So we put the first part of the functionality working, tested it well. And then, since the second part would be used only if the client had troubles and had a work around, we decided to document everything.

The functionality worked fine and the second part wasn’t needed by the client.

Several things should have been done in this sub-project:

-          Since the programmer didn’t work with the functionality for a long time and wasn’t sold to any client, an evaluation of the state of the art was really needed before planning;

-          Since team elements were on vacation, the planning should consider when human resources should be simultaneously present in exactly what time;

-          The delivery date shouldn’t be agreed before the two previous points were sorted out.

This example shows that when planning it is important to consider the team availability for the project, the complexity of the tasks, the time to develop, the time to test and time to correct problems (certainly if the complexity is low it’s shorter than when you have a very risky function).

If managers allow people to plan before they give deadlines, mistakes will be avoided, work will flow on time from one team to the next and if they might have to rework it will be minor changes…

Planning has to be done knowing what each one has to do in the project and other projects. When considering a big new project we might use crossed Gant graphics however in minor features or corrections, this task is much easier.

I have to remind that if planning doesn’t consider what might go wrong people are always delivering low quality work, are stressed out, teams work late… And that is a source of mistakes too! Developers, programmers, technical staff are people, that need to feel good with themselves and have proper time to rest in order to produce higher quality work in less time! I’m completely against working on weekends and after 8 pm, people need to have a life, rest their minds from their tasks in order to return fresh for the next day of work.

What do we do when we realise we can’t deliver everything? Our programmers always inform changes the moment they detect them. When deadlines can’t be changed and they realise they won’t do everything on time instead of delivering whatsoever, unsure if it works, they analyse what’s critical for the client, which are the most important features, and leave the minor things to the end. These priorities are identified and people are informed immediately. When QA team receives the features and the D day is close (major delay in the reception of the product) also has to prioritise tests. We only include in our versions what is working and when there isn’t time to test it isn’t included at all. We prefer to deliver high quality products, with value for the client, maybe leaving one minor thing for the next version rather than ruining clients business…

23-Nov-2006 - Sorry folks!

But programmers need to test too. I’m not talking about implementing Unit Testing or executing a script to exercise their functions, they’re already aware of that. They also need to test their functionalities interface. In other words do some black box tests. And why, you may ask? Obviously because it’s absolutely unreasonable to deliver a product to test that doesn’t work at all.

I got to introduce this measure for more than a year ago, but they still don’t do it right = don’t do it at all… The Dev manager makes them sign what they deliver but he himself doesn’t do it!

So imagine that we tested a setup today and when I tried to use my application one of the services didn’t work at all. The programmer tried to do the smoke test but since he slipped his deadline didn’t remember on time. That version included some rework on the services so the services should be tested…

You don’t compare black box tests done by programmers to black box tests done by testers, but they have to see if their interface with the user works…

Mistakes like buttons that aren’t linked to the methods, wizards that don’t finish… All that shouldn’t happen in tests environment, should be prevented by programmers!

And you might say, “Isn’t that testers work?” For that question I have the answer, there are bugs that are inadmissible, like when the programmer creates a new window and the button OK doesn’t work and it is much more expensive if this problem is detected in a release candidate by testers than by the programmer before the builds.

22-Nov-2006 - Documentation

ISO 9001 requires that companies maintain a great deal of documentation. It his crucial that all the documents available are available for the entire company and placed in an organized structure of folders that concern all areas of the organization. You can use the intranet to do so but one must be very cautious in the organization of the web site in order that finding a document doesn’t become a nightmare and the use is intuitive.

It is also important to determine which documents, that have versions, need to have history. Most of the documents are only useful on their last version, for others it is helpful to have the previous versions. That can be interesting for instance in the requirements document for a software project, so information about the evolution of the product, the moments of change and the way it was redesigned might be available.

It’s important to understand that ISO 9001 wasn’t designed to create a great deal of paperwork but to allow companies to continuously improve quality, and as in everything History is important to recognize the good things and bad things from the past and construct a better future.

22-Nov-2006 - The importance of versioning

I thought we would only have a mistake with versions once but I was wrong...

Background:

In my company, such as in many others, we have a database, actually it’s more an application with a database, where we store our bugs and changes (new features, minor improvements, change requests). Normally when a bug/chance, that we generally call issue, is inserted in the database it comes with a “detected on version” field and when is passed to QA team for testing comes with a “target release” label. The problem is that sometimes issues are solved for one target release but after QA tests it’s reopened and work has to be done.

I had an issue to test that was retested on several versions, and target release never changed, staying 1.0.1 forever. After being corrected and closed, last year, the target release wasn’t updated but it was approved for V1.2 (for example).

One year later I received the issue once again, because a problem was detected. The target release, once again wasn’t updated and the latest documents shown the hotfix was available for V2.0, so the team tested on that version.

Later on, when delivering it to the seller we were informed that TR should be V1.2.3 instead of V2.0, so a day of work was wasted.

I checked out if the work was done to the proper version 1.2.3 but it wasn’t. The Development Manager worked out the hotfix for the wrong version and passed it to QA to test with the wrong version. So once again the client will receive the work late and retest will be done because of an experienced manager mistake, once again!

The last time something like this happened the consequences were bigger and I thought it would teach him a lesson. A client had several requests and it’s version wasn’t the last one. All the programming was done for the last version (he didn’t bothered to ask for which version it had to be done), the files were sent to the client and only too late the mistake was discovered once again by QA, once again with the retesting needed to be done.

Lesson learnt? Always update the version for which it must be developed and tested!

22-Nov-2006 - Big Bang

And I created this blog.

Here I intend to share my experience and also have feedback from you all, so we can all learn something in this web page.

I welcome my readers to the QA Big Bang!