Wednesday, December 5, 2007

Buh-bye-blogger

PLEASE GO TO http://hjornevik.wordpress.com. Sorry blogger/blogspot, but there are too many features missing...

Tuesday, December 4, 2007

Windows Live Writer

Ok, so here I am, after putting my kids to bed, I lay on the guests bed waiting for my son to fall asleep (he's a bit afraid of the dark, so I tend to lie in his room), surfing randomly around.

And, behold, what do I find. A lifehack.org article about a Microsoft product, which assumably works? I read more, seeing possibilities never seen before; blogger/blogspot lacks some features, and is not as good as I want it to be in some areas, but here is a product from Microsoft which actually makes it easier to blog!

Windows Live Writer is a WSIWYG (what you see is what you get) tool, which lets you write posts for (all) your blog(s). You can easily add pictures, tables, maps and videos, and then upload the full post directly to your blog.

You can make drafts, and I hear that there are some add-ins too, which gives you even more flexibility. I haven't tried any of those yet, but I will as soon as I have looked into some of the standard features (which seems pretty good so far).

 

I wonder what happens if I edit the post I just published, and the hit "Publish" again...

Answer; sweet. It actually managed to amend it to the post instead of doubleposting... ;)

 

iStock_DarkSmoke_Small And, with tables available, and the option of adding pictures directly, instead of "upload to server - then select a size and a placement which doesn't seem to matter no matter what you do", this can actually turn out to be one of my new favorite tools!

I think I read something about it beeing able to add videos, del.icio.us links and more on the fly as well (might need some plugins), which will be a major step for my blogging!
   

Monday, December 3, 2007

Three secrets of the one minute manager

Three secrets of the one minute manager by Kenneth Blanchard. More on The CPA Journal.

The First Secret: One-Minute Goals.
All good performance starts with clear goals. If you don't know where you are going, any road will get you there. This is about as fundamental as God, mother and apple pie. If we were going to improve the performance of people all over this country, the simplest and easiest way would be to make sure people have clear goals.

The Second Secret: One-Minute Praisings.
Of all the things I've taught over the years, I can't say enough about the importance of praising. The key to developing people will always be to concentrate on catching them doing something right instead of something wrong. Yet most people are still managed by being basically left alone until they make a mistake that's noticeable and then their boss criticizes them. I call that a "leavealone zap" management style or "Sea gull management." Sea gull managers fly in, make a lot of noise, dump on everyone, and then fly out.

The Third Secret: One-Minute Reprimands.
What do you do when people do not perform well or make limited or no progress toward their goals? You have to hold them accountable.

The first alternative for poor performance should be redirection, which means going back to goal setting trying to find out what went wrong and getting them back on track. Never reprimand or punish a learner -- you'll immobilize them. If you are dealing with somebody who knows better, who as performed a similar task well in the past, then a One-Minute Reprimand might be appropriate.

Stickies

A small program for making Post-it notes on your pc.
Very handy for taking notes, ToDo-lists etc.

It has many nice features, but not unnecessary ones like animated dancing naked ladies, so it's small and doesn't take up much system resources.
...and, it's completely free.

Zhorn Software - Stickies

One minute management course

LESSON ONE
An eagle was sitting on a tree resting, doing nothing.
A small rabbit saw the eagle and asked him, "Can I also sit like you and do nothing?"
The eagle answered: "Sure, why not."
So, the rabbit sat on the ground below the eagle, and rested. All of a sudden, a fox appeared, jumped on the rabbit and ate it.

MANAGEMENT LESSON
To be sitting and doing nothing, you must be sitting very, very high up.

Saturday, December 1, 2007

Top 10 Secrets from Anthony Robbins

Thomas Murrel at Ezine Articles has an article, Top 10 Secrets from Anthony Robbins, which is the authors gift to us, building on his experiences from a seminar with Anthony Robbins.

I'm gonna add the secrets here, without the rest of the story, which can be read at Ezine Articles

1. YOUR POTENTIAL IS DETERMINED (OR LIMITED) BY YOUR SELF-BELIEF.
The simple message is if you believe in yourself enough you can achieve anything.
A memorable one-liner was "the only thing that's keeping you from getting what you want is the story you keep telling yourself".

2. MOST PEOPLE HAVE SELF-DOUBT AROUND UNIVERSAL THEMES.
Ask anyone and most people will admit they lack confidence in some areas of their life. The interesting thing I learnt from this seminar is that this self-doubt is around universal themes. These themes cross age, gender, religous, cultural and language barriers.
Common doubts include 'I am not good enough', 'I am lazy' and 'No-one loves me'.

3. YOU CAN LEARN MECHANISMS TO ELIMINATE SELF-DOUBT.
Robbins calls it 'immersion' where you break old patterns and build new ones by repetition. He uses a lot of Neuro-Linguistic Programming techniques to achieve this with his audiences.
He says "progress is not automatic".
A memorable moment in the seminar was when we had to visualize ourselves inside a bubble and inside that bubble was a series of videotapes neatly arranged in a time-line that represented all our memories in our lives so far. We had to pull out the negative videotapes and destroy them. This was followed by time spent visualising the future and how your life will look 10 and 20 years from now.

4. BELIEF IMPACTS ON MANY LEVELS.
The Robbins message was that 3 things shape our self-belief. He calls them the Triad. These are our patterns of physiology, focus and language or meaning.
He highlighted this with the quote: "where focus goes energy flows".

5. OUR VALUES AND BELIEFS SHAPE OUR ACTIONS.
Robbins believes you can "vanquish whatever is holding you back from taking action".
Walking barefoot across a bed of glowing coals is the physical metaphor he uses in his seminars to prove this point to the skeptics.
Eliminate negative self-belief and take massive action are his keys to success.

6. TO CREATE POSITIVE OUTCOMES YOU MUST TAKE MASSIVE ACTION.
"Where focus goes energy flows" is a quote used by Robbins in his presentation to highlight why you need to know your outcome and why achieving this is a must.
But many people fail to take the next step. They delay, put off and find many reasons or excuses not to act.
Robbins believes "progress is not automatic" and "action is power". Take action, even if it is the wrong action. He says it is "never a failure if you learn something".

7. MATCHING & MIRRORING CREATES CONNECTION, TRUST & EMPATHY.
Robbins spent a fair amount of time in the seminar talking about and demonstrating interpersonal communication skills.
He used people from the audience to show how the process of "matching and mirroring" the non-verbal communication and body language of others can be a very powerful way to connect with people.
In essence, you create rapport by adopting the body language of the person you are communicating with.
He believes "rapport is power" and "total responsiveness is created by a feeling of commonality".
If you have learnt these techniques before and haven't used them for a while, I suggest it is time to dust them off and put them into action next time you are communicating with someone on a one-to-one basis.

8. ANYTHING IS POSSIBLE IF YOU FOCUS ON PASSION AND PURPOSE.
Robbins believes that "to have an extraordinary quality of life you need two skills: the science of achievement (the ability to take anything you envision and make it real) and the art of fulfilment (this allows you to enjoy every moment of it)."
He says "success without fulfilment is failure".
Find your passion and purpose in life. My purpose is to make a difference in people's lives and use my gift as a speaker.

9. MODEL YOURSELF ON OTHER ACHIEVERS.
To gain improvements quickly and step up to a new level of achievement, Robbins believes learning from others who are the best in their field is the fastest way to achieve success.
He told the story of how he wanted to improve his tennis game and so employed Andre Agassi, the then number one ranked player to help him achieve this.
Who could you model yourself on?
"People's lives are a direct reflection of the expectations of their peer group," according to Robbins.

10. SUCCESS IS BUILT ON A HEALTHY, HIGH ENERGY BODY, HEART AND MIND
If you are not healthy - all of the above points are a waste of time.
Your health is determined and influenced by your lifestyle.
One major change I've made since the seminar is to eat a healthier diet and exercise more regularly.
As a speaker, my whole business depends on my ability to perform at a peak state. Like any professional athlete, the success of business is directly linked to my diet and health.
Take care of yourself, your body is ultimately your most important asset.

--- End of rip ---

This was so well written, I ripped majority to keep it for immediate access. All credit to Thomas Murrel at Ezine.

Wednesday, November 28, 2007

7 Ways to Improve Defect Reports

As a software tester, it is easy to get carried away when digging into a new piece of software; the unexplored area of newly developed software calls to us "Test me, test me!".

If the development has been poor, and several defects are found at once, it is often easy to skip one of the most important tasks the tester does; create good reports. In a hurry, several failures have to be transformed into defect reports, and to make sure none is forgotten while the first ones are written, it is quite common to type in the short version, which often lack important information.

When we test, we tend to be engaged in what we do, and we forget that the developer who'll receive the defect won't be able to understand what situation the failure occured: What test data was used. Which environment was the test performed, and what kind of known/business data was loaded into the database. Did we do any workarounds to be able to reach the frontend, and what other parameters did we enter.

If the software is in an early phase of the project, the development team might have quite a different version in their environment, so the screens may look completely different. There may have been changes to the code, or even just a dataload may cause the software to behave differently in the development environment, so it is of great importance to deliver good test reports.

Defects and test execution reports are not only for the development team; they can be used to show the evolution of the software as the project goes along, and if a failure occurs at a later stage (e.g. in Acceptance Test or even in production), the test team can refer to the test report and tell if the feature (and/or surrounding area) has been tested before.

There are two main reasons for making the test execution reports and the defect logs as good and descriptive as possible:

  • The developer needs to understand what the failure is, and how it is caused. The better the description is, the easier it is for the developer to understand what's causing it.
  • When the defect is fixed, and the development team has released it to the test environment, it is very likely that some time has passed by. It may have been days, or even weeks, since that time when the tester was really engaged and digging into that part of the software, and thus the tester won't neccesarily remember how the failure was caused (if the report is poorly written, that is)
 

So, what are the steps to write a good defect report..? Here are some tips:

  1. Start with a short description of what the failure is. In a short sentence, sum it all up so that the developer might go straight to fixing the problem, if he understands right away what's causing it. Even though the description is short though, it should be precise and meaningfull, so that it is possible to understand what the problem is.

  2. Next, write down a summary of what was done. This can be written as a step by step guide saying what you did, or you can write it as more as an essay kind of text. It is still important to remember though: You want to keep the attention of the reader. Too much text, and nobody will read what you've done, and that's a good reason (maybe not good, but still very common indeed) for not getting the bug fixed. The developer will send the defect back to you and say he can't reproduce the failure.

  3. Attach scripts for loading test data, and logs from the inserts you did. The developer will probably try to reproduce the failure in her environment, so it is important to attach data so that the preconditions for the test are the same. Also, when the defect is fixed and returned to you, you might get a different result than expected, so you'll want to try it with the exact same script as you did the first time. If the test data is stored in e.g. an excel spreadsheet, and then generated into sql, you don't want to regenerate the data if you have to be 100% sure that no one have made changes to the data.

  4. Screenshots are of great value when logging a defect; they are proof of what the situation look liked when the defect was logged, and they are a quick way for the developer to see where the problem is located.

  5. Data extract. After code has been executed, what happened with the data? If it has any value, retrieve the altered data from the database, and attach it to your defect. If records were supposed to be created in a table, and were either incomplete or not there at all, show this by attaching it (it can even be a screenshot from the table in e.g. Toad).

  6. If you have time to do some debugging, or have a vague idea about where the defect is located, it's a nice thing to help the developer by describing your analysis about the bugs whereabouts.

  7. Finally, you'll want to add the general information, such as which environment and version did you perform the test, what part of the functionality were you testing at the time. What test (test case number) were you executing, and so on.