SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 8 of 8
  1. #1
    Member
    Join Date
    Mar 2000
    Posts
    33
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Regarding getting started...

    Okay, I have a question for all you QA gurus out there. What I want to get a feel for is how you go into a place that has nothing as far as quality assurance is concerned and what you do to start implementing it. Are there steps you follow? Is there some rigorous method that can be followed almost like an equation? I really am interested in becoming a QA guru myself and I want to be as educated as possible on what to do. I am looking for general stuff here - not the specifics you have done.

  2. #2
    Moderator AJ's Avatar
    Join Date
    Jun 1999
    Location
    San Jose, CA
    Posts
    1,691
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Every place depends on what they have!

    My advice is:
    Buy a test management tool like TestDirector, you can shart by adding the requirements in it, then start to develop testcases which are manual at first, but later will automate... Then implement a bug tracking system and sell it to your development team, since without their vote it really won't be a successful QA effort.

    You can develop a Test Plan as you do the work, simply grab any resources that are relavent and stick them all into a document. There are many examples of plans out there. And some tools like TestDirector will generate a plan for you (or a starting point).

    Also read books... visit http://qabooks.com and check out Testing Computer Software (the original QA Bible) then Testing applications on the Web and Automated Software Testing

    Hope all this helps.

    ------------------
    AJ Alhait
    BetaSoft Inc.
    AJ Alhait
    BetaSoft Inc.

  3. #3
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Basically what I try to do is go in with a staged approach and, unfortunately, many of the books out there I have found do not really advocate this and, when they do, they do not give the particulars or even some of the necessary ingredients to the effort.

    What I first do (assuming there is little to nothing in place for quality assurance or quality testing) is in this rough order:

    1. Determine cultural resistance points

    2. Determine budget, resource, staffing limitations

    3. Determine what exists already

    4. Quality Audit & Implementation Plan

    5. Quality Policy Statement (mission statement; direction papers)

    6. Quality System

    7. Test System

    8. Quality Process

    9. Test Process

    10. Determine use for automation and educate on this

    11. Requirements, Design, Code review institution

    12. Formulate TechQA

    13. Establish QA Intranet

    Now there is a lot that goes into what I am talking about here (I trust that is obvious) and I guess I will just leave you with this for now rather than boring you to death with all the details. I do this in the spirit in which you asked: for general details rather than the specifics in what we have done. But I will say that some of those specifics are very important. For example, defining a quality-risk based approach is something I very much adovcate as I do a moderated approach to any quality testing. And, speaking along that line, I try to institute "quality axioms" as well as get the idea out there that quality assurance and quality testing are different things.

    Also, just as an aside, many people look at me askance when they see "QA Intranet" on there and yet I find that this is a very important way to show that QA has some knowlewdge and to get it disseminated.

    I hope that this helps or, at the very least, made sense.



  4. #4
    Member
    Join Date
    Mar 2000
    Posts
    33
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Thanks for the comments guys. AJ, we are not even looking at tools yet. So TestDirector is out for the time being. Jeff, I notice you do not mention defect tracking. Was that an oversight or is it part of the other stuff you mentioned. Regarding all that, I have a lot of questions for you! When you say "cultural resistance points" what do you mean? When you say "determine what exists already" wouldn't that be covered in determining the resources? Based on other posts you have done here and what you said, I take it that you take a very dim view on using tool solutions (like TestDirector or anything else). AM I right? Also I'm not sure what you mean by formulate TecHQA. Also what do you mean by quality axioms?

  5. #5
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Defect tracking, as you surmise, is part of the other concepts I had mentioned although, in actuality, you are correct that it was an oversight in that I should have given it its own place on the list. Of course I firmly believe that a solution of some sort should be adhered to. The tool solution really matters not as much as whether there is a stable, documented defect process.

    The cultural resistance points I refer to are simply the people issues. For example, I will try to find out if anyone is resistant to the idea of having a quality assurance and quality testing effort and find out why. I particularly want to make friends with the lead developers early on and talk with them about their views of QA and how we can work together. I usually take them to lunch (one at a time) when I start somewhere if time permits. At the very least, I schedule time with them. I also like to see what views management has of QA. For example, some managers fear that it will become something akin to a fascist regime while others feel that it is simply not effective as an overall solution. I like to find where the major gaps in knowledge or expectations are regarding quality assurance and quality testing: both as an effort and as a set of practices.

    When I say "determine what exists" that does not necessarily fit in with finding out what resources exist. Determining what exists is finding out what, if any, type of quality assurance or quality testing exists. Was a quality audit previously done? Is there a quality system already in existence? Is the focus on ISO? Is the focus on IEEE? What tools exists and are being used? For example, is there a defect tracking tool? Is there a configuration management tool? What has been standardized across the organization? Have fiefdoms been established? This is important to me because I may disagree with what exists (a particular tool, say) or how it is being implemented. Also, when I write up a quality audit I need to know these things. One fear that many people have is that quality assurance (when it is brought on as a full effort) will sweep away all that came before it, regardless of want or need. This needs to be alleviated by showing that you want to determine fit for the environment.

    As far as my "dim view" on tool solutions, I would say that this is definitely a mischaracterization of my viewpoints and if I gave this impression at any time I was wrong to do so. I do, however, take a very moderated approach to implementing outside tool solutions and the reliance that is placed upon them. I have seen more quality efforts flounder because people treat tool solutions as some sort of silver bullet. I love automation tools and, for the most part, I think they do a good job. However, I think that functional automation tools (such as eTest, SilkTest, WinRunner, et al.) are very much misused because they are not treated as what they should be: development scripting tools. I think many of the companies sell their tools based on the record-and-playback features without mentioning that this is not a good way to perform automation. Having said that, I am very much in favor of performance tools (such as eLoad, SilkPerformer, LoadRunner, et al.) as well as tools that automated link checking and tag validation. So my problem is not with the tools, but with the way that they are used.

    As far as saying "TechQA" that is just short for "Technical QA." The reason for this is that it should be realized that QA staff are going to be technical to a certain degree. We are not "just testers" and we are not just pie-in-the-sky theoreticians. We have a practical side and we, like the organizations we work within, are technical. Having said that it is important to make people realize that we are not necessarily developers - nor should we be. I always like to distinguish it by saying that we have domain knowledge, not domain expertise.

    Finally, regarding the axioms these are just concepts I like to make clear from the outset. For example, what I just said above (about the distinction between domain knowledge and expertise) is an axiom I like to throw around as a kernel of what I perceive to be wisdom. (I do not presume others see it as wisdom.) Another one I like to use is "You should not test that an application does what an application does." I call this "tautology testing" (and, as far as I know, that may be one of my few original thoughts). I also apply this to quality testing (during interviews, for example) by stating that "Testers should be pragmatic, not dogmatic" or that "Testers should be curious, not obssessive." Another axiom I like to toss of is that when looking at people for the positions of quality assurance an quality testing, make sure to be wary of those that tout automated or other tool solutions at all costs. (The key phrase is "at all costs.") Many times this is because they do not grasp (or do not want to deal with) some of the basics such as test casing, test planning, etc. because it is seen as drudgery. On the flip side of that coin, however, is making sure that you find people that do not lack all knowledge of such tool solutions. This usually means they do not have the requisite technical skills or do not recognize the value of them.

  6. #6
    Junior Member
    Join Date
    Nov 2000
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Dude, you rock! Awesome stuff. I'm just getting into QA and this is really good stuff! What do you mean about the requirements and design stuff. I know code reviews because those correspond to unit tests right. And thanks for giving such in-depth answers. I've been following you all around this site quite a bit now before posting to much and I'm impressed. Can I e-mail you too?

  7. #7
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by QA_Babe:
    I've been following you all around this site quite a bit now...<HR></BLOCKQUOTE>

    Should I be worried?

    Anyway, what I meant about the reviews was simply that: reviewing the non-executable parts of the application/product. This means the documentation for requirements and design. Code is, of course, executable but what I meant by a code review was not a unit test but something akin to a walkthrough or inspection of the code itself.

    Keep in mind that I am not saying quality assurance or quality testing staff should do these code reviews. But a quality assurance effort should assure that some such efforts are being undertaken as well as making sure that there are coding standards. It is, generally, up to development what those standards will be - but they must then be followed.

    With the requirements and design reviews, a member of quality assurance can and should be present. This is basic requirements analysis on the one hand (making sure they are essentially complete, non-contradictory, and testable) and basic design reviews in the sense of making sure everything makes sense - not only from a testing perspective, but even from the standpoint of usability issues and logical flow-through.

    These reviews are an attempt to be proactive and to employ phase containment techniques based on the truism that the earlier you find the problems, the easier they are to correct.

    And, yes, if you wish you can certainly e-mail me, although ideally if you have comments/questions, etc. post them here so that everyone can benefit and help you out with any issues you might be encountering.

  8. #8
    Junior Member
    Join Date
    Nov 2000
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Regarding getting started...

    Should you be worried? Depends on what worries you. But we can talk more about that in e-mail. (Insert cat-like purr here.) Thanks for the tips. Very helpful.

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.71%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 09:21 AM.

Copyright BetaSoft Inc.