SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 7 of 7
  1. #1
    Junior Member
    Join Date
    Sep 2003
    Location
    Sri Lanka
    Posts
    13
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Getting quick releases to QA

    Hi,

    Is getting frequent intermediate releases to QA a good idea? Objective of this is to give quick feedback about the status of the release to the development team.

  2. #2
    Moderator JakeBrake's Avatar
    Join Date
    Dec 2000
    Location
    St. Louis - Year 2025
    Posts
    15,609
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    If the release consists of more work than the test team can handle, then it might be ungood - OR - if the test team is playing Spider Cell 40 hours per week or drinking way too much beer, then the releases could stand to be more frequent.

    That is a simple answer to a question with many complex moving parts. What do you think about it?

  3. #3
    Senior Member
    Join Date
    Jan 2003
    Posts
    1,898
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    My team uses the time inbetween releases, which sometimes is practically nothing, to prepare for the next release and write test cases.

    While I can understand the benefit of the intermediate releases to development, it would represent a burden on the test team. When the final release was made, the entire system would still have to be regression tested.

    Still, if you have the bandwidth to it, it improves the quality of the product.

    There's also room for some compromise; I've sometimes "loaned" a few of my staff that were caught up with other things to development to do testing of a given release in the development environment prior to turnover. It has the same good effect on the code, and disrupts less of our staff.

    - Linda

  4. #4
    Moderator Joe Strazzere's Avatar
    Join Date
    May 2000
    Location
    USA
    Posts
    13,170
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    How quick? And how much feedback is desired?

    I've worked with daily builds before - that wasn't a problem.

    I've also worked with builds every two weeks = that wasn't a problem either.

    Both methods worked well, but each had different expectations.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  5. #5
    Senior Member
    Join Date
    Sep 2006
    Posts
    153
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    If I understand you correctly, it is actually a very good question and the answer is not always clear.

    I think (at least from my experience) it is a common practice in Agile to release to QA intermediate releases (can be also integration builds) to test before FC (Feature Complete).
    The advantage of it is that the product is more stable when you get to the stabilization period (when you get the first RC – Release Candidate), which is always (and again, this is my experience in Agile) stressful and the team has to bring the product to an acceptable quality in a not enough time (and then 2 weeks later release SP with all the fixes that the team didn’t manage to finish on time).

    It also holds the potential of wasting QA time, if the testers test incomplete features where most of the bugs that they find become obsolete few days later because of changes in the feature (the feature is still dynamic).

    Testing intermediate releases is a good practice if you have good communication with the developers team, and can get information of what to test and what not(depends on each feature's development stage), what are the known issues (to the developers) due to a new code which they are going to fix/change anyway.

    Frequent? – If every time the developers tell you exactly which features to test I think it is a good practice. If they don’t give you any info and every time you just test everything I think that this is bad from the above reasons.
    I think it can also help if you don’t do Agile, but maybe the advantage is not as significant, but still it is good to get good info from the developers to avoid wasting testers’ time.

    I always put pressure to plan intermediate releases to the QA team when we prepare the sprint plan (the developers not always happy to do that because this forces them to be more planned [img]/images/graemlins/smile.gif[/img] ).

  6. #6
    Junior Member
    Join Date
    Sep 2003
    Location
    Sri Lanka
    Posts
    13
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    Thanks guys for your thoughts!

    In our project, we got QUICK UNPLANNED releases for testing and because of this the team couldn't complete the test cases.
    Also I noted that because of this kind of releases, the developers tend to do less unit testing. [img]/images/graemlins/frown.gif[/img]

    So as you said, the more you plan the better the quality would be.

  7. #7
    Senior Member
    Join Date
    Sep 2006
    Posts
    153
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Getting quick releases to QA

    [ QUOTE ]
    In our project, we got QUICK UNPLANNED releases for testing and because of this the team couldn't complete the test cases.
    Also I noted that because of this kind of releases, the developers tend to do less unit testing.

    So as you said, the more you plan the better the quality would be.

    [/ QUOTE ]
    You bring two good points.

    If you feel that the developers using the QA team instead of them doing their basic tests I would suggest that you do some metrics on that and show it to the PM or other managers.

    We had that feeling in the past, and collected metrics through a full month. We logged things like: obvious bugs that were found in a feature within first 10 minutes of test session (shows that the developer didn’t try to run her/his feature even once before submitting to QA), and if the broken functionality is simple or deep. Simple is something like ‘Cancel’ button in a ‘Save’ dialog tries to save instead of canceling. This shows on not running a unit test.
    Unit tests can cover only simple functioning because they only check that a specific interface actually does what it should. Unit tests can’t test any deep broken functionality or workflow bugs. Try not to go crazy with the data you want the testers to log for each bug, because this might turn logging a bug into hell.
    We showed our metrics (without giving any developers’ names, just treated the developers as a team) and the management took it very seriously and accused the developers for wasting company’s resources.

    About planning: according to my experience, the QA team is usually the most planned team in an organization. I am in a fortunate position in my current job, that I own the development processes and reports, and usually the management backs my decisions (especially if I use good metrics and reports to prove my point).

    I whish you good luck with this struggle,
    Ofer

 

 

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 08:05 PM.

Copyright BetaSoft Inc.