DAY 2 - Industry Connect

a. Explain SDLC with an example 

SDLC is Software Development Life Cycle, which 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

for example:

STEP 1. Identify the Current Problems 

When we got a new project of workout app for mobile device, we should ask ourselves a simple question first:“What are the current problems?”

This stage of the SDLC means getting as much as info from all stakeholders, customers, workout experts, and programmers. Learn the strengths and weaknesses of the current system with improvement as the goal. 

STEP 2. Plan 

“What do we want?”

In this stage of the SDLC, our team should determines the possibility of implementing the project successfully, along with the lowest risk.

STEP 3. Design 

“How will we get and what we want?” 

This phase of the SDLC starts by turning the software specifications into a design plan called the Design Specification. All stakeholders then review this plan and offer feedback and suggestions, which is very important to have a plan for collecting and incorporating stakeholder input into this document. 

STEP 4. Build

“Let's create what we want.” 

At this stage, the actual development starts. all developers should stick to the agreed Design Specification.

STEP 5. Code Test 

“Did we get what we want?” 

In this stage, we test for defects and bugs. and also we fix all the bugs or issues that we can find to meet the Specification.

STEP 6. Software Deployment 

“Let's start using what we got.”

At this stage, the goal is to deploy the software to the production environment so users can start using the product.

b. What happens in requirement analysis phase in SDLC 

The purpose of the Requirements Analysis Phase is to transform the stakeholders' needs and requirements into measurable, testable, traceable, complete, consistent, and stakeholder-approved requirements.

c. Explain STLC with an example 

The Software Testing Life Cycle (STLC) includes both verification and validation, which is part of the Software Development Life Cycle (SDLC) with 6 core principles:

1. Requirement Analysis;
2. Test Planning;
3. Test Case Development;
4. Test Environment Setup;
5. Test Execution;
6. Test Cycle Closure.

for example:

STEP 1. Requirements analysis

This is the most important phase, due to we can almost fix all the potential issues and bugs for free. Also, we can determine the potential needs for automation testing, and estimate the labour cost, along with the entry and exit criteria, and then document all above info.

STEP 2 Test Planning

We build a test plan at this phase, which includes all phases of the testing itself, timing, participants, and responsibilities. As a result of this, we receive data on: the participants and their roles in testing; the necessary testing tools; the necessary test environment.

STEP 3 Test Case Development

We use manual and automated testing to achieve full coverage of the software's functionality, which based on the requirements. 

STEP 4 Test Environment Setup

The test plan makes it clear which test environment should be used. At this STLC phase, operating systems and virtual machines are configured, testing tools, the project's test environment and databases are deployed. We also make requests to DevOps and Admins if support is needed.

STEP 5 Test Execution

Tests are performed based on the requirement and correctly configured test environment on Step 4. All test results are recorded in the Test Management System. Negatively passed tests, where the actual result differs from the one expected, are recorded as errors and transferred to the development team for revision with subsequent rechecking after correction.

STEP 6 Test Cycle Closure

The last phase of the STLC is the final version of testing reports for the client or stakeholders. These should include the time spent, the percentage of errors found to positive test results, the total number of errors found and fixed. 

d. If you are given a new requirement, how would you go about testing this requirement? 

STEP 1

I'll have QA check all the requirements specifications, wireframes, and mockups first. 

STEP 2

Checking the completeness which includes all possible scenarios have been considered in a requirement, and try to find any gaps or uncovered cases.

STEP 3

Checking the clearness which includes all statements are correct, truthful, and logical.

STEP 4

I'll check the correctness which means no conffused terms in requirements and only generally accepted terms should be used.

STEP 5

Check the consistency to see if therer is any uncover contradictions with other requirements and with internal and external standards.

STEP 6

I'll check the testability to see if there is a way to check whether implementation meets a requirement.

STEP 7

Finally, I'll use heuristics testing approach or testing strategy that relies on past data about probabilities to make testing requirements more effective due to there are some of types of common errors occur in certain parts of the code. It also helps to check requirements against an accumulated base of problems. 

I'll make sure to cover all these areas in requirements or app:

Structure (what the product is): 

Is it one program or many? 

What physical parts come with it? 

Can I test it module by module?

Function (what the product does): 

What are its functions? 

What kind of error handling does it do? 

What kind of user interface does it have? 

Does it do anything that is not visible to the user? 

How does it interface with the operating system?

Data (what it processes): 

What kinds of input does it process? 

What does its output look like? 

What kinds of modes or states can it be in? 

Does it come packaged with preset data? 

Is any of its input sensitive to timing or sequencing?

Platform (what it depends on): 

What operating systems does it run on? 

Does the environment have to be configured in any special way? 

Does it depend on third-party components?

Operations (how it will be used): 

Who will use it? 

Where and how will they use it? 

What will they use it for? 

Are there certain things that users are more likely to do? 

Is there user data that would make the tests more realistic?

All those questions could apply to the whole application as well as to requirements analysis.

Good requirements should be clear and precise, with no uncertainty or ambiguity; should be measurable in terms of specific values; should be testable and complete; and shouldn't contain any contradictions. 

e. What would you do during the Test cases development phase in STLC 

Test Case Development Activities includes:

• Create test cases, automation scripts (if applicable)
• Review and baseline test cases and scripts.
• Create test data (If Test Environment is available)

f. How do you log bugs/defects? 

The bug report document includes every detail regarding a bug, such as the description, the date the bug was discovered, the identity of the tester who discovered it, the name of the developer who corrected it, and so on.

Bug Report should include the following details when reporting the bug to the developer.

• Defect ID — The defect’s unique identifying number.
• Defect Description — Detailed explanation of the Defect, including information about the module where the Defect was discovered.
• Version — The application version in which the flaw was discovered.
• Steps — A detailed set of steps with screenshots that the developer can use to reproduce the issues.
• Date Raised — Date when a Defect Is highlighted
• Reference — To help explain the fault, include references to papers such as specifications, design, architecture, or even screenshots of the error.
• Detected By — Name/ID of the tester who reported the issue
• Status — The defect’s current state; more on this later.
• Status — The defect’s current state; more on this later.
• Fixed by — Name/ID of the developer who made the fix
• Date Closed — The date on which the defect was resolved.
• Severity — the fault defines its influence on the application.
• Priority — that is related to the urgency of defect correction. Severity According to the impact urgency with which the issue should be corrected, the priority could be set to High, Medium, or Low.

g. Why do you need screenshots and logs to be attached to a defect/bug? 

Because it is the easiest and the most intuitive way to record and reproduce the defect/bug.

h. How would you prioritize your defect/bug? 

STEP 1

First of all. only prioritize the bug when we are interacting with the customer and thoroughly understand the business flow implemented in the application. 

Priority should be set based on the criticality of the business / functional requirement. Also, set severity only after doing a through impact analysis. Best is if we can have bug triage meeting at this stage, so that everyone can provide their inputs to identify the correct severity level.

STEP 2
Set four severity levels: High, Medium, Low, Lowest. Set their values as 4, 3, 2, 1. 4 as highest and 1 as lowest.

Severity	Severity Value	Example
High	4	Data loss, missing feature, security violation
Medium	3	Feature is missing but workaround is there, if high profiles users like management will get an impact, then it would be of high severity 4
Low	2	It is impacting minor things, but, user is able to do the work
Lowest	1	A cosmetic error, spelling mistake, typo etc..

STEP 3

Set four priority levels: Critical, High, Medium, Low. Set them values as 4, 3, 2, 1. 4 as Critical and 1 as low. Please ask the business analyst to set the priority.

Priority	Priority Value	Example
Critical	4	Application is getting started, Critical business flow got stuck, Data loss, business loss, loss of end user, a security violation, system is very unstable
High	3	Feature is missing which is not critical for only very few users that do not have much impact on business, if high profiles users like management will get an impact, then it would be of high severity 4
Medium	2	Feature is missing but workaround is there. If users from management group are getting impacted, then it can be of priority 3 or 4. It can also be some feature of the functionality is not working
Lowest	1	A cosmetic error, spelling mistake, typo. Here, one important point to note is that even a spelling mistake or typo can also be of high priority or critical. e.g. If there is a spelling mistake of name of a person from senior management, then it may have high priority.

Priority can be calculated as

Bug Id	Bug Description	Severity Value	Priority Value	Priority
Bug_1	Bug Description 1	2	4	8
Bug_2	Bug Description 2	3	2	6
Bug_3	Bug Description 3	1	1	1
Bug_4	Bug Description 4	4	3	12
Bug_5	Bug Description 5	2	4	8

STEP 4

Now, the bug with highest priority should be fixed first. In this case bug “Bug_4” should be fixed first. Then Bug_1 and Bug_5 should be fixed and so on.

i. How do you go about writing test cases for a given requirement? 

STEP 1 Test Case ID

Test cases should all bear unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization, clarity, and understanding.

STEP 2 Test Description

This description should detail what unit, feature, or function is being tested or what is being verified.

STEP 3 Assumptions and Pre-Conditions

This entails any conditions to be met before test case execution. One example would be requiring a valid Outlook account for a login.

STEP 4 Test Data

This relates to the variables and their values in the test case. In the example of an email login, it would be the username and password for the account.

STEP 5 Steps to be Executed

These should be easily repeatable steps as executed from the end user’s perspective. For instance, a test case for logging into an email server might include these steps:

1. Open email server web page.
2. Enter username.
3. Enter password.
4. Click “Enter” or “Login” button.

STEP 6 Expected Result

This indicates the result expected after the test case step execution. Upon entering the right login information, the expected result would be a successful login.

STEP 7 Actual Result and Post-Conditions

As compared to the expected result, we can determine the status of the test case. In the case of the email login, the user would either be successfully logged in or not. The post-condition is what happens as a result of the step execution such as being redirected to the email inbox.

STEP 8 Pass/Fail

Determining the pass/fail status depends on how the expected result and the actual result compare to each other.

Same result = Pass
Different results = Fail

j. What is the difference between a use case and a test case? 

A Use Case is used to define the system that how to use the system for performing a specific task. 

A Test Case is defined as a group of test inputs, execution condition, and expected results which further lead to developing a particular test objective.

k. What is the difference between test scenario and test case?

A Test Scenario is defined as any functionality that can be tested. It is a collective set of test cases which helps the testing team to determine the positive and negative characteristics of the project. Test Scenario gives a high-level idea of what we need to test. 

Example of Test Scenario For an eCommerce Application, a few test scenarios would be 

• Test Scenario 1: Check the Search Functionality 
• Test Scenario 2: Check the Payments Functionality 
• Test Scenario 3: Check the Login Functionality

A Test Case is a set of actions executed to verify a particular feature or functionality of your software application. A Test Case contains test steps, test data, precondition, postcondition developed for specific test scenario to verify any requirement. The test case includes specific variables or conditions, using which a testing engineer can compare expected and actual results to determine whether a software product is functioning as per the requirements of the customer.

KEY DIFFERENCE

1. Test Case is a set of actions executed to verify particular features or functionality whereas Test Scenario is any functionality that can be tested.
2. Test Case is mostly derived from test scenarios while Test Scenarios are derived from test artifacts like BRS and SRS.
3. Test Case helps in exhaustive testing of an application whereas Test Scenario helps in an agile way of testing the end to end functionality.
4. Test Cases are focused on what to test and how to test while Test Scenario is more focused on what to test.
5. Test Cases are low-level actions whereas Test Scenarios are high-level actions.
6. Test Case requires more resources and time for test execution while Test Scenario require fewer resources and time for test execution.
7. Test Case includes test steps, data, expected results for testing whereas Test Scenario includes an end to end functionality to be tested.