Software Development / QA: Tools and Knowledge Base?
August 27, 2014 5:11 PM Subscribe
Does your development/software qa department have a knowledge base?
What tools/software do you use for knowledge sharing and collaboration?
I heard it's good to have a QA Wiki page to document information?
Any interesting free software out there for software testers? like to generate test cases?
Is your department efficient?
Thanks
There is plenty of open-source wiki software out there. The most important thing is that you need a culture that encourages everybody to be a contributor, and a few dedicated people to curate / edit the content. You just want tools that get out of your way, the less fancy the better.
posted by mr vino at 5:32 PM on August 27, 2014 [2 favorites]
posted by mr vino at 5:32 PM on August 27, 2014 [2 favorites]
Response by poster: Thanks for your feedback.
I took a quick look on github. Looks like a great software tool for collaboration. However, my team is highly experienced and knows how to code. Does this mean a knowledge sharing tool is not necessary?
I'll take a look at wiki software. Not sure if anyone will contribute...
posted by Mountain28 at 6:18 PM on August 27, 2014
I took a quick look on github. Looks like a great software tool for collaboration. However, my team is highly experienced and knows how to code. Does this mean a knowledge sharing tool is not necessary?
I'll take a look at wiki software. Not sure if anyone will contribute...
posted by Mountain28 at 6:18 PM on August 27, 2014
Just as one data point, my software development group uses Confluence as a knowledge sharing Wiki (previously encountered problems, new team member info, test environment details, project status, etc). I have no experience with others, so it's just one possibility for you to consider.
posted by forthright at 6:30 PM on August 27, 2014 [2 favorites]
posted by forthright at 6:30 PM on August 27, 2014 [2 favorites]
Best answer: However, my team is highly experienced and knows how to code. Does this mean a knowledge sharing tool is not necessary?
I'll take a look at wiki software. Not sure if anyone will contribute...
These two statements boldly underline what Mr Vino said above: you need to have a culture of encouraging knowledge transfer or else no tool in the world will work. Figure that part out first.
The answer to your question of whether a knowledge sharing tool is not necessary: an emphatic no unless your company literally has zero turnover, ever. They know how to code so they can't use a knowledge sharing tool? That sounds more like laziness.
I have implemented wikis for companies, in fact specifically for QA departments, and the one that took hold the best was MediaWiki. I think the reason for this was because it looks just like wikipedia and the layout of the pages is familiar and simple to navigate. The editing markup is exceptionally well documented too.
I use Redmine now for work and while it accomplishes a lot of workflow-related taskes, I think the UI is an unmitigated disaster.
Github I think is pretty limited for this specific question.
posted by mcstayinskool at 8:23 AM on August 28, 2014 [1 favorite]
I'll take a look at wiki software. Not sure if anyone will contribute...
These two statements boldly underline what Mr Vino said above: you need to have a culture of encouraging knowledge transfer or else no tool in the world will work. Figure that part out first.
The answer to your question of whether a knowledge sharing tool is not necessary: an emphatic no unless your company literally has zero turnover, ever. They know how to code so they can't use a knowledge sharing tool? That sounds more like laziness.
I have implemented wikis for companies, in fact specifically for QA departments, and the one that took hold the best was MediaWiki. I think the reason for this was because it looks just like wikipedia and the layout of the pages is familiar and simple to navigate. The editing markup is exceptionally well documented too.
I use Redmine now for work and while it accomplishes a lot of workflow-related taskes, I think the UI is an unmitigated disaster.
Github I think is pretty limited for this specific question.
posted by mcstayinskool at 8:23 AM on August 28, 2014 [1 favorite]
Response by poster: Thanks for your comments.
There are great people within the department and rarely any turnover (highly experienced individual and don't really need code review sharing tools). We do have a Sharepoint site & network drives (just to store docs) for specs only.
But, I like the idea of MediaWiki or Confluence (share info within the team than to the rest of the company).
I will download a couple free software online and try it out.
posted by Mountain28 at 6:22 PM on August 28, 2014
There are great people within the department and rarely any turnover (highly experienced individual and don't really need code review sharing tools). We do have a Sharepoint site & network drives (just to store docs) for specs only.
But, I like the idea of MediaWiki or Confluence (share info within the team than to the rest of the company).
I will download a couple free software online and try it out.
posted by Mountain28 at 6:22 PM on August 28, 2014
Best answer: Nthing the above that it's really getting people to use it regularly more than the specific tool.
If you have low turnover and highly knowledgeable people... How many person-hours is it going to take to train an incoming hire with all of that domain knowledge? It's a lot easier to amortize some of that cost into regular documentation, and it also affords you some protection against someone falling under a bus. (Answering that question also gives you an idea of what should go in to your knowledge base.)
A side story about low turnover--One of the groups related to mine is a group of mainframers with turnover so low that they have evolved into a weird and terrible symbiotic relationship with their program. They can't leave, because no one else wants to pay COBOL programmers as much as they're getting now, and they can't be fired, because there are no replacement COBOL programmers with the domain knowledge to replace them. There was even an embarrassing incident where one developer was fired for mouthing off to the higher-highers in an e-mail chain, only to be rehired a month later when they realized they couldn't get along without him. No one knows now if the last one will retire because their application will finally be replaced, or if their application will finally be replaced because the last person capable of maintaining it has retired.
We use Confluence and we had a Sharepoint based wiki before that. Problem is not the tool, problem is time and motivation to use it. Plan the time when you're doing planning, and provide some kind of motivation to keep that time from slipping elsewhere.
posted by anaelith at 12:17 AM on August 31, 2014
If you have low turnover and highly knowledgeable people... How many person-hours is it going to take to train an incoming hire with all of that domain knowledge? It's a lot easier to amortize some of that cost into regular documentation, and it also affords you some protection against someone falling under a bus. (Answering that question also gives you an idea of what should go in to your knowledge base.)
A side story about low turnover--One of the groups related to mine is a group of mainframers with turnover so low that they have evolved into a weird and terrible symbiotic relationship with their program. They can't leave, because no one else wants to pay COBOL programmers as much as they're getting now, and they can't be fired, because there are no replacement COBOL programmers with the domain knowledge to replace them. There was even an embarrassing incident where one developer was fired for mouthing off to the higher-highers in an e-mail chain, only to be rehired a month later when they realized they couldn't get along without him. No one knows now if the last one will retire because their application will finally be replaced, or if their application will finally be replaced because the last person capable of maintaining it has retired.
We use Confluence and we had a Sharepoint based wiki before that. Problem is not the tool, problem is time and motivation to use it. Plan the time when you're doing planning, and provide some kind of motivation to keep that time from slipping elsewhere.
posted by anaelith at 12:17 AM on August 31, 2014
« Older Things to do along PA I-70W/OH I-71S in... | Trailheads and camping near Wytheville, VA Newer »
This thread is closed to new comments.
posted by phil at 5:18 PM on August 27, 2014 [1 favorite]