Creating a more open team

There is an ongoing thread on software-testing forum about how you may turn your team into a great team, in what concern knowledge sharing, interest for investigating new ideas and state-of-the-art testing practices. It all started with this email:

"I work in a team and I'd like to look at moving the team away from what often seems like a team of individuals and create a more open culture where people willingly talk about experiences gained within projects, techniques being used outside of our company and other conversations like simply mentioning an article they've read regarding testing. Has anyone out there had a similar culture-shift they've tried to achieve and therefore has a suggestion on ways to go about this?"

Here are some suggestions:

"A wiki is the ideal tool to do this sort of thing. If your team is not experienced using wikis, you might consider designating some experienced team members as "content creators" at the beginning, and make it part of their job to find and post interesting and important things to the wiki. Less experienced team members might take a more passive role, but be sure that the less-experienced are encouraged to read and comment on the content. Make it so that everyone feels that contributing to the community on the wiki is an important activity. "

"Creating forums is a good idea. You would need to have one dedicated team to drive the whole activities. You can also have brain storming sessions, solution boards.

You can also initiate Knowledge Exchange Session by bring prominent personalities across different areas (it could be testing, architects, domain experts etc)

Reward programs for sharing knowledge will be a good motivational tool to bring about the willingness in sharing experiences."

"I've found the wiki we use at my place of work to be a good place to put processes and how-to guides, but I honestly think that it won't encourage your team to further interact with each other. You can fill it full of useful knowledge, but that's not what makes a team great.
Try a practical demonstrations of the value of working more closely together. I recently reproduced an exercise from the 'rapid software testing' course I attended recently (thanks James :) ), whereby I had the team look at a completely unfamiliar gui and write down what they thought it did and how they'd test it. After a few minutes, I had them read their answers, pressed them a bit for more. Every single person in the room (8 of them) said something different (and useful). That five minute exercise alone was enough to show them that while they have a common set of skills, they also have different approaches and ways of thinking about a problem. They are now much more apt to ask each other questions or opinions than they previously were. I am encouraging the team to come up with ideas and exercises and questions that they have thought of or discovered, and present them to the rest of the group.

Maybe you should be asking them what sort of forum they would enjoy using to communicate their ideas. That question alone might be a good one to get intra-team discussion happening. You could have your test leads present a test post-mortem for a given project, have them identify (and defend) key decisions they made, what risks they identified, how they reacted to adversity and so on - then open it up to the rest of the group for comments and questions. You may need to encourage the quieter ones to speak up, but that will happen regardless. I find that people want to feel useful. If you provide a forum that encourages people to interact, to share their knowledge in a way that is useful to others, then you will probably get more buy-in than giving them a screen to regurgitate their thoughts into."

"Utilize the stickyminds editorials, find some older ones perhaps that are relevant, with some interesting comments as well, send out the link and discuss it over lunch. That will start the process going.
Another possibility now is just watching some of the google testing videos presented by testing luminaries over lunch, then having a discussion. At the google page, select Video then "Google techtalks testing", which finds 66 videos!
It has to be within the scope of people's work commitments though: I often push for people to have an hour or two a week (on average) for private study/research as part of their job role, and encourage them to present their discoveries etc at brown bag lunches."

"A nice idea (the open team one that is) but be careful not to "create" anything artificial or cringe making.
I can't count the number of times I've been on the receiving end of horrific artificial "team building" exercises.
I've watched these things alienate teams rather than build them or open them.
I suppose they do give the team an opportunity to bitch about something they have in common, but is that what you are after? ;-)

The wiki idea actually seems counter productive to your goals to me i.e. just another excuses for technical folk NOT to talk to each other.

The only thing I think every member of your team will have as a common goal is "better work/life balance".
For me, better planning and use of human resources i.e. going home on time AND having lunch (by myself or with friends), is what floats my boat.
I moved from permanent work to contract/consulting work because it actually encouraged my management to send me home on time i.e. every extra hour I spent in a day it affected their budget."

TestLink after one year...

We used Word documents and Excel worksheets as our documentation tool for scripted testing, and at one point I was given the task to evaluate and choose a new tool.

TestLink is a browser based tool to document Test scripts (planning) and execution results. It was chosen because it has some interesting features:
-there is an area for the tests design and another for the tests execution. Same test Plan (design) may be instantiated several times, for example for different platforms. It also supports Builds. Every result is easily stored and consulted.
-Main metrics are built-in. For example we may see at any point how many tests have passed, failed, blocked, not run
-Roles are supported: a tester has different privileges than a team leader, an administrator or a test designer
-Through Access rights, test executions are easily assigned to testers. Each tester only sees what matters.
-It is possible to import test cases from excel worksheet (though we had to make a macro to convert word to excel…)
-It is possible to connect to a bug tracking system

Note that this is not a tool for automation, or for calling automated scripts. It is a tool to store test documentation.

Now what is not so good:
-it does not link smoothly with exploratory testing; so one should think what is the real value of scripted testing for the System Under Test; in our case we do have to guarantee some basic features recurrently, so we do need some detailed test execution record. If the tests are not to be re-utilized, the usefulness of TestLink should be questioned.

Brilliant post from Michael Bolton, related with context-driven

Imagine reading this message:

"I'm looking to take a drug, but don't have the budget for the name brand pharaceuticals, and want more than is provided by folk remedies. I'm looking at ampicillin and ritalin, but don't know anyone who has taken these drugs. Does anyone have any experience with these drugs, or other drugs that they would recommend?"

Wouldn't you be curious to know what malady the writer was interested in relieving?

---Michael B.

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of gmel74Sent: July 5, 2007 10:17 AMTo: agile-testing@yahoogroups.comSubject: [agile-testing] test management tools

I'm looking to implement a test management tool, but don't have the budget for the name brand solutions and want more than is provided with the open source solutions. I'm looking at TCM by Seapine and Devtest from techexcel, but don't know anyone that has used these tools. Does anyone have any experience with these tools or other test management tools that they would recommend?