| Good Testers | Good Developers |
|---|---|
| Get up to speed quickly | Thorough understanding |
| Domain knowledge | Knowledge of product internals |
| Ignorance is important | Expertise is important |
| Focus on what can go wrong | Focus on how it can work |
| Comfortable with conflict | Avoid conflict |
| Report problems | Understand problems |
Friday, July 31, 2009
Difference between Good Tester and Good Developer
Sunday, July 26, 2009
Software Testing Life Cycle
Software testing life cycle identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.
Software Testing Life Cycle consists of six (generic) phases:
* Test Planning,
* Test Analysis,
* Test Design,
* Construction and verification,
* Testing Cycles,
* Final Testing and Implementation and
* Post Implementation.
Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing – Manual, Automated and Performance.
Test Planning
This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.
Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.
Test Analysis
Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.
Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.
Test Design
Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.
Construction and verification
In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.
Testing Cycles
In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).
Final Testing and Implementation
In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.
Post Implementation
In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage.
Software Testing Life Cycle
Planning Phase
Activities: Create high level test plan
Outcome: Test plan, Refined Specification
Analysis Phase
Activities: Create detailed test plan, Functional Validation Matrix, test cases
Outcome: Revised Test Plan, Functional validation matrix, test cases
Design Phase
Activities: test cases are revised; select which test cases to automate
Outcome: evised test cases, test data sets, sets, risk assessment sheet
Construction Phase
Activities: scripting of test cases to automate,
Outcome: test procedures/Scripts, Drivers, test results, Bugreports.
Testing cycles Phase
Activities: complete testing cycles
Outcome: Test results, Bug Reports
Final testing Phase
Activities: execute remaining stress and performance tests, complete documentation
Outcome: Test results and different metrics on test efforts
Post implementation Phase
Activities: Evaluate testing processes
Outcome: Plan for improvement of testing process
Software Testing Life Cycle consists of six (generic) phases:
* Test Planning,
* Test Analysis,
* Test Design,
* Construction and verification,
* Testing Cycles,
* Final Testing and Implementation and
* Post Implementation.
Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing – Manual, Automated and Performance.
Test Planning
This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.
Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.
Test Analysis
Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.
Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.
Test Design
Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.
Construction and verification
In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.
Testing Cycles
In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).
Final Testing and Implementation
In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.
Post Implementation
In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage.
Software Testing Life Cycle
Planning Phase
Activities: Create high level test plan
Outcome: Test plan, Refined Specification
Analysis Phase
Activities: Create detailed test plan, Functional Validation Matrix, test cases
Outcome: Revised Test Plan, Functional validation matrix, test cases
Design Phase
Activities: test cases are revised; select which test cases to automate
Outcome: evised test cases, test data sets, sets, risk assessment sheet
Construction Phase
Activities: scripting of test cases to automate,
Outcome: test procedures/Scripts, Drivers, test results, Bugreports.
Testing cycles Phase
Activities: complete testing cycles
Outcome: Test results, Bug Reports
Final testing Phase
Activities: execute remaining stress and performance tests, complete documentation
Outcome: Test results and different metrics on test efforts
Post implementation Phase
Activities: Evaluate testing processes
Outcome: Plan for improvement of testing process
Wednesday, July 15, 2009
Control & Data Plane in networking
Routers (also known as layer-3 switches) perform two basic functions:
- Forward packets between interfaces (layer-3 switching).
- Exchange reachability information between routers (routing).
There is no conceptual difference between a router and a layer-3 switch. Layer-3 switching is a product of creative vendor marketing.
Switching (packet forwarding) is performed in the data (forwarding) plane. Routing (exchange of routing information) is performed in the control plane. The information collected with routing protocols (for example, ) is used to build topology databases (also known as link state databases or routing databases depending on the terminology of the routing protocol). The routing protocols extract best paths from the protocol-specific data structures and insert them in the routing table. The routing table might contain recursive information and is thus not suitable for fast packet forwarding. The routers use two mechanisms to speed up packet forwarding:
- They can cache the results of routing table lookup for recently used destinations (fast switching in Cisco IOS terminology).
- They can pre-compute the actual forwarding data for every destination and store them in the forwarding table that can be directly used by the data plane.
Figure 1 illustrates the relationships between the control and the data planes.
Processing of inbound packets
In most router implementations, the data plane receives and processes all inbound packets and selective forwards packets destined for the router (for example, routing protocol updates) or packets that need special processing (for example, IP datagrams with IP options or IP datagrams that have exceeded their TTL) to the control plane.
The control plane might pass outbound packets to the data plane or use its own forwarding mechanisms to determine the outgoing interface and the next-hop router (for example, when using the local policy routing).
Figure 2 shows typical packet flow in a router.
Common architectures
In devices with distributed (multiple CPU) architecture, the central CPU implements the control plane (most routing protocols are designed to operate on a single control plane node), while the CPUs on linecards implement distributed high-speed data plane.
High-speed layer-3 switches commonly implement data plane with special hardware (for example, Ternary Content Addressable Memory; TCAM).
Single-CPU devices that perform layer-3 switching in software usually implement the data plane in the interrupt code (high-priority process-independent code in the kernel of the operating system) to minimize the overhead associated with forwarding of individual packet. For example, Cisco IOS implements the Cisco Express Forwarding (CEF) and the fast switching in the interrupt code.
Subscribe to:
Posts (Atom)
