Human Resource Management And Organisation Strategy To Achieve The Maximum Objectives

Introduction:
In today world when productivity, quality, efficiency and more importantly business competitiveness are the more important area of the more successful organisation. When is someone talking about the labour performance that is the meaning of labour performance /productivity in other world? In today organisation human resource management (HRM) involve the linkage of management and development of human resources to an organisation’s strategic plan, goals, and objectives. In other world, the performance of the organisation through HRM planning, personal policy and practices, HRM data, management and training is our research discussion in this paper. The HRM is regardless of the size, complexity and degree of the organisation either private or public. In this paper we discuss the impact of HRM on performance of organisation and people and how it has to link with organisation policy. Some people think that it is difficult to implement in small organisation and some think that they have negative outcome for various reasons. For example HR policy has long term impact so then why most of organisations are hesitate to incorporate and integrate with their organisation strategy. In socially and economically developed country such as in UK in which competitive strategy often based on short term policy not long term and quality enhancement. The beneficial approaches may presume that HRM policies and practices and organisational performance are linked and this relation is two way not one way and it has a long term effect. This relation has positive or negative effect. In short we have to explore the HRM strategy in an organisation whether they contribute positively to or affect adversely the organisational performance but it depends on the factors that could be internal or external.

HRM and Organisation
In today organisation to established HRM system, there are key issues that an organisation has to consider when it has to set up business strategy. These issues are as:
1. Should expand and explore the role of HRM.
2. Encourage leadership
3. Development of performance management system at organisation level.
4. Establish a comprehensive supervisory system at all level in the organisation.
5. Invest in learning and development in the organisation.
Now we will discuss the above mentioned issues in comprehensive way to explain why and what level HRM is integral part of business strategy and why most of management think that none of organisation corporate policy is complete without HRM policy in place.
Role of HRM in the organisation:
As an integral part of overall organisation management strategy should consider how HRM is beneficial and valuable for the organisation to achieve its mission and objectives. So HRM will help you to keep focus on the linkage of human resource and organisation strategies, goals and mission.
In my perception and personal experience, when had I been working in the Tough Rider Ltd Sialkot Pakistan, people often think that HRM role is very limited? They think that this administrative role is concerned with salaries, benefits, personal policies (grievance, holidays, medical policy, pension etc), job description and training and development only. This administrative role is very crucial and integral for strong HRM system and you could not restrict this role to these limited activities only. In any organisation whatever the size should be:
• Strategic partner of other organisation strategy to achieve its goals and develop its strategy.
• Act as administrative expert in developing and incorporation the administrative policies and procedures and organisational structure.
• Support and develop employees.
• A change agent for the organisation
Why HRM is a Strategic Partner of the organisation?
In any organisation top level management could use the HRM strategically by working with HR professional to establish HR system that align with other organisation practices, strategies and goals. The following are the objectives that HR policies and practice support:
1. Generate new vacancies in the organisation.
2. Revision of job description.
3. People recruitment of having diversified knowledge and skills they brought in the organisation.
4. Organising and conducting the training sessions for employees at all level in the organisation.
5. Arranging seminars for top level management.
6. Learning and development of middle level management e.g. supervisors, section managers.

Why HRM as an administrative expert in the organisation?
Because of its administrative role in the organisation structure, so it is more efficient and constructive. The administrative structure that HRM system play are to hiring or recruiting new work force, work planning and performance review. HR manager could also develop an coherent and clear job policy regarding its classification, compensation, salary, pension, disciplinary actions, grievance and labour law compliance regarding health and safety etc and maintain the employee record and information according to information acts.
How HRM support and develop the employee?
Human resource in the organisation believes that it is true representative of the employee for providing a systematic way of expressing their views and concerns regarding their job and other matter. It pleader of employees and developing their skills and knowledge and improve their commitment to the organisations.
Why HRM is a change agent?
In any organisation human resource management system play a key of training and preparing employees for identifying and implementing the new change in the organisation. The most important activities that human resource support regarding change can include analysing processes, competency and then supporting the new reformed processes and redesign the systems to help organisation to meet new target and improve the sustainability of the organisation and reach the new target with the existing staff.
The change incorporated in the organisation could generate the lack of cooperation and decline the performance at all level in the organisation. It is the task of human resource management to minimise the negative impact of the change on the staff and try to involve all people those are affected by the change through different ways like:
• All employees should be informed and anticipate about the change taking place.
• Provide an environment and held meeting with employees to contribute their ideas, help in developing plan, improving procedures of change and ask different question regarding change and provide the suitable answers and also discuss the impact of changes too.
• Soliciting and getting ideas from the staff about how to prepare for new changes in the organisation.
• Generate new spirit regarding change in the team to get maximum benefits of the change.
• Follow the agreed actions after involving the employees.
In the following diagram that shows how the people-centred values at the core of an organisation can guide the top level management when they have to make the decision for any kind of change in the organisation.

Organisation Values
“In addition to providing a structure and framework for strategically managing your staff, infrastructure, and processes of change, human resource management can and should play an important role in shaping the values of your organisation and dissemination them throughout the organisation. As shown in the diagram below, employee-oriented values are at the very core of the organisation. Surrounding these organisational values are the organisational objectives that guide decision making. Surrounding them in turn, are organisational strategies and practices that can change from year to year in response to changes in the internal and external environment.”(Letts et al 1999).

(Letts et al, 1999)

Furthermore here I will discuss the mores aspects of human resource (HR) regarding the employee training, and improving skill to enhance the productivity of the employees and it’s effects in the increasing organisational performance.
In House Skill Training for Increasing Organisational Productivity:

In organisation training is a management tool to use to develop skills and knowledge as mean of increasing not even an individual’s but ultimately an organisation’s current performance in terms of efficiency and effectiveness but could also increase the productivity.
Most of the research argues that the investment in training is another tool for future performance of the individual and organisation and is connected to organisational objective for the future. This tool is used not even pursue a career in line with its evolving needs of the individual skill but explore abilities to move along with the organisation.
The employee training and development has widely argued is essential to organisation which seeks to gain competitive advantage through a highly skilled and flexible workforce as a major ingredient for high performance and productivity. A highly skilled and well trained workforce may increase the productivity of greater value. They could not even cut the cost of supervision as they have skill to inspect their own work but also minimise the machinery downtime because they are able to diagnose faults on machinery and are even repair them. Because the multi-skills of the workforce they could improve the functionality flexibility. Technically competent employees enhance the management confidence of incorporating new technology and changes introduce in the production methods and product requirements. In the today intensified competitive environment, “ efficient production even of technically unsophisticated products benefits from technically advanced machinery operated by a workforce with a high level of skills” which in turn “ a pre-condition for successful selection of appropriated machinery and its efficient utilisation” (Steedman and Wagner, 1989,p133).
At last a well trained workforce not even increase the efficiency and productivity of the organisation but also maintaining the relationships with customers and suppliers, organising smooth flows of production materials and keeping correct records to ensure that the products are delivered in time and to the customer satisfaction. Training and development of the workforce not even an attempt of the top level management to improve the productivity of the organisation but also give a sign to employees that they are valuable asset of the organisation. This message is not encourage the workforce commitment to achieve organisation goals and objective but also raise the morale of them.
The training they got in the organisation give them a sense of responsibility and creativity but hence give them more satisfaction and higher motivation which will long term increase the productivity of the organisation.
However, firms are not always prepared to harness all these benefits.”Management selects, recruits and trains in accordance with its work organisation policies, perceived skill needs and with the traditions and prejudices of the society, industry, locality and firm” (Senker and Bredy, 1989, p158). The subsequent skill structure is then determined by the reorganisation of work responsibilities (Burgess, 1985). Sometime organisation underestimates the skill availability for the new technology they acquire. Some time the decisions about investing in new technology are made on the based on assumptions without considering the skill and knowledge of the available workforce skill and knowledge. But sometime the burden on the organisation regarding production could not send all employees on the training they need prior to introduce new change and technology.
In the above mentioned study of maintenance craftsmen (Cooke, 1999), the managers interviewed expressed their awareness that the maintenance staff should have been more involved in the installation and commissioning of the new equipment. But it is very difficult sometimes, because at the end of the day, the main job is to achieve the production target. And if you are limited with staff, you cannot just take people off to go on a training course or to walk around with the commissioning engineers’ ( a maintenance supervisor, 1999). Rapid technological change and shorter product life cycle make it expensive and difficult for firms to invest in skill training of its own workforce. Under a dominant culture of short term cost saving rather than long term development (Atkinson and Meager, 1986), out sourcing is increasingly being used in order to cheapen the immediate labour and hence production cost. According to a recent study on large companies in the recession period of the early 1990s, ‘focus on core business’ was an action considered very important by 54% of the firems surveyed (Geroski and Gregg, 1997, p74).

HR policies and improving production:
Job satisfaction, employee commitment and motivation have often been regarded as important HR dimensions to organisational performance. Employees, enthusiasts of the ‘soft’ model of HRM argue, should be treated as valued assets, a source of competitive advantage through their commitment, adaptability and high quality (of skills, performance and so on )(Guest, 1987). The stress is therefore on generation commitment via ‘communication, motivation and leadership’ (Storey, 1989,p6), ‘if employees commitment will yield better economic performance ‘(Storey, 1995,p35).

In British firms in now a day’s making great effort to cultivate employee job satisfaction and commitment and use the employee involvement to implement new policies and improve their performance and commitment. In contrast, productivity and efficiency in production are achieved through the following factors:
• Flexibility
• Work satisfaction
• Exploitation of the labour factors such as climate of job insecurity.

Flexibility: O’Reilly draws a distinction between flexibility ‘used in an ad hoc manner to meet shortages and intensify work and flexibility ‘accompanied by an increase in training and upgrading’ (O’Reilly, 1992, p370). For example, Geary (1995) argues that changes in work organisation have been in the direction of removing boundaries and demarcations rather than investing in the up skilling of the workforce. It has also been argued that functional flexibility does not necessarily have to be secured through the acquisition of very high levels of skill by core workers in the way that the Atkinson model describes (e.g. Ackroyd and Procter, 1998).
Work Intensification: The more critical factor organisations can use for improving productivity is through work intensification, partly as a result f downsizing and/or increased quantity of production. For example, the rising profit in a printing company (Cooke, 1999) was mainly achieved by successive reduction of manning level per press (from the original 17 men per press 15 year ago to currently 4men per press) and at the same time doubling the amount of production. It has been argued that there has been a productivity ‘miracle’ in the 1980s owing, in large part, to successive governmental legislation to curb the trade union power ( e.g. Metcalf, 1989; Nolan and Marginson, 1990).
Management is now far more aware of the need to use labour resources efficiently in production;’ restrictive practices’ have diminished; strikes have fallen off; and the closed shop is less of a problem. The performance gains of recent years owe more to workers’ ‘fear and the enhanced power of management than to a new spirit of co-operation. Nolan et al (e.g. 1989,1990) argues that the productivity gains in British industry in the 1980s can be attributed to three aspects: increased work intensify, the sharp recovery of output with a significantly reduced industrial workforce after 1982, and piecemeal changes in the technical and organisational structure of production.
Job Insecurity and Pay: the most attractive factor that plays a key role of improving the employee’s motivation is pay factor. Pay has long and for reaching factor that management could use this tool. Organisation could attract new skilled and well trained workforce by paying them a salary higher than the average going rate available in the currently market. The introduction of agency or out sourcing is job insecurity for the permanent employee that could generate the less commitment and work hard to achieve the organisation objective. This factor could be overcome by providing job security and better job rate to increase employee commitment and flexibility is secured by playing the labour market factors effectively.
The strategy of deploying external temporary labour to cheapen cost and to reduce the bargaining power of the in-house workforce is perhaps somewhat characteristic of the British practice. According to Goold and Campbell (1986), mangy British manufacturing firms like ‘The Park Cake Bakeries Ltd’ organisation adopt the financial control’ type of management style in which control is exerted predominantly in response to the short term performance and profit target. This policy pointed the low-trust relation between management and labour.

Organisational Performance Management System:
The most important factor after investing in training and people development there should be HR system that could measured the performance of organisation and its overall effect on the organisation development and achieving its objectives and goals.
The HR management leader task is to establish performance management system that connects strategic and operational plans with performance measures for organisational units and for individual employee. This system not even help the individual to measure his/her work contributions to the success of the organisation but help them to feel more committed and motivated and productive. If organisation implements the system in a systematic way then it has potential way to improve the individual performance but contribute the organisation success.
The performance management system must consider the following factors regarding performance:
• Job description for each job in the organisation.
• Clear supervisory relationships with employee should be there.
• Period held meeting for supervisor and employee.
• Periodic performance review regularly.
• Generate opportunity for staff learning and development.
For effective performance management system need a regular planning that play key role in any competitive organisation? For a good planning need a supervisor and employee should together develop the work plan that could be effective for organisation to achieve the desired goals. After agreed on the plan developed there should be regular meeting after three or six month time periods to consider the performance objectives and before considering any lacks is the current plans and consider these issues in developing next plan. So achieving agreed upon work objectives accountability is an important element in any organisation. The people centred approach does not mean that spare the employee about accountability but human resource management should provide a system that provide for assessing employee performance in an objective and constructive way and holds employees accountable for work planning objectives.

How HRM Improve Organisation Performance:

So in any organisation wages alone could not improve the employee performance but dealing employee fairly without any prejudice or any other factor that could make the organisational environment chaotic. The effect of pay rise has very limited but providing the individual new opportunity and to provide better chance to get better job in the organisation that could improve the employee performance. Today successful organisations make sure that human resource management system integrates with organisational performance management to achieved the organisation goals and objective and employee understand his/her work relate to and contribute to the organisation pre designed mission statement.
Today most top level management/more efficient management to enhance the workforce performance they tried to address their concern/issues. Most of research agreed that following could be the issues, if any organisation addressed could grow faster as compared with others that do not. The most important issues that need to address are as:
• Are employee treated fairly and equally?
• What is my job responsibility?
• Am doing well that should I have to do?
• Is my work is contributed in the organisation?
• How could i develop myself in the organisation?
If organisations addressed these issues hope could become more productive and competent in today competitive environment.

Discussion and Conclusions:
At last researcher argue that to improve performance organisation should adopt a well fitted HR policies to increase performance and competitiveness. Amongst other things, functional flexibility through investment in training and development, pay rise, employee involvement in planning and commitment, quality initiative are seen central issues for sustained organisation economic performance. In Britain most of organisations are adopting a comprehensive HRM system in place. Some think because of its quality policy, pragmatic, incoherent and inconsistence outcomes at times which is not necessary in the best interest of their employees and/or organisational performance in the long-term. The major concern these days’ organisations are keeping their operating cost down rather than investing for the future because of credit crunch. For long term improvements, organisations require assets in term of finance and human skills and a conductive working environment. ‘Capabilities are built up over relatively long periods and need constant replenishment. This implies an orientation toward encouraging learning. As much of this is firm-specific ‘know how’, it depends on long-term commitment as well as identification with firm objectives. This requires continuity of employment for trained and knowledgeable personnel, to keep the ‘know how’ and ‘know –why’ inside the organisation. Skills are difficult to acquire ‘off the shelf or change quickly’ (Swann, 1993,p38-39).
At last HRM systems should be the responsibility of leading player in the organisation that have administrative role. The partnership between supervisor, section manager, senior manager and HR professional makes the HRM system more constructively that really work in systematic ways.

References:
1:Ackroyd, S. And Proctor, S. (1998), ‘ British manufacturing organisation and workforce industrial relations: some attributes of the new flexible firms, British Journal of Industrial Relations,36(2): 163-183.
2:Atkinson, J. And Meager, N. (1986), ‘Is flexibility just a flash in the pan?’, Personnel Management, Sept.: 26-29.
3: Burgess, C. (1985), ‘Skill implications of new technology’, Employment Gazette, 10th Oct.; 397-430..
4: Cooke, F.L. (1999), Maintenance skills and Maintenance Work in the Context of Technological and organisational change, unpublished PhD thesis, Manchester School of management, UMIST.
5: Geary, J.F. (1995), ‘Work practices: the structure of work’, in Edward, P. (ed), Industrial Relations: theory and practice in Britain, Oxford:Blackwell.
6: Geroski, P.A. and Gregg, P. (1997)0, Coping with recession: UK company performance in adversity, Cambridge: NIESR.
7:Goold, M. And Campbell, A. (1986), Strategies and Styles: the role of the centre in Managing Diversified Corporations, Oxford: Blackwell.
8: Guest, D. (1987), ‘Human resource management and industrial relations’, journal of management studies, 24(5): 503-21.

9:Letts C., W.P.Ryan, and A.Grossman. High Performance Nonprofit Organisations: Managing Upstream for Greater Impact. New York: John Wiley & Sons Inc.,1999.
10:Metcalf, D. (1989), ‘Water notes dry up’, British journal of industrial Relations, 27(1).
11: Nolan, P. (1989), ‘Walking on water? Performance and industrial relations under Thatcher’, Industrial Relations Journal, 20(2); 81-92.
12: Nolan, P. and Marginson, P. (1990), ‘Skating on thin ice? David Metcalf on trade unions and productivity’, British journal of Industrial Relations, 28 (2); 226-247.
13: O’Reilly, J. (1992), ‘Where do you draw the line? Functional flexibility, training and skill in Britain and France’ , Work, Employment and Society, Sept.
14: Steedman, H.and Wagner, K. (1989), ‘Productivity, Machinery and Skills: Clothing Manufacture in Britian and Germany’, National Institute Economic Review, May: 40-57 p133.
15: Senker, P. And Brady, T. (1989), ‘Corporate strategy: skills education and training’, in Dogeson, M. (ed), Technology Strategy and the Firm: management and public policy, London:Longman.
16: Storey, J. (1989), New perspective on human resource management, London Routledge and Kegan Paul.
17: Storey, J. (1995), (ed), Human Resource Management: a critical text, London: Routledge.
18: Swann,P.(1993), (ed) New Technologies and the Firm: Innovation and Competition, London: Routledge.

software Testing Notes

Chapter 1: The fundamental of Testing

 

 

Reasons of system failure:

 

• Pressure of deadline
• Complexity of system
• Changing technology
• Error in specifications
• Error in code

Other conditions of failure are as:

• Environmental condition
• Presence of radiation
• Magnetism
• Electronic field or pollution

Can affect the operation of the hardware and firmware and lead to system failure.

 

Faulty Component:

 

If specification document is not correct as a result lead a faulty component and faulty components will cause system failure.

 

An error (or mistake) leads to a defect, which can cause an observed failure.

 

Error                 Defect                   Failure

 

Incorrect software can harm:

 

• People (i.e. aircraft crash, life support system failure)
• Companies (i.e. incorrect billing, loss of money)
• Environment (i.e. releasing radiation and chemical into the atmosphere)

 

 

Software failure can lead:

 

• Loss of money
• Loss of time
• Loss of business reputation
• Injury
• Death

 

Keeping software under control:

 

More and better software testing seems a reasonable aim but that aim is not quite as simple to achieve as we might expect.

• Exhaustive testing of complex systems is not possible
• Testing and risk (greater risk implies more and better testing)
• Testing and quality (functional and non functional weakness i.e. online tax one user could view other details and a web site to handle peak load )

 

The vertices of the triangle are:

 

• Time
• Money
• Quality

 

So key role of testing is to ensure that key functional and non functional requirements are examined prior system goes live. So detects defects and reported to development team for ratification.

 

Deciding when “enough is enough”

 

The most important aspect of achieving an acceptable result from a finite and limited amount of testing is prioritization. So priorities and completion criteria provide a basis for planning.

 

 

What is testing and debugging?

 

Debugging is the process that developers go through to identify the cause of bugs or defects in code and undertake corrections. Whereas testing does not include correction of defects however ensure that changes and corrections are checked for their effects on other parts of the component or system.

 

Static testing:

 

It is a term where code is not executed. It involves techniques of reviews, preventing defects, removing ambiguities and errors in specification documents.

 

Dynamic testing:

 

It tests the program under some test data, mean of test execution.

 

Testing process:

 

It is the process of not missing critical steps and that we do things in the right order. To prepare some preparatory work to design tests and test work needed to record the results and check whether the tests are complete.

 

Testing Principle:

 

• Testing shows the presence of bugs (testing does not show that software is error free)
• Exhaustive testing is impossible (for large and complex system not possible). An approach in which all possible data combinations are used. This includes implicit data combinations present in the state of software/data at the start of testing.
• Early testing. Tester does not have to wait until software is available to test. Works products are created throughout the software development life cycle. So as soon as these are ready we can test them. So requirement documents are the basis for acceptance testing. In this process to find errors and defects before they are passed to the next stage of the development process. If problems are solved at this stage in which it is introduced, this leads to what Kit calls ‘errors of migration’.
• Defect clustering. Defects are not uniform there are variety of reasons. Which are

i.e. system complexity, volatile code, the effects of change upon change, development staff experience, development staff inexperience.

• The pesticide paradox.
• Testing is context dependent.
• Absence of errors fallacy.

 

Fundamental of test process:

 

Time pressure can mean that we begin test execution before all tests have been designed.

1. Test planning and control

 

The main activities of planning are as:

 

• Scope and objectives
• Test approach
• What is required for testing i.e. people, resource etc.
• Test strategy
• Scheduling of analysis and design tasks.
• Scheduling of implementation and execution and evaluation.
• Exit criteria

The main activities of controlling are as:

• Measures and analyzing results.
• Comparing expected and actual progress, test coverage and exit criteria.
• Making corrections, if things go wrong and deciding actions.

 

 

2. Test analysis and design

 

The main activities are as:

• Reviewing requirements, architecture, design, interfaces and others as collective test.
• Analyzing test items, specification, behaviour and structure to identify test conditions and test data required.
• Designing the tests.
• Determining test requirements are testable.
• What test environment look like and infrastructure and tools required.

 

3. Test implementation and execution

 

These activities have the following parts.

 

·         Developing and prioritizing test cases, creating test data, writing procedures and preparing test harness and writing automated test scripts.

·         Collecting test cases into test suits,

·         Checking the test environment set-up is correct.

·         Running test cases in the determined order using test execution tools.

·         Keeping log of testing activities, including outcomes and version of software, data, tools and test ware.

·         Comparing actual results with expected results

·         Reported discrepancies as incident with as much information as possible,.

·         Where necessary, repeating test activities when changes have been made following incident raised.

 

Confirmation testing: re-execution of the test that previously failed in order to confirm a fix.

Regressing testing: executing of a corrected test and execution of previously passed tests to check that defects have not been introduced.

 

4. Evaluating exit criteria and reporting

 

This process comprises the following things.

 

• Check whether previously a determined exit criterion has been met.
• Determining if more test is needed or specified criteria need amending.
• Writing up the result of the testing activities for the business sponsors and other stake holders.

 

5. Test closure activities.

 

• Ensuring that the documentation is in order ; what has been delivered  is defined, closing incident and raising changes for future deliveries, documenting that the system has been accepted.
• Closing down and archiving the test environment, test infrastructure and test ware used.
• Passing over test ware to the maintenance team.
• Writing down the lessons learned from this project for later.

 

List of order of independence testing:

 

• Those who wrote the code
• Members of the same development team.
• Members of a different group (independent test team).
• Members of a different company (a testing consultancy/outsourcing).

 

Developers to test their own code have advantage because as soon as problems are discovered , they can fixed without  the need for extensive logs, but also difficulties to find your own mistakes.

 

Way of avoiding confrontations>

 

• The aim to work together rather than be confrontational. Keeping focus of delivering a quality product.
• Results should be presented in a non-personal way.
• Attempt to understand how other feel.
• At the end of discussion, confirm that you have both understood and been understood.

 

Chapter 2: Life Cycles

 

Software development Models;

• Water fall model (Linear or sequential model)
• V-model
• Iterative Model (cyclical model).

 

 

The steps in this model are in sequences which are as:

• Requirement specification
• Functional specification
• Technical specification
• Program specification
• Coding
• Testing

 

In this model testing starting once the code has been developed. Then decision is made whether production can be released into the live environment. This is major draw back of this model.

 

Verification- checks that the work-product meets the requirement set out for it. An example of this would be to ensure that a website being built follows the guidelines for making websites usable by as many people as possible. Verification helps to ensure that we are building the product in the right way.

 

Validation- changes the focus of work product evaluation to evaluation against user needs. This means ensuring that the behaviour of the work product matches the customer needs as defined for the project. Fore example for the same website above the guidelines may have been written with people familiar with websites in mind. It may be that this website is also intended for novice users. Validation would include these users checking that they too can use the website easily. Validation helps to ensure that we are building the right product as far as the users are concerned.

 

V-Model.

 

• Requirement specification- user needs
• Functional specification- functions required to meet the user needs.
• Technical specification- technical design of the function identified in the functional specification.
• Program specification- detailed design of each module or unit to be built to meet required functionality.

 

Specification review:

 

·         Conformance to the previous work product (in case of functional specification, verification would include a check against the requirement specification).

·         Sufficient detail for subsequent work product (again, for the functional specification, this would included a check that there is sufficient information in order to create the technical specification).

·         Testable- details are sufficient for testing.

 

Middle of v-model show the planning for testing should start with each work product.

The right side focuses on the testing activities for each work product.

 

• Acceptance testing: testing against requirements.
• System testing: against functional requirements.
• Integration testing: against technical specifications.
• Unit testing: against program specification.

Advantage:  defects can be identified and resolved as early as possible.

But disadvantage is that you can not go next stage until complete first stage as a result changes in requirements are uncovered until the user testing is carried out.

 

Iterative Development Model

 

Requirements do not need fully defined before coding can start. Instead a working version of the product is built in a series of stages or iterations- each stage encompasses requirement definition, design, code and test. In this model each cycle has a define timescale and cost. And cycles are referred as time boxes. At the end of each time box a decision is made about functionality needs to be created for the next iteration. The advantage of this is involvement of user representative in testing. Which minimize the risk in development? But disadvantage is that the lack of formal documentation makes testing difficult.  For this developer may use test –driven development approach. Developer makes change without documents which could lack of traceability so for this a change management process is needed. Furthermore need amount of testing for implementing any changes so that does not cause unintended changes to other parts of the software.

 

Iterative development includes prototyping, rapid application development (RAD) and agile software development. A proprietary methodology is Rational Unified Process (RUP).

 

TEST LEVELS

 

Characteristics of good testing are:

 

• Early test design- begins with specification documents.
• Each-work product is tested- each document in v-model on left is tested by an activity on the right. So specification document is test basis.
• Testers are involved in reviewing requirements before they are released.

 

The test stages in v-model are called test levels:

 

• Unit testing- code testing which build in isolation. Units are programs, module or components or units. For checking conformance to the program specification unit test would also verify that all of the code that has been written for the unit can be executed. Defects found and fixed during unit testing are often not recorded.
• Integration testing- is to put units together. The purpose of integration testing is to expose defects in the interfaces and in the interactions between integrated components or systems. There are three integration strategies.
  1. Big Bang integration- where all units are linked at once, results in a complete system. Difficult to isolate any error found because of not paying attention to each individual unit.
  2. Top down integration- system is built in stages starting with components which called other components. Calling component is at top and called components are at bottom. In it the interactions of each component must be tested when it is built. When a component is not integrated yet then stub (skeletal implementation of the component)                                                                      is used which is a passive component, called by other components. So stub is commonplace in top down approach.
  3. Bottom up  integration- opposite to top down approach. In it the components which are not in place are those which actively call other components. In bottom up approach of replacing these components with special components they called drivers because they are active and calling other components.

So there may be more than one level of integration testing.

•  
  1.  
     • Component integration- intersection between software components and done after unit testing. This type of integration is carried out by developers.
     • System integration – intersection between different system and done after system testing of each individual systems. This is usually carried out by testers.

 

 

 

 

System testing:

 

This is to check the functionally from end to end perspective. It determines the behaviour of the system/product defined in the scope documents. It is done by an independent team not development team base on the specification as written, and not the code. It check that system built meet the system requirements. Functional specification should contain definitions of both the functional and not functional requirements of the system.

 Functional requirements- is a requirements that specifies a function that a system or system component must perform. It could be specific to a system. What application will do i.e. check your fund in bank accounts.

Non functional requirements- are important but not directly related to what the system performs.

Examples of not functional requirements are:

• Install ability- installation procedures
• Interoperability-operation of application in different environments.
• Maintainability- ability to introduce changes to the systems.
• Performance- expected normal behaviour.
• Load handling- behavior of the system under increasing load.
• Stress handling- behaviour at upper limits of the system capability.
• Portability- use on different operating platforms.
• Recovery- recovery procedures on failure.
• Reliability- ability of the software to perform its required functions.
• Usability- ease with which users are engage with the system.

But Security is a functional requirement.

 

Acceptance testing:

 

It provides confidence to end users that system will function according to their expectations. It is also base on the specification document. In other words it is the system conformance to the customer requirements. It assesses the system readiness and deployment and use. It is the responsibility of customers and users.

 

Forms of acceptance testing:

 

• User acceptance testing
• Operational acceptance testing- it include checking the
  1. Back up facilities
  2. Procedures for disaster recover
  3. Training for end users
  4. Maintenance procedures
  5. Security procedures.

• Contract and regulation acceptance testing
  1. contract acceptance testing-
  2. Regulation acceptance testing- governmental, legal or safety standards.
• Alpha and beta testing:

1.      Alpha testing take place at developer site. Operational system testing.

2.      Beta testing- at customer site. Operational system is tested by a group of customers at their own locations and provides feedback. It is also called field testing.

 

 

Confirmation testing:  When a defect is detected and fixed then the changed software should be retested to confirm that the problem has been successfully removed.

 

Debugging:  when a developer removed the defects, this is called debugging? But it is not testing activity.

 

Regression testing:  when unchanged software should also be retested to ensure that no additional defects have been introduced as a result of changes to the software.

 

Maintenance testing: testing which take place on a system which is in operation in the live environment is called maintenance testing.

 

Impact analysis:  an understanding of the parts of the system which could be affected by the changes could reduce the amount of regression testing required which is practically impossible and not cost effective. In other word the analysis of impact of changes on the system.

 

Chapter3:  Static Testing

 

Static testing: are those techniques that test software without executing the code. This includes both the testing of work-products other than code, typically requirements or specification documents and testing of code without executing it. First is known as review and second is known as static analysis, review are completed manually and static analysis is normally completed automatically using tools.

 

Review and test process:

A review is a systematic examination of a document by one or more people with the main aim of finding and removing errors in requirement specification, design, code, test plans and test cases any thing written/typed in during the software development life cycle.

 

 

 

Benefits of review:

 

 Important for cost and time saving and many others which are as?

 

• Development productivity can be improved and timescale reduced because the correction of defects in the early work-products will help to remove product ambiguities.
• Testing cost and time.
• Reductions in lifetime costs i.e. on-going support costs will be lower.
• Improved communication results.

 

 

The types of defects most typically found in review are.

• Deviations from standards.
• Requirements defects.
• Design defects. I.e. not matching requirements
• Insufficient maintainability i.e. too complex
• Incorrect interface specifications.

 

Review Process: reviews are formal or informal. The decision on the appropriate level of formality for a review usually based on combinations of the following factors:

 

 

• The maturity of development process.
• Legal or regulatory requirements.
• The need for an audit trail. The level of formality in the type of review used can help to raise the level of audit trail.

 

Reviews objectives:

 

The reviews have varieties of objects.

• Finding defects
• Gaining understanding.
• Generating discussion.
• Decision making by consensus.

 

Basic review process:

 

Formal and informal review both exhibit same elements of process.

 

• The document under review is studied by the reviewers.
• Reviews identify issues or problems and inform the author either verbally or documented form.
• The author decides on any action to take in response.

 

Phases of a formal review:

 

Characteristics of formal review:

• Planning

 

•  
  1. Selecting the personnel.
  2. Allocating roles
  3. Defining the entry and exit criteria
  4. Selecting the parts of documents to be reviewed (not always required).
• Kick-off:
• Individual preparation
• Review meeting
  1. Time available (short meeting may collect defects).
  2. Requirements of the author (to help in correction of defects).
  3. Type of review.(collection of defects not discussion)

• Rework (correction of defects by author).
• Follow up: the review leader checks that the agreed defects are corrected and how much time has been spent on it. He will also check the exit criteria.

 

Roles and responsibilities in review: (user, maintainer, tester or operations)

 

The specific roles and responsibilities that should be fulfilled for formal reviews are:

 

• Manager: what to reviewed and ensure the sufficient time allocated in the project plan for all the required review activities and determine that if the review objectives have been met.
• Moderator: this is who lead the review of document or set of documents including planning, the review, running the meeting and follow up the meetings, review leader or a person upon whom the success of review rests.
• Author: responsible for fixing any defects.
• Reviewers: have business or technical background also called checkers or inspectors.
• Scribe or recorder: attend meeting and document all defects, issues and problems.

 

Role of tester is not normally associated with reviewers.

 

Types of review:

 

There are four types of reviews.

1. informal review (least formal) key characteristic:
   • no formal process undertaking
   • may or may not documented
   • Reviewer does not have technical skill but to check and ensure that document makes a sense.
   • Main purpose to find defects and it is inexpensive way.
   • Review may be implemented by pair programming (one programmer reviews the code of the other pair programmer) or technical lead reviewing design and code.
2. Walkthrough. Key characteristics.

·         Meeting lead by author of document and attended by peer group.

·         Review session is open ended and may vary in practice for quite informal to very formal.

·         Preparation by reviewers before the walkthrough.

·         Main purpose is to enable learning about content of document under review, to help team members gain an understanding.

·         Walkthrough typically explore scenarios or conduct run of code or process.

1. Technical review. Key characteristics:

·         Include peers and technical experts.

·         Led by trained moderator and performed as a peer review without participation of management.

·         Prepare a review report about the list of finding.

·         Vary in practice and have numbers of purposes i.e. Discussion, decision making, evaluation of alternatives, finding defects, solving problems and checking conformance to specifications and standards.

1. Inspection (most formal). Key characteristics:

·         led by moderator

·         Inspection process is formal, base on rules and check lists and uses of entry and exit criteria.

·         Pre-meeting preparation is essential to ensure document consistency.

·         An inspection report with a list of findings to aid improvements including correcting defects under reviews.

·         From follow up process is used to ensure corrective action in completed and timely.

·         Main purpose is to find defects and process improvement may be a secondary purpose.

 

Success factors for reviews:

 

• Each review should have a clearly predefined and agreed objective and the right people should be involved to ensure the objective is met.
• Any defects found are welcomed, and expressed objectively, and the review leader has ensured that the people issues and psychological aspects are dealt with.
• Review techniques (both formal and informal) that are suitable to the type and level of software work products and reviewers (this is especially important for inspections).
• Checklist or roles should be used where appropriate, to increase effectiveness of defect identifications.
• Management support is essential for a good review process.
• Emphasis on learning and process improvement.

 

For quantitative success measurement could be as:

 

• How many defects found.
• Time taken to review/inspect.
• Percentage of project budget used/saved.

 

Fagan inspection method was developed by Michael Fagan in 1976 of IBM.

 

Static analysis by tools:

 

The purpose of static analysis is to find defects is software source code and software models without executing the code.

 

Source Code: a series of statements written in some human-readable computer programming language.

 

Software model:  is an image of the final solution developed using techniques such as UML (unified modeling language) and normally generated by designer.

 

 Static analysis finds defects which are hard to find during the execution.

 

The benefits or value of static analysis are:

 

• Early detection of defects prior to test execution.
• Early warning about suspicious aspects of code or design by using the calculation of metrics, such as high –complexity measure.
• Identification of defects not easily found by dynamic testing such as development standard breaches as well as detecting dependencies and inconsistencies in software models, such as links or interfaces that were either incorrect or unknown before static analysis was carried out.
• Improved maintainability of code and design.
• Prevention of defects (by identification early in the life cycle is easier to identify why it was there in the first place root cause analysis).

 

 

The defects discovered by static analysis tools include.

 

• Reference a variable with an undefined value i.e. using a variable as a part of calculation before the variable has been given a value.
• Inconsistent interface between modules and components.
• Variables that never used.
• Unreachable code (dead code) mean did not execute.
• Programming standards violations.
• Security vulnerabilities i.e. password structures that are not secure.
• Syntax violations of code and software models i.e. using wrong modeling language.

 

A static analysis tool run automatically and reports all defects it identifies either significant or not.

 

Chapter 3: Test Design Techniques.

 

 

The specification of the test case is the second case of test specification. The term specification and design are used interchangeably.

The design of test comprises three main steps.

• Identify test condition
• Specify the test cases.
• Specify test procedures.

 

 

Identify test condition:  an item or event of a component or system that could be verified by one or more test cases e.g.  A function, transaction, feature, quality attribute, or structural element.

 

A test case: a set of input values, execution preconditions, expected results and execution post conditions, developed for a particular objective or test condition , such as to exercise a particular program path or to verify compliance with a specific requirement.

 

A test procedure specification: a sequence of action for the execution of a test. It is also called test scripts to distinguish it from automated scripts that control test execution tools.

 

To test a whole system a test execution schedule which puts all the individual test procedures in the right sequence and sets up the system so that they can be run?

 

Test coverage idea:  it provides a quantitative assessment of the extent and quality of testing. It is important for two reasons.

• Quantitative measure of the quality of testing that has been done by measuring what has been achieved.
• Estimating how much more testing needs to be done,   using quantitative measure can set targets for test coverage and measure progress against them.

 

 

 

Categories of Test Case Design Techniques

 

 There are three categories.

1.      Those based on deriving test cases directly form a specification or a model of a system, known as specification-based or black-box techniques.

2.      Those based on deriving test cases directly form the code written to implement a system, known as structure-based or white-box techniques.

3.      Those based on deriving test cases from the tester’s experience of similar systems and general experience of testing, known as experience based techniques. It also called ‘ad hoc’ techniques. It is not a systematic technique.

 

Specification Based or Black Box Technique:

 

If there is no specification then tester has to build a model of the proposed system, by interviewing key stakeholders to understand what their expectations are. It provides the test basis to generate tests systematically.

Here are five specification based techniques which are:

 

1. Equivalence partitioning
2. Boundary values analysis
3. Decision table testing
4. State transition testing
5. Use case testing.

Now have look on each one.

 

Equivalence Partitioning:

Input partitions

It is that in many cases the inputs to a program can be chunked into groups of similar inputs. This technique has advantage of the properties of equivalence partitions to reduce the number of test cases we need to write. In it both valid and non valid partitions are important to test.

   See examples on book page no 81:

 

Out put partitions:

 

As input to a programmed can be partitioned, so can the output. So need a test case that generates each of these outputs as an alternative to generating input partitions.

 

Other partitions and examples on book page 82.

 

Boundary Value Analysis

 

Each component has a limited value e.g. 1 to 99 these are boundary of integer inputs. This is work well close to equivalence partition analysis because of partitions must have boundaries.

 

“As Close As we can get “means take the next value in sequence using the precision that has been applied to the partition.

 

For example see book page 83.

 

Decision Table Testing

 

It is derived from the specification because specification contains the business rules to define the function of system and the conditions under which each function operates. It is the mechanism used to capturing the logical decision is called a decision table. It inputs all conditions and actions that can arise from them. Conditions are on the tope and actions are in bottom. The business rules involve the combination of some condition to produce some combination of actions, are arranged across the top and in table these are in form of column. In reality there are large number of condition and actions but number of combinations producing specific actions is relatively small. The tables which have limited entries is called limited entry table and distinguish from others which have large inputs identified. From decision table we can determine test cases by setting values for the conditions and determining the expected output. So each column represents a test case.

 

State Transition Testing

 

In it output triggered by changes to the input conditions, or change state. In other word behaviour depends on current state and past state. So the main diagram used in this technique is called state transition diagram.

 

State Transition Diagram

 

It is a representation of the behaviour of a system. It is made up from just two symbols.

State 1

 

 

A state mean the system is static in a stable condition and it will only change if it is stimulated by an event of some kind. E.g. a TV stays on until you turn it off.

 

The second is arrow which is symbol of transition e.g. change from one state to another. The state change will be triggered by an event e.g. pressing button. The start state will have a double arrow head pointing to it.

 

Event

 

An event is anything that acts as a trigger for a change; it could be input to the system or inside the system e.g. data base field being updated. What happens for each event each time we want to initiate a test? We can take the intermediate step of creating what is known as a state table. It records all possible events and all the possible states. State table is the source from which we derive the test cases. For each combination of event and state it shows the outcome in terms of the new state and any outputs that are generated. ST has a row for each state in the state transition diagram and a column for every event. If the event has no effect we label the table entry with a symbol that indicates that nothing happens; this is sometimes called a ‘null’ transition or an ‘invalid ‘transition. We should also test negative test cases. Which mean those cases where the ST indicates there is no valid transition?

 

Use Case Testing

 

They capture the individual interactions between ‘actors’ and the system. An actor is user and use cases capture the interactions that each user takes part in order to produce some output that is of value. Test case based on use case, often called scenarios. This is high level view of requirements. It has major benefit that it relates to real user processes. The main thing is that first test the highest priority use cases.

 

 

 

 

Structure-based or white Box techniques

 

It is used to explore the program structures. It is used to ensure that each statement in the code is executed at least once. In this technique test cases generate from the code. It is mostly done by the specialist tools in reality but the knowledge of the techniques is still valuable. In this technique you can say that the code is the starting point. In it code is always mean pseudo code. It is limited language than any real language. But it enables the designer to create all the main control structure needed by programs. It is sometimes used to document designs.

 

Code can be of two types, executable and not executable. Executable code instructs the computer to take some action; non executable code is used to prepare the computer to do its calculation but it does not involve any actions. E.g. it is reserving space for some kind of calculation. In pseudo code non executable statement at beginning of the program and executable program start with Begin and End statement.

 

There are three ways that executable code can be structured which are:

 

• Sequence: statements execute one after another.
• Selection: computer has to decide if a condition is true or false (Boolean).
• Iteration: a chunk of code is executed more than once.

 

 

Flow Charts

 

Is the visual representation of the program structure? It consists of two symbols. Rectangles request sequential statements and diamonds represent decisions.

 

 

Control Flow Graphs

 

This provides a method of representing the decision points and the flow of control within a piece of code, it is similar to flow chart but it only shows decisions. It is produced looking only at the statements affecting the flow of control. It also made of two symbols: node and edges.

Node: represents any point where the flow of control can be modified (i.e. decision points), or the points where a control structure returns to the main flow (e.g. END WHILE OR ENDIF).

Edge: is a line connecting any two nodes.

Region: the area contained within a collection of nodes and edges.

 We can draw sub graphs, to represent individual structures.

 

Techniques to draw flow graph:

 

1. Analyse the component to identify all control structures i.e. all statements that can modify the flow of control, ignoring all sequential statements.
2. Add a node for a decision statement.
3. Expand the node by substituting the appropriate sub graph representing the structure at the decision point.

Any chuck of code can be represented by using these sub graphs.

 

Statement Testing and Coverage

 

Statement testing is testing aimed at exercising programming statements. It is used to test the executable statements. And if we test 100 percent then it is called 100 percent coverage. The flow chart is good because the rectangles and diamonds show the executable statements but a flow graphs is less cluttered, showing only the structural details, in particular where the program branches and rejoins. Do we need both diagrams? Well, neither has everything that we need.However we can produce a version of the flow graph that allows us to determine statement coverage. To do this we build a conventional control flow graph but then we add a node for every branch in which there are one or more statements.

 

To understand what happen with the control structure when program runs. So best way is to ‘dry run’ the program with some inputs; this means writing down the inputs and then stepping through the program logic noting what happens at each step and what values change. When you go to end you know the complete path.

 

Hybrid Flow Graph

 

 An additional node that represent the edges with executable statements in them; they make it a little easier to identify what needs to be counted for statement coverage.

 

Flow charts, control flow graphs and hybrid flow graphs all show essentially the same information, but sometimes one format is more helpful than other. So hybrid flow graph is as a useful combination of the control flow graph and the control flow chart. To make it even more useful we can add label to indicate the paths that a program can follow through the code. All we need to do is to label each edge; paths are then made up from sequence of the labels see figure 4.12. And for more detail see book page 107.

 

Rules for statement coverage

• Exclude the non-executable statements that precede Begin.
• Ignore blank lines that have been inserted for clarity.
• Are you consistent about what you do or do not include in the count with respect to control structures.

 

Decision Testing and Coverage

 

The aim of it is to ensure that the decisions in a program are adequately exercised. Decision coverage is measured by counting the number of decisions exercised (i.e. both exits are exercised) divided by the total number of decisions in a given program. It is usually expressed as a percentage.

For testing the decision two test cases needed but for loops one test case is enough.

 

 

Experienced Based Techniques

 

This technique is used when there is no specification from which you derive specification-based test cases or no time to run full structured set of tests.

 

            All type of testing tap knowledge and experience either ad hoc or error guessing through more sophisticated techniques such as exploratory testing.

 

Error Guessing

 

A special test to find errors that could not find by the formal techniques. It takes advantage of tester’s knowledge skill and experience with similar applications. Advantage of this technique is that when applied after systematic techniques; add value in identifying and exercising test cases. But main drawback is that its effectiveness can depends upon the tester experience but could be overcome by listing a number of possible errors by contributing the testers and or users of system.

 

            Error guessing could become more structure by creating list of defects and failure points. This list could be used as a basis of a set of tests that are applied after the systematic technique has been used.

 

Exploratory Testing

 

Exploratory testing is a technique that combines the experience of testers with a structured approach to testing where specifications are either missing or inadequate and where there is severe time pressure. It exploits concurrent test design, test execution, test logging and learning within time-bones and is structured around a test charter containing test objectives.

 

            Using objectives tester could focus on more important area and can maximize the amount of test achieved.

 

Systematic and Experienced –Based Techniques

 

Which one is best use the simple Rule of Thumb?

1. Always use functional testing as the first priority but some time may be needed to use structured techniques for early code product testing.
2. After functional testing think about the test coverage because when coverage is inadequate then extra tests will be needed.
3. Structural method is supplement to functional methods even functional coverage is adequate. It is worth to checking the statement and decision coverage to ensure that enough of code has been exercised during testing.
4. Once the systematic testing is complete then there is opportunity to use experience-based testing to ensure that the most important and more error prone areas of the software have been exercised? In some circumstance e.g. time pressure, poor specification, experienced based techniques is a viable option.

 

Choosing which technique is best does not only the one factor. There are number of factors to bear in mind which are;

 

1. Type of system
2. Regulatory standards
3. Customer or contractual requirements
4. Level of risk
5. Type of risk
6. Test objectives
7. Documentation available
8. Knowledge of the testers
9. Time and budget
10. Development life cycle
11. Use case methods
12. Experience of type of defects found.

 

Some leave no room for selection e.g. regulatory or contractual requirements leave the tester with no choice. Test objectives, where they relate to exit criteria such as test coverage, may also lead to mandatory techniques.

 

 

 

 

 

 

 

 

 

Chapter 5 Test Management

 

No need of testing if there is no chance of adverse future events in software or hardware development.

 

Risk

 

   A factor that could result in future negative consequences, usually expressed as impact and likelihood.

 

Level of Risk = probability of the risk occurring* impact if it did happen.

 

Project Risks:

 

 The project leader will use project risks to manage the capability to deliver.

 

• Supplier Issues

 

      a: failure to supply on time

      b: acceptance criteria

• Organisational  Factors

 

a: skill and staff shortage.

b: personal & training issues.

c: political issues, change of management/restructuring that will affect the project resources.

• Problems that stop testers to communicating their needs and test results.
• Failure to follow up on low-level testing and reviews.

a: lack of appreciation of testing benefits.

• Specialists issues:

 

a: problems in defining right requirements.

b: requirement met with existing project constraints.

c: the quality of design, development and test team.

 

Risks are analysed, manage and mitigate. These are recognized during test planning should be documented in the IEEE 829 test plan. Risk register should be maintained by test leader for the on-going management and control of existing and new project risks.

 

Product Risks:

 

Tester or test leader using the risk-based testing approach for managing product risks. Potential failure areas (adverse future events or hazards) are the product risks.

 

Product risks are:

• Error prone software delivered.
• Poor requirements leading to badly define and built software.
• Potential that a defect in the software/hardware could cause harm to an individual or company.
• Poor software quality characteristics (E.g. functionality, security, reliability, usability, performance) leading to poor user feedback.
• The software does not meet the requirements and delivers functionality that was not requested.

 

 

Using risks, leader decides from where to start testing in the software development i.e. poor requirements is the major risks.

 

Product risks also provide information regarding decisions, means how much testing should be carried out on specific components or systems.

 

            Testing is used to reduce the adverse effects of risks.

 

So risk based approach provide the proactive opportunities to reduce level of risks.

  In risk based approach the risks identified are:

 

• Will determine the test technique to be employed or extent of testing carried out e.g.. [MISRA] Motor Industry Software Reliability Association define which test techniques should be use for each level, more risk, more coverage required from test techniques.
• Priorities testing is an attempt to find the critical defects as early as possible i.e. areas having more defects or complexity.
• Non-test activities to reduce risk e.g. provide training to inexperienced designers.

 

 

Risk-based testing draws on collective knowledge and insights of project stakeholders, testers, designers etc. and any one with solution of knowledge to determine risks and level of testing to address those risks.

 

To minimize product failure risk management provide the disciplined approach.

 

• To assess continuously what can go wrong (risks). For these regular reviews of the existing and looking for new product risks should occur periodically throughout life cycle.
• Determine the priority of risks using probability and likelihood. So for reducing these risks mitigating activities should be carried out.
• To implements actions to deal with those risks (mitigating actions).

 

Testing is actually support the identification of new risks by continually reviewing risks of the project deliverables through out the life cycle.

  To deal with risks identified different strategies, such as contingency plans.

 Testing is a risk control activity that provides feedback about the residual risk in the product by measuring the effectiveness of critical defect removal and by reviewing the effective of contingency plans.

 

Test Organisation

 

Independent testing: is a testing carried out by someone other than the creator

(Developer) of the code being tested.

 

Developer: as the creator and owner of documents and code related to development, perceives these deliverables as being correct when they are delivered.

 

Tester: by contrast will take the view that any thing delivered for testing is likely to contain errors and will search diligently to identify and locate those errors.

 

          The greater is the level of independence, the greater the likelihood of errors in testing arising from unfamiliarity. So level of independence depend on the size of the organisation.

        For complex or safety critical projects, best to have multiple level of testing with some or all of the levels done by independence tester.   

 

 The ‘agile’ approach to development challenges the traditional approach to independence. In this approach every body takes on multiple roles and so maintaining total independence is not always possible.

 

Feature of independence testing see book page [131], software testing.

 

Tasks of a test leader and tester

 

Test leader role: could be a project manager or who have skill and experience of testing but depend upon the structure and organisation and complexity, size of the system. It is important to understand testing job and role. A role is an activity or a series of activities given to a person to fulfill e.g. the role of test leader. A person can have more than one role at any moment but depend upon their experience and level of understanding. A job is effectively what an individual is employed to do.

 

  Tasks of a leader include:

• Coordination in development of strategy and planning with others.
• Writing and reviewing test strategies and policies produced for the project.
• Contributing the testing perspective to other project activities such as project deliverable schedule.
• Planning of required tests-which will include ensuring that the development uses the correct understanding of the risks, selecting the required test approaches (test levels, cycles, approach, objectives and incident management planning), estimating the time and effort and converting to the cost of testing and acquiring the right resources.
• Managing the specification, preparation, implementation and execution of tests, including the monitoring and control of all the specification and execution.
• Taking the required action, including adapting the planning, based on test results and progress (sometimes documented in status reports), and any action necessary to compensate for problems or delays.
• Ensuring that adequate configuration management of test ware is in place and that the test ware is fully traceable e.g. there is a hierarchical relationship establishes between the requirements and the detailed specification documents.
• Putting in place suitable metrics for measuring test progress and evaluating the quality of the testing delivered and the product.
• Agreeing what should be automated, to what degree, and how, ensuring it is implemented as planned.
• Where required, selecting tools to support testing and ensuring and any tool training requirements are met.
• Agreeing the structure and implementation of the test environment
• Scheduling all testing activity.
• At the end of the project, writing a test summary report based on the information gathered during testing.

Test leader tasks under taken by test leader very closely align with project manager and close with standard approaches to project management. The key is to ensure that everyone is aware of who is doing what tasks, that they are completed on time and within budget, and that they are tracked through to completion.

 

 

 

 

Tasks of Tester

 

 The task under taken by tester may include.

 

• Reviewing and contributing to the development of test plans.
• Analyzing, reviewing and assessing user requirements, specifications and models for testability.
• Creating test specification from the test basis.
• Setting up the test environment (often coordinating with system administration and network management). In some organisations the setting up and management of the test environment of the test environment could be centrally controlled: in this situation, tester would directly liaise with the environment management to ensure the test environment is delivered on time and to specification.
• Preparing and acquiring/copying/creating test data.
• Implementing tests on all test levels, executing and logging the tests, evaluating the results and documenting the deviations from expected results as defects.
• Using test administration or management and test monitoring tools as required.
• Automating tests (may be supported by a developer or a test automation expert).
• Where required, running the test and measuring the performance of components and systems (if applicable).
• Reviewing tests developed by other testers.

 

If specialist testers are not available, then additional resources could be used at different test levels.

 

• For component and integration testing, any additional roles would typically be filled by someone from a development background.
• For system and user acceptance testing, any additional roles would typically be filled by someone from a business or user background.
• System operator (sometimes known as production support) would be responsible for operational acceptance testing.

Within test project a job may contain many roles and tasks.

 

Test Approaches (Test Strategies)

 

 It defines how testing will be implemented. A strategy should be developed early in

 

• In the project life cycle to stop defects.
• Left until start of execution, also called reactive approach. Sometime follow waterfall model/using sequential approach mean next will not start until previous one has nearly finished.

 

 

 

 

There are many approaches/strategies that can be employed including:

 

• Analytical approaches: such as risk based testing where testing is directed to areas of greater risk.
• Model-based approaches: such as stochastic testing using statistical information about failure rates (reliability growth or usage (such as operational profiles).
• Methodical approaches: such as failure based (including error guessing and fault attacks), check list based and quality-characteristic based.
• Standard-compliant approaches, specified by industry compliance standard such as MIRSA.
• Process-compliant approaches, where various processes developed for use with the various agile methodologies or traditional waterfall approaches.
• Dynamic and heuristic approaches: such as exploratory testing where testing is more reactive than pre-planned, and where execution and evaluation are concurrent tasks.
• Consultative approaches: such as those where test coverage is driven primarily by the advice and guidance of technology and/or business domain experts outside or within the test team.
• Regression-averse approaches: such as those that include reuse of existing test material, extensive automation of functional regression tests, and standard test suites.

 

Different approaches can be combined but depend upon the circumstances prevalent in a project at the time.

   Some time standard i.e. MIRSA may dictate to choose a strategy but following factors must be considered when define strategy/approach.

 

·         Risk of failure of the project.

·         Skills and experience of the people in the proposed techniques, tools and methods. There is no point of implementing the sophisticated component-level, technique-driven approach or strategy when the only resources available are business users with no technical grounding.

·         The objective of the testing endeavour and the mission of the testing team. E.g. finding most serious defects.

·         Regulatory aspects such as external and internal regulations for the development process e.g. MIRSA.

·         The nature of the product and the business e.g. different approaches is required for testing mobile phone coverage than for testing an online banking operation.

 

Testing Planning and Estimation

Test Planning

Testing planning normally is under taken by the project leader. It contain a list of tasks and milestone against which the progress against. In other words define the shape of testing efforts in development and implementation project called ‘green field’ as well as maintenance (change and fix) activities. Main document produced in testing planning is called master test plan.

 

  This document defines high level test activities being planned. The details of test-level activities are documented within test level plans e.g. the system test plan.

  The factors influencing the testing process are:

• Risks, test plicy- constraints, scope of testing- resources, test objectives- critically, testability.

 

The content section of plan is normally identical to IEEE829 which is the standard for software test documentation. This standard identifies 16 sections present in the test plan.

         Test is a continuity activity that spans over the life of the project.  As risks and change occurs the plan and planning should be amended to recognize these and reflect the current position.

   Changes are introduced through a change process. The 16 point section is acronym of SPACDIRT which is as:

 

• S= scope (testing items, features to be tested and feature not to be tested ).
• P= people (responsibilities, staff and training and approvals).
• A= approach
• C= criteria (including item pass/fail criteria and suspension and resumption requirements).
• E= environment needs
• D=deliverables (test)
• I= identifier and introduction (test plan)
• R= risks and contingencies
• T=testing tasks and schedule

 

Test- planning Estimation

 

 There are number of testing activities:

 

• Putting together the overall testing approaches (sometimes called test strategy) ensuring that the test levels and entry and exit criteria are defined.
• Liaising with the project manager and making sure that the testing activities have been included within the software life-cycle activities such as: design, development, and implementation.
• Working with the project what to be tested, who plan, test, involved and how test activities should be done, how result will be evaluated and define exit criteria (stop testing).
• Finding and assigning resources for different tasks under taken during testing.
• Deciding what the documentation for the test project will be e.g. which plans, how test cases will be documented etc.
• Defining the management information, including the metrics required and putting in places the processes required to monitor and control test preparation and execution, defect resolution and risk issues.
• Ensuring that the test documentation generate repeatable test assets e.g. test cases.

 

Exit Criteria

 

Exit criteria mean when a test activity will be complete and when it should be stop. There should be a exit criteria for all test project activities e.g. planning, specification and execution as a whole or some specific level for specific specification as well as execution.

Exit criteria must be specified in the relevant plan. Some exit criteria might be:

 

• All test planned have been run.
• A certain level of requirement coverage has been achieved.
• No-high priority or severe defects are lefts outstanding.
• All high risk areas have been fully tested, with only minor residual risks left outstanding.
• Cost-when the budget has been spent.
• Schedule has been achieved e.g. release date has been reached and product has to go live.

 

    It should have been agreed as early as possible in the life cycle, but some time subject to controlled changes but must be understand by those responsible for delivery.

 

Test Estimation

 

There are two approaches:-

 

• Metrics-based
• Expert-based

Metric-based approach:

 

                   It relies upon the data collected from previous or similar projects.

This kind of data include:-

 

• Number of test conditions
• Number of test cases written.
• Number of test cases execution
• Time taken to develop test cases.
• Time taken to run test cases.
• The number of defects found.
• The number of environment outages and how long an average each one tested.

 

Using this approach, quite easy to estimate the accurate time and cost required for similar project.

 

Expert-base approach:-

 

It is relies on the experience of owners of relevant tasks or expert to derive an estimate. It also kwon as Wide Band Delphi approach. In this context, ‘expert’ could be;

 

• Business expert
• Test process consultants.
• Developers
• Technical architects.
• Analysts and designers.
• Anyone with knowledge of the application to be tested or the tasks involved in the process.

 

There are many ways of using this approach e.g.

 

• Distribute a requirement specification to the task owners and get them to estimate for their task in isolation. Amalgamate the individual estimates when received; build in any required contingency, to arrive at the estimate.
• Distribute to known experts who develop their individual view of the overall estimate and then meet together to agree on and or debate the estimate that will go forward.

Many things affect the level of effort required to fulfill the test requirements of a project. These are split into three main categories as:

 

 1: Product characteristics:

 

·         Size of the test basis

·         Complexity of the final product

·         The amount of non-functional requirements

·         The security requirements (perhaps meeting BS7799 (, the security standard).

·         How much documentation is required e.g. some legislation –driven changes demand a certain level of documentation which may be more than an organisation would normally produce ).

·         The availability and quality of the test basis e.g. requirements and specifications.

    2: Development process characteristics:

·         Timescales

·         Amount of budget available

·         Skills of those involved in the testing and development activity ( the lower the skill level in development, the more defects could be introduced, and the lower the skill level in testing, the more detailed the test documentation needs to be );

  

·         Which tools are being used across the life cycle ( i.e. the amount of automated testing will affect the effort required ).

 

   3: Expected outcome of testing such as:

 

•  The amount of errors
• Test cases to be written.

 

Taking all of this into account, once the estimate is developed and agreed the test leader can set about identifying the required resources and building the detailed plan.

 

Test Progress Monitoring and Control

 

1: Test Progress monitoring

 

The activities and timescale determined within the test plan are constantly monitored, mean what is actually happened. The purpose of test progress monitoring is to provide feed back and visibility of the progress of test activities.

      The data required to monitor progress can be collected manually e.g. test cases developed or by using test management tools or to collect the data as an automatic output from a tool either already formatted into a report or as a data file that can be manipulated to present the picture of progress. The progress data is also used to measure exit criteria such as test coverage e.g. 50percentage requirement coverage achieved.

 Common test metrics include:

 

• Percentage of work done in test case preparation (percentage of planned test cases prepared).
• Percentage of work done in test environment preparation.
• Test case execution (e.g. number of test cases run/not run, and test cases passed/failed).
• Defect information (e.g. defect density, defects found and fixed, failure rate and retest results).
• Test coverage of requirements, risks or code.
• Subjective confidence of testers in the product.
• Dates of test milestones.
• Testing costs, including the cost compared with the benefits of finding the next defect or to run the next test.

These metrics are used to track progress towards the completion testing, which is determined by the exit criteria. So exit criteria are directly related to metrics.

        There is a trend towards ‘dash board’ which reflects all of the relevant metrics on single screen or page ensuring maximum impact. For a dashboard, and generally when delivering metrics, it is best to use a relatively small but impact-worthy subset of various metric options available. Because reader does not want to wade through lots of data for the key information they are after, which invariably is ‘are we on target to complete on time?’

 Metrics are displayed in graphical form which reflects progress on the running test cases and report on defects found.

 

  

2: Test Reporting

 

 It is a process of reporting test metrics in summarized form updating the reader regarding the testing tasks undertaken.

 

The reported information can include:-

 

• What happened during a given period of time e.g. a week, a test level, whole test endeavour or when exit criteria have been met?
• Analysed information and metrics required to support recommendations and decisions about future actions. Such as :-
  1. an assessment of defects remaining;
  2. The economic benefits of continued testing e.g. additional testes are exponentially more expensive than the benefit of running.
  3. Outstanding risks.
  4. The level of confidence in tested software e.g. defects planned vs. actual defects found.

 

 The IEEE 829 standard include outline of test reporting summary which could be used for test reporting.

 

1. Test summary report identifier; e.g. TSRXYZ.
2. Summary- documents the environment in which the test activity being reported on took place.
3. Variances- test strategy, plan, specification, procedures etc.
4. Comprehensive assessment.
5. Summary results;- results from test activities, include detailed defects raised and fined and those that remain unresolved.
6. Evaluating;-quality of test, pass/fail criteria.
7. Summary of activities:- major testing activities, test environment, unavailability, successor weakness test specification process etc. should include resource usage data e.g. planned spend against the actual plan.
8. Approvals;- identifies all approvers of the document.

 

This information’s could also be used to help to process improvement activities.

 This information could be used to assess whether:-

• Goals for testing were correctly set (achieved, if not why?)
• Test approach/ strategy were adequate (e.g. did it ensure there was enough coverage?).
• Testing was effective in ensuring that the objectives of testing were met.

 

 

 

3: Test Control

 

 Test control uses the information’s collected in the monitoring and reporting phases to decide on a course of action to ensure control of test activities is maintained and exit criteria are met. It needs only when planned test activities are behind the schedule.

    The action taken could impact any of the test activities and may also affect other software life cycle activities.

 Examples are:

• Reprioritizes tests when an identified project risk occurs (e.g. software delivered late).
• Change the test schedule due to availability of a test environment.
• Set an entry criterion requiring fixes to be retested by a developer before accepting them into a build (this is particularly useful when defect fixes continually fail again when retested).
• Review of product risks and perhaps changing the risk ratings to meet the target.
• Adjusting the scope of the testing (perhaps the amount of tests to be run) to manage the testing of late change requests.

 

The following are not the responsibility of the test leader but not stop him to making recommendation to the project manager.

• De-scoping functionality e.g. removing less important planned deliverable from the initial delivered solution to reduce the time and effort required to achieve that solution.
• Delaying release into the production environment until exit criteria have been met.
• Continuing testing after delivery into the production environment so that defects are found before they occur in production.

 

Incident Management

 

 An unplanned event occurring that requires further investigation. In testing, anything where the actual result is different to the expected result.

  Incidents can be reviewed at any time in the software life cycle e.g. from review of the test basis (requirements, specifications etc) to test specification to test execution.

                 Incident management, according to IEEE 1044 (standard specification for software anomalies), is ‘the process of recognizing, investigation, testing action and disposing of incidents. It involves recording incidents, classifying them and identifying the impact.

           The process of incident management ensures that incidents are tracked ensures that incidents are tracked from reorganization to correction, and finally through  retest and closure. It is important that organisations documents their incident management process and ensure they have appointed someone (often called an incident manager/coordinator) to mange/police the process.

          Incidents are raised an incident reports via electronically or on paper.

 

Incidents are raised on incident reports have the following objectives.

·         To provide developers and other parties (involved in testing) with feedback on the problem to enable identification, isolation and correction as necessary. The more information’s provided the better.

·         Provide test leader to track quality of system under test and progress of testing. One of the key metrics used to measure progress is a view of how many incidents are raised; their priority and finally those they have been corrected and signed off.

·         To provide ideas for test improvement. For each incident the point of injection should be documented e.g. a defect in requirements or code and subsequent process improvement can focus on that particular area to stop the same defect occurring again.

 

The detail that normally included on an incident is:-

 

• Date of issue, issuing organisation, author, approvals and status.
• Scope, severity and priority of the incident.
• References, including the identity of the test case specification that revealed the problem.
• Expected and actual results.
• Date the incident was discovered.
• Identification or configuration item of the software or system.
• Software or system life-cycle process in which the incident was observed.
• Description of the anomaly to enable resolution.
• Degree of impact on the stakeholder(s) interests.
• Severity of the impact on the system.
• Urgency/priority to fix.
• Status of the incident (e.g. open, deferred, duplicate, waiting to be fixed, fixed awaiting confirmation test or closed).
• Conclusions and recommendations.
• Global issues, such as other areas that may be affected by a change resulting from the incident.
• Change history, such as the sequence of actions taken by project team members with respect to the incident to isolate, repair and confirm it as fixed.

 

The IEEE829 contains the outline of a test incident report. Which are as:-

 

• Test incident report identifier: the unique identifier assigned to this test incident report.
• Summary: a summary of the incident, detailing where expected and actual results differ, identifying at a high level the items that are affected, and the steps leading up to the recognition of the incident e.g. if in test execution, which test was executed and the actual key strokes and data loaded.
• Incident description: a detailed description of the incident, which should include:
  1. Inputs. 2. Expected results 3: actual results 4: anomalies 5: date and time.

6: procedure step 7: environment 8: attempts to repeat 9: tester’s comments

10: Observer’s comments should also include any information regarding possible causes and solutions.

 

• Impact: if known, document what impact the incident has on progress.

 

 

Configuration Management

 

Configuration management is the process of managing products, facilities and processes by managing the information about them; including changes and ensuring they are what they are supposed to be in every case.

          In testing configuration management will involve controlling both the versions of code to be tested and the documents used during the development process e.g. requirements design and plans.

 Configuration management should ensure traceability throughout the test process e.g. a requirement should be a traceable through to the test cases that are run to test its level of quality and vice versa.

 

        Effective configuration management is important for the test process as the contents of each release of software into a test environment must be understood and at the correct version, otherwise testers could end up wasting time because either they are testing an invalid release of the software or the release does not integrate successfully, leading to the failure of many test.

    A good configuration management system will ensure that the testers can identify exactly what code they are testing, as well as have control over the test documentation such as test plans, test specification, defect logs etc.

 

 

 

 

 

 

Chapter 6:

What is a test tool?

 

 A software product that supports one or more test activities, such as planning and control, specification, building initial files and data, test execution and test analysis.

 

            It is a piece of software that is used to make the testing process more effective or efficient, meaning making testing easier, quicker, more  accurate etc.

 

Benefits and Risks

 

Test tools need to be thought of as long-term investment that need maintenance to provide long-term benefits, mean upfront investment and ongoing maintenance and support can provide substantial income in return. Moreover cost needs to be less than the cost of performing testing activities without the tool if the investment is to be worthwhile.

 

 

Comparator Tool

 

It can be used virtually straight out of the box. A comparator can check whether one large test file is the same as another, if different report upon the difference but manually doing so is different.

 

            In addition, incident management tools are fairly intuitive and easy for both experience and novice testers to use. They are likely to provide a ‘quick win’.

 

Other tools built in house by developers e.g. test harnesses, test oracle or test data preparation tools relatively easy for developers to produce with a good understanding of the tool management and the system and databases in the test environment.

 

Benefits

 

The amount of time and effort spent performing routine, mundane, repetitive tasks is greatly reduced. And a tester can spend this time to other key tasks, such as planning, analysis and design.

Using tools provide more predictable and consistent results as human failing such as manual keying errors, misunderstandings, incorrect assumptions, forgetfulness etc are eliminated.

   The widespread use of databases to hold the data input, processed or captured by the test tool, means that it is generally much easier and quicker to obtain and present accurate test management information, such as test progress, incidents found/fixed etc.

 

Risks

 

Risks associated with test tools are:

 

• Over-optimistic expectations
• Lack of appreciation of effort required to implement and benefits that the tool can bring.

 

More over test environment is not designed and built with the test tools in mind, for a vendor to demonstrate the shortcomings it may encounter in a typical test environment.

 

Test Tools

 

Type of tool

 

       There are several ways to classified then

 

• Fundamental test process (Primarily associated).
• Type of testing that supports
• Who use them?

 

In ISTQB foundation level test tools will be classified according to type of activity they support.

 

Tool support for management of Testing and Tests

 

Test Management Tools

 

• Provide various activities and tasks through out the development life cycle.
• Some activities to interface to other more specialist tools

E.g. Requirement Management tool, text execution tool, incident management tool and configuration management tool.

 

Test management tools provide a framework for creating, storing and editing test procedures.

 These may be linked or traced to requirements, test condition and risks.

 

Such test procedures can be prioritized or grouped together and scheduled so that they are run in the most effective and efficient ways or order. Some test management tools allow decencies to be recorded so that test will fail owning to known defect can be highlighted and left unexecuted.

Tests can be recorded as passed or failed so that an incident be raised if the actual and expected results differ.

            Test management tools generally ho;d data imn a database. This allows a large amount of reports and metrics to be produce. The metrics are as;

 

• Test and project management to control the current project.
• Estimated for future projects.
• Identifying weaknesses or inefficiencies in the development or test process that can be subsequently investigated with the aim of improving them.

 

Test management information’s reports should be designed to meet the needs of project managers and other key users.

 

It can also enable reuse of existing test ware in future test projects.

 

Incident Management Tools

 

 It is also known as defect management tool. At the basic level provide two critical activities:-

 

• Creation of the incident report.
• Maintenance of details about the incident as it progresses through the incident life cycle.

 

Sometime lots of mandatory information is required in order to comply with industry or generic standard IEEE1044 to ensure agreed incident life cycle is strictly applied.

 

Incidents are only able to be assigned to particular teams or users.

 

             It also use database to store and mange details of incidents. Incidents to be categorized according to values stored in appropriated fields. Such values change during the incident life cycle as incident analysed, debugged, fixed and confirmation tested. It also views the history for management information about incidents. And also search using SQL-type questions.

 

It can also be used in conjunction with data held in test management tools when planning and estimating for future projects. It also analysed to provide input to test process improvements projects. The field in database structure normally include:-

 

• Priority (H, M, L).
• Severity
• Assignee (to whom incident assign).
• Status in the incident life cycle (New, Open, Fixed, Reopen, Closed).

 

These tools can be integrated with test management, requirements management and or test execution tools which enable incidents to be input and related to test cases and requirements. It used to raise defects during regression testing.

 

Requirement Management Tools

 

 It is used by business analyst to record, manage and prioritize requirements of a system and also used to manage changes to requirements.

If requirements change after tests have been written then test cases may also need t change then these changes issues to developers.

 The tractability function within which this too enable links and references to be made between requirements, functions, test conditions and other test ware items. This mean, as requirements change, it is easy to identify which other items may need to change.

Requirement tools also enable requirements coverage metrics to be calculated easily as tractability enable test cases to be mapped to requirement.

 

As seen, traceability can create a lot of maintenance work but it does highlight those areas that are undergoing change.

 

Tester obtain requirement from the tool and begin to devise test conditions and test cases. Tractability within requirements tool will also highlight the test conditions affected by the changed requirement.

 

Configuration Management Tools

 

Mainly developed for management: the versions of different software (hardware) components that comprise a complete build of the systems; and various complete builds of systems that exit for various software platforms over a period of time;

 

 What is build:   a development activity where a complete system is compiled and linked (typically daily) so that a consistent system is available at any time including all latest changes?

 

Benefits of Configuration Management Tools

 

The benefits largely depend upon the following:

1. Complexity of system architecture.
2. Number and frequency of builds of the integrated systems.
3. Number of choice available to customer (internal or external )

 

CM tools allow traceability between test ware and builds of an integrated system and versions of subsystems and modules. Traceability is useful for:

 

1. Identification of correct versions of test procedure to be used.
2. Determination of test procedures and test ware reused, updated and maintained.
3. Assistance of the debugging process in case of failure of running a test procedure could be traced back to the appropriate version of a subsystem.

 

Tool support for static testing

 

Review Process Support Tools

 

These tools provide framework or inspections. This can include:

 

1. Maintaining information: rules and checklists.
2. Record, communicate and retain review comments and defects.
3. Ability to amend and reissue the deliverable under review whilst retaining a history or log of the changes made.
4. Traceability functions to enable changes to deliverable under review and other deliverable that may be affected by the change.
5. Use web technology to provide access to this information’s any where.

 

This tool interfaces the configuration management tool to control version number of a document under review. It is good for technical/peer review but not for walk through and informal reviews. Management buy in if it benefits are long run.

 

Static Analysis Tool

 

It enables developers to analyse code before its execution or find defects early as possible. These tools generate lot of errors and warning message about the code. Used for medium to large changes good but not for small changes in code. Could also used for messages that are not relevant and finds defects that are hard to find during dynamic testing. Used to understanding code and to calculate complexity and other metrics. Some are integrated dynamic tools and coverage management tools and are language specific. E.g. code written in c needs to have static analysis tool that specific to c.

 

Types of defects that can be found using a static analysis tools can include:

 

1. Syntax error e.g. spelling or missing punctuation
2. Variance from programming standard e.g. too difficult to maintain.
3. Invalid code structures. (Missing ENDIF statements).
4. Modules or code may not be executed or unreachable code or invalid code dependencies may point to errors in code structure.
5. Portability (e.g. code compiles on window but not on UNIX).
6. Security vulnerabilities.
7. Inconsistence interfaces between components (e.g. XML message produced by a component is not of the correct format to be read by component B).
8. References to variables that have a null value or variables declared but never used.

 

Modelling Tools

It is used by developers for

• Analysis
• Design stages of development cycles.

 

• Benefits: cost effective at finding defects at early stage of development life cycle. Benefits similar to reviews and inspections.

 

• Allow omissions and inconsistencies to be identified and fined early so that detailed design and programming can begin from a consistent and robust model.

 

• Designers use UML to build a model of the software specification.

 

• It can map business processes to the system architecture model. This enable programmer and testers to have a better and common understanding of what program should do and testing is required.

States object models, databases can help to identify what testing is required and assist in checking whether tests cover all necessary transactions useful for complex system.

 

Tool support for test specification

Test design tools

 

1. Use for creating test cases (For which test basis needs to be input and maintain).
2. integrated with
   • modeling tools
   • requirement management tools
   • static analysis tools
   • Test management tools.

 

1. Some tools allow a GUI model of the test basis to be created and then allow tests to be generated from this model.
2. Some tool (Test frames) generated template from requirement specification held in narrative form.
3. Test designed from state, object, database can be used to verify that model built correctly and used to derive test cases.
4. Test oracle is a type of test design tool that automatically generate expected results.
5. Test oracle replacement systems, migrations and regression testing.
6. Test design tools useful for safety critical, high risk software when coverage level is higher and industry, defence or government standards need to be adhered to.

 

 Test Data Preparation Tools

 

 These are used by developers to manipulate data so that environment is in appropriate state for test to be run.

 

Tools Support for test execution and logging

Test Comparators

It compares the contents of files, data bases, XML messages, object and other electronic data formats. Also compare the actual result and expected results. Highlight difference and provide assistance to developers when localizing and debugging code.

Provide function to ignored specified section of file, screen or object or masked out. Used date or time stamped technique for this. It is useful for regression testing because the output or interface files should usually be the same. This is the onley benefits of this tool and included in the execution tools.

 

Test Execution Tools

 

This allows test scripts to run automatically or semi automatically.

 

Test Script:  written in programming language or scripting language and used to navigate through system under test and to compare predefined expected outcomes with actual outcomes. At last result of test run written in test log. Test script can then be amended and reused to run different scenarios through the same system.

 

1.      Record tools (capture playback): used to record test script and then play back exactly as it was executed. The recordings of tests are useful during exploratory testing for reproducing a defect or for documenting how to execute a test. These tools can be used to capture user actions so that navigation through a system can be recorded. In both cases the script can then be made more robust by the technical expert so that it handles valid system behaviours depending upon the inputs and the state of the system under test.

2.      Data-driven testing: robust test script that deal with various inputs can be converted indo data driven test. This is where hard-coded inputs in the test script are replaced with variables that point to data in a data-table.

3.      Key-driven testing: it is further enhancement of data driven testing or action word. Include extra column in the data table. The script read the keyword and takes the appropriate actions and subsequent path through the system under test. E.g. IF ELSE OR SELECT CASE statements are required in the test script for keyword-driven testing.

4.      Technical skills: programming skills and standard are required to use the tool effectively. manual testing also relies on the robust and well driven test scripts that are easy to maintain

5.      Maintenance: for maintenance of test script time and budget is required. And change to a system can mean that the test scripts need to be update. So relevant skills and knowledge is also required to do this.

6.      Effective and Efficient Use: the following are benefits:

a: cost savings as a result of the time saved by running automated tests rather manual tests.

b: accuracy benefits from avoiding manual errors in execution and comparison.

c: the ability and flexibility to use skilled testers on more useful and interesting tasks  than running repetitive manual tests.

d: the speed with which the results of the regression pack can be obtained. They are generally more useful for regression testing.

The automated test scripts to produce the amended documents would need to be analysed and updated as required. Automated scripts for new documents could be added to the regression pack after this release is complete.

       At start the manual regression testing is cheaper but for long term benefits of automated regression testing is more beneficial and cost effective.

 

Test Harnesses

 

Used by developers and written in house by developers to perform component or integration testing for specific purpose. It is also used to test various objects ranging from a middleware system to a single or small group of components.

 Easy to control and manage the small environment. Enable tester/developers to localize defects quicker and turn-around time to fix those defects.

 It is based on the similar principle of data-driven testing using test execution tools, for test harness different kind of test cases to be designed and run without the time-consuming process of keying them manually.

 The benefits of which one is best between the test execution tool and test harness depends upon the, task, environment, risk, purpose and level of the testing being performed.

 

 

 

 

Coverage Measurement Tools

 

It is used to measure the percentage of code structure covered across the white box measurement techniques such as statement coverage and branch or decision coverage. More over it is used to measure the modules and functions calls. It is often integrated with static and dynamic analysis tools and are primarily used by developers. It can measure the code written in any language but not all tools. Good for reporting coverage measurement and can therefore be used to assess test completion criteria and or exit criteria. Coverage measurement of requirements and test cases/scripts run can usually be obtained from test management tools. More over is used to instrumenting the code with extra statements, extra statement written into log and finally remove before execution goes into production. It is generally used on high risk and safety critical systems.

 

Security Tools

 

These tools are used to detect security threats, support execution of test procedures to confirm that different security issues handled (defect) i.e. viruses, denial of services and any other attacks.

They are useful for testing e-commerce, e-business and websites. A person of security tools expertise must be select for security like testing.

 

Tool support for performance and monitoring

 

Dynamic analysis tools

 

These are used to find defects that hard to find during static testing, used by developers, during component testing and component integration testing to:-

·         Report on the state of software during its execution;

·         Monitor the allocation, use and reallocation of memory.

·         Identify memory leaks

·         Detect time dependencies

·         Identify unassigned pointers

·         Check pointer arithmetic

Further more they are used for safety critical and high risk software where reliability is critical. Moreover these are integrated with static analysis and coverage measurement tools.

 

Developers used static analysis to find defects before component test execution. The integrated tool may allow;

 

• The code to be analysed statically
• The code to be instrumented
• The code to be executed (dynamically)

 

Dynamic analysis tool usually language specific. The tool could then;

 

• Report static defects
• Report dynamic defects
• Provide coverage measurement figures
• Report upon the code being (dynamically)\executed at various instrumentation points.

 

Performance testing/load testing/stress testing tools

 

Performance testing tools have been developed to carry out both loading and stress testing. It is difficult to do accurately and in a repeatable way without using test tools;

 

Load Testing

 

 This testing reports upon the performance of a system under test, under various loads and usage patterns. A test driver can be used to simulate the load or usage pattern. Alternatively, response time or transaction times can be measured under various levels of usage by running automated repetitive test scripts via the user interface of the system under test. In both cases output will be written to a log. Reports or graphs can be generated from the contents of the log to monitor the level of performance.

 

Performance Testing

 

This tool is also be used for stress testing. In this case load on the system under test is increased gradually in order to identify the usage pattern or load at which the system under test fails e.g. if an air traffic control system support 200 concurrent aircraft in the defined air space , the entry of the 201^st or 205^th aircraft should not cause the whole system to fail. It can also be used against the whole systems but they can also be used during system integration test to test an integrated group of systems, one or more servers, one or more databases or a whole environment.

         If the risk analysis finds that the likelihood of performance degradation is low then it is likely that no performance testing will be carried out. E.g. a small enhancement in the existing mainframe system not necessary for formal performance testing, For this normal manual testing may be considered sufficient.

 

There are similarities between performance testing tools and test execution tools in that they both use test scripts and data driven testing.

 

Performance testing tools can find the defects such as;

 

• General performance problems
• Performance bottlenecks
• Memory leakage (e.g. if system running under heavy load for some time).
• Record-tracking problems
• Concurrency problems
• Excess usage of system resources
• Exhaustion of disk space

The cost of some performance tools is high and the implementation and training costs are also high.

 

Monitoring Tools

 

These tools are used to check whether;

 

·         Systems are available

·         Their performance is acceptable

·         Used for monitoring e-commerce, e-business, websites because their affects consequences are severe.

·         Less important for internal system because due to failure, in organisation there is contingency plan to resolve it.

It is not actually a testing tool but good for performance testing.

 

Other Tools

 

Not assigned for testers/developers but could be used to support one or more test activities;

• Spreadsheets
• Word processors
• E-mail
• Backup and restore utilities
• SQL and other database query tools
• Project planning tools
• Debugging tools

 

In absence of test management and incident management tools, spreadsheets are normally used for recording, tracking and maintaining. Test pass or fail could be recorded on spreadsheets.

 

1. Spreadsheets- for producing decision tables, different test scenario required, manipulate test management information.
2. Word-Processor- writing test strategies, plans, weekly reports and test deliverable.
3. E-mail- communication with developers about defects, distributing reports and other deliverables.
4. Back-up and restore utilities- restore a consistent set of a data into the test environment for regression testing.
5. SQL- for analyzing data to obtain actual or expected results.
6. Project- estimating resources, timescales, monitor progress.
7. Debugging-by developers to localize and fix defects.

 

 

 

 

 

Introducing a tool into an organisation

Leadership and Practical Management in East and West

MANAGEMENT THEORIES AND LEADERSHIP STYLE

Author: Muhammad Irfan Aslam Cheema

University of Salford

A Greater Manchester University

Greater Manchester

England, U.K

 

 

ITRODUCTION

 

The word leadership has got much attention in last few years due to the rapid and continuous changes because change is endemic. So organisation must be cared and prepared to adapt the readily all sort of changes. For effective and flexible strategy development and implementation need a competent and effective leadership in management, which is integral part for success in today changing organisation environment and power culture? It is need of hour to understand the psychology and need of individuals and group needs to influence, motivate and lead to achieve the organisation goals and objectives (task needs) in best possible way which is critical for business (survival) and strategy (vision for future)?

 

More over it is very important for adding value to business and for organisation’s successfulness to understand the management behaviour and style of leading subordinates when exercising power or using position.

 

The main objective/purpose of this paper is to look insight the characteristics of the leadership style using two theories and their comparison and application in real world.

 

HERESY AND BLANCHARD’S SITUATIONAL MODEL

 

The Heresy and Blanchard modulate the maturity into four different categories which show in the model below. In other word’s I could say that is job-centered and team-centered approach. So both theorists describe their model based on three factors which are as:

• Job/Task/Objectives.

• Situation/ Nature of task, Organisation structure and environment, follower readiness.

• Group/Team ability, skill and commitment.

 

So effective and efficient leader is who manage these to achieve goal and objectives of the organisation.

Diagram .1 Sources: [7]

 

Diagram 2: source [8]

 

Leadership styles suggested in this theory (empirical based) are:

 

1. TELLING

Telling style of management, in this style gives dictation to subordinates and strictly follows up the decision. So this could generate coercive from followers.

 

1. SELLINNG

Selling style of management adopted when leader is alone and has complete information’s on which decision is based upon.

 

1. PARTICIPATING/CONSULTATION

Consulting style of management, consult with subordinates but manger has control for final decision. Provide some degree of subordinate involvement.

 

1. DELEGATING/EMPOWERING

In this style of management manager/leader leader choose when s/he sell the decision and failed. In this style group make decision according to defined limits which is fit for problem. But the as leader s/he will take all responsibility and accountability of the decision.

 

1. JOINING

In joining style of management, in this style manager role as leader is to chair the meeting to emerge out the decision after group discussion and don’t impose his/her decision as peer/head because s/he is part of group.

 

TANNENBAUM AND SCHMIDT

 

In most organisations, problem arises for managers to decide which action is best for handling particular situation to achieve objectives.

So for providing meaning/description of leadership behaviour both researchers suggest a continuum illustrated as below.

 

 

Diagram 3: Source [6]

 

In left side of continuum depicted the high degree of managerial control/boss-centered approach. Where as in right side of this model it shows the delegation of manager to their sub-ordinates/sub-ordinate centered leadership style for decision making.

 

COMPARISON AND CRITICAL ANALYSIS OF BOTH THEORIES

 

If we check both model all activities along the curve of Hersey and Blanchard model are same to the diagonal line of the Tannenbaum and Schmidt’s model.

 

The fundamental objective of the Heresy and Blanchard’s situational leadership theory [SLT] is to determine of the leader behaviour with task and follower’s readiness. The situation of the leader behaviour is based on the level of task and level of follower/employee readiness. As the task and level of readiness is change, leader behaviour changes [1]. So the leader behaviour with task and relationship could be effective when follower’s readiness match with leader behaviour. The follower readiness is the maturity/ability of the followers. Both behaviour and readiness are necessary for the specified job/task to complete or being directed to complete. In heresy and Blanchard situational model briefly described above show the high degree of leader maturity but it depends upon the situation, skill of team members and task nature.

 

Hersey, Blanchard and Johnson [4] did not plead the coercion for workers which according to them is horrible and insecure. According to them situational model is fit for all situations where to influence the behaviour of others. As written down above it provides important variables (e.g. Task, Situation, Team) to adopt the particular style when dealing people and handling task.

Vecchio critical features of behaviour which already identified are focused in this model too [5]. So no body could say its theory superior than others. A critique conducted by the Claude Graeff [3] presented and disregarded it on based on pragmatic and theoretical level. Further more, Graeff said that this four dimension model in two dimension graph is a critical problem for the theory

In Tannenbaum and Schmidt’s model is showing scale of time and employees commitment. Tannenbaum and Schmidt’s model left side show autocratic style, in this area boss/leader uses his/her own decision i.e. “de facto decision” [2]. This side shows the less maturity of the leader/manager. Using this style leader uses force, position, threat and punitive actions to achieve the shared goals. The authoritative action is stitch to organisational objectives and goals. In this style task is priority not individual or group which is major disadvantage of this approach.

The right side of model shows the democratic style of leadership. It shows the maturity of the leadership skill and perception. In this style sub-ordinate has their participation in goal setting, criticizing but within defined limits set in the task objective which already set by the boss or senior executives.

Authoritative approach is commonly effective for short-term goals but democratic approach which is participative and for long-term objectives. Tennenbaum and Schmidt’s model has advantage that it gives leaders a range of choices and focus on the more specified criteria. More over this model has made difficult for others to develop the relevant theories and research. So organisation and business always think for long term not for short terms for its survival.

 

At last we could say that both are situational or contingency theories of leadership.

 

 

 

 

MANAGEMENT THEORIES IN PRACTICE

 

MANAGEMNT THEORIES AND ROLE OF HR MANAGER IN EAST

 

Cino-Pak International Traders has a flat managerial structure which consists of General Manager, Human Resource (HR) Manger, Financial manager, Export Manager, Marketing and Sale Managers, and Administration Manager. I was the Head of HR department with one Assistant Manager and two recruitment officers. Our department main job was to recruit the new staff and develop the different training programmes and arrange meetings of company officials etc.

 

Mostly, I discussed departmental matters with my assistant and rarely involved the others. My view was that there is no need to involve the junior staff in policy matters and think it is better and comfortable for me. I saw my self perfect and knowledgeable than others. My staff always expected they should be involved and used their professionalism and ability in both innovative and routine work. I used mostly “Telling” Style but some time discuss with my assistant managers and involved others rarely mentioned above used “Selling” style because I was responsible and accountable for any concerns. So I used the authoritative behaviour in form of telling and selling to achieve the company goals and objective through power and position. I did not trust in their ability and as a result created anger, coercion and suppress.

 

But according to my knowledge in our country authoritative style of leading and managing has been adopted due to cultural and environmental effects because most of companies are private. In public sector companies this style of leadership is exercising also.

 

MANAGEMENT THEORIES AND SKILLED WORKER OBSERVATION IN WEST

 

In U.K when I joined the Northern Foods Plc Hull in Aug 2004 as skilled worker I observed that there are regular workers meetings to tell about company news regarding profit, new procedures and asked for comments and suggestion regarding something discussed if someone has. In this way Workers think that they are important for company and feel pleasure and get motivated to perform their job efficiently and effectively. In this company the leading style is “Consulting” and “Participating” and some time “Joining” For example last year the absent level was too high as a result company lost their profit. It is still a challenging task that how to drive out the absence cost and reduce its level. So management arranged meetings and discussion session on it at all level to resolve this discrepancy. Further more last week company General Manager gave presentation to increase the workers salary 2% and told company financial condition. Employee union leaders said we will take it in election and know the workers opinion in this regard and then will inform you that we are accepting your offer or not. In other word according to Tannenbaum and Schmidt model there is a democratic way of leading and managing people which is most effectively using in EU and other western countries mostly not for others.

 

CONCLUSION

 

Overall, the behaviour of leadership style and the approaches used in Hersey and Blanchard and in tannenbaum and Schmidt’s model are valuable contribution. These theories are more realistic then other management theories. Both theories provide different leading styles but did not suggest which one is best to adopt in all situations. If we attempt to find a best leadership style is an extremely complex and challenging task for a leader. The finding of this study shows that leaders should not restrict to one leadership style, with aim of developing and creating the best possible environment and achieving the highest possible performance outcomes on the part of followers. The Heresy and Blanchard theory according to different researchers need further research and clarification and must encompasses more variables within the leading situation. The leader must be well activated, flexible, open-minded, well-informed and adaptable. An old saying is “a wise man would not have any fixed thinking, but adopt the views of others as his own”. In my point of view this saying is a good edge for leaders/managers to think and adopt when leading and managing people.

 

REFERENCES

 

[1]:Blank, W., Weitzel, J.R. and Green, S.G. (1990), “A test of the situational leadership theory”,

Personnel Psychology, Vol. 43 No. 3, pp. 579-97.

[2]: George T.,Y. Zotos & P. Dekoulou (2007), “Leadership style in the top Greek media companies: Leading people with mixed style”, The International Journal on Media Management, 9(2), P( 77-86).

[3]: Graeff, Claude L. 1983. “The situational leadership theory: A critical view”. Academy of

Management Review. 8 (2): 285-291.

[4]: Hersey, Paul, Kenneth H. Blanchard and Dewey E. Johnson. 2001.” Management of

Organizational behavior: Leading human resources. 8^th ed”, Upper Saddle, NJ: Prentice Hall.

[5]: Vecchio, Robert P. 1987.” Situational leadership theory: An examination of a prescriptive theory”, Journal of Applied Psychology. 72 (3): 444-451.

[6]http://www.whitestag.org/resources/sb217.htm Accessed date (02/07/2007).

[7]:http://www.ceeol.com/aspx/getdocument.aspx?logid=5&id=AC427B1E-CBA0-4323-AE41- E854EB835109 Accessed date (28/06/2007).

[8]:http://www.enviedentreprendre.com/images/motivation1.jpg Accessed date (11/07/2007).

 

1

Project Management (IT related), A trader Project Implementation for an English National Bank

 

TRADER PROJECT A CRITICAL ANALYSIS

Author: Muhammad Irfan Aslam Cheema

University of Salford

A Greater Manchester University

Greater Manchester

England, U.K

ITRODUCTION

 

As change is a constant factor due to technological development which not affect our lives but the organisations and businesses too. It is rarely implemented in the same ways in organisation as in our lives. The technology brought changes which could be incorporated through projects that need to be managed across the organisations, departments. To handle this project management methodology and disciplines bring significant benefits.

 

However every organisation has finite resources so it is necessary to limit these to initiate a project and control and implementation. Managing the project portfolio effective and efficiently. So project management is best method for change management of acquisition, enhancement and implementing the new trader project software in Barwest Bank to handle the international trade and finance problems effectively and efficiently.

 

WHAT IS A PROJECT?

 

A project is a temporary endeavour undertaken to create unique product or service [2]. A project consists of following disciplines:

 

• A start and end date (e.g. finish within five months time period).

• Multi disciplinary team (ABC team and Bank IT team work together).

• Constraint of Cost, time and quality (fixed cost, now negotiated time).

• Scope of work. (Implementing the Trader Project to handle financial issues internationally).

 

 

 

 

BUSINESS ISSUES/PROJECT ENVIRONMENT

 

In Barwest Bank the major tasks were to automate the FSO/FABs work so that finance and others activities at internationally conducted accurately, reduction in staff, increase market shares 40%. Reduction staff could raise the aggression among the staff already involved in the activities which were being automated. Some staff members could hesitate to use the new system and could not pay proper attentions on this issue. First needed to handle these concerns through communication and tell them the true benefits. For working on internationally there was a need of communication link. It was necessary for Barwest Bank to also parallel run its business with enhancement and implementation of new system through Trader Project (TP) to handle the customer queries without any interruption. There was lack of coordination amongst the stake holders e.g. Bernard Bresslaw and other regional directors. So lack of coordination and commitment generated conflicts regarding finance and extra staff timing, hardware e.g. in letter dated December 1. Before introducing any change in the organisation, there is need of coordination and commitment among the key stakeholders e.g. Board of Directors in Barwest Bank and even among the staff of the organisation too. This is the way through which could bring true benefits of the new system being developed. Otherwise the new system could suffer the whole organisation and become a financial burden and create chaos in the organistion e.g. Barwest Bank trader project. In this project environment is chaotic and coerced.

 

BUSINESS CASE/FINANCIAL ISSUES

 

In trader Project the business case was not prepared, reviewed carefully. In trader project no mission statement set, no risk and requirements analysis managed effectively e.g.email-1. More over these factors were also not managed properly.

 

• Cost/Benefit Analysis/Financial Issues: In trader project budget was not set carefully. There was not given any budget tolerance in trader project. It was bad to stitch with fixed budget at early stage. In other words the trader project sponsors were over optimistic regarding budget, time and benefits. If time was priority then there should be flexibility on the budget side, gave tolerance and reasonable contingency for unexpected risks and issues which were not carefully analysed. Moreover, if we check the project progress it revealed that the benefits which the sponsors set in view of cost of budget, staff and time could not achieved because project cost is more than double as compared to the project budget. How could bank achieve true benefits? When you set budget sponsors should discuss with project manager to understand fully all the explicit and hidden costs (basic and technical cost) to help to control cost more accurately during the project development life cycle. Estimate is not once off need more review in case of major change e.g. tight schedule and fixed budget were major challenges in trader project.

 

RISK/ISSUES ANALYSIS

 

In trader project the risks were not considered carefully and avoided those which were vague and important to managed e.g. email-1.Moreover, other risks like hardware, software, accommodation, unscheduled over time, printer etc in e.g. emails -4, 5,10,13,14,15,16,19 were not managed and mitigated effectively at early stage, which as a result raised during the project development life cycle.

 

TECHNICAL ISSUES

 

In trader project the technical issues were not managed successfully. Which are as?

 

• Data loading problem for programs testing which in result unable to response to the customer enquiries and cause project slippage E-mail 10.

• Due to error in tape and coding error which caused loading problem. So no equipment was available to handle this issue.

• For communication between different branches a communication link needed which was not considered for equipment sharing.

• According to email 4: and 16: printer problems which were severed for the team to carry out their work.

• Impractical to share the terminal e.g. E-mail 13

• Shortage of kit to server FSBs purpose.

• Software maintenance and upgrade were not considered need which is necessary for Bank.

• Disk space/IMB drives problems which was critical was not considered before which was important for data/record storage for testing.

 

Different technical issues should be resolved before planning through risk analysis. So that they not appear during the project, if appeared could be handled easily without wasting time and cost. Which really affect project completion time, cost and quality (scope)? But in trader project these technical issues generated due to poor risk management.

 

PROJECT MANAGEMENT ACTIVITIES

 

PROJECT PLANNING

 

In any project, plan is most important function. It is better to develop it with after consultation with team members. In Trader Project there is no project definition (PD) which is one of the most important things before starting a project. It is a process of selection and reduction of the ideas and clearly defined Objective, Key Success Criteria and evaluated Risks.

The trader project was kicked off in rush. More over there was poor team management due to which needed to restructure the team during the development. The purpose of the PD is that team members could understand goals and objectives of the project. It gives them a sense of purpose and commitment to achieve their tasks efficiently. In trader project there was little team member’s involvement in planning but ignored suggestions e.g. email-1,9.In trader project there was no project start up meeting through which run goals, objectives and scope of the project. The purpose of this meeting is to involve the team members in planning, get suggestions regarding risks, budget, time, etc. which is very beneficial approach now a day. Even in successful projects, the team members some time develop their own tasks plan.

 

 

PROJECT ORGANISATION

 

Work under taken by more than one person needs some coordination, supervision and finally organisation and structure e.g. for projects. The main purpose of project start up meeting is to create the appropriate organisation and structure of the project. Which was not conducted in TP? To handle this issue the project manager should be developed a start up meeting. In trader project no reporting structure for communications (meetings: formal, informal, face to face etc) and progress reporting (oral, presentation and some time written etc) too. Some time the processes which delivered the project are most important then planning especially for trader project. In trader project no communication structure, no body know to each other in trader project and their progress, no presentation, no meeting held to review project progress e.g. E-mail 6.There were no timely response e.g. Email 13. Which surely affected the project progress? Project manager did not consider project important but manage it like a routine activity.

 

PROJECT CONTROLING

 

In every project, work is carried out and completed by the project team. So there is need of guidance and control to ensure that work is on track. But in trader project there is lack of control on the project activities which was the responsibility of the project manager. E.g. E-mail 10 is best example. Lack of controlling too affected the project scope and cost? The higher authority like Bernard Bresslaw and Graham Gooch would have to invoke, if necessary to ensure that the timely decision, necessary actions and resources and removal of obstructions were dealt.

 

PERSONAL/INTERPERSONAL RELATIONSHIP

 

In a project a communication plan is necessary to facilitate smooth flow of information’s to various activities involved in the project, including upper management, project team, sponsor, user etc. But in the trader project there were poor communication and no communication plan to coordinate different activities between team members e.g. an email from Charles Baker to Graham Gooch (Project manager). Charles mailed to project manager dated 5^th February but did not get response and he had to again mail him dated 11^th April about printer condition. Moreover an email from David johns to Graham Gooch and one more important thing was that Bank IT team leader Dave Duckham did not know that the project manager was on leave, so there was serious lack of communication matrix in trader project. As a result project slippage and staff had to worked long hours which affected cost and project scope too. Communication in a project is like blood in the human body. More over in trader project team members of different countries were working together e.g. ABC team members. They have different cultural values, experience, personal characteristics etc. so there should be getting to gather before project so that could understand each others, and otherwise there will be communication gap which could generate the team relationship issues and chaos. It is good for project manager to consider this issues too which could seriously affect the project outcomes .e.g.email-3.

 

LEADER SHIP STYLE IN VIEW OF MANAGERIAL GRID

 

Before discussing the leader ship style in trader project first it is necessary to discuss what managerial grid is? And different proposed leadership styles by both Blake and Mouton.

 

Both Blake and Mouton in their managerial grid proposed two dimensional leadership styles. The productions based and People concerned leadership styles. Production concerned leadership need results, mean profit/benefits in trader project, time required to complete and implement the trader software within five months within specified budget.

 

People concerned leadership is to achieve the same results through trust, commitment, reward, recognition and motivation which is lack of this approach in the trader project.

 

Diagram 1.Source [1]

 

Both suggested a matrix of different management styles but from different 81postitions only five are more important. Which are?

• 1, 1Impoverished Management [1] position show little concern to both production and people and try to avoid the conflicts.

• 1, 9 Country Club Management [1] position show high concern for people and little for production. This position also avoids conflicts but concentrate of likelihood and recognition.

• 9, 1 Authority-Compliance [1] position or leadership style shows high concern for production/results/benefits and little for people.

• 5, 5 Middle of the Road Management [1] in this position managers/leaders have average concern for both issues and some time this leadership style is known a organisation management.

• 9, 9 Team Management [1] also know as effective management style for organisations or even projects. Show high concern for both production and people and work through the people motivation, recognition and commitment.

 

Project Director Leadership Style The project director Bernard Bresslaw directed behaviour regarding business case not seriously affected the cost of project but also affected overall benefits, which could be viewed in project progress in Appendix-1. When developed the business case did not check it reliability and scope mentioned above. In it only made little changes and asked go ahead. He did not concern the project team suggestions and issues that could generate risk during the project life cycle those as a result affected cost and scope e.g. in email.no.1.from Wally welling (senior IT manager) to Bernard Bresslaw (Project Director) and Malcolm shenley (Senior IT Director) about software arrival, staff untrained, business requirements were not properly analysed, business case over optimist regarding cost and time period, which were proposed by IT team not considered, risks seemed growing were quite extensive which were due to sheered lack of risk analysis at early stage. But the project Director mailed back that business case is my responsibility. He chooses the Authority Compliance leadership style in view of Managerial grid. Which not affected the overall cost, scope but also de-motivated and forced them to achieve the results within specified budget in trader project? If stake holders (Project Director, Regional Directors) used team management approach, discuss business case with team members and project manager this could even motivate the team members but could also avoided the potential risks, which were early identified and suggested. In this way they could control the project cost and achieve the desired benefits set about. But project director thinks that I’m only a knowledgeable person. According to an old saying “a wise man would not have nay fixed thinking, but adopt the views of others as his own”.

 

Project Manager Leadership Style

 

In email no.3 from Project manage Graham Gooch to All team Members wrote that new ABC members will be arrived. For this, he restructured the team without consultation with other team members already working in the old structure. Before doing this should use the forming, storming, norming and performing approach to build team of diversified cultural team members. Which could affect the effectively working relationship with new members due to culture and past experience and could raise uncertainty, confliction and pressure of desk sharing with new members?

Further email no.10 from Project manager to Wally welling he dictated that your team have had to work long hours what ever the reason to complete the task on daily basis and accomplish within schedules. More over the project manager did not pay proper attention to different team leaders and team members needs, task need and individual needs paradigm properly and timely to motivate and encouraged. He always gave priority to different tasks in the project which was clearly evident in emails. 4, 9, 13, 15, 16 are best examples that he also use the Authoritative accomplice behaviour/leadership styles in the trader project.

 

CONCLUSION

 

After analysis of trader project case study I reach a point that there are very important things in trader project that were not considered carefully and tried to ameliorate them but avoided them. The most important things which affected the overall project outcomes and benefits were wrong:

• Poor Communication.

• Time Constraint.

• Poor Risk Management.

• Unrealistic Cost/Benefit evaluation.

• Over optimist Budget

 

These are key factors which must be considered carefully when starting a project especially those have long term impacts on the business prospects. If you manage these issues within view of team, task and individual needs properly then hopefully project is successful and bring more benefits otherwise tarnished the spoil the organisation reputation and waste its resources too.

 

 

REFERENCE

 

[1]: Low Sui Pheng, Ben S.K.Lee “Managerial Grid” and Zhuge Liang’s “Art of management”: integration for effective project management. Management decision 35/5[1997] 382-391.

[2]: http://www.psg.co.nz/frameset.html?t=header_inner.html&inner_doc=inner_faq.html

Word Count: 2491