The Big Bang Model

The Big Bang is built upon three main tenets:

1. the universe used to be very hot
2. the universe used to be very dense
3. the universe is expanding (which is why it isn't so hot or dense anymore)

Note that the basic Big Bang Model does NOT say anything about the following questions:

• will the universe collapse again, or expand forever?
• is space curved or flat?
• how old is the universe?
• what is the matter density in the universe?
• what about dark matter?
• is there some mysterious "repulsive" force on large scales?
• how did galaxies form?

Some of these questions all depend upon the values of certain parameters in the model, which we may derive from observations. Others have nothing to do with the Big Bang itself.

Our understanding of the laws of nature permit us to track the physical state of the universe back to a certain point, when the density and temperature were REALLY high. Beyond that point, we don't know exactly how matter and radiation behave. Let's call that moment the starting point. It doesn't mean that the universe "began" at that time, it just means that we don't know what happened before that point.

One of the primary successes of the Big Bang theory is its explanation for the chemical composition of the universe. Recall that the universe is mostly hydrogen and helium, with very small amounts of heavier elements. How does this relate to the Big Bang?

Well, a long time ago, the universe was hot and dense. When the temperature is high enough (a few thousand degrees), atoms lose all their electrons; we call this state of matter, a mix of nuclei and electrons, a fully-ionized plasma. If the temperature is even higher (millions of degrees), then the nuclei break up into fundamental particles, and one is left with a "soup" of fundamental particles:

• protons
• neutrons
• electrons

Now, if the "soup" is very dense, then these particles will collide with each other frequently. Occasionally, groups of protons and neutrons will stick together to form nuclei of light elements ... but under extremely high pressure and temperature, the nuclei are broken up by subsequent collisions. The Big Bang theory postulates that the entire universe was so hot at one time that it was filled with this proton-neutron-electron "soup."

But the Big Bang theory then states that, as the universe expanded, both the density and temperature dropped. As the temperature and density fell, collisions between particles became less violent, and less frequent. There was a brief "window of opportunity" when protons and neutrons could collide hard enough to stick together and form light nuclei, yet not suffer so many subsequent collisions that the nuclei would be destroyed. This "window" appeared about three minutes after the starting point, and lasted for a bit less than a minute.

Which nuclei would form under these conditions? Experiments with particle colliders have shown us that most of the possible nuclei are unstable, meaning they break up all by themselves, or fragile, meaning they are easily broken by collisions

Helium (the ordinary sort, with 2 protons and 2 neutrons) is by far the most stable and robust compound nucleus. Deuterium (one proton and one neutron) is easily destroyed, and so is helium-3 (2 protons, one neutron).

So, it seems that this period of hot, dense plasma would create a lot of helium. Could it create other, heavier elements, too?

Detailed models of Big Bang nucleosynthesis predict that the brief "window of opportunity" lasted only a minute or two. After that, about three and a half minutes after the starting point, the temperature and density dropped so much that collisions between particles were rare, and of such low energy that the electric forces of repulsion between positively-charged nuclei prevented fusion. The result is

• lots of hydrogen
• some helium (ordinary helium-4)
• tiny bits of deuterium
• tiny bits of lithium
• not much else

Testing Plan Template

Project Overview

(Optional) In this section, briefly discuss the project background and objectives. The appropriate information can be copied from the Project Definition document.

Testing Risks

Testing risks are circumstances and events that may occur before or during testing that would have an adverse impact on the testing process. For each high- and medium-level risk, determine what activities you will do to ensure that the risk does not occur. These risk plan activities should also be moved to the project workplan.

Testing Risk	Level (H/M/L)	Risk Plan
Example The team is not familiar with the Web testing tools we will be using on this project.	H	· Try to find at least one person who has used the tools before. · Send at least two team members to formal training. · Set up follow-up training sessions to cross-train the rest of the developers.

Testing Schedule

This section contains a summary of the overall testing schedule. It is not at the activity level, but it should contain more detail than the major milestones included as a part of the Testing Strategy.

Testing Milestone/Events	Date Started	Date Completed
Example
Testing Strategy	05/15/YYYY	05/31/YYYY
Testing Plan	06/01/YYYY	06/30/YYYY
Unit Testing	08/15/YYYY	10/10/YYYY
—Test scripts turned in to project manager		10/10/XXXX
Integration Testing
—Integration coordinators assigned	09/15/YYYY	09/23/YYYY
—Integration testing	10/01/YYYY	11/01/YYYY
—Integration tests approved and scripts turned in	10/20/YYYY	11/01/YYYY

Unit Testing Design

Unit testing is the first and most basic level of testing. The testing focuses on individual components and is usually performed by the person who developed the component.

Person Responsible

Define the person responsible for the unit testing.

Person(s) Approving

Define the person(s) or organization responsible for approving individual unit tests and for validating that the component is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the unit test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc. (A formal validation may not be needed for unit testing.)

Forms Used

Check the TechRepublic download library for unit test templates available in the future.

Integration Testing Design

Integration testing involves combining the individual components into the complete solution. The purpose is to test the interfaces between the various components and to ensure that the entire solution works as a whole according to the business requirements.

Person Responsible

Define the person responsible for the integration testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the integration test and for validating that the group of components is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the integration test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for integration test templates available in the future.

System Testing Design

System testing is the most important and complex of the testing stages and can consist of multiple subtests. System testing validates the overall requirements of the solution in terms of quality, performance, and functionality. The system test may include subtests such as the following:

· Requirements validation ensures that the solution satisfies the documented business requirements.

· Stress testing proves that the solution can handle heavy volumes of data, transactions, concurrent users, etc.

· Security testing ensures that the proper level of security and internal controls are in place.

· Disaster-recovery testing shows the solution’s ability to be recovered in case of disaster or massive failure.

· Usability testing determines how well the user will be able to use and understand the application. It identifies areas of poor human factors design that may make the system difficult to use.

· Procedures validation determines whether the user procedures and overall documentation is accurate and understandable.

Person Responsible

Define the person or group responsible for the system testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the system testing and for validating that the solution is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the system test environment, including location, equipment needed, software or tools used, etc. Many tools, processes, and locations may be needed for system testing that will not be used elsewhere on the project.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for system test templates available in the future.

Acceptance Testing Design

Acceptance testing is designed for the customer to prove that the solution meets the original business requirement. In many cases, the customer is responsible for this testing since when the solution is completed successfully, it is expected that the customer will approve and accept it. Customers need to test the solution as they would expect to use it in production and then work with the project team to validate that the results come out as expected.

Person Responsible

Define the person or group responsible for the acceptance testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the acceptance testing and for validating that the solution is ready to be moved into production. This level of approval should signify customer acceptance of the completed solution.

Test Environment

Describe any noteworthy features of the acceptance test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for acceptance test templates available in the future.

Optional Sections

You can add the following sections to the Testing Strategy if they provide more perspective and value to the reader or if the information is needed within your company.

Testing Methodology

Describe any specific methodology or standards that will help the reader understand the rationale behind each part of the Testing Plan.

Testing Assumptions

Document any assumptions surrounding the testing plan.

· Assumption #1

· Assumption #2

· Assumption #3

· Etc.

Testing Metrics

Describe any metrics you will capture as part of the testing process, such as total components tested, total defects per testing event, average time for defect correction, total number of hours spent on testing, total cost of testing, etc.

Testing Strategy Template

Introduction

One of the basic principles of the testing process is to plan for testing early in the development life cycle. For large projects, this starts in the analysis phase with the formulation of the Testing Strategy, which you later translate into the lower-level Testing Plan.

The Testing Strategy provides overall guidance and direction for the rest of the testing process. Preparing a Testing Strategy helps the project team think through the work at a high level, concentrating on the requirements of the testing events, the approach that will be used, and the resources necessary to complete the testing.

Testing stages in the Testing Strategy include:

· Unit Testing—The first testing is to ensure that the component meets expectations in terms of features and functionality. In almost all cases, the person that develops the component also does unit testing.

· Integration Testing—After the components have been unit tested, they are executed together. This testing verifies that the interfaces work correctly and that data is processed in its entirety as expected.

· System Testing—This is where the most rigorous testing takes place, to ensure that the solution meets the technical and environmental needs of the customer and that the solution behaves as it should. Many individual tests can be performed under the system test umbrella. These include stress testing, usability testing, security testing, performance testing, recovery testing, and multisite testing.

· Acceptance Testing—This is the final set of tests to ensure that the solution meets the business objectives and requirements. The business customers may be responsible for this testing. It requires their active participation to work with the solution, as they will when it moves to production status.

This template is designed to help you draft your own Testing Strategy. Note that the shaded text in this template is explanatory only; you should delete these comments and the example text from your version of the document.

Project Overview

Briefly discuss the project background and objectives. The appropriate information can be copied from the Project Definition document.

Business Risks

These are high-level risks of the project that will affect the overall testing strategy. For instance, the risk of doing business on the Internet may drive the need for rigorous system tests of firewalls, technical architecture, and security. The risks can be classified in terms of high, medium, and low, depending on the nature and impact of the problem. For each high and medium risk, identify which elements in the overall testing approach will help ensure that the potential problem does not occur.

Risk Area	Level (H/M/L)		Risk Plan
Example Since this is our first system doing e-commerce on the Internet, there is a concern that security will not be tight enough.		H	· Rigorously test security with our initial partners. · Bring in subject matter experts to validate our security design. · Set up tests for people to try to break in to the system or get around security features.

Testing Milestones

This section contains the overall schedule at a major milestone level. The associated details will be broken down further in the Testing Plan. Since this document is created in the analysis phase, these dates are subject to later revision.

Testing Milestone	Date Completed
Example
Testing Strategy	06/01/YYYY
Testing Plan	07/01/YYYY
Unit Testing	10/01/YYYY
Integration Testing	11/01/YYYY

Testing Environment

Think through the technologies and facilities needed for the testing process. If the overall testing environment needs are understood up front, it will be easier to put the environment in place after the Test Plan is created. In addition, some parts of the environment may not be available and may need to be planned for and acquired well in advance.

Example

The developers will conduct unit testing from their offices, with no additional software required. Integration testing will also be conducted in the developer’s workspace, based on who is assigned to coordinate the major system components. System testing and user testing will be coordinated in the project war room. The war room will have six desktop machines installed, with Internet access and our standard testing tools. For system testing, we will also need access to the servers in the operations center….

Testing Approach

Describe the testing process at a high level, including how you will conduct unit testing, integration testing, system testing, and acceptance testing. This is where fundamental decisions are made about the type of testing that makes sense for your project. For instance, if you are implementing a packaged solution, the approach may start in system testing, with the vendor providing close support. If you are doing iterative development cycles, the testing approach will reflect this overall development life cycle. For system testing, define the major testing events such as stress testing, security testing, disaster-recovery testing, usability testing, and response-time testing.

Unit Testing Approach

Describe the approach for conducting unit testing to ensure that each component works according to specifications.

Example

Each developer is responsible for unit testing his or her programs as they are completed. The project manager will consider each assigned component to be completed when it has been developed and successfully unit tested. The developers will keep all test data, along with a document stating the expected results, so that these same cases can be used in the integration tests….

Integration Testing Approach

Integration testing validates that the individually tested components work correctly together.

Example

Specific developers will be assigned to coordinate the integration tests. The project manager will assign the specific parts of the system to be tested. The prior test cases created during unit testing will be used as the basis for integration testing, with new test cases added to fully test all the interfaces and dependencies. All databases should be loaded with a set of test data so that all logic can be initially tested. Reports will be created from the files that would normally be sent to our customers so that the data can be validated….

System Testing Approach

System testing is the time for fully testing all features and functions and for ensuring that production conditions are fully tested. This can include stress testing, requirements validation, security testing, customer testing, testing of the training material, etc.

Example

System testing will include many separate tests to ensure that the application will work as expected in production. The test cases from integration testing will be brought forward as the basis for system testing. During system testing, we will conduct a stress test to generate the number of transactions we feel are normal for one day and feed them through the online system within an hour. This will be in an environment that mirrors the ultimate production environment. As many tests as possible will be conducted with a subset of our trading partners, so that we can simulate the actual Web transactions going from our application to our partner’s environment….

Acceptance Testing Approach

Describe the approach for conducting business unit customer acceptance testing to ensure that the system satisfies requirements for operational functionality, procedures, and usability.

Example

The customers will have access to all of the test data that has been generated previously, but they will ultimately be responsible for generating whatever sets of transactions are required to test the system to their satisfaction. For all intents and purposes, the system will be placed in a production status, including hardware and software. They will coordinate testing with the partners as well and ensure that the resulting transactions are as they expect….

Optional Sections

The following sections can be added to the Testing Strategy if it provides more perspective and value to the reader or if the information is needed within your company.

Business Assumptions

Document any assumptions surrounding the testing strategy.

· Assumption #1

· Assumption #2

· Assumption #3

· Etc.

Testing Objectives

The project should have a set of overall objectives to be achieved. Usually these overall objectives can be broken down into a specific set of testing objectives that will be accomplished through the testing process. You can state these in terms of the overall testing results, or you can break them down into objectives for the unit, integration, system, and acceptance testing. (Remove this comment section from final document.)

Testing Organization

In this section, define the high-level organization structure for testing. This might be especially helpful for large projects where many people will be involved in various aspects of the testing process. It also would be good if an independent testing organization has responsibility for portions of the testing process. An organization chart works well here, or you can just list the various groups involved. At this point, you may not have specific names, but you should know what groups will be needed.

Testing Event	Organizations/People Involved
Example
Unit Testing	Developers
Integration Testing	Developers, DBAs, project manager
System Testing	Testing organization, developers, partners, server administration,…
Acceptance Testing	Developers, customers,…