• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

root of all evil and QA

 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Unfortunately things too often are not what we like it to be or what we call it which is a root of all evil AKA miscommunication. I am considering adding a Quality Assurance view to my SAD (Software Arch. Document). I do not think that the name is as important (or perhaps there is a better name for it and I would definitely like to hear it) so the name is not as important as intentions. I see View idea as a grant element of any SAD because of its targeted nature. Creating suitable view by putting proper information in it is a key to communication, which is a corner stone of any human effort (see Tower of Babel biblical example). Well, My QA view idea is sort of vague at this point and I know it has to do with setting a common ground for QA and DEV teams and telling everyone what tools/software components we should use and what is this TDD and performance and stress and all the rest. I would like to hear your opinion on this idea.
Best
 
author
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not 100% sure about your question. Are you saying that you're thinking of writing down the details of your QA process, and you want to know (a) whether this is a good idea, and (b) what should go in it?
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Peterson:
I'm not 100% sure about your question. [...]?


That is actually also my problem. I have this nasty habit of saying my ideas out loud to see how stupid they sound and what exactly do I mean. Thought and ideas have this amazing quality that they look excellent before being said.
With that said. I ma convinced that Test plan is necessary but it is not a part of SAD (Test plan as an instance of a test process definition). I have a feeling that there is an aspect of it concerning building blocks of environment and solution itself. JUnit as a technology and what it means for a QA guy (have them involved since start), Log4J, JMeter, cruisecontrol, ANT and such.
So I am not really asking about Test plan, rather about Architectural QA View of the solution and what should go in it and if that makes any sense?
Thanks David!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michal Harezlak:
JUnit as a technology and what it means for a QA guy (have them involved since start


Well, I am also not sure what you are getting at, but here seems to be a misunderstanding. JUnit is *mainly* a tool for the developers, not for the QA guys.
It's still a good idea to involve them early, though. In Extreme Programming, for example, you would want to have them help the Customer come up with Acceptance Tests using tools such as FitNesse.
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Well, I am also not sure what you are getting at, but here seems to be a misunderstanding. JUnit is *mainly* a tool for the developers, not for the QA guys.
It's still a good idea to involve them early, though. In Extreme Programming, for example, you would want to have them help the Customer come up with Acceptance Tests using tools such as FitNesse.


Ilja,
Thanks for you comments. JUnit is mainly, perhaps only developer's tool. Although I see software development as a never-ending stream of development cycles (never mind the specifics of process). Developers work is never done. Unit test are alive in QA environment and they could be run there. Therefore an explanation of unit test could be beneficial for a QA person. They understand what it is and who to ask when something happens with it. Perhaps it is good to include them in Cruse control mailing list of daily reports so they can use it for metrics. Dose it make any sense to put this perspective inside SAD?
Best regards.
[ March 08, 2004: Message edited by: Michal Harezlak ]
 
David Peterson
author
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could have the QA team look at the Cruise Control reports, but I'd be worried that this would just be distracting for them. How would they use the metrics to improve the process?
As well as functional acceptance tests, the QA team will need to consider performance, stress and usability testing. Are you going to document these too?
Printed manuals quickly go out of date, and they're usually so dull that no-one really reads them properly. How are you going to overcome these factors?
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
David,
All very valid points, thanks for your contribution. Lets start from the easiest one. I am against printing anything. Since I cannot afford RequisitePro or any other such expansive (license + training) tool. I have manufacture small document management engine (version control+web publishing) that is how I intend to avoid having printed out of sync documents. My personal experience is that �dullness� of document can be avoided by applying author�s commitment (read the thing at least once and remove all the crap that has no meaning) as well as validation (do we need it?) and verification (is it what we said it should be and dose it do what we want it to do?).
Yes I think I will need to document performance, acceptance, usability, configuration, documentation testing approachs. I see it more as a giving direction to QA and taking as much as possible of my developer�s shoulders (an example would be giving QA unit test data to create and analyze metrics). Showing them tools that could be used and explaining wher quality fits into development architecture.
I think that improving the process by analyzing metrics is possible. Lets say that metrics shows that even thought we have height number of unit test we still have high number of defects (of sort that unit test should discover) while doing test in labs. Lets go back and see how developers write unit tests. Perhaps we will discover that they do not have proper data set to use for testing. We could get this data from QA. Voila we have process improvment.
Best reagrds!
[ March 08, 2004: Message edited by: Michal Harezlak ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic