JIRA and Project Management

JIRA is really an amazing change management tool, and the cost is not bad as these tools go.

Developer Focus
The only thing that has been the downside (and maybe the upside of JIRA marketwise) is that its very developer focused. They´re interconnections with the other devtools they offer including Fisheye, Bamboo and others are simple and very very functional (combine that and you get functional oO).
Atlassians Agile Plugin Greenhopper costs as much as the tool it self, but is mindbogglingly good. Virtual wallboards, drag and drop, prioritizing/ranking, and configurable for scrum agile, "scrum but" .... ohh my.

User Interface
Lately they have upgraded the UI and made it much more user friendly. They still have some stuff to fix, maybe I should lend them my User experience designer, but alas I can´t spare him ;).

For Testers
Testing wise they have made HUGE steps forward, lately it was the Atlassian JIRA Bonefire which looks to be amazing.

But .. Project & Release Management ..
They big thing they are missing, are huge steps forward in Project & Release Management. Nowdays everyone is "Agile" whether they really are or not. That means small projects, or at least big project split in small parts. Now then you need to be able to handle that well. And yes they have made some steps in that direction. For example being able to tag an issue to multiple versions (that is what Atlassian calls the releases of a project) is good. But it´s an workaround really. Using the concepts you have but in a bit better way.

I hope that Atlassian turns their attention to Project & Release Management a bit, to have Improvements like Create versions on multiple projects open since 18/Nov/03 11:14 AM shows that Project & Release Management needs more focus and effort.

At my work we release once a month, that includes ALL projects, small improvements (in the "improvements" project if there is no project running that they can conveniently be smuggled into) and maintenance. Very lean and agile and all that, works very well. Business is happy, developers are happy. Testers and Project Managers could be a bit more happy. Keeping it all together can be a pain and I won´t mention how much a pain in the butt the release notes are.

Just my 2c

/The mountain troll

Selenium 2.0 released in June!

This is awesome news, now hopefully we can run everything via the new selenium server including Grid!
And via ruby 1.9.x

From Selenium HQ.

Selenium Server (formerly the Selenium RC Server)

The Selenium Server is needed in order to run either Selenium RC style scripts or Remote Selenium Webdriver ones. The 2.x server is a drop-in replacement for the old Selenium RC server and is designed to be backwards compatible with your existing infrastructure.

Ruby, rspec 1.x and cygwin

One thing that has irritated me for a long time is the inability to run rspec tests in Cygwin without having to maintain dual environments. Keeping 2 parallel environments one for Windows and one for "Cygwin on Windows" is an exercise in futility. But finally I decided to "hack" it, not that i's really an hack.

Use => ruby "c:\Ruby191\bin\spec" item_spec.rb

Replace C:\Ruby191 with your ruby installation directory and ofc item_spec.rb with your spec file of choice.

For an even more easy way, put it as an alias in your .bash_profile, e.g.
alias rsp="ruby 'c:\Ruby191\bin\spec'"

Then you can use => rsp item_spec.rb

More detailed explanation:
in the bin directory there is an spec.bat, the mixture of Ruby for Windows and Cygwin has a problem with paths. So by running the command in the spec.bat file we circumvent that problem and voila everything works.

Addition: Regarding my environment. Due to restrictions with selenium grid and local factors I am using ruby 1.87 and 1.9.1, with rspec 1.2.8 and latest selenium-client (as of 2010-11).

How to teach non-tech savy testers to automate (part 1)

or "Make the testers more effective"

Watch out here, you are about to be critted by a wall of text... and as usual the troll expects all to forgive him his mistakes, especially all the typos!

Make the testers more effective..

I have gone through this a couple of times, and there have been some good articles on related subjects. But I can't seem to find them when I need to. In short I usually find me in the position of advocating that we need to make a testers time more effective. So we need to teach testers to automate their test. Now some of them are from a programmer background, some have education in systems development on so on and so forth.
But there is always some there that do not either have the technical background or just haven't had the time or the interest to delve deeper into the automation side of testing.
Usually the tester gaining the most from being able to automate they're tests are just so overloaded that they never seem to have the time to do check out the benefits of automating the boring basic regression tests that most application seem to need, i.e. is the logo still there, the submit button, the company information and so on and so forth.

I have seen several Let's get all automated drives in companies fail horrible. Usually these drives tend to share the same problems. Bing Bang approach and using too techy approach for non tech aligned testers.
Let’s look at them one at a time:

Big Bang approach to problem solving is usually bad and at the worst a recipe for disaster, if the problem is huge then solving it one piece at a time is the way to go. Where do you think that the proverb "divide and conquer" comes from... Divide up your problems and conquer each "mini" problem at the time and you will have much better success.

"Too Techy” approach to automation seems to be a normal problem. Usually the organization uses a certain programming language and tools. They then feel that, in order to maintain conformity, they must use the same languages and tools for test automation. This is a problem for many testers since they are often more analytical then "programatical" (did I just invent a word oO). Why not let the testers use an easy to understand and light scripting language instead (and for the love of God I hope you do not think of Perl as one of those). That way the big hump to overcome when starting automation is lessened. A good slide show about this (and very related to this topic) can be viewed at Mountains to Molehills: A Story of QA

Confronting the problem

So how do we get people that are busy or not really interested to develop a spark and interest for automating they're testing?
I find it best to confront this from the “basic” regression test side. These tests often get ignored or skipped or worse when under pressure. Everyone acknowledges that they really need to be run, but ...
So by approaching the problem from this side it is quite easy to get even the non tech-savy tester to get interested.
I am going to lay out my approach here, and then I’ll go deeper into each one further down in this (or next!) post.

Building Awareness

Point out the problem areas and offer to show them how you can help them solve them. Usually these are the basic regression tests. Then ask for a basic regression test case and bring that up (usually those are in excel). (Install and) Fire up Firefox and install the Selenium IDE. Start the IDE and and record at least two cases. Now run them in a suite.

This is usually enough to get a tester started. They see now that they can make a suite of easy tests and that it’s not hard! Now leave them for a while with the mission to make test cases in the IDE from those basic regression tests. It is very important to stress that if they run into problems in a case, it is better to skip that case and later bring that up with you (or go Google the problem). During this stage I usually send them some good pointers, like the Selenium IDE documentation page on SeleniumHQ.

to be continued...

WIFI problems on the android

Very nice article about WIFI problem solving on the andriod. Helped me connect to the 802.1x Enterprise WIFI at work on my android. How to fix Android Wi-Fi problems.

Sliding scrum ;)

Sometimes vacation plays hell with your nice schedule. This picture is from a maintenance sprint at work, they solved the problem in they're own way ;) 

It works for them, and if it ain't broken ... don't fix it!

We might want to recommend them to end the sprint soon though!

RT: Mountains to Molehills: A Story of QA

is an excellent slideshow by Dave Haeffner.

Check it out => Mountains to Molehills: A Story of QA.