Testing


9
Oct 09

The Atlassian Dragons Exercise

The installation process for the Atlassian Starter suite – Crowd, Bamboo, Fisheye, JIRA, Greenhopper and Confluence – is quite daunting and takes about 5 hours+ (way more on my Parallels VM setup, but I did expect that).

It’s obvious that the different Atlassian products have been built by different teams, at different times and sometimes even different companies. Although, AFAIK, all products are built with basically the same base technology (J2EE), each product has some minor differences in

  • Installation
  • Configuration
  • Directory set-up
  • Starting up / Stopping products (e.g. there’s no shutdown command for Crowd, Bamboo automatically installs as a service)
  • Configuration files

If the suite has to be installed manually, consistency in the setup process trumps everything. This is even more relevant if the suite is installed by a non-IT, non-Java plain old-fashioned C++ hacker like me.
Generally, editing the configuration files was no big deal, although the sheer number of changes necessary induced cross-eyes at times.

Including Crowd into the installation process made the setup process quite involved and complicated. Although single sign-on is quite a feature, I wouldn’t consider it crucial for a 10 user set-up. I would’ve preferred to make integration with Crowd an optional exercise. Plus, removing Crowd from the standard equation would have enabled more detailed feedback on setting up the different applications’s integration features.

Kudos to the Atlassian documentation team responsible for the detailed step-by-step descriptions. It was close to perfect, just very very minor errata in terms of version numbers. A few more screenshots would have been helpful, but would have made the endeavour of documenting the suite’s installation process not only daunting, but outright impossible to maintain over time.

I was very disappointed that Crucible was neither part of the exercise nor part of the $10 offer. Atlassian, please make Crucible part of the Dragons exercise and part of the $10 / 10 users offer. I’m sure there were very good technical and/or business reasons not to include it, but if the Atlassian team can pull of a stunt like the Dragons exercise, I know they can pull off including Crucible, too. It just takes a few more beers, I suppose. German beer, of course. :-)


5
Mar 09

Is Quality Dead?

This looks like the start of an extremely interesting series: Quality is Dead #1: The Hypothesis.

Another factor contributing to this crisis are insanely short release cycles (even for desktop software) and the expectation that each major update has to introduce substantial new features. Lot’s of them. There’s no more time to polish & deepen existing features.


24
May 07

The Humble Dialog Box & more…

Even if you are not into .NET, WinForms etc. this series by Jeremy D. Miller is a great one to follow. Posts so far:

Plus, as a bonus, you will notice that Jeremy is not afraid of using really long function names:
void CloseTheScreenWhenTheScreenIsDirtyAndTheUserDecidesNOTToDiscardTheChanges()
And I’m mentioning this not to make fun of Jeremy.


1
May 07

I’m not a tester

Erkan Yilmaz tagged me with a few questions regarding testing. However, I’m not a tester, I just happen to be interested in some areas of testing, e.g. unit testing & test-first-coding.
Could you tell something about your first tests?
I started getting interested in unit testing in the late 90s when XP came up. Still not 100% sure about where unit testing ends and acceptance testing begins.
What would you like to highlight as an important thing of testing – from your personal experiences?
As far as unit testing & test-first-coding is concerned, the most important aspect is “Just doin’ it even if you think you can’t do it”.
Why is testing not trivial?
Testing is always hard for a software developer because his/her brain knows about the inner workings of the code and therefore it requires an enormous amount of discipline to thoroughly test the code.
Test-first-coding is hard because it requires to change your mind set from testing as an afterthought to testing before you start coding.
What do you do after testing at work?
Coding :-)
How do you think testing will evolve in the next 13 years?
Most of the kind of testing I’m interested in very much depends on the way the code is structured. So I would guess that the most interesting things will happen round tools & patterns which enable testable code.


26
Feb 07

Interesting Point of View on OO-Principles & Testing

Roy Osherove on Object Oriented Testable Programming:

…in many ways, pure object oriented design does not go well hand in hand with the notion of testable design.


27
Oct 06

Great advice…

…by The Braidy Tester: R E S P E C T.
No, this isn’t a subtle hint to anybody in particular. It’s just a great post on a very important topic.


26
Sep 06

Excellent Blog on Testing

Michael Hunter is doing a great job with his blog: THE BOOK OF TESTING – Thoughts From a Braidy Tester.
This is required reading for everybody involved with software testing.
I have setup (and will maintain :-) an RSS feed for all entries in the “You are not done yet” category of this blog.


1
Sep 06

Testing Setups

You Are Not Done Yet: Setup
This blog looks like a worthy addition to the RSS subscription of anyone interested or involved with testing.


21
Jul 06

12 Benefits of Test Driven Development

J. Timothy Kingblogs about 12 Benefits of Test Driven Development:

The first thing you ask is not “What code will I write?” The first thing you ask is “How will I know that I’ve solved the problem?”.

(Via MemoRanda.)


19
Jul 06

Test-Driven Development

Oren Ellenbogen started a great series of posts on Test-Driven Development. Well worth following:
* Preface
* NameResolver – Part 1

(Via ISerializable.)

Get Adobe Flash playerPlugin by wpburn.com wordpress themes