The Software Development Life Cycle (SDLC) is a framework defining tasks performed at each step in the software development process. SDLC is a structure followed by a development team within the software organization. It consists of a detailed plan describing how to develop, maintain and replace specific software. The life cycle defines a methodology for improving the quality of software and the overall development process. The software development life cycle is also known as the software development process.
The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment and decommissioning of the software once it becomes a legacy.
The SDLC methodology usually contains the following stages: Planning, Defining, Designing, Building, Testing, Release & Maintenance.
Who are the different stakeholders involved in different phases of SDLC?
1. Business Analyst - Requirements
2. System Architect - Design
3. Software Developer / Development Team - Coding
4. Tester / Testing Team - Testing
5. Operational Team - Implementation
6. Production Support Team - Maintenance
Stakeholder: Active stakeholder's participation is vital to the success of IT projects. Stakeholders should be kept engaged throughout the life of the project. Without the fully engaged cooperation of the stakeholders, it is difficult to have a successful software development project. This is especially true in agile development, where everything is moving very quickly and so much depends on the Product Owner obtaining a complete understanding of the stakeholder needs and communicating these needs to the development team.
The most important and obvious involvement for the stakeholder is during requirements development. Stakeholders have the most knowledge of the processes involved and their input is imperative to your project’s success. Using the requirements, the stakeholders can stay involved during the rest of project.
In the design phase, the stakeholders need to be involved to verify that their requirements are correctly interpreted into the design. The stakeholders often need to clarify requirements in both the design and development activities. The stakeholders can use the requirements and design documents to plan for necessary changes to the business processes and business rules while the developers are working on the program code.
In User Acceptance Testing (UAT), the stakeholders can validate that the developers correctly converted the design into the expected functional product. After delivery, stakeholders should be asked if the product satisfied their needs and met the business objectives. They are asked questions like:
• Was the product outcome what they anticipated?
• Was their user group made aware of process modifications due to software improvements?
• Were their needs addressed?
Collaboration with the stakeholders throughout the project will make the majority of these answers affirmative and make sure all of the steps are less painful, as well as reducing time and money spent on re-work.
What is the role of a Business Analyst in different phases of SDLC?
Understand the project with scope of the project from Project Charter. Understand the current process and what are we trying to achieve…Prepare the questionnaires (existing issues, problems & business justification) for the project.
Business Analyst required to identify the high-level requirements from Scope document or Project Charter, SME, Managers, and Project Owners.
An effective BA always document or record the conversation regarding the topics/requirements/decisions (chances of forgetting the topics/decisions after some days)
During the Development phase…Clarify or address the developers questions regarding the requirements, gather relevant information and communicates to developers/programmers.
During the Testing phase…Conduct requirements review meeting with the Testing team (QA-Quality Assurance/QC-Quality Control/UAT-User Acceptance Testing). Ensure testing team understands all the requirements and use cases clearly. If have any issues document the issues on the issue log and communicates to Project Manager.
What is the role of a Developer in different phases of SDLC?
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.
Software developer: A software developer is a person concerned with facets of the software development process. Their work includes researching, designing, developing, and testing software. A software developer may take part in design, computer programming, or software project management. They may contribute to the overview of the project on the application level rather than component-level or individual programming tasks. Software developers are often still guided by lead programmers but the description also encompasses freelance software developers.
In the Development Phase
In the development phase, all the documents from the previous phase are transformed into the actual system. The two primary activities involved in the development phase are as follows:
1. Development of IT infrastructure
2. Development of database and code
In the design phase, only the blueprint of the IT infrastructure is provided, whereas in this phase the organization actually purchases and installs the respective software and hardware in order to support the IT infrastructure. Following this, the creation of the database and actual code can begin to complete the system on the basis of given specifications.
What is the role of a Test Analyst in different phases of SDLC?
Responsibilities of a Tester
The roles and responsibilities of a tester often vary from organization to organization. In general, a testers main purpose is to design, develop, and conduct system tests and supports acceptance testing. The roles and responsibilities of a tester include the core activities associated with the test effort.
This usually involves identifying the most appropriate implementation approach specific tests, performing test preparations, executing the tests, logging outcomes, and administering the defect tracking system.
More detailed aspects of the roles and responsibilities of a tester is included in the following:
· Analysing client requirements
· Understand the software application being tested
· Prepare test strategy
· Participating in test plan preparation
· Preparing test scenarios
· Preparing test cases (used for module, integration, and system testing
· Preparing test data (used for test cases)
· Preparing test environment
· Analysing test cases (those prepared by others)
· Write necessary test scripts
· Executing the test cases
· Defect tracking
· Perform necessary retesting
· Providing defect information (for developers)
· Preparing report summaries
· Preparing lesson learnt documents
· Conducting review meetings within the team
Requirement Phase: Tester understands the requirements and analyzing the requirements and also checks whether given requirements are testable requirements or not. If the tester finds any defects in requirements, the tester directly reports those defects.
Design Phase: in this phase, the tester identifying high-level test Condition and test cases for given requirements and develops test scenarios and test cases. and preparing test data if necessary.
Build Phase: in this phase, tester do the static testing like design review, test cases review. checking we cove all requirements or we miss any requirements.
Testing Phase: in this phase actually we execute the test cases, log results and if any test case is failed we have to report the defect using any defect management tool. after fixing those defect again retest those defect to ensure that the defect is fixed or not. if not again reopen the defect after finishing all test cases the test manager will sign off on the testing.
What is the role of a Customer/ Client in different phases of SDLC?
Having a professional vendor and sufficient investments are not enough to ensure successful implementation of a custom software solution. The project outcome significantly depends on the customer’s constant involvement, which includes providing business and technical requirements (such as contained in the Product Vision), answering the vendor’s questions, reviewing interim user-related and technical deliverables, checking the project progress and budget (especially for T&M projects), as well as anticipating and addressing risks. The more engaged the customer is in the above-mentioned project activities, the more chances are that the solution will finally fit its business needs.
Why do we need a separate environment for the developers and testers?
Development – It is an environment where developers commit code, experiments, fix bugs, make mistakes etc…
Staging – It is an environment where manual or automated tests are executed, and due to complexity, these can consume a lot of server resources.
Production – It is an environment where we create value for customers and/or the business. This is a highly sensitive environment and puts a deep effect on your reputation and brand name.
Staging – It is an environment where manual or automated tests are executed, and due to complexity, these can consume a lot of server resources.
Production – It is an environment where we create value for customers and/or the business. This is a highly sensitive environment and puts a deep effect on your reputation and brand name.
Reasons for having separate environments
§ Software development is a continuous process. To avoid the issues caused by software development and reducing the risks of blocking business.
§ To reduce risks of unwanted downtime due to developers ad-hoc rigging.
§ To improve the SLA of application and provide better user experience to your users.
§ To reduce the risks of production data getting into the wrong hands. It is very important when organizations deal with very sensitive and private data, like client information, ID, numbers, financial transactions and health information. Moreover, we want this for avoiding production data getting intermingled with test data.
§ Write access to a production server is limited to specific system engineers.
§ A production server hosts only live applications and finalize content. The unfinished and preliminary versions of applications and data should never be placed on this server, except possibly under highly controlled test conditions.
Difference between Use Case and Test Case?
Use cases are used in the requirement and design phases of the SDLC, which lead the development in the right direction.
Test cases are employed in the testing phase of the SDLC where the correct execution is demonstrated, and failures in the software are detected.
Key Differences Between Use Case and Test Case
1. The use case contains actions sequentially which illustrate the interactions between the user using a process and the system to achieve a goal. Conversely, a test case is comprised of conditions, inputs and expected output to validate the software.
2. Use case main purpose is to provide a document through which an objective can be attained while the test case is intended to check the software behaviour that whether it works as defined or not.
3. While testing the software the single test case undergoes through the process. In contrast, in a use case there exist different paths to reach the target, among which any path can be followed.
4. The use case relies on the software requirements, whereas the test case depends on the use case.
5. You can complete a use case in one go. On the contrary, in testing there are multiple test cases are involved, each dedicated for testing a particular area in the software.
6. The use case involves interaction with users, while the test case does not require interaction with users.
The use case and test case are the terms frequently used in the software testing field, which are also closely related. A use case is used to specify how to use the system designed for performing a specific task. As against, a test case is a group of test inputs, execution conditions, and expected results developed for a particular test objective.
The use case does not run or execute as it is a textual or diagrammatic presentation of a document which specifies how to accomplish a certain task. Whereas, test cases are prepared by the software testers to validate the software and check whether it is working as per requirements or not.
Use Cases performs an important role in the requirement analysis phase of Software Development Life Cycle, where the interaction of the user and the system is demonstrated. The use cases are the base for deriving the test cases and the method of deriving the test case is known as use case path analysis.
An actor which is a system boundary interface is responsible for defining the Use Case. A use case is comprised of preconditions, results and sequential execution.
Use Case Roles
· Management and monitoring of requirements
· Identification of the classes and objects
· Designing and coding
· Developing application documentation
· Producing training
· Developing test cases
Information requirements to define Use Case:
1. Use case name or ID – A small name given to the business that identifies that particular use case.
2. Actor – An actor is intended to represent the roles that people play as the system operates.
3. Aim – It specifies objective and what a use case could achieve by a defined group of conditions. It includes preconditions and results.
4. Detailed description – It contains the information like a sequence of the steps, response of steps, precondition, results and events of the internal system.
5. Exception – The generated errors that could deviate the actor from the basic course.
6. Alternative course – A set of valid events may increase or decrease the number of steps in case of deviation.
Test case is a set of inputs and expected output which is used for analyzing the program behaviour. The relationship established between the test case and use case definition must be is one-to-one. It is required to create two test cases for every use case. Use case description is fed as the input to the test case worksheet, which is also prepared by the actor.
The process of testing entails setting up the required preconditions, providing the test case inputs, obtaining and analysing the output and comparing these with the expected outputs to find whether the test succeeded or not. Test Case templates could contain inputs in the two forms – Preconditions and actual inputs.
Preconditions: The pattern of execution of the test case that is prior framed.
Actual inputs: These are provided to the test case on the basis of the test case and testing method.
Actual inputs: These are provided to the test case on the basis of the test case and testing method.
Similarly, it has outputs like – Post-conditions and actual outputs.
Process of generating a test case
· Identify the test resources
· Identify conditions to be tested
· Rank test conditions
· Choose conditions for testing
· Determine the correct outcome of processing
· Create test cases
· Document test conditions
· Conduct test
· Verify and correct
Information required to define a Test Case is given as followed
1. Test objective – It is somehow related to the use case definition that specifies the description action.
2. Test condition – Any scenario probably as an outcome of the action that is being tested from the use case description worksheet.
3. Operator action – The operator is supposed to perform the specific steps to execute the test condition.
4. Input specifications – The input necessarily needed for the execution of the test cases.
5.Output specifications – The expected results produced by performing the operator actions over the provided input.
6. Success or failure – The outcome of executing the test case.
7. Comments – Supervision and guidance provided by the actor to the individual carrying out the test.
Test Case Designing technique
1. Black-box approach does not consider the inner structure of the software under test and contain zero knowledge about it but the tester is aware of what result it could produce or what it does.
2. White-box approach emphasizes on the inner structure of the software to be tested. The tester must have complete knowledge of the internal structure along with codes and pseudo code.
Benefits of a properly designed test case
· The detection of the defects is easier and highly possible.
· Organizational resources are more effectively utilized.
· Higher probability of test reuse.
· Testing and project schedules and budgets can be strictly followed.
· Higher quality project is developed and delivered.
Phase of SDLC does the testers begin to write test case
For the betterment, reliability and performance of an Information System, it is always better to involve the Testing team right from the beginning of the Requirement Analysis phase. The active involvement of the testing team will give the testers a clear vision of the functionality of the system by which we can expect a better quality and error-free product.
Once the Development Team-lead analyses the requirements, he will prepare the System Requirement Specification, Requirement Traceability Matrix. After that he will schedule a meeting with the Testing Team (Test Lead and Tester chosen for that project). The Development Team-lead will explain regarding the Project, the total schedule of modules, Deliverable and Versions. The involvement of Testing team will start from here.
In SDLC after completion of FRS (Functional Requirement Specification) document, the test lead prepare the use case document and test plan document, then the tester role is start.
The difference between functional document and business document
Business Requirement Documents are written to define the requirements of a business process or a system that needs to support a business process. For purposes of contrasting the Business Requirement Document (BRD) and the Functional Specification Document (FSD), the description of the BRD that follows is written in terms of preparing a BRD for a system. The exact scope of a BRD and FSD vary from company to company. However, the two documents are typically defined as follows:
The BRD contains the business requirements that are to be met and fulfilled by the system under development. These requirements specify "what" the system must do in order to fulfil the requirements of the business. They often take the form of "The system shall..." Each requirement, or group of similar requirements, is typically accompanied by a business rationale. The business rationale explains "why" the business requirement is necessary. This is often important later if analysts or developers have questions regarding the purpose or validity of the requirement. The rationale can be used to support the need for the business requirement or clarify ambiguous language by providing a context for the requirement. In addition to a rationale, constraints can be provided for each requirement along with other supporting reference material.
In contrast, the FSD defines "how" the system will accomplish the requirements by outlining the functionality and features that will be supported by the system. Ideally, the functionality of the system will be described in logical terms so that the FSD is technology and platform independent. This gives the architects and developers more freedom in making development and design decisions about the physical design of the system. Inevitably, however, some things have to be explained in physical terms. The User Interface is one such example. Many FSDs include screen mock-ups or wire-frames for communicating the layout and design of the system screens.
References:
No comments:
Post a Comment