SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 7 of 7
  1. #1
    New Member
    Join Date
    Jun 2014
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Regression testing in Agile env assistance

    Hope to get some help on such scenario below

    Sprint is 4 weeks long
    Initial expectation, 1 week before end of the sprint to run testing to check new features completion/bugs verification
    1st week of next sprint to run regression testing

    Case
    Env provided is being used not by QA only, but also, by others.
    Builds deployment happens - 2-3 times a week weekly

    Question

    Is there a possibility to run regression in such scenario when there is no time provided to complete regression cycle (5 days estimation)?

  2. #2
    SQA Knight
    Join Date
    May 2006
    Location
    Playa Del Rey, California, United States
    Posts
    2,621
    Post Thanks / Like
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    In Agile, one typically go one of two ways. (or both)

    1) Have so much automation that you can perform regression upon nearly every build. Have a whole battery of unit, integration, and end-to-end tests running on CI.

    2) Scope your changes per iteration so the risk is small enough so you can effectively limit the scope of testing your changes. For example, when doing refactoring, limit it to one module, and plan out your features so you don't have different devs on the team working on different feature areas at the same time. This means developers need to design using SOLID ( SOLID (object-oriented design) - Wikipedia, the free encyclopedia ) priciples. This allows modules to be very decoupled and swapped out very easily, minimizing the risks of refactoring.

    If manual testing is very intensive. I would say it's better to have 1 week sprints and make your changes so small and focused that you can test whatever's being changed within 20 minutes.
    Last edited by dlai; 06-18-2014 at 06:48 AM.
    David Lai
    SDET / Consultant
    LinkedIn profile

  3. #3
    New Member
    Join Date
    Jun 2014
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Quote Originally Posted by dlai View Post
    In Agile, one typically go one of two ways. (or both)

    1) Have so much automation that you can perform regression upon nearly every build. Have a whole battery of unit, integration, and end-to-end tests running on CI.

    2) Scope your changes per iteration so the risk is small enough so you can effectively limit the scope of testing your changes. For example, when doing refactoring, limit it to one module, and plan out your features so you don't have different devs on the team working on different feature areas at the same time. This means developers need to design using SOLID ( SOLID (object-oriented design) - Wikipedia, the free encyclopedia ) priciples. This allows modules to be very decoupled and swapped out very easily, minimizing the risks of refactoring.

    If manual testing is very intensive. I would say it's better to have 1 week sprints and make your changes so small and focused that you can test whatever's being changed within 20 minutes.

    Testing is done on mobile and STB, therefore, so far no option to do automation. As QA, I cannot change sprint duration as well as change scope, that is not an option for me. This is done by management that passes info to devs and QA.

    Mostly right now, I do not do regression as expected as I do not have time to complete such thing. Only new feature/bug fixes testing and sanity testing.

  4. #4
    New Member
    Join Date
    Mar 2015
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Is it not possible for your to ask for a separate QA environment? That way you control the environment and build deployments.

  5. #5
    SQA Knight
    Join Date
    May 2006
    Location
    Playa Del Rey, California, United States
    Posts
    2,621
    Post Thanks / Like
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    Quote Originally Posted by vanatomas View Post
    Testing is done on mobile and STB, therefore, so far no option to do automation. As QA, I cannot change sprint duration as well as change scope, that is not an option for me. This is done by management that passes info to devs and QA.

    Mostly right now, I do not do regression as expected as I do not have time to complete such thing. Only new feature/bug fixes testing and sanity testing.
    You should talk to your QA manager. He/She should stand up for you and push back against the organization asking you the impossible.

    There's really only really 4 things you co do in a bandwidth constrained project of any type.

    * limit scope
    * invest in automation
    * increase man power
    * increase time
    David Lai
    SDET / Consultant
    LinkedIn profile

  6. #6
    New Member
    Join Date
    Apr 2015
    Location
    Chennai, Tamil Nadu, India
    Posts
    1
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Hi,
    Changing scope or timeline is close to impossible from QA side. This is across companies and is well known issue. It will take awhile to change these things in an organization. So here are few tips from me in your condition:
    1. As you mentioned automation is not feasible you can prioritize: H,M,L your regression cases. Based on your count of regression cases and available 5 days of time you can target only critical cases. This is better than No Regression. Prioritization is very important. If you have identified cases which are to work fine for your application then you can even skip other test cases and execute only these critical test cases.
    2. You can either execute portion of H and M or 100% H cases. This you can only decide based on your application nature.
    3. Risk based testing is the only possible way in your case. You decide the risk for each functionality and execute only high risk(if not tested) test cases
    4. Test case automation may not be possible but you can look for options like optimized way of test data generation, quick way to update test results and log bugs etc to save time in the testing process. That way you will get more time to cover more test cases.

    In my experience tester's decision takes major role in critical period so perform adhoc testing and try to break code. This is one of the quick way to find if code has broken

    Let me know if you have any further questions in this regard.

    Regards
    Diana A

  7. #7
    Apprentice
    Join Date
    Aug 2015
    Posts
    12
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    But aren't you saying that the first week of the sprint that follows is spent doing manual regression? (that is 5 days). I believe that this is a question that all the team should get together and answer because quality is a responsibility of all the team. Does the team feel confident that when the development is finished, this product will be ready to be launched? Without having any kind of automation, I don't think it's possible to feel confident. If the team doesn't feel confident, does it make sense to keep adding new functionality sprint after sprint. Or probably it would make more sense to go slower, but with more certainty that the functionality that already exists keeps working when new one is added. Remember, this is a problem of the whole team, not just from the QAs!

 

 

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 © 2017 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 9.38%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 09:46 AM.

Copyright BetaSoft Inc.