SPPM 6

• 
  TSP provides a defined operational process to guide engineers and managers through the team building steps.
• This process specifies the steps that is needed to establish an effective environment.
• Without specific guidelines,engineers must work out the details of team-building and team-working for themselves.
• TSP provides the operational process needed to form the engineering teams to establish an effective team environment.
• TSP is one of the series of methods that can help engineering teams,to establish an effective team environment.

·        LAUNCHING A TSP TEAM:

·         Day 1:

1.      Establish product and business goals.
2.     Assign roles and define team goals.
3.      Product development strategy.

            Day 2:

1.      Build top-down and next phase plans.
2.     Develop the quality plan.
3.     Build bottom-up and balanced plans.

Day 3:

1.      Conduct risk assessment.
2.      Prepare management briefing and launch report.

Day 4:

1.      Hold management review.
2.     Perform the launch postmortem.
3.      TSP process review.

STRUCTURE OF THE TSP:

                                                                                                   

• Before the members can participate on the TSP team, they must know how to do the disciplined work.
• PSP training includes how to make detailed plans,gathering and processing data.
• Engineering can be trained before they can participate in the TSP team.

TSP TEAM WORKING PROCESS.

Ø Leading the team.

Ø Process discipline

Ø Issue tracking

Ø Communication

Ø Management reporting.

Ø Maintaining the plan

SPPM 5

§     The PSP is the self-improvement process.

§     It helps to control,manage and improve the work you develop.

§     It is a structured framework of forms,guidelines and procedures for developing software.

§     PSP used to provide data that you need to make commitments.

§     The PSP  also provide the framework for understanding why you make errors and how best to find fix, and prevent them.

§  THE LOGIC OF THE SOFTWARE ENGINEERING DISCIPLINE

§     Software has become the critical part of many of the systems on which modern society depends.

§     Everyone seems to need more and better software.

§     The intuitive software development methods generally used today are acceptable only if there is no alternative.

§  USING DISCIPLINED DEVELOPMENT PROCESS

§      A defined process specifies precisely how to do something.

§     If we have not done such work before and we don’t have a definitely good process

§     Unfortunately without prior experience or a lot of guidance few of us would know precisely how to do the requirements work.

§  OPERATIONAL PROCESS

§      Most development, object to the idea of using the operational process.

§     We all object to being told how to do our job, particularly by someone who doesn't know as much about the work as we do.

§  DEFINING AND USING THE PERSONAL PROCESS

§     With the defined and the measured process not only will you know how well you are doing your job today, you will see how to improve  and to keep improving as long as you can develop software.

§  LEARNING TO USE A PERSONAL PROCESS

SPPM 2

      Functional requirements: -

                    These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

                    It may also state what the system should not do explicitly.

                   Describe the system function in detail, its inputs and outputs, expectations and so on.

                   Expressed in numerous ways:-

• LIBSYS:- able to search the database. able to read the document. provide unique ID. single interface. allows the user to download copies.

Requirements must be precise and should not be ambiguous.

Identify what the customer wants.

Changes to the previous requirements or new ones established.

Complete and consistent. complete means all services ought be defined. consistent in the sense there should be no contradictory definitions. 

Large system would lead to many mistakes and omissions; since there are numerous stake holders with different views; so we need deeper analysis.

Non functional requirements: -

              The non functional requirements are constraints on the services.

The constraints include 

•       Timing constraints. 
•       Development constraints.  
•       Standard constraints.      

Applied system as a whole.

1. Product 
2. Organizational
3. External.

Product in the sense behavior of the system

•  efficiency(include Performance and space)
• reliability
• usability
• portability.

Organizational include policies and procedures in an organization

• Delivery
• Implementation
• Standards.

External in the sense external factors

• Interoperability 
• Ethical
• Legislative.

Non functional requirements must be verifiable. 

Non functional requirements have goals.

Non functional requirements interacts with other functional and non functional requirements.

Metrics: -

• Speed. 
• Size.
• Ease of use.
• Reliability.
• Robustness.
• Portability.

SPPM 3

Three stages: - 

• measurements (attributes)
• analysis (current process assess)(weakness and bottleneck are identified)
• change

Characteristics of process: -

• understandability
• visible
• supportability
• reliability
• robustness
• maintainability

Process classification: -

• Informal process(prototypes or short time products)
• Managed process(large system or long time product )
• Methodological process( well understood domain)

Measurement: -

three classes: 

• time
• resources 
• event occurrence

Basili and Rom Bach proposed a measurement approach GQM

Goal: - what the organization is trying to achieve.

Reliability, productivity.

Questions: - goals-refinement.

eg. how effective assessment are made.

Metrics: - helps to answer the question.

Process analysis: -

Techniques

1. Questionnaire and interview
2. Ethnography techniques

Process change: - 

Making modification to the process.

Stages: -

1. Improvement identification
2. Improvement prioritization
3. process change introduction
4. process change training 
5. change tuning.

Regression Testing

REGRESSION TESTING

1. The word regress means to return to the previous.                                         

2. Regression testing refers to that portion of the test cycle in which a program q is tested to ensure that not only the newly added or modified code behaves correctly but also that code carried over unchanged from the previous version p continue to behave correctly.

3. Regression testing is also called as program "revalidation".

4. The term corrective regression testing refers to regression testing of a program obtained by making corrections

5. Regression testing is also needed when a subsystem is modified to generate a new version of an application.

REGRESSION TEST PROCESS:

Test revalidation/selection/minimization/prioritization   ------->2.Testsetup------>3.Test sequencing------->4.fault mitigation------>5.Output comparison------>6.Test execution

The steps in brief: -

1. Test revalidation/selection/minimization/prioritization:

->Test revalidation refers to the task of checking which test for p remain valid for q. Revalidation is necessary to ensure that only tests are applicable to q are used during regression testing.

->Test selection can be interpreted in several ways. Validation test must be redundant that they do not traverse any modified portions in q.

->Test minimization discards the tests seemingly redundant with respect to some criteria. for eg: if both t1 and t2 test function f in p, then one might decide to discard t2in favor of t1.

PURPOSE: reduce the number of tests

Test prioritization refers to the task of prioritizing test based on criteria. A set of tests become useful only a subset of tests can be executed due to resource constraints.

TEST SETUP:

->It refers to the process by which the application under test is placed in its intended or simulated, environment ready to receive data and able to transfer any desired output information.

->Test setup process and the setup itself are highly dependent on the application under test and its hardware and software environments.

TEST SEQUENCING:

->The sequence in which tests are input to an application may be concern.

->Test sequencing often becomes important for an application that has an internal state and is continuously running.

->Eg: ATM cash withdrawal.

TEST EXECUTION:

->Once the testing infrastructure has been setup, tests selected, revalidated and sequenced, it is time to execute them.

->The importance of a tool for test execution cannot be overemphasized.

Walk through

 $ Walkthrough and inspections are the integral part of static 

testing.

 $ Walkthrough is an informal process to review,any application-

related document.

 $ For eg:,requirements are reviewed using a process termed 

requirements walkthrough.

 $ Code is reviewed using code walk-through is also known as 

peer code review.

 $ A walk-through begins with a review plan.

$ Each item of the document (eg) a source code module is   

reviewed with clearly stated objectives in view.

 $ A detailed report is generated that list items of concern 

regarding the document reviewed.

 $ In requirement walkthrough,the test team must review the 

requirement document to ensure that the requirements match 

user needs,and free from ambiguities and inconsistencies.

$ Review of requirements also improves the understanding of the 

test regarding what is desired in the application.

$ Both functional and non-functional requirements are reviewed.

$ A detailed report is generated that list items of concern 

regarding the requirements.

Test Plan

Test Plan: -

• Planning
• Deciding the features to be tested
• Deciding the approach
• Deciding the criteria
• Identify responsibilities, staffing and training needs
• Resource Requirements
• Test the output
• Testing task
• Activity breakdown
• Scheduling
• Management of communication
• Risk management

Planning: -

1. what needs to be tested( what will be tested and what will not be tested).
2. how testing is about to be done.
3.  resources needed for testing.
4.  test activity time line.
5. risk faced.           

Deciding the features to be tested: -

1. we should decide the phases for testing.
2. we can have a single test plan for all phases or separate plan for each phases.
3. Master test plan: various testing include unit testing,integration testing, performance testing, acceptance testing, and so on..which can be a part of a single plan or could be for multiple plans. When there are multiple test plans, there must be a single test plan which holds all the test activities common plan.
4. Scope Management: specify the scope of the project.                                    

                            *understand what needed for the release of the project.

                            *break down into features.

                            *prioritize the features.

                            *decide the features to be tested.

                            *prepare an estimation of the resources.              

             

       For the best testing we should know the end product qualities that would satisfy the end user. If we know the end user need we could easily do the testing process. During testing we should clearly have a complete picture of the end product, which would help us to decide the scope and priority of testing.The features of the product are identified during the testing. The testing team should get involve early in the planning cycle and understand the features.This would help the testing team should prioritize the features of testing.

                             Factors that help us to prioritize testing: 

       1. New features that are critical for the release.

       2. Features whose failures are catastrophic

       3. Features that are complex for testing.

       4. Extension features that are prone earlier.

     

Deciding the approach: -

       1. Decide the type of testing based on the functionality of the product.

      2. Decide the scenarios for testing.

      3. Decide the integration testing that would ensure the features are working together.

      4. Decide the needed localization validation.

      5. Decide the needed non functional tests.

This would result in identifying the right type of test for each feature or combination.

Deciding the criteria: -

          1. We should have a clear exit and entry point for different phases of testing 

         2. The test strategies determine how the features and combinations would be tested.

         3. Test should be carried out as early as possible. Reducing the last minute pressure.

         4. Entry criteria specify the threshold criteria. This specify the entire testing activity to start.

         5. Exit criteria specify the test cycle or a testing activity can be deemed complete.

         6. Suspension criteria  specify when a test cycle can be suspended from the process.

         7. Resumption criteria specify when the suspended criteria can be resumed from the suspension.

Typical suspension criteria: -

           * Occurrence of more defects cause frequent stoppage testing activity.

           * When developers release the new version product they would advise should be used in lieu of the product under test.

           * Show stoppers would prevent further progress of testing.

Identifying responsibilities, staffing, and training needs: -

             1. Testing requires different roles.

            2. They are test engineers, test leads and test managers.

            3. There is clear role definition for the modules being tested.

            4. The different roles should complement each other.

            

Role definitions: - 

             *Each person should know what he or she does in the testing.

             *We should list the responsibilities, so that everyone knows how their work fit into the entire project.

             *We should complement each other. So that no one overlaps.

             *We should supplement each other so that no task is left unassigned.

    Role definition should list the management and reporting responsibilities. It includes frequency, format, recipients of status reports and project tracking mechanism. Responding to queries should also be addressed during the planning stage. 

   Staffing is done aiming on estimation of effort to be involved and the availability of time before the release.            

Resource Requirements: -

    Project manager should provide estimate for the hardware and software required.

 Factors to be considered: - 

             * Machine configuration needed to run the product under test.

             * Overheads required by the test automation tool

             * Supporting tools such as compilers, test data generators, configuration management tools and so on.

             * The different configuration on of the supporting software.

             *  Special requirements for running machine intensive tests such as load tests and performance tests.

            * Appropriate number of licences of all the software.

            * Environmental requirements must be taken into account.

         Under estimation of the above can lead to slowing down of the testing process which can lead to delayed release of the product.

         

Test the output: -

        Test plan identifies the deliverable that should come as the output of the testing phase. 

    The deliverable:-

   

       All reviewed and approved by the appropriate people.

  *The test plan itself.

  * Test case design specifications.

  * Test cases including any automation that is specified the plan.

  * Test logs produced by running test

  * Test summary reports.

       Defect repository gives the status of the defects produced during the product life cycle. Defect repository is kept up to date. This means entering new defects into the repository and are updated periodically. the status of defect are fixed after verification. 

 Testing task: -

      * The scenarios identified till now tells what should be tested.

      * The estimation is quantified in the estimation step.

      

Estimation: -
  

          1. size

         2. effort

         3. schedule 

        

       Size estimation quantifies the actual timing needed for testing.

size of the product under test: -

       Determines the amount testing that ought to be done.

       When the product is larger, greater is the size of testing which ought to be done.

   

    Measures of the size of the product:-

  

Lines of code

Functional Point

Number of screens,reports or transaction.

Extent of the Automation:- 

      The size of testing goes on increasing when there is automation.  

       Because we need to perform the basic test case design and then script them to the programming language of the test automation tool.

Number of platforms and inter-operability to be tested:- 

                A particular product must be tested for different platforms.

size estimate can be expressed as- 1. Number of test cases.

                                                     2. Number of test scenarios

                                                     3. Number of configurations which ought to be tested.

     

Productivity data: -

                denotes the processes being carried out during testing, based on the historic data.  

Reuse of test cases developed: -

               when we consider the reuse of test cases developed, then the effort needed goes down.

Robustness of the process: - 
                1. well documented standards for the test cases developed.

               2. proven process of performance.

               3. Consistent way of training the staff involved.