SDLC, PDLC, and Shift left approach in Testing

SDLC, PDLC, and Shift left approach in Testing

SDLC, PDLC, and Shift left approach in Testing

SDLC (Software Development Life Cycle) Phases, Process, Models

What is Software Development Life Cycle (SDLC)? Learn SDLC Phases, Processes, and Models:

Software Development Life Cycle (SDLC) is a framework that defines the steps involved in the development of software at each phase. It covers the detailed plan for building, deploying, and maintaining the software.

SDLC defines the complete cycle of development i.e. all the tasks involved in planning, creating, testing, and deploying a Software Product.

  • Software Development Life Cycle Process
  • SDLC Cycle
  • SDLC Phases

#1) Requirement Gathering and Analysis

#2) Design

#3) Implementation or Coding

#4) Testing

#5) Deployment

#6) Maintenance

Software Development Life Cycle Process

SDLC is a process that defines the various stages involved in the development of software for delivering a high-quality product. SDLC stages cover the complete life cycle of a software i.e. from inception to retirement of the product.

Adhering to the SDLC process leads to the development of the software in a systematic and disciplined manner.

Purpose:

The purpose of SDLC is to deliver a high-quality product that is per the customer’s requirement.

SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and Maintenance. It is important to adhere to the phases to provide the Product in a systematic manner.

For Example, the software has to be developed and a team is divided to work on a feature of the product and is allowed to work as they want. One of the developers decides to design first whereas the other decides to code first and the other on the documentation part.

This will lead to project failure because of which it is necessary to have good knowledge and understanding among the team members to deliver an expected product.

SDLC Cycle

SDLC Cycle represents the process of developing software.

Below is the diagrammatic representation of the SDLC cycle:

SDLC Phases

Given below are the various phases:

  • Requirement gathering and analysis
  • Design
  • Implementation or coding
  • Testing
  • Deployment
  • Maintenance

#1) Requirement Gathering and Analysis

During this phase, all the relevant information is collected from the customer to develop a product as per their expectation. Any ambiguities must be resolved in this phase only.

The business analyst and Project Manager set up a meeting with the customer to gather all the information like what the customer wants to build, who will be the end-user, and what is the purpose of the product. Before building a product a core understanding or knowledge of the product is very important.

For Example, A customer wants to have an application that involves money transactions. In this case, the requirement has to be clear like what kind of transactions will be done, how it will be done, in which currency it will be done, etc.

Once the requirement gathering is done, an analysis is done to check the feasibility of the development of a product. In case of any ambiguity, a call is set up for further discussion.

Once the requirement is clearly understood, the SRS (Software Requirement Specification) document is created. This document should be thoroughly understood by the developers and also should be reviewed by the customer for future reference.

#2) Design

In this phase, the requirement gathered in the SRS document is used as input and the software architecture that is used for implementing system development is derived.

#3) Implementation or Coding

Implementation/Coding starts once the developer gets the Design document. The Software design is translated into source code. All the components of the software are implemented in this phase.

#4) Testing

Testing starts once the coding is complete and the modules are released for testing. In this phase, the developed software is tested thoroughly and any defects found are assigned to developers to get fixed.

Retesting, and regression testing is done until the point at which the software is as per the customer’s expectation. Testers refer SRS document to make sure that the software is as per the customer’s standard.

#5) Deployment

Once the product is tested, it is deployed in the production environment, or the first UAT (User Acceptance testing) is done depending on the customer's expectation.

In the case of UAT, a replica of the production environment is created and the customer along with the developers does the testing. If the customer finds the application as expected, then sign-off is provided by the customer to go live.

#6) Maintenance

After the deployment of a product in the production environment, maintenance of the product i.e. if any issue comes up and needs to be fixed or any enhancement is to be done is taken care of by the developers.

?What is PDLC?

Key Phases of Product Development Life Cycle (PDLC)

Project Initiation

It is often said:? ‘Well Begun is Half Done. The same applies to any product development. Proper planning at the beginning of the project often leads to a successful result. A focused approach toward nailing down the requirements for the product, creating a detailed project plan, identifying the development methodologies and processes to be followed through the PDLC and defining the test strategies, and setting up the right infrastructure for product development are some of the key activities in this phase.

?Technical Design and Architecture

Before starting the development, it is imperative to create an overall architecture for the product with a focus on non-functional areas like Scalability, Security, Usability, Performance, Integrity, Reliability, and Supportability. In parallel, we need to freeze on the tools, technologies, and frameworks for development; and execute various Proof of Concepts (POCs) to ensure that they are workable and apt for the project. The resulting deliverable should be a detailed design document that uses tools like pseudo-code, flowcharts, object structure diagrams, or event diagrams to group the program’s activities into modules.

Development

This is undoubtedly the most critical phase of PDLC. This phase ensures that requirements and design are translated into a working application using a programming language and application development tools.? Developers need to ensure that their code is robust, well commented, and meets the specifications. Making sure that each code is reviewed and unit tested before taking it to the next phase is the key.

?Test Execution

Today, management of product quality has become an integral part of the product development life cycle. Every product organization is laying stress on building an effective process that is well supported by systems to enforce stringent quality management of their product. The phase involves testing the completed code as per the test cases and managing the test results, along with management of defects identified during this phase.

?PDLC Best Practices

The ability to launch products in record time and manage them over their entire life cycle gives product development companies a decisive advantage over competitors that can translate into increased revenue and above-average growth. So, how does Clarice realize these benefits for its customers? It does this by using “best practices” at various levels: some at the Organization level and some in each of the above-mentioned phases of PDLC. Some of these best practices in a collaborative product development environment are listed below:

?Integrated Design and Development

If your product focuses on User Experience as a key differentiator, getting such products developed by a service company that has Product UI design and technology services under one umbrella gives you a distinctive advantage. Getting the designers and development involved together upfront eliminates technical feasibility and integration gaps and creates a highly cohesive development environment.

?Agile Development

Most independent software vendors often start with a concept or idea that they feel has the potential to become a full-fledged product. Such product developments are often driven by faster time to market and ever-changing requirements that are driven by customer feedback. Agile development methodologies fit quite well for such customers. An agile model promotes development iterations, teamwork, collaboration, and process adaptability throughout the product life-cycle.

?In-person Discussions during Project Initiation

When product development is aimed at geographically distributed teams, In-person discussions during the Initiation phase help build rapport and mutual trust and this goes long way in establishing a foundation of a good working relationship. Rotational travels both ways add further to strengthening the bond between teams and weakening cultural gaps.

?Remove Unknowns early in the Cycle

During the Initiation and Design phase, it always helps to have productive discussions and trials in order to remove any unknowns earlier in the cycle as the cost of such unknowns will be quite high if they occur during later phases. Whiteboard discussions, Proof of Concept (POCs), and technology evaluations are some of the must-do activities in the initial stages.

?Leverage Solution Accelerators

In order to align themselves to the client’s goal of a shorter time to market, services companies need to arm themselves with solution accelerators to increase the productivity of development. Such solution accelerators could be a combination of reusable components, tools, and frameworks that could reduce development time. At Globant, we have created a number of such solution accelerators like login components, security frameworks, notification frameworks, pdf generators, etc to enhance the design and development process.

?Religious Code Reviews

Ensuring that a developer’s code is thoroughly reviewed by a peer or a lead ensures that a number of defects get removed before the code is passed to QA for testing.? Apart from setting up a process for code review, various code analysis tools could be used to determine the quality of code written by a developer. Tools like PMD, CPD, CheckStyle, FindBugs,? JavaNCSS, Sonar, etc could be used for Java code while tools like FxCop, NDepend, Reflector, etc could be used to analyze .Net code. Also, the use of a good unit testing framework like JUnit or NUnit also helps to remove bugs earlier in the cycle.

?Process, Tools, Documents, and Templates

Documenting PDLC processes in standard templates helps execute product development inefficiently way. Documents like ODC Handbook, Quality Plans, Status Reports, Review Reports, etc should be prepared and tracked through the PDLC. Further, adapting easy-to-use tools across the entire value chain for better collaboration, visibility, and program governance adds to the smooth execution of projects.

?Governance model for improved Quality and Customer Satisfaction

An appropriate level of governance is the essence of PDLC. Daily status reports, weekly project status meetings, monthly review meetings, and quarterly governance meetings are some of the key activities under a governance model. Also, portals like Wiki, SharePoint, etc for Online ‘Total Visibility’ add to the proper governance of projects.

************************************************************************************

Include the topic of shifting left.

?What’s the shift left testing?

The easiest way to explain shift-left software testing is to think of the development cycle as a line running from left to right.

In the old model, testing only came into play on the far right of the line. Recognizing the bottleneck here, we now want to move the initiation of testing as far to the left as possible.

Shift Left is a practice intended to find and prevent defects early in the software delivery process. The idea is to improve quality by moving tasks to the left as early in the lifecycle as possible. Shift Left testing means testing earlier in the software development process.

Why Shift Left?

In the traditional software development model, requirements are kept on the left side of the plan, and the delivery and testing requirements on the right. The problem is that these practices can’t handle changing expectations and requirements, resulting in negative outcomes for the business such as:

  • Increased costs
  • Increased time to market
  • Unexpected errors

Cost alone is a very strong incentive for shifting your testing to the left. Estimates indicate that over half of all software defects could be identified during the requirements phase, with less than 10% emerging during the development phase of the lifecycle. The cost of resolving these defects works in reverse:

A defect that is removed after the product has gone into the product will cost around 100 times more than one that is identified and removed during the requirements phase.

Research from the Ponemon Institute, in 2017, found that if vulnerabilities get detected in the early development process, they may cost around $80 on average. But the same vulnerabilities may cost around $7,600 to fix if detected after they have moved into production.

The Shift left approach emphasizes the need for developers to concentrate on quality from the earliest stage of a software build, rather than waiting for errors and bugs to be found late in the SDLC. Shifting left enables product teams to perform daily tasks like:

  • Testing
  • Providing feedback
  • Reviewing changes and progress

Is Shift Left always appropriate?

A Shift Left testing approach may not always be able to deliver optimal performance and functioning in a real-world environment. In such situations, a Shift Right testing strategy may help to:

  • Enhance customer experience
  • Provide scope for implementation of test automation
  • Ensure better test coverage

Shift Right initiates testing from the right, i.e., post-production. In this Shift Right practice, you’ll test a completely built and functioning application to ensure performance and usability traits. Reviews and feedback from targeted users further help in enhancing the quality of the software.

An important characteristic of the Shift Right approach is a willingness to:

  • Validate a hypothesis by trying out new solutions
  • Collaborate with customers to determine what is working (instead of working from assumptions)

Continuous feedback from users may help in responding better to software failures.

How to move to Shift Left

There are some key strategies that will help you shift left with your software testing:

Demand planning

Test analysts will engage with business and operational stakeholders, providing a forward view of demand. Having this view enables you to—ahead of time—plan and finalize:

  • The budget
  • Resourcing
  • Test strategies

Demand planning is an integral part of the shift left approach and provides a starting point for all other activities in the test lifecycle.

Static testing

Static testing is carried out in the early cycles of the project and includes validation of requirements and design. The purpose of static testing is to find defects early in the life cycle that could prove to be very expensive to remove in the later phases of the project.

Use appropriate checklists to verify and validate requirements and design. Log defects into a defect management tool.

Unified test strategy

This is an overall, high-level strategy for testing end-to-end—from unit testing through user acceptance testing (UAT), operational readiness testing (ORT), and post-deployment testing. The strategy will cover all phases of quality control, defining clear responsibilities.

A unified test strategy allows you to analyze dependencies on environments, stubs, automation, and test data—ensuring that the respective teams can fulfill the needs.

Risk-based analysis

A risk-based analysis is carried out to determine the impact and likelihood of failure for each test scenario. This approach is used for functional, non-functional, and regression types of testing.

Once the test cases are established, decide the priority for the test cases based on the finished analysis. Discuss the impact of failure with the business analyst or designer. Determine the likelihood of failure from the development team.

Benefits of a shift left approach

There are several benefits that can be obtained by adopting a shift left strategy. Here are some of the most important:

Automation

Shifting left gives a greater ability to automate testing. Test automation provides some critical benefits:

  • Much fewer human errors
  • Increased test coverage (multiple tests can be conducted at the same time)
  • The ability for testers to focus on more interesting and fulfilling tasks
  • Fewer production issues

Increased delivery speed

Earlier means faster. When you find defects earlier in the production cycle, you can also fix them a lot faster. As a result:

  • The time between releases can reduce significantly.
  • The quality of software improves.

Increased satisfaction

Faster delivery of software with fewer defects is a major benefit of the shift-left approach.

If nothing else convinces you that this is a good move, then the smiles on the faces of your business partners should be all you need.

Learn from the choices Humana made when selecting a modern mainframe development environment for editing and debugging code to improve their velocity, quality, and efficiency.

要查看或添加评论,请登录

Jigna Jain的更多文章

社区洞察

其他会员也浏览了