What comprises Test Ware Development : Test Strategy Continued...

Test ware development is the key role of the testing team. Test ware comprises of:

Test Strategy

Before starting any testing activities, the team lead will have to think a lot and arrive at a strategy.The following areas are addressed in the test strategy document:
- Test Groups: From the list of requirements, we can identify related areas, whose functionality is similar. These areas are the test groups. We need to identify the test groups based on the functionality aspect.

- Test Priorities: Among test cases, we need to establish priorities. While testing software projects, certain test cases will be treated as the most important ones and if they fail, the product cannot be released. Some other test cases may be treated like cosmetic and if they fail, we can release the product without much compromise on the functionality. This priority levels must be clearly stated.

- Test Status Collections and Reporting:
When test cases are executed, the test leader and the project manager must know where exactly we stand in terms of testing activities. To know where we stand, the inputs from the individual testers must come to the test leader. This will include, what test cases are executed, how long it took, how many test cases passed and how many failed etc. Also, how often we collect the status is to be clearly mentioned.

- Test Records Maintenance: When the test cases are executed, we need to keep track of the execution details like when it is executed, who did it, how long it took, what is the result etc. This data must be available to the test leader and the project manager, along with all the team members, in a central location.This may be stored in a specific directory in a central server and the document must say clearly about the locations and the directories.

- Requirements Traceability Matrix: Ideally, each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. In this matrix, the rows will have the requirements. For every document, there will be a separate column. So, in every cell, we need to state what section in HLD addressed in every single document, all the individual cells must have valid section ids or names filled in.

- Test Summary: The senior management may like to have a test summary on a weekly or monthly basis. If the project is very critical, they may need it on a daily basis also. It addresses what kind of test summary reports will be produced for the senior management along with the frequency.

Quick description - How does a Router work?

Here is a technical description of how a router works. This would make sense if you have already an understanding of the network protocols.
The layers 2 and 3 of the OSI model i.e. Data Link layer, is where the Ethernet protocol, MAC addresses and switches fit in.
Layer 3, the Network layer, is where the IP protocol, IP addresses and routers fit in. All traffic is sent from your computer, starting with Layer 7 (your network application) and going down to Layer 1 (physical). With the physical layer, the traffic is going across your network medium.
Traffic goes to a router only if it is not on your local LAN. Routers work primarily at Layer 3 but must understand Layers 1-3, at a minimum. Many routers understand traffic all the way up to Layers 4-7 in varying ways.
One of the tools a router uses to decide where a packet should go is a configuration table. A configuration table is a collection of information, including:
• Information on which connections lead to particular groups of addresses
• Priorities for connections to be used
• Rules for handling both routine and special cases of traffic
Internet data, whether in the form of a Web page, a downloaded file or an e-mail message, travels over a system known as a packet-switching network. In this system, the data in a message or file is broken up into packages about 1,500 bytes long which includes information on the sender's address, the receiver's address, the package's place in the entire message, and how the receiving computer can be sure that the package arrived intact. Each data package, called a packet, is then sent off to its destination via the best available route -- a route that might be taken by all the other packets in the message or by none of the other packets in the message.

A brief summary of design engineering

Design Engineering is a process used by software engineers which encompass the set of principles, concepts and practices that result in the development of a high quality system or product. Design Engineering is the point which actually has a great role in determining the quality of the software, and a careful review of the design process is useful in ensuring that the quality of the software remains high. Software design serves as the foundation for all software engineering steps that follow regardless of which process model is being employed. Without a proper design we risk building an unstable system – one that will fail when small changes are made (and we all know how likely small (or even big) changes can happen, one that may be difficult to test; one whose quality cannot be assessed until late in the software process, perhaps when critical deadlines are approaching and much capital has already been invested into the product. Making changes later down in the cycle to compensate for problems in the design process is not guaranteed to succeed, and is expensive.

Steps Involved In Design Engineering:

1. Identifying the need.
2. Defining the problem.
3. Conducting Research.
4. Narrowing Research
5. Analyzing set criteria
6. Finding alternative solutions
7. Analyzing possible solutions
8. Making a decision.
9. Presenting the product.
10. Communicating & selling the product.

During the design process the software specifications are transformed into design models that describe the details of the data structures, system architecture, interface, and components. Each design product is reviewed for quality before moving to the next phase of software development. At the end of the design process a design specification document is produced. This document is composed of the design models that describe the data, architecture, interfaces and components.