Soliciting features from your pre-release / beta testers to get them more involved ..

An active set of pre-release participants can be very useful for a product team. Typically why does a team use a pre-release program ? Following are some of the reasons:
- Pre-release participants provide external validation of the features of the application, verifying whether the features that have been built into the product are deemed useful for potential customers. When a team builds a feature, they do so on the basis of market research or other inputs, and then through a process of design and working with the user interface team, they design a solution that is supposed to meet the needs of customers. You can show the workflow to research user bases early, but the validation is only when people get their hands on the product and test it out. And this is extremely valuable, since this sort of validation comes in early enough that there can be changes made in the product to incorporate such feedback.
- Many of these pre-release participants would have been there for multiple versions of the product, and as a result, they have a good knowledge of the product with the advantage that they also have knowledge of actual customer workflows, and hence can quickly suggest some great ways of improving the features. It is upto the product team to take such improvements or not, but I have seen cases where this kind of interaction with the pre-release participant helped the product team learn about some workflows that they were not aware of before. This kind of knowledge is invaluable and the product team should ensure that such participants remain committed to contributing to the pre-release program.
- If you consider the case of video products or imaging products or products that are used for writing to CD/DVD, there are a huge range of devices out there. It is practically impossible for a product team to obtain as well as test these range of devices but when you have a large number of pre-release participants, you can be sure that the total number of devices that you are able to test with is more than what you could obtain on your own, and this gives increased confidence on the part of the product team in the product. As another example, we had a case whereby the product was importing video clips, and there are a large number of video formats that can be used. In one specific format, the embedding of audio with the video clip was crashing the application, and this was not happening with other formats. We would never have found this issue, it was reported by a pre-release participant.

With all these, what else can you do with a pre-release participant. I had earlier mentioned that you need to engage with these valuable testers, and engage with them early. I have seen teams using these participants earlier in the program, even working with them during the feature requirement and feature workflow design process, and even making modifications or tweaks based on the inputs that were received. As a result, there were valuable improvements in the features as well as ensuring that the pre-release participants became very involved with the product. A spin off was that many of them became more active in the user forums and helped some of the more simple customer issues.

Working early with providers of external components to test out with your software and verify that everything is fine ..

If you have been reading some of the posts that I have written, there are several dealing with working with those groups within or outside your organization that make the components that you use in your software application (with the assumption that most medium-to-heavy complex products use a number of components inside so as to get some great functionality without having to write all that amount of code themselves). Now, there can be several problems when dealing with components:
- You may have no control about the features being built into the next version of the component and whether those features that are indeed built in work well with the product.
- Your features or defects don't fit into the priority of the component and the schedule of the component does not work for you
- The quality of the component that is delivered to you is low enough that you keep finding defects in the component and are unable to accept the component
- And some more ..

And yet most software applications will use components. For example, there makes no sense for individual applications to write code that replicates the connection to media such as DVD's/Blu Ray, etc. Instead, it makes sense to use a ready-made component to do this; and in most cases, the interaction with the component does not cause significant problems.
But there are steps you can take to ensure that you have as much control over your fortune while integrating with the component:
- You retain in regular touch with the component team, both at manager level and at individual team level; this includes a standing meeting that happens at periodic intervals
- Have discussion with the component team about your interactions with the defect database, defect assignment, and a Service Level Agreement about how to ensure that defects are seen early and fixed early
- This next step may seem somewhat resource heavy, but it is very useful. You need to ensure that you have a request pending with the external team that they provide you this component before it is ready; that is, you get regular copies of the component during the development phase. This ensures that you find problems early, rather than later when there are problems found near the release date of the component, and is pretty much almost impossible to fix such defects. Once you are getting the component on a regular basis, you can work out with the QE team about an optimization method to ensure that these deliveries of the component are all tested and any issues are sent off to the team that is making the component, so that these defects or even feature requests can be handled by the component team.

Phase 4 of Unified Process Life cycle - Transition

Unified process is one of the best development processes we have of the iterative and incremental form. The whole unified process is completed in four phases which have been mentioned below:

1. Inception phase
2. Elaboration phase
3. Construction phase and lastly
4. Transition phase

This whole article is all about the last phase i.e., the transition phase. In this whole article we are going to discuss about the last phase. 

What is a Transition Phase?

- The final phase of the unified process i.e., the transition phase involves the deployment of the system for targeting the customers.

- The feedback that is collected on the account of the previous releases helps in further refining or improving the software system or application. 

- It can also be decided over the further functionality that have to be added to the software system or application under development to make it much better. 

- Transition phase like all of the preceding three phases is composed of several timed iterations that are time boxed. 

- Apart from just targeting the users, the transition phase also involves user training and the system conversions. 

- The transition phase has been named so because it is in this phase that the transition of the whole system from development to production takes place and software is made available to the users. 

- Along with the end users in some cases the maintainers might also be treated. 

- This phase also witnesses the beta testing of the software system or application so that it is validated against the expectations of the end users. 

- A certain quality level is set in the phase i.e., in the inception phase which is tested in against by the quality of the software system or application in the transition phase. 

- The point at which all the objectives are met is called the “product release milestone”. 

- At this point the product is declared finished and the development is also declared to be complete. 

- The unified process is quite a robust software process that is meant for addressing the development as well as the production needs of the users and the customers. 

- We need a software development process that serves the scope of our real world quite well and provides us with a balanced perspective of the alternative programming methodologies available from all around the field. 

- In this transition phase, if there are any legacy systems that you are going to replace, then your whole software system or application is operated in parallel with those legacy systems. 

- This leads to the conversion of the legacy data bases and the systems in to an improved one that supports your new software system or application. 

Goals of transition Phase

The transition phase has got three main goals as mentioned below:

1.Evolving the final product baseline or the production base line of the software system or the application.

2.Training the materials for the software system or application.

3.Creation of the documentation which is inclusive of all the user manuals, operations documentation and the support documentation.

Issues faced during Transition Phase

- This phase is concluded with the product release milestone. 

- Achieving this milestone is not so easy since you have to satisfy all the expectations of the end users and also justify the actual expenditures against the planned expenditure. 

- Issues such as finishing the features that were postponed usually arise after the product has been transited to the end users or customers. 

- The production baseline ought to be mature enough to be deployed in the end user domain. 

- The operational data bases are also converted and the final product is released for marketing, distribution and sales team. 

What are different characteristics of beta testing?

Beta testing is carried out after the successful completion of the alpha testing. As alpha testing can be regarded as the internal form of user acceptance testing, similarly beta testing can be regarded as the external form of the user acceptance testing.

- A few versions of the finished software application are released. These testing versions are called the beta versions of the software system.
- These beta versions of the software system are released to a certain limited audience.
- The audience consists of the people who are not a part of the programming team or the software development team.

- This is done so because the more number of people, there will be more exploitation of the software. This is done to ensure that the number of bugs is minimum.
- Sometimes, the software manufacturer company may decide to release the beta versions of the software to a huge open public so as to get more feedback on the quality of the software application.
- Alpha testing is the internal pilot test and beta testing is called the external pilot test.

- Beta testing is carried out on only on the software that has successfully passed the first level unit testing, integration testing, system testing, internal pilot test and removal of the faults or the bugs.
- Beta testing is carried out because the finished software product may still have some minor errors and bugs. In order to find them, user participation is very much needed.
- The beta versions are released to some selected customers only to simulate a normal execution environment for the software application to make it run normally and to spot the problems in such an environment.

- Beta testing phase starts when the software development is complete.
- Beta testing can be thought of as a way of incorporating usability testing.
- The process of releasing the beta versions to the selected customers and other suitable audience is known as beta release.

- Usually after the development of the software system, this is the first time for which the software becomes available to the public.
- The audience selected for carrying out beta testing on the beta version of the software system is called beta testers.
- Beta testers are generally the prospective customers of that particular software manufacturing company who are willing to test the software system free of charge. As a reward for this, they are given the completed and finished software free of cost or sometimes at a reduced price.

- The beta testing phase is known by many names such as prototype, preview, early access or technical preview (TP).
- One is normal beta testing, there’s one more kind of called perpetual beta testing.
- In perpetual beta testing, new features and functionalities are continually added to the software system and therefore, not declaring the beta version as the final release of the company.

- In the context of software development, beta testing is considered as the second phase of the software testing stage.
- Beta testing is nothing but the pre release testing. Beta versions provide a preview of the final release of the firm.
- Alpha testing and beta testing collectively form the acceptance testing. So we can say that the beta testing is the second phase of the acceptance testing.

- Beta testing is conducted in the customer environment by multiple customers.
- Beta testing also ensures that the behavior of the software system is same in the development environment and in the customer environment.
- Beta testing is time consuming and may take weeks and months. The whole application is installed in the customer environment and the development of the software system has been 100 percent completed.

Introduction to Validation testing? What is the validation criteria?

Validation tries to uncover errors, but the focus is at the requirements level, i.e. on the things that will be immediately apparent to the end user. It begins at the end of integration testing, when all individual modules are packaged and interface errors are uncovered and corrected. In validation testing phase, testing focuses on user visible actions and output that is user recognizable. The criteria of software entering into validation phase is that it functions in a manner that is reasonably expected by the customer.

In software requirements specification, there is a section called validation test criteria. Test plan lists out the tests to be conducted and a test procedure defines test cases. These plan and procedure are designed to ensure that all the functional requirements are satisfied, behavioral characteristics are achieved, performance requirements are attained, usability is met and documentation is done.

Configuration review ensures that all elements of software configuration are properly developed, cataloged and every necessary detail is given. It is also known as audit.

Alpha testing is done at developer's site. It does not happen at usual workplace. The real users are simulated by using these techniques and carrying out tasks and operations that a typical user might perform.

Beta testing is done at end user sites. The developer is not present. It is the live application of software in an environment that is not controlled by the developer. The end user records all the problems that he faces and reports to the developer.

Some best practices that contribute to improved software testing

There is always a serach for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The basic practices are like training wheels which you need to get started and when you take them off, you know ow to ride. The basic practices include:

- Functional Specifications
It is basically a development activity but it is also necessary for software functional test. It defines the external view of an object or procedure. It helps the test generation activity to move in parallel with code development. It helps in the clarity from designer's and an architect perspective.
- Reviews and Inspections
Software reviews and inspection provides a ten times gain in debugging process.
- Formal entry and exit criteria
This practice offers a careful management of software development process. Every process step has a precise entry and exit criteria defined by development process and management keeps a track of the movement from one stage to another.
- Functional test varaitions
This practice involves understanding how to write variations which refers to combination of input condition to yield a output and gain coverage to thoroughly test the function.
- Multi platform testing
Today products run on different platforms so the necessity arises of designing and testing the product for different platforms. This practice addresses aspects of multi platform development and testing.
- Internal betas
Beta means the product is released to few customers and their feedback is recorded. This practice deals with beta programs to best levarage it and reduce cost of external beta.
- Automated test execution
Using automated test execution, the amount of manual work is minimized and higher coverage is gained. This is the best practice which is well understood in some areas. This practice needs to levarage and then develop methods for areas where automation is not fully done.
- Beta programs
- Nightly builds
Nightly build captures frequent builds from changes that being promoted. Advantages include firstly, errors are captured quickly if major regression occurs. Secondly, regression tests can run in background. Thirdly, newer releases of software are available to developers and testers sooner.

What are steps involved in deriving test cases? What are Validation, Alpha, Beta testing? What are test metrics?

The steps in deriving the test cases using use cases are:
- Using the RTM, the use cases are prioritized. Importance is gauged based on the frequency with which each function of the system is used.
- Use case scenarios are developed for each use case. The detailed description for each use case scenario can be very helpful in later stage.
- For each scenario, take at least one test case and identify the conditions that
will make it execute.
- Data values are determined for each test case.

After system testing is culminated, validation testing is performed which consists of a series of black box tests. It focuses on user-visible actions and user-recognizable output.
Alpha and Beta Testing are a series of acceptance tests. Alpha testing is performed in a controlled environment normally at developer's site. In alpha testing, developers record all errors and usage problems while end users use the system. Beta testing is done at customer's site and developers are not present. In beta testing, end-users records all errors and usage problems.

The amount of testing effort needed to test object oriented software can be indicated by the metrics used for object-oriented design quality. These metrics are:
- Lack of Cohesion in Methods (LCOM)
- Percent Public and Protected (PAP)
- Public Access To Data Members (PAD)
- Number of Root Classes (NOR)
- Number of Children (NOC) and Depth of the Inheritance Tree (DIT)

Validation Phase - Beta Testing - Objectives

The beta testing is conducted at one or more customer sites by the end-user of the software. The beta test is a live application of the software in an environment that cannot be controlled by the developer. The software reaches beta stage when most of the functionalities are operating. The software is tested in customer's environment, giving the user an opportunity to exercise the software, find the errors so that they could be fixed before product release. Beta testing is a detailed testing and needs to cover all the functionalities of the product and also the dependent functionality testing. It also involves the user interface testing and documentation testing. Hence, it is essential that this is planned well and the task accomplished. The test plan document has to be prepared before the testing phase is started, which clearly lays down the objectives, scope of test, tasks to be performed and the test matrix which depicts the schedule of testing.

The objectives of beta testing is to:
- evaluate software technical content.
- evaluate software ease of use.
- evaluate user documentation draft.
- identify errors.
- report errors/findings.

The role of a test lead is to provide test instruction sheet that describes items such as testing objectives, steps to follow, data to enter, functions to invoke and to provide feedback forms and comments.
The role of a tester is to understand the software requirements and the testing objectives and carry out the test cases and report defects.