SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 3 of 3

Thread: some questions?

  1. #1
    Member
    Join Date
    Jan 2001
    Location
    UK
    Posts
    33
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    some questions?

    1. What is the role of the QA team on a software development project? (other than testing?)

    2. What makes automated testing hard?

    3. What are some likely differences between a QA and a Production
    environment?

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

    Re: some questions?

    1. The QA team may facilitate JAD sessions, or phase reviews. The QA team may escalate issues to upper management. The QA team may be involved in SDLC (system development life cycle) methodologies, and may write or change development procedures to improve efficiency.

    2. Some of the challenges with automated testing are:

    If there is no manual testing process in place that works, adding automation will just make it worse. Managing automation efficiently requires organization.

    Untrained staff. The staff that automate tests need a specific skill set and they need to be trained on the test tool(s) by an expert on that tool. Otherwise, the ramp-up time is significant.

    Lack of planning. The first automation effort should be carefully planned in advance. Manual test cases should be reviewed and specialized, common procedures (such as how to code for system-supplied fields) should be determined. New test cases written for the application which is going to be automated should be written with automation in mind. Standardized test data usually needs to be created and stored. The tool itself needs to be installed and configured. Security issues needs to be addressed (who is going to be able to change the automated scripts?).

    Lack of time. It takes at least twice as long to prepare automated scripts as manual scripts. I've seen some threads here that say it can take up to 10 times longer! The payback is that future runs of the scripts can save up to 2/3 in time and resources. Often a management team (believing the silver bullet speeches of a sales person), will buy test tools in order to save time on their largest, most complex, most time-critical project. It's best to start automation efforts on the smallest, most stable product available.

    Automated scripts are not maintained appropriately. If you don't maintain the automated scripts, they become worthless. Script maintenance needs to be included in project plans.

    Unrealistic expectations. Not every test can (or should be) automated. The purpose of automated testing is to remove repetitive tasks from the tester (particularly for regression testing), allowing them to focus on new or complex functionality. Automated tools are required for stress, load, and performance testing. Automated tools can be superb for generation of quantities of test data. For relatively stable applications, automated tools can increase test efficiency and lower test costs. They cannot, however, take the place of a human being. They need to be maintained. Test results still need to be analyzed. They take twice as long to create. Staff need to be trained.

    You may need more than one tool to do the job. Many organizations are seduced by entire tool suites from one given vendor. And they do have some advantages, since they're specifically built to play nicely with each other. However, depending on your environment, you may need tools from a variety of vendors. Each facet of each tool needs to be tested prior to purchase in the environment in which it will be run. A close-to-perfect choice should not be discounted because a few applications are so specialized, they need a different tool. You may need both tools.

    Tools are not installed as an enterprise-wide solution. I've seen this many times (as a consultant). It is cheaper in the long run to plan for corporate-wide use of the tool, particularly the defect manager. What ends up happening is a constant purchase of additional licenses, upgrading of servers, and (in the case of concurrent licenses), frustrated and angry staff unable to access the system.

    Your tools may become obsolete. Technology changes very quickly. When you make your initial investment, you need to also invest in maintenance packages (around $200/hr per license). Most vendors keep their tools current with technological advances. Even so, some vendors go out of business. Some change their focus. It's a good idea to review your automation efforts and tool sets every 5 years. It could be that another tool would be more effective. Because at some future date, you may change tools, or they may become obsolete, it is important to continue to maintain a respository of manual test cases (or, at the very least, test requirements).

    I'm sure many others have additional comments; these are the ones that came to mind with your questions.

    - Linda

  3. #3
    Senior Member
    Join Date
    Feb 2001
    Location
    Colorado Springs, CO, USA
    Posts
    864
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: some questions?

    Originally posted by chetanv:

    3. What are some likely differences between a QA and a Production
    environment?
    <font size="2" face="Verdana, Arial, Helvetica">If you are working in an IT department where there will only be one producion environment:
    Sometimes there isn't enough money to build a test environment which is exactly like production. Then you end up with less memory, less disk space, and slower connection speeds.

    Sometimes the test environment doesn't have the same amount of data as production. Or it doesn't have the same kind of data. It has test accounts, with bogus information rather than real names, addresses, and phone numbers. Occassionally, bugs in the system come from data issues not encountered in test. Or bugs come from production-like-quantities of data.

    If you are working in a software development shop where there will be many producion environments:
    Sometimes the user has a different configuration than the ones you tested.
    Thanks,
    Tim Van Tongeren

 

 

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.34%
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 02:00 PM.

Copyright BetaSoft Inc.