1.Explain SDLC with an example?

The Software Development Life Cycle (SDLC) refers to a methodology with clearly defined processes for creating high-quality software. in detail, the SDLC methodology focuses on the following phases of software development:

• Requirement analysis
• Planning
• Software design such as architectural design
• Software development
• Testing
• Deployment

SDLC or the Software Development Life Cycle is a process that produces software with the highest quality and lowest cost in the shortest time possible. SDLC provides a well-structured flow of phases that help an organization to quickly produce high-quality software which is well-tested and ready for production use.

The SDLC involves six phases as explained in the introduction. Popular SDLC models include the waterfall model, spiral model, and Agile model.

Examples

The most common SDLC examples or SDLC models are listed below.

Waterfall Model

This SDLC model is the oldest and most straightforward. With this methodology, we finish one phase and then start the next. Each phase has its own mini-plan and each phase “waterfalls” into the next. The biggest drawback of this model is that small details left incomplete can hold up the entire process.

Agile Model

The Agile SDLC model separates the product into cycles and delivers a working product very quickly. This methodology produces a succession of releases. Testing of each release feeds back info that’s incorporated into the next version.The drawback of this model is that the heavy emphasis on customer interaction can lead the project in the wrong direction in some cases.

Iterative Model

This SDLC model emphasizes repetition. Developers create a version very quickly and for relatively little cost, then test and improve it through rapid and successive versions. One big disadvantage here is that it can eat up resources fast if left unchecked.

V-Shaped Model

An extension of the waterfall model, this SDLC methodology tests at each stage of development. As with waterfall, this process can run into roadblocks.

Big Bang Model

This high-risk SDLC model throws most of its resources at development and works best for small projects. It lacks the thorough requirements definition stage of the other methods.

Spiral Model

The most flexible of the SDLC models, the spiral model is similar to the iterative model in its emphasis on repetition. The spiral model goes through the planning, design, build and test phases over and over, with gradual improvements at each pass.

2. What happens in Requirement Analysis phase in SDLC?

The Software Development Life Cycle, or SDLC for short, which includes important stages that can be categorized into planning, implementation, and maintenance of the system solution, has established itself as the de facto process for years to help build information systems, systems engineering, software engineering from the ground up. This article will examine the Software Development Life Cycle (SDLC), specifically the analysis phase.

Since its standardized phases, the SDLC has become increasingly important because it allows businesses to fulfill the needs of today’s fast-paced, complicated, and financially constrained markets.

The requirement phase is where you build the base of your software. Before you shortlist software development companies, it is important to work on the requirement phase because by looking at this important document and work, the dedicated software development team shall come to know what they will be working on. Without the requirement phase documentation, even the best offshore software development company will get confused about their task.

Firstly, you need to list down the business needs you expect from the customized software to address. In other words, it is what you expect from the remote software development team to work on. 

Once you make the list of all business needs, the dedicated software development teams and other senior members from the management teams go through it to discuss it thoroughly. Then, they finalize the list by analyzing each item and considering its feasibility.

Upon deciding the feasibility and approving it, the list is then passed on to the other team such as designing. The design team puts their own requirements by looking at the features required from the client side.

All in all, every team and a team member shall go through the requirement phase documentation to have their two cents in it that would ultimately contribute to software development speed because everybody is familiar with the common goal.

3.Explain STLC with examples?

STLC –Software Test Life Cycle defines what testing activities to perform during the duration of the project. It is formalized by defining various phases of the testing process throughout the project. In modern, software products the STLC is repeated multiple times till the product reaches satisfactory software quality.

As in SDLC, there are different phases in in STLC

Lets understand each phase one by one:

Requirement Analysis:

In this phase the QA team performs following activities:

• Understands requirements from the testing point of view to identify testing requirements of the project.
• Develop a better understanding of the desired software product.  
• Quantify the requirement testability via manual testing or automation.
• Identity types of tests to be performed
• Create a requirement traceability matrix.

Test Planning:

Following activities are performed in this phase:

• Analyze various test approaches.
• Create a test plan.
• Prioritize test conditions.
• Identify test tools.
• Test effort estimation.
• Resource planning

Test Design:

Following activities are performed in this phase:

• Prioritization of test conditions
• Design the high level Test Case
• Designing of Test environment
• Identification of Tools and Infrastructure
• Refine test conditions identified in the test analysis

 Test Implementation:

Following activities are performed in this phase:

• Designing of low level test cases
• Detailed test procedures are defined.
• Sequencing of test procedures is done.    
• Test suites are identified
• Test execution schedule is prepared
• Service virtualization of automated scripts are created 
• Creation of verification of test data and test environment is done
• Expected results are defined.

Test Execution:

Following activities are performed in this phase:

• Categorize every test case or procedure into following categories
  • Pass
  • Fail
  • Blocked
  • Ready to Run
  • Skipped.
• Defect reports are created
• Detailed documentation about which test items, objects, tools and test ware are involved in testing.
• Once test execution is complete, we know that 
  • Which requirements are passed.
  • Which requirements are failing and what are corresponding defects.
  • Which requirements are planned to be tested
• It gives better understanding to all the stakeholders about the state of the product.

Test Completion:

Following activities are performed in this phase:

• Test Summary reports are generated,
• Action items for improvement of product are identified.
• Change request are created
• Product backlog items are added.

3. What would you do in the Test Design phase in STLC?

Following activities are performed in this phase:

• Prioritization of test conditions
• Design the high level Test Case
• Designing of Test environment
• Identification of Tools and Infrastructure
• Refine test conditions identified in the test analysis

4. How do you log defects?

Defect logging, a process of finding defects in the application under test or product by testing or recording feedback from customers and making new versions of the product that fix the defects or the clients feedback.

Defect tracking is an important process in software engineering as Complex and business critical systems have hundreds of defects. One of the challenging factors is Managing, evaluating and prioritizing these defects. The number of defects gets multiplied over a period of time and to effectively manage them, defect tracking system is used to make the job easier.

Defects are tracked based on various parameters such as:

• 1.Defect Id

• 2.Priority

• 3.Severity

• 4.Created by

• 5.Created Date

• 6.Assigned to

• 7.Resolved Date

• 8.Resolved By

• 9.Status

5. Why do we need screenshots attached when logging a defect?

When you report a defect, you want to provide as much information as possible to help the developers understand and fix the issue. One way to do that is to attach screenshots, logs, or videos that show the defect in action. But how do you attach them effectively and efficiently? Here are some best practices for attaching screenshots, logs, or videos to a defect report.

If there is a snapshot/video file, developers may overlook the description and instructions. This is why it’s crucial to know when and how to use each attachment based on the situation. The most common type of attachment when we describe visual problems (interface, layout) is a screenshot. The files you attach must be entirely informational.

A screenshot should be taken if there is a fault with the cursor. It often appears that a screenshot is unnecessary because everything is obvious. However, past experience has shown that discovered bugs are not immediately rectified.

It’s possible that the interface has changed, and without a screenshot, it’ll be difficult to tell what and where the problem is. The screenshot allows you to compare and contrast the prior and current user interfaces.

6.Differences between Use Case and Test Case

	Use Case	Test Case
Definition	A diagram that includes a series of actions taken by an actor that interacts with the system to reach a goal	A document for testers to follow that contains various testing elements, actions, expected results, etc
Purpose	To understand the end-user interaction with the system, as well as the system’s behavior	To validate that a particular feature is functioning faultlessly as it should
Based on	System requirement specification	Use cases
Executed by	Business user or external software	QA Testers
Focused on	The end-user	The results
Advantages	Concentrate on the end-user interaction with the system Help understand the system’s behavior based on the requirements Give a clear visualize picture of the interaction Could serve in later stages as a firm base for test cases	Validate a specific software feature is working flawlessly Ensure good testing coverage Keep the team aligned with forthcoming assignments Can be reusable for future purposes

7. What is the difference between a test case and a test scenario/condition?

Here, are significant differences between Test scenario and a Test Case

Test Scenario	Test Case
A test scenario contains high-level documentation which describes an end to end functionality to be tested.	Test cases contain definite test steps, data, expected results for testing all the features of an application.
It focuses on more “what to test” than “how to test”.	A complete emphasis on “what to test” and “how to test.”.
Test scenarios are a one-liner. So, there is always the possibility of ambiguity during the testing.	Test cases have defined a step, pre-requisites, expected result, etc. Therefore, there is no ambiguity in this process.
Test scenarios are derived from test artifacts like BRS, SRS, etc.	Test case is mostly derived from test scenarios. Multiple Test case can be derived from a single Test Scenario
It helps in an agile way of testing the end to end functionality	It helps in exhaustive testing of an application
Test scenarios are high-level actions.	Test cases are low-level actions.
Comparatively less time and resources are required for creating & testing using scenarios.	More resources are needed for documentation and execution of test cases.

This website uses cookies to improve your experience. If you click OK or continue to use this website, we will consider that you accept our cookie policy.