Software Development Life Cycle QA&Testing. January 2014 Alain Chacun all rights reserved 1

Size: px
Start display at page:

Download "Software Development Life Cycle QA&Testing. January 2014 Alain Chacun all rights reserved 1"

Transcription

1 Software Development Life Cycle QA&Testing January 2014 Alain Chacun all rights reserved 1

2 Introduction: Entities have to meet success in their Information Communication Technology (ICT) projects in the allocated budget and timeline. Success means successful go-live and end-users/client satisfaction. There are 4 success factors to be considered: Budget Timeline Successful go-live End-users/client satisfaction January 2014 Alain Chacun all rights reserved 2

3 In 2011, the Standish Group Research revealed in the Chaos Report that: Only about 37% of ICT projects are completed on-time and on-budget About 21% are cancelled before completion About 42% of ICT projects are challenged, meaning over time and over budget. The same Chaos Report has identified the TOP5 causes of failure (projects cancelled or challenged): Incomplete requirements / Poor articulation of users requirements Lack of user involvement / Failure to involve users appropriately Lack of resources / Poor project management Lack of attention to the human and organizational aspects of IT / inadequate attention to business needs and goals Unrealistic expectations January 2014 Alain Chacun all rights reserved 3

4 For an ICT project, it has to be considered the Total Cost Ownership (TCO) that represents all the costs of implementation for the software, hardware, training but also the production costs and the medium/long term expenses such as upgrade, replacement / decommissioning. Outside of the medium/long term and production TCO, the TCO for the implementation is dramatically increased for the challenged ICT projects, up to 4 times the initial budget. The TOP5 causes of failures have to be solved: Incomplete requirements / Poor articulation of users requirements Lack of user involvement / Failure to involve users appropriately Lack of resources / Poor project management Lack of attention to the human and organizational aspects of IT / inadequate attention to business needs and goals Unrealistic expectations January 2014 Alain Chacun all rights reserved 4

5 1) Incomplete requirements / Poor articulation of users requirements How to? Static testing versus dynamic testing Some control checks have to be defined at different milestones of the Software Development Life Cycle (SDLC) to validate the consistency of the requirements all along the specification phase. 2) Lack of user involvement / Failure to involve users appropriately How to? End users and sponsor Involve users in the project and in the process of decision. The role of the sponsor must not be limited to the budget safe keeper but must be also the one motivating the change and involving the end-users. January 2014 Alain Chacun all rights reserved 5

6 3) Lack of resources / Poor project management and unrealistic expectations How to? Planning, budget, resources and realism Make a planning of deliverables realistic according to the budget and available resources 4) Lack of attention to the human and organizational aspects of IT / inadequate attention to business needs and goals How to? AS IS and TO BE, listen the people Define and understand how the end users work, define and understand what has to be improved, removed and added in the organization January 2014 Alain Chacun all rights reserved 6

7 Define best practices means also to bring some methodologies. But methodologies does not mean that the entity has to adopt a rigid framework. Methodology adoption for an entity must be a correct balancing between best practices and culture of the entity. A methodology is also adaptable to the specific constraints of the entity and the project. The adoption of a methodology must be done gradually according to a planning defining tasks and goals at short, medium and long term. An approach similar to CMMI can help to gradually acquire best practices. CMMI is made of 5 levels, initial (1), managed (2), defined (3), quantitatively managed (4) and optimizing (5). January 2014 Alain Chacun all rights reserved 7

8 LEVEL DETAILS 1 Processes are usually ad hoc and chaotic. No stable environment to support processes. Success depends on the competence of the people in the organization and not on the use of proven processes. Project frequently exceed budget and schedule. Organizations are characterized by a tendency: To overcommit To abandon their processes in a time of crisis To be unable to repeat their successes 2 Processes are planned and executed in accordance with policy. Projects employ skilled people who have adequate resources to produce controlled outputs Stakeholders are monitored, controlled and evaluated for their adherence to the process descriptions Process discipline helps to ensure that existing practices are retained during times of stress. Projects are performed and managed according to their documented plans. Status of the work products are visible to management at defined points (e.g., at major milestones, at the completion of major tasks). Commitments are established among relevant stakeholders and are revised as needed. Work products are appropriately controlled. Work products and services satisfy their specified process descriptions, standards, and procedures. 3 Processes are understood, described in standards, procedures, tools, and methods. Organization s set of standard processes is the basis for maturity level 3 and is established and improved over time. Processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization s set of standard processes (*) according to tailoring guidelines. (*) organization s set of standard processes A collection of definitions of the processes that guide activities in an organization. These process descriptions cover the fundamental process elements (and their relationships to each other such as ordering and interfaces) that should be incorporated into the defined processes that are implemented in projects, work groups, and work across the organization. A standard process enables consistent development and maintenance activities across the organization and is essential for long-term stability and improvement. 4 Organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing projects. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of projects. 5 The organization improves its processes based on a quantitative understanding of its business objectives and performance needs. The organization s quality and process performance objectives are established, continually revised to reflect changing business objectives and organizational performance, and used as criteria in managing process improvement. The organization uses a quantitative approach to understand the variation inherent in the process and the causes of process outcomes. The effects of deployed process improvements are measured using statistical and other quantitative techniques and compared to quality and process performance objectives. Source January 2014 Alain Chacun all rights reserved 8

9 Return on investment (ROI): The cost to define best practices is largely cover with the risk inherent to incorrect specification that does not respond to the end user needs. The later a defect is found, the more expensive the resolution will be. January 2014 Alain Chacun all rights reserved 9

10 We can identify 3 types of entities showing some interest in QA & testing: Emergency approach: the entity has projects at risk and is willing to bring some QA & Testing to control the projects Hesitant approach: the entity wishes to improve the Software Development Life Cycle (SDLC) but does not know how to do it or hesitant regarding the changes in the organisation, there is sometimes no overall commitment with end users, IT stakeholders and management Volunteer approach: the entity wishes to improve the SDLC and has no restraint to move forward, has commitment from the overall end users, IT stakeholders and management January 2014 Alain Chacun all rights reserved 10

11 For reminder, how to improve the maturity? Know the competitors, market trends Plan the future of the business in the short, medium and long term Define and validate the business case Identify the AS IS and the TO BE Define the investments required to support these new challenges Strengthen the sponsor role Check/verify top bottom consistency of user requirements, functional specifications, architecture and code Identify and benchmark the external solutions proposed by providers without miss-considering the internal solutions Imply users upstream of the project in the process of decision Never under estimate the workload effort and resource needs in order to obtain the budget January 2014 Alain Chacun all rights reserved 11

12 QA & testing role in the SDLC Specification phase / static testing Dynamic testing Project Initiation Document Review/test User requirements Review/test Test Strategy Test Planning UAT Functional specifications Review/test SIT Technical designs Review/test UT QA & Test team has to be involved early in the SDLC Timeline Coding If the QA & test team is involved in the SDLC once the code is delivered, it is too late as the discrepancies between the requirements have not been identified January 2014 Alain Chacun all rights reserved 12

13 ? January 2014 Alain Chacun all rights reserved 13