Skip to main content

Setting up a company QA forum/Wiki

I've recently looked into creating a QA forum, at a request of a number of team members, where members of the QA community inside where I work can post questions or blog posts and share them with others.

The benefits of using something like this over email is that it keeps everything in one place, it stores the questions for ever, so if we have new starters and they have a question they can look at these sites first before sending out an email.

I've suggested OSQA as the question exchange software and we are just going to use a standard wiki for the blog post /information storage.

I got asked how can we ensure that its kept up to date? As it will only really be useful if it is kept up to date.

The simple answer is, that if it's not kept up to date then obviously people aren't using it so it's not that much of an issue if that is the case. If people are using it consistently then it should in theory stay up to date and be an excellent source of information for new starters and older heads! 


I will keep you up to date with its success (or lack of)  over the next coming months! 

Comments

  1. If its only for internal issues - then it make sense, if its for general issues - I would direct to one of the community forums.
    We also use a network directory of "HowTo", where we keep different internal usage instructions in MS-Word or TXT format - this reduces the need to elaborate common instructions in STD.
    Might be easier to save E-Mails as text rather than export into wiki, and probably easier to maintain.
    @halperinko - Kobi Halperin

    ReplyDelete
    Replies
    1. Hey,

      This will only be for internal issues that are specific to our systems and their architecture. We'll also have a wiki which will have a few things on...

      But you're right, for general issues, community forums are definitely the way forward.

      Delete
  2. I really don't get the point to have QA forum wiki. It will be great to display a sample to understand the idea over this, for the QA members.
    Currently we have a wiki but we don't use it much...

    ReplyDelete
  3. We have a wiki and this QA forum. It's effectively an online message board where people can post questions they have about ASOS systems that someone in QA might be able to answer, there's also a karma aspect in that people that give good answers receive upvotes (kind of like reddit). It's better than emailing all of QA to ask a question as often the emails will get lost over time, whereas this way we have a storage for all the questions that might be asked, and the search functionality is pretty good as it makes use of tags etc. If you often have people asking you questions and sometimes it's the same question then I'd highly recommend something like this :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Treating Test Code as Production Code

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....

Testers: Be more like a Super-Villain!

Who doesn't love a Super Hero? Talk to my son, and he'll tell you how much he loves them, talk to many adults and they'll say the same! Deep down, we all love to be the Super Hero, we all want to save the day! However, I want to talk about the flip side of Super Heroes, the Super Villains... I often play Imaginext with my son, and I (unfortunately?) am nearly always the Super Villain! Be it Lex Luthor, Joker, Two Face, Mr Freeze or The Riddler! These are all great characters and great Super Villains, but why would I want to write about Super Villains? A while ago where I worked, we had a few Super Heroes, people who would be able to come in and "fix" things that had broken and help deliver projects on time. We then shifted, we decided to do away with the Super Hero culture and try and prevent from being in that position in the first place, whilst we didn't go as far as wanting to hire Super Villains, it's definitely a story that has stuck with me and t...

Using BDD and gherkinising your Acceptance Tests

In my post Testing of Automated tests , I mention about a BDD framework which involves using BDD to drive your acceptance tests. BDD stands for Behaviour Driven Development.  One effective method of writing BDD tests are by using a format known as Gherkin language. These consist of Given, When, Thens. The main advantage of the gherkin language is that it's readable by the business, and in an ideal world forms part of the Conditions of Acceptance around a PBI. Also, using a Visual Studio plugin of SpecFlow , you can integrate your Gherkinised COAs into your solution with feature files, and then drive the automated tests, however, for this post I will focus solely on how to effectively gherkinise your acceptance tests. A Feature file consists of a feature outline, which details what the feature file is testing followed by Scenarios and examples (parameters).  The BDD scenarios are made up of a Given, When, Then... These are effectively an initial state (Given), an action (W...