FEEDBACK IS KEY, WHETHER IT BE POSITIVE OR NEGATIVE, IT HELPS THE DEVELOPERS. MOST TESTERS IGNORE THIS PROCESS OF THE BETA TESTING.HERE ARE SOME TIPS FOR EVERONE
Beta Explained By Wikipedia.com
"Beta" is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.
A "beta version" is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price, but act as free testers.
Beta versions test the supportability of the product, the go-to-market messaging (while recruiting Beta customers), the manufacturability of the product, and the overall channel flow or channel reach.
Beta version software is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access. As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet.
Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product. Only software issues, or bugs and unimplemented features will be addressed.
Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.
An example of a major public beta test was when Microsoft started releasing regular Windows Vista community technology previews (CTPs) to beta testers in January 2005. The first of these was build 5219. Subsequent CTPs introduced most of the planned features, as well as a number of changes to the user interface, based in large part on feedback from beta testers. Windows Vista was deemed feature complete with the release of build 5308 CTP, released on February 22, 2006, and much of the remainder of work between that build and the final release of the product focused on stability, performance, application and driver compatibility, and documentation.
When a beta becomes available to the general public it is often widely used by the technologically savvy and those familiar with previous versions as though it were the finished product. Usually developers of freeware or open-source betas release them to the general public while proprietary betas go to a relatively small group of testers. Recipients of highly proprietary betas may have to sign a non-disclosure agreement. A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.
As the Internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". [1] Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser to the public and calling them "beta" releases. In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production-level [2]. It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006. This technique may also allow a developer to delay offering full support and/or responsibility for remaining issues. In the context of Web 2.0, people[who?] even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate such as the Halo 3 public beta.
Google Definitions:
- Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the ...
en.wikipedia.org/wiki/Beta_Testing - Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service ...
en.wikipedia.org/wiki/Beta-testing - Testing of a release of a software product conducted by customers.
www.software-testing-outsourcing.com/glossary.html - Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. ...
thiyagarajan.wordpress.com/glossary/ - The process of testing and improving unfinished software. Beta testing is most useful when the testers aren't the original programmers and can ...
www.netc.org/openoptions/appendices/glossary.html - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. ...
www.techinterviews.com/ - rigorous testing across platforms and browsers on beta sites to resolve any outstanding issues or bugs.
loetus.com/glossary.html - A test for a computer-related product prior to commercial release. Beta testing is the last stage of testing and normally can involve sending the ...
www.s3co.com/glossary/
Top Twelve Tips for Running a Beta Test
Here are a few tips for running a beta test of a software product intended for large audiences -- what I call "shrinkwrap". These apply for commercial or open source projects; I don't care whether you get paid in cash, eyeballs, or peer recognition, but I'm focused on products for lots of users, not internal IT projects.
- Open betas don't work. You either get too many testers (think Netscape) in which case you can't get good data from the testers, or too few reports from the existing testers.
- The best way to get a beta tester to send you feedback is to appeal to their psychological need to be consistent. You need to get them to say that they will send you feedback, or, even better, apply to be in the beta testing program. Once they have taken some positive action such as filling out an application and checking the box that says "I agree to send feedback and bug reports promptly," many more people will do so in order to be consistent.
- Don't think you can get through a full beta cycle in less than eight to ten weeks. I've tried; lord help me, it just can't be done.
- Don't expect to release new builds to beta testers more than once every two weeks. I've tried; lord help me, it just can't be done.
- Don't plan a beta with fewer than four releases. I haven't tried that because it was so obviously not going to work!
- If you add a feature, even a small one, during the beta process, the clock goes back to the beginning of the eight weeks and you need another 3-4 releases. One of the biggest mistakes I ever made was adding some whitespace-preserving code to CityDesk 2.0 towards the end of the beta cycle which had some, shall we say, unexpected side effects that a longer beta would have fleshed out.
- Even if you have an application process, only about one in five people will send you feedback anyway.
- We have a policy of giving a free copy of the software to anyone who sends any feedback, positive, negative, whatever. But people who don't send us anything don't get a free copy at the end of the beta.
- The minimum number of serious testers you need (i.e., people who send you three page summaries of their experience) is probably about 100. If you're a one-person shop, that's all the feedback you can handle. If you have a team of testers or beta managers, try to get 100 serious testers for every employee that is available to handle feedback.
- Even if you have an application process, only one out of five testers is really going to try the product and send you feedback. So, for example, if you have a QA department with 3 testers, you should approve 1500 beta applications to get 300 serious testers. Fewer than this and you won't hear everything. More than this and you'll be deluged with repeated feedback.
- Most beta testers will try out the program when they first get it, and then lose interest. They are not going to be interested in retesting it every time you drop them another build unless they really start using the program every day, which is unlikely for most people. Therefore, stagger the releases. Split your beta population into four groups and each new release, add another group that gets the software, so there are new beta testers for each milestone.
- Don't confuse a technical beta with a marketing beta. I've been talking about technical betas, here, in which the goal is to find bugs and get last-minute feedback. Marketing betas are prerelease versions of the software given to the press, to big customers, and to the guy who is going to write the Dummies book that has to appear on the same day as the product. With marketing betas you don't expect to get feedback (although the people who write the books are likely to give you copious feedback no matter what you do, and if you ignore it, it will be cut and pasted into their book).
Beta Explained By Wikipedia.com
"Beta" is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.
A "beta version" is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price, but act as free testers.
Beta versions test the supportability of the product, the go-to-market messaging (while recruiting Beta customers), the manufacturability of the product, and the overall channel flow or channel reach.
Beta version software is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access. As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet.
Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product. Only software issues, or bugs and unimplemented features will be addressed.
Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.
An example of a major public beta test was when Microsoft started releasing regular Windows Vista community technology previews (CTPs) to beta testers in January 2005. The first of these was build 5219. Subsequent CTPs introduced most of the planned features, as well as a number of changes to the user interface, based in large part on feedback from beta testers. Windows Vista was deemed feature complete with the release of build 5308 CTP, released on February 22, 2006, and much of the remainder of work between that build and the final release of the product focused on stability, performance, application and driver compatibility, and documentation.
When a beta becomes available to the general public it is often widely used by the technologically savvy and those familiar with previous versions as though it were the finished product. Usually developers of freeware or open-source betas release them to the general public while proprietary betas go to a relatively small group of testers. Recipients of highly proprietary betas may have to sign a non-disclosure agreement. A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.
As the Internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". [1] Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser to the public and calling them "beta" releases. In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production-level [2]. It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006. This technique may also allow a developer to delay offering full support and/or responsibility for remaining issues. In the context of Web 2.0, people[who?] even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate such as the Halo 3 public beta.
Google Definitions:
- Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the ...
en.wikipedia.org/wiki/Beta_Testing - Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service ...
en.wikipedia.org/wiki/Beta-testing - Testing of a release of a software product conducted by customers.
www.software-testing-outsourcing.com/glossary.html - Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. ...
thiyagarajan.wordpress.com/glossary/ - The process of testing and improving unfinished software. Beta testing is most useful when the testers aren't the original programmers and can ...
www.netc.org/openoptions/appendices/glossary.html - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. ...
www.techinterviews.com/ - rigorous testing across platforms and browsers on beta sites to resolve any outstanding issues or bugs.
loetus.com/glossary.html - A test for a computer-related product prior to commercial release. Beta testing is the last stage of testing and normally can involve sending the ...
www.s3co.com/glossary/
Top Twelve Tips for Running a Beta Test
Here are a few tips for running a beta test of a software product intended for large audiences -- what I call "shrinkwrap". These apply for commercial or open source projects; I don't care whether you get paid in cash, eyeballs, or peer recognition, but I'm focused on products for lots of users, not internal IT projects.
- Open betas don't work. You either get too many testers (think Netscape) in which case you can't get good data from the testers, or too few reports from the existing testers.
- The best way to get a beta tester to send you feedback is to appeal to their psychological need to be consistent. You need to get them to say that they will send you feedback, or, even better, apply to be in the beta testing program. Once they have taken some positive action such as filling out an application and checking the box that says "I agree to send feedback and bug reports promptly," many more people will do so in order to be consistent.
- Don't think you can get through a full beta cycle in less than eight to ten weeks. I've tried; lord help me, it just can't be done.
- Don't expect to release new builds to beta testers more than once every two weeks. I've tried; lord help me, it just can't be done.
- Don't plan a beta with fewer than four releases. I haven't tried that because it was so obviously not going to work!
- If you add a feature, even a small one, during the beta process, the clock goes back to the beginning of the eight weeks and you need another 3-4 releases. One of the biggest mistakes I ever made was adding some whitespace-preserving code to CityDesk 2.0 towards the end of the beta cycle which had some, shall we say, unexpected side effects that a longer beta would have fleshed out.
- Even if you have an application process, only about one in five people will send you feedback anyway.
- We have a policy of giving a free copy of the software to anyone who sends any feedback, positive, negative, whatever. But people who don't send us anything don't get a free copy at the end of the beta.
- The minimum number of serious testers you need (i.e., people who send you three page summaries of their experience) is probably about 100. If you're a one-person shop, that's all the feedback you can handle. If you have a team of testers or beta managers, try to get 100 serious testers for every employee that is available to handle feedback.
- Even if you have an application process, only one out of five testers is really going to try the product and send you feedback. So, for example, if you have a QA department with 3 testers, you should approve 1500 beta applications to get 300 serious testers. Fewer than this and you won't hear everything. More than this and you'll be deluged with repeated feedback.
- Most beta testers will try out the program when they first get it, and then lose interest. They are not going to be interested in retesting it every time you drop them another build unless they really start using the program every day, which is unlikely for most people. Therefore, stagger the releases. Split your beta population into four groups and each new release, add another group that gets the software, so there are new beta testers for each milestone.
- Don't confuse a technical beta with a marketing beta. I've been talking about technical betas, here, in which the goal is to find bugs and get last-minute feedback. Marketing betas are prerelease versions of the software given to the press, to big customers, and to the guy who is going to write the Dummies book that has to appear on the same day as the product. With marketing betas you don't expect to get feedback (although the people who write the books are likely to give you copious feedback no matter what you do, and if you ignore it, it will be cut and pasted into their book).
Source:http://www.joelonsoftware.com/articles/BetaTest.ht
QUOTE:
S0UTHERN_C0MF0RT wrote:
Southern_Drunk wrote:
S0UTHERN_C0MF0RT wrote:
Good thread. It can really help the unknowledged people who want to be beta testers.Yup, so hopefully out of 100 people, maybe well get 80 good testers.
Whoever gets the beta better do their job correctly. If MAG is glitchy when it releases, we will know who to blame
Yeah, the developers. Beta testers will find & report issues, as will QA testers that work for the developing company (Zipper) and for the publisher (Sony) -- It's up to the developer to fix those issues.
A lot of the issues with SOCOM: Confrontation were found by QA Internals @ Slant Six, and Private Beta Testers (including Pictures, Videos, Great write ups & Detail on issues that would pass for a college thesis for gods sake)
What got fixed? Well, it was up to the developer to handle the issues after that.
- last edited on by
Ascalon
TheCraZyCloWn wrote:
FEEDBACK IS KEY, WHETHER IT BE POSITIVE OR NEGATIVE, IT HELPS THE DEVELOPERS. MOST TESTERS IGNORE THIS PROCESS OF THE BETA TESTING.HERE ARE SOME TIPS FOR EVERONE INCLUDING ZIPPER
Beta Explained By Wikipedia.com
"Beta" is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.
A "beta version" is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price, but act as free testers.
Beta versions test the supportability of the product, the go-to-market messaging (while recruiting Beta customers), the manufacturability of the product, and the overall channel flow or channel reach.
Beta version software is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access. As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet.
Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product. Only software issues, or bugs and unimplemented features will be addressed.
Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.
An example of a major public beta test was when Microsoft started releasing regular Windows Vista community technology previews (CTPs) to beta testers in January 2005. The first of these was build 5219. Subsequent CTPs introduced most of the planned features, as well as a number of changes to the user interface, based in large part on feedback from beta testers. Windows Vista was deemed feature complete with the release of build 5308 CTP, released on February 22, 2006, and much of the remainder of work between that build and the final release of the product focused on stability, performance, application and driver compatibility, and documentation.
When a beta becomes available to the general public it is often widely used by the technologically savvy and those familiar with previous versions as though it were the finished product. Usually developers of freeware or open-source betas release them to the general public while proprietary betas go to a relatively small group of testers. Recipients of highly proprietary betas may have to sign a non-disclosure agreement. A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.
As the Internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". [1] Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser to the public and calling them "beta" releases. In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production-level [2]. It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006. This technique may also allow a developer to delay offering full support and/or responsibility for remaining issues. In the context of Web 2.0, people[who?] even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate such as the Halo 3 public beta.
Google Definitions:
- Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the ...
en.wikipedia.org/wiki/Beta_Testing- Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service ...
en.wikipedia.org/wiki/Beta-testing- Testing of a release of a software product conducted by customers.
www.software-testing-outsourcing.com/glossary.html- Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. ...
thiyagarajan.wordpress.com/glossary/- The process of testing and improving unfinished software. Beta testing is most useful when the testers aren't the original programmers and can ...
www.netc.org/openoptions/appendices/glossary.html- testing when development and testing are essentially completed and final bugs and problems need to be found before final release. ...
www.techinterviews.com/- rigorous testing across platforms and browsers on beta sites to resolve any outstanding issues or bugs.
loetus.com/glossary.html- A test for a computer-related product prior to commercial release. Beta testing is the last stage of testing and normally can involve sending the ...
www.s3co.com/glossary/
Top Twelve Tips for Running a Beta TestTuesday, March 02, 2004Here are a few tips for running a beta test of a software product intended for large audiences -- what I call "shrinkwrap". These apply for commercial or open source projects; I don't care whether you get paid in cash, eyeballs, or peer recognition, but I'm focused on products for lots of users, not internal IT projects.
Source:http://www.joelonsoftware.com/articles/BetaTest.ht
- Open betas don't work. You either get too many testers (think Netscape) in which case you can't get good data from the testers, or too few reports from the existing testers.
- The best way to get a beta tester to send you feedback is to appeal to their psychological need to be consistent. You need to get them to say that they will send you feedback, or, even better, apply to be in the beta testing program. Once they have taken some positive action such as filling out an application and checking the box that says "I agree to send feedback and bug reports promptly," many more people will do so in order to be consistent.
- Don't think you can get through a full beta cycle in less than eight to ten weeks. I've tried; lord help me, it just can't be done.
- Don't expect to release new builds to beta testers more than once every two weeks. I've tried; lord help me, it just can't be done.
- Don't plan a beta with fewer than four releases. I haven't tried that because it was so obviously not going to work!
- If you add a feature, even a small one, during the beta process, the clock goes back to the beginning of the eight weeks and you need another 3-4 releases. One of the biggest mistakes I ever made was adding some whitespace-preserving code to CityDesk 2.0 towards the end of the beta cycle which had some, shall we say, unexpected side effects that a longer beta would have fleshed out.
- Even if you have an application process, only about one in five people will send you feedback anyway.
- We have a policy of giving a free copy of the software to anyone who sends any feedback, positive, negative, whatever. But people who don't send us anything don't get a free copy at the end of the beta.
- The minimum number of serious testers you need (i.e., people who send you three page summaries of their experience) is probably about 100. If you're a one-person shop, that's all the feedback you can handle. If you have a team of testers or beta managers, try to get 100 serious testers for every employee that is available to handle feedback.
- Even if you have an application process, only one out of five testers is really going to try the product and send you feedback. So, for example, if you have a QA department with 3 testers, you should approve 1500 beta applications to get 300 serious testers. Fewer than this and you won't hear everything. More than this and you'll be deluged with repeated feedback.
- Most beta testers will try out the program when they first get it, and then lose interest. They are not going to be interested in retesting it every time you drop them another build unless they really start using the program every day, which is unlikely for most people. Therefore, stagger the releases. Split your beta population into four groups and each new release, add another group that gets the software, so there are new beta testers for each milestone.
- Don't confuse a technical beta with a marketing beta. I've been talking about technical betas, here, in which the goal is to find bugs and get last-minute feedback. Marketing betas are prerelease versions of the software given to the press, to big customers, and to the guy who is going to write the Dummies book that has to appear on the same day as the product. With marketing betas you don't expect to get feedback (although the people who write the books are likely to give you copious feedback no matter what you do, and if you ignore it, it will be cut and pasted into their book).
ml
re copy the thing copy in HTML not graphic then you will get the picture as well
