Arkisto: January 2010

Community Services And Testing

26. Januaryta, 2010 | Kirjoittaja: Antti Niittyviita

Different kinds of community tools are a part of modern Internet. There is Facebook, Twitter, different kinds of Wikis, there’s Doodle and Etherpad. Huge amounts of different and genuinely useful tools. Community services make constant use of methods that have formed from the needs of a user community and according to their rules. Only the solutions found good by the end user survive.

In professional organizations there are several tools being used, whose implementation and methods deviate significantly from the community services. Professional systems should be significantly better than amateur systems, when it comes to price, versatility and profit responsibility. Despite this, the direction for adapting new methods and techniques happens primarily from community service systems to professional systems.

How often have you seen, for example, a report for investigative testing in the form of a blog text or an rss-feed of your test result reports? When was the last time you saw test cases being organized according to keywords, or a project-specific instant messaging channel? Have you made use of the entire developer team (community) opinions to assess the severity of error reports? Personally, not many good examples come to mind when thinking of the cases above.

Bringing small, but genuinely useful, solutions aboard is naturally never easy. It requires tools a lot of preparedness and openness. Commercial softwares regrettably offer very little space for creating or accommodating new tricks. I wonder, what genuinely working and efficient could happen if the end user would be offered a little more when it comes to customizing own tools and playfield?

Information administrations’ strategies and guidelines regrettably often block and at the very least slow down good ways to improve functionality. Openness and freedom of action would take communication, among other things, miles ahead.

One year ago I was working in a telephone project, which had made the revolutionary step to take up a Wiki for sharing project-related information among its workers. The idea was good and it got me fired up as well. Yet, the first time I tried to edit a document where I had input as a test manager, I noticed that such access levels had only been given to chosen few among the team. I left the page un-updated and mailed everyone about the subject. Wiki was gradually forgotten from the project, since no one updated it anymore. Those who had the rights didn’t have the time, and those who had something to contribute could not. Wiki, after an arduous implementation, was reduced to a place restricted by access levels where information went to grow older and older until it died. Well, wasn’t that worth it?

I claim that in this project a less tight control and freeing access levels would have elevated the documentation and teamwork to a whole new level. The biggest issues that arose were in the version control of the information. Requirements specifications were in several different formats and Word file versions. Our own version control system had one copy, and the end user system had the other. In addition, e-mail traffic had the third copies circulating for assessment. They were never in sync. A lot of valuable work time was wasted in catching up with the version histories and comparing the documents. It was not very enjoyable, but it did leave something worthwhile behind.

Next time it pays to trust in own experts more. Increasing their access levels to information and changing it. The intellect and social support by peers of the developer community lowers not only the risk of human errors, but the number of needless documentation load, time and nerves.

On The Importance Of Making Good Purchases

18. Januaryta, 2010 | Kirjoittaja: Antti Niittyviita

Having a talent for making good judgment calls when it comes to making purchases is important. When one is buying software solutions, one needs to have the expertise to specify requirements right, assess the properties of the offered system and the quality of the delivered system once the sale has been closed. And, of course, the price in relation to these.

In the public sector, the competition works like a charm. System solutions are specified requirements, and the cheapest candidate is chosen from all the offers according to the requirements. This process works and there aren’t any problems… are there?

Professor Matti Pohjola disagrees:

The ball is missing.

Different branches of administration produce their own information technological services, when even one Google-like service center would suffice for the entire nation. This way, we could make use of the scale benefits of the information technology.

I believe that in this case the problem lies in the wrong kind of requirements specification.

The global world has a couple of word processing programs. There is Word, OpenOffice, Google Docs and a few others. There are approximately around 1,5 billion computers. Each word processing program should find a fitting market share, when roughly estimating according to the sheer numbers, even if not all computers are used to process words.

Back to Finland. Finnish local authorities and business enterprises that offer medical services have around the same number of different patient information systems as there are word processing programs in the entire world. There is Effica, Pegasos and Uranus to name but a few. Oh dear.

Patient information systems are being used by as many people as there are under the national health care. The systems do not communicate with one another and after the implementation phase it becomes impossible to have a competition for further development projects. System interfaces are closed, after all. In addition, there is often a short period for feedback in the system deliverances, after which all the flaws are fixed with billing by the hour.

Would it not be more feasible to add a few additional points to the requirements when they are still being specified, and make sure that they get fulfilled? Could we not demand that the interfaces are open and the documentation for them is left to the receiving party? If we cannot find suppliers, let us combine the requirements for several local authorities and businesses. When the pot accumulates, we are sure to find the suppliers.

Invest in knowing how and what to buy. Make sure that your team has the professional for technology, testing and finance. If your own competence is not enough, ask for a professional to help.

Whose Work Is Worth Making More Efficient?

11. Januaryta, 2010 | Kirjoittaja: Antti Niittyviita

In Talouselämä’s “Minä Väitän” section NSN’s leaders discussed Finland’s competitive ability. The keyword in this case as well was ‘productivity’. In their text, Ilkka Lakaniemi and Anne Larilahti declare that Finnish companies have a lot of room for improvement when it comes to taking up and using information technology.

I agree with them. I even dare say that often the decisions to keep the old methods and tools are born from the desire for comfort. Postponing or cancelling projects that aim to develop modes of action or system changes is easy to base on financial points of view, but I say that the reality is different.

Change is hard work, changes cause risks and someone carries the responsibility. Actually, responsibility is not very comfortable. What would be the most comfortable would be to stay on safe and explored soil. In their comfort zone. Has it not worked insofar?!

What about when the daring and keenness has finally been enough for a change? A new information technological solution has been chosen to make working more efficient and it is time to implement it. Users begin to feel anxious and change resistance has been set up even before the training for the tools has started. Changes introduced by the leaders cause, almost without an exception, counter reactions among the staff. Where does this come from?

Lakaniemi and Larilahti proposed that it would be important to get readiness for taking up new technology inside the companies.

This should happen in a manner that allows the information technology to benefit the entire staff, not just the leaders or choice expert groups.

Could the opposition be caused by a force of habit? An employee has grown accustomed to information technology not making the work of his or her own field more efficient and that it might actually cause more work. Unfortunately, the winner for most tool-upgrades is only the boss who gets cool reports and new observation tools. The seller (*) of the solution has made his or her work well among the target audience. So, here is a challenge:

Dare to demand more next time when you start an upgrade project! Demand first of all that the solution you have chosen will benefit the entire staff. Finally, you will see that the change resistance crumbles and your organization dares to learn something new.

(*) In this instance, the seller means the party who has successfully driven a new solution through an implementation decision. The seller of the thought can also be from inside your own organization.

Car Pooling

4. Januaryta, 2010 | Kirjoittaja: Antti Niittyviita

What kind of a car do you drive? Do you like it when there are only pedals, gear shift and the wheel in the cockpit, or do you demand electronic navigators or various other gadgets? Are you a person, to whom the car is merely a means for getting from point A to point B, or is your car a comfort factor for you?

Let us imagine a situation where the car is manned with an entire testing team. Being higher up in the pecking order, the test manager takes the wheel, after which the lesser testers take the remaining seats. The situation can only be called crowded. Moving about in their seats proves to be surprisingly difficult and at the last moment the team realizes that the car does not even have seat belts and the only factor for safety is the single airbag by the driver’s seat, which have been changed a couple of times already. The rag tag group starts driving, before the last door has even been closed. Does this sound familiar to you from your experiences from the project life?

As an interjecting clarification, according to the last few paragraphs of this text, I am comparing the test control tool to a generic car with emphasis on basic quality criteria. Let the carpool commence!

The first order of business when sitting down in a car is to find a proper driving position for both the driver and the passengers. One must have enough room in the car to move, and the seats must be adjustable to permit everyone’s body structure properly. This is reflected in the test control tool usage allowing a basic tester to influence the test case’s advancement. To great chagrin of many a tester, the tool’s access levels have been limited to execute-level, when a small tester can do nothing but sit on his or her seat, shackled to his or her armrests (should those be found in the car at all) and only end up where the test manager drives them. After they get there and remove the shackles, it is stated that the tester’s self-initiative did not meet the expectations. Development must happen.

Let us go back in time, to the middle of the trip. When in a car, the most important thing is without a doubt being able to see where it is headed. This part is very loosely based on the test control tool. From the tool’s perspective, it is more important to see from the rear mirrors just what kind of tracks are they leaving behind. Do they see bloody pedestrians lying still and explosions – the kind of which you see in Hollywood – or normal traffic heading forward? Gathering from this information, the test manager on the driver’s seat can deduce far forwards whether or not his or her hasty choices had been rational for the progression of the trip, while at the same time having to listen constant whining from the back seat: “Are we there yet?” How long still? Where are now?”. Ideally, every passenger would have their own rear mirrors, where they can see that small part of the trip which they have had the chance to influence, and maybe a bit more.

The trip naturally involves picking up passengers along the way. Therefore, the basic assumption is that there would be room for them in the car as well. The project manager calls the driver in the middle of the trip saying that he or she also needs a lift from point A to point B. He must naturally have a place reserved from the front seat, being a true genteel, so that there is no need to be with the bickering tester litter in the backseat, while clearly seeing where they are coming from and where are they heading. The lift is easily managed when the test control tool has the required information without painful protracted lawsuits. The project manager exits the vehicle with a smile and thanks for the beautiful scenic route. A property such as this is a rare thing in a test control tool.

One factor to consider when getting a car is their green values. No one does anything with a tool that contaminates and destroys the environment. Put quite provocatively. Yet, there are tools such as those do indeed exist. They can be found even among the large names of the business, where their usage is kept as minimal as possible for as long as possible, because they slow down the testing process and make the work anything but pleasant. To consider green values, one must consider fuel consumption. When getting every car or a testing tool, the acquirement cost is always stressful, but after the initial shock, a car that spends 3,5 litres of diesel for 100 kilometres while purring in a relaxed manner is definitely worth it, after all the dozens, or even hundreds of thousands of kilometers. The test manager sees this from the driver’s seat, while perusing through the drive computer’s extensive menu options.

How would one get the car to be just like the one that is wanted? Gearing up the car is an important factor for many owners in order to have comfortable trips. Just like a car that can be equipped with one’s choice of basic and extra features, a test control tool can be customized to fit a purpose.

Why should a tool guide a testing process to a set of tracks, when you can guide the tool to the testing process’s tracks?