Contents

Internships: ...................................................... 3
Skill not interested in: ......................................................................................................... 3

Functional testing: ............................................ 3

What is QA? ....................................................................................................................... 3
What is QC? ....................................................................................................................... 4
Verification vs validation: .................................................................................................... 5
SDLC ................................................................................................................................. 5
STLC .................................................................................................................................. 5
5. **Unit Testing:** ............................................................................................................. 6
6. **Integration Testing:** ................................................................................................... 7
7. **System Testing:** ........................................................................................................ 7
8. User Acceptance Testing (UAT):....................................................................................... 7
9. Smoke Testing ................................................................................................................ 7
10. Sanity Testing: .............................................................................................................. 7
11. Regression Testing: ....................................................................................................... 8
12. Test Case: .................................................................................................................... 8
13. Test Scenario: ............................................................................................................... 8
14. **Test Plan:** ............................................................................................................... 8
15. **Test Strategy:** ......................................................................................................... 8
Difference between Test Case, Test Scenario, Test Plan, and Test Strategy: .......................... 9
Entering and Exit Criteria of STLC: ....................................................................................... 9
Severity and Priority: ........................................................................................................... 9
Bug Leakage vs Release: ................................................................................................... 10
State of Bug:..................................................................................................................... 10
How to Comment or Log a Bug: ......................................................................................... 10
Monkey Testing: ............................................................................................................... 10
Ad Hoc Testing: ................................................................................................................ 10
V Model:........................................................................................................................... 10
Distributed Testing: .......................................................................................................... 11
Alpha vs Beta Testing: ....................................................................................................... 11
Static vs Dynamic Testing: ................................................................................................ 11
Functional vs Non-Functional Testing: .............................................................................. 11
Difference between Error, Bug, and Defect: ....................................................................... 12
Resume: ......................................................... 12
Projects ........................................................................................................................... 12
Graph Route Planner for Rawalpindi & Islamabad .......................................................... 12
Scheduling Algorithms (Operating System, Visual Studio, C++) ....................................... 13
CNN based lung segmentation: ..................................................................................... 15
Infinite Runner game ..................................................................................................... 15
Snake and Ladder Game ............................................................................................... 16
Student's Learning Management System ....................................................................... 17

FYP: ................................................................ 18
My role: ............................................................................................................................ 18
Difficulty i faced: .............................................................................................................. 21
Internships:
At ZIMCO International, my internship focused on project management and quality
assurance within supply chain operations. our assignments involved managing
projects, coordinating sales and procurement processes, and ensuring quality
standards were upheld.
During my internship at NESCOM, the primary focus was on conducting research into AI
models, particularly in machine learning (ML) and deep learning.

This experience improved my skills in project management and quality assurance,

providing valuable insights into optimizing processes.
During my internship at NESCOM, Our task was to explore how ML and deep learning
models contribute to the development of AI systems. This experience provided valuable
knowledge of theoretical foundations and practical applications of AI technologies,

Skill not interested in:

I want to be transparent about my skills and experiences. While I have listed [html and
css] on my resume, I must admit that it's an area I no longer have a strong interest in
pursuing. My engagement with it has been limited, and I possess only surface level
knowledge. However, I am eager to focus on areas where I can bring my full enthusiasm
and expertise to the table, such as python etc. I believe that dedicating my efforts to
these areas will allow me to contribute effectively to the team.

Functional testing:
What is QA?
In service-oriented sectors QA refers to ensuring that products and
services meet the desired standards. In software development QA refers to
ensuring the functional and nonfunctional requirements of the software
are met and it performs adequately in different conditions. It also includes
processes like coding reviews, documentation checks etc.

{ functional requirements define the system i.e how the system MUST
work.
These are the basic demands of the end user. Mandatory needs,
What is QC?
Where quality assurance refers to establishing processes to check to
ensure quality throughout the development cycle, QC refers to the actual
inspection and testing to verify adherence to quality standards.

Let's use the example of baking a cake to illustrate the difference between
quality assurance (QA) and quality control (QC).
1. Quality Assurance (QA): Imagine you're baking a cake for a special
occasion. In the QA phase:
• You carefully follow a tested recipe that you know produces
good results. This recipe represents the established process or
standards.
• You ensure that you have all the necessary ingredients and
equipment before you start baking. This represents the
preparation and planning phase of QA.
• You verify that you're using fresh ingredients and that your oven
is properly preheated. This represents adherence to standards
and best practices.
2. Quality Control (QC): During the baking process, you implement
quality control measures:
• You periodically check the cake as it bakes to ensure it's rising
evenly and not burning. This represents inspection and testing
during production.
• You use a toothpick to test the doneness of the cake before
removing it from the oven. This is a specific QC test to verify
that the product meets the desired quality standard.
• After the cake has cooled, you inspect it for any cracks, uneven
layers, or other imperfections. This represents a final QC
inspection before delivery to ensure the product meets
customer expectations.
In this example:
 • QA involves following the recipe, preparing properly, and ensuring
that the baking process adheres to established standards and best
practices to prevent defects.
• QC involves actively monitoring the cake during baking, conducting
tests to verify its quality, and inspecting the final product to identify
and address any defects before it's served to the customer.

Verification vs validation:
Verification -> ARE WE BUILDING THE PRODUCT RIGHT?
Validation -> ARE WE BUILDING THE RIGHT PRODUCT?
• Verification ensures that the product is built correctly according to
its specifications.
• Validation ensures that the product meets the needs and
expectations of its users or customers.
SDLC

Requirement analysis -> planning -> design -> implementation -> testing ->
deployment -> maintenance

STLC
Requirement analysis -> test design -> test environment setup -> test
execution ->defect reporting and tracking -> test closure

1. **Testing Types:**
Testing types refer to different approaches and techniques used to
validate and verify software. Some common testing types include:
- Unit Testing
- Integration Testing
- System Testing
 - User Acceptance Testing (UAT)
- Smoke Testing
- Sanity Testing
- Regression Testing

2. **Gray Box Testing:**

Gray box testing is a testing technique that combines elements of both
black box and white box testing. Testers have partial knowledge of the
internal workings of the software system, allowing them to design tests
based on both the specifications and the internal logic.

3. **Black Box Testing:**

Black box testing is a testing approach where testers examine the
functionality of a software system without knowing its internal code
structure. Testers focus on inputs and outputs, treating the system as a
"black box."

4. **White Box Testing:**

White box testing, also known as glass box or clear box testing, is a
testing technique where testers have full knowledge of the internal code
structure of the software system. Testers design tests based on the
internal logic, paths, and structures of the code.

5. **Unit Testing:**
Unit testing is a testing phase where individual units or components of a
software system are tested in isolation. It focuses on verifying the
correctness of each unit's behavior through automated or manual tests.
6. **Integration Testing:**
Integration testing is a testing phase where multiple units or components
of a software system are combined and tested as a group. It verifies the
interactions and interfaces between integrated components to ensure they
work together correctly.

7. **System Testing:**
System testing is a testing phase where the entire software system is
tested as a whole. It validates the system against its requirements and
verifies that it meets the specified functionality, performance, and
reliability criteria.

8. User Acceptance Testing (UAT):

User Acceptance Testing (UAT) is a testing phase where end-users or
stakeholders evaluate the software to determine if it meets their
requirements and expectations. It validates that the software is ready for
deployment and use in the production environment.

9. Smoke Testing
Smoke testing is a type of testing that quickly verifies whether the critical
functionalities of a software system work correctly. It is performed to
ensure that the system is stable enough for further testing.

10. Sanity Testing:

Sanity testing is a type of testing that verifies whether specific
functionalities or areas of a software system have been fixed or updated
correctly after changes or enhancements. It focuses on ensuring that the
system remains stable and usable.
11. Regression Testing:
Regression testing is a testing technique that verifies whether recent
changes to a software system have affected its existing functionalities. It
ensures that new code changes or modifications do not introduce
unintended side effects or break existing features.

12. Test Case:

A test case is a set of conditions or steps designed to determine whether
a particular feature or aspect of a software system is working correctly. It
includes input data, execution steps, and expected results.

13. Test Scenario:

A test scenario is a high-level description of a specific functionality or
feature to be tested. It outlines the conditions, actions, and expected
outcomes for testing purposes.

14. **Test Plan:**

A test plan is a comprehensive document that outlines the testing
approach, scope, objectives, resources, schedules, and deliverables for a
software testing project. It serves as a roadmap for the entire testing
process.

15. **Test Strategy:**

A test strategy is a high-level document that defines the overall approach
to be taken for testing a software system. It outlines the testing
methodologies, techniques, tools, and resources to be used, as well as the
roles and responsibilities of the testing team.
Difference between Test Case, Test Scenario, Test Plan, and Test Strategy:

- **Test Case:** It is a detailed specification of a test scenario, including

input data, execution steps, and expected results.
- **Test Scenario:** It is a high-level description of a specific functionality
or feature to be tested.
- **Test Plan:** It is a comprehensive document that outlines the testing
approach, scope, resources, schedules, and deliverables for a testing
project.
- **Test Strategy:** It is a high-level document that defines the overall
approach to testing, including methodologies, techniques, tools, and
resources
.

Entering and Exit Criteria of STLC:

• Entering Criteria: These are the conditions that must be met
before starting a particular phase of the Software Testing Life
Cycle (STLC). Entering criteria ensure that the testing process
can begin effectively and efficiently.
• Exit Criteria: These are the conditions that must be fulfilled
before concluding a phase of the STLC. Exit criteria help in
determining when testing activities for a particular phase are
completed and when to move to the next phase.
Severity and Priority:
• Severity: Severity refers to the impact of a defect on the
system's functionality. It categorizes how severe the impact of
a bug is on the software's operation or its ability to meet user
requirements.
• Priority: Priority indicates the importance or urgency of fixing a
defect. It determines the order in which defects should be
addressed based on their impact on the system and business
priorities.
Bug Leakage vs Release:
• Bug Leakage: Bug leakage refers to the situation where
defects or bugs are identified by users or customers after the
software has been released to production. These defects were
not detected during the testing phase.
• Release: Release refers to the process of making the software
available to users or customers. A software release occurs
after it has undergone testing and meets the predefined quality
standards.
State of Bug:
• The state of a bug refers to its current status in the bug tracking
system. Common bug states include New, Assigned, In
Progress, Fixed, Verified, Closed, and Reopened.
How to Comment or Log a Bug:
• When logging a bug, it's important to provide clear and concise
information about the issue, including steps to reproduce,
expected behavior, actual behavior, environment details, and
any relevant attachments or screenshots. Comments should
be added to keep all stakeholders informed about the bug's
status and any updates.
Monkey Testing:
• Monkey testing, also known as random testing, involves
executing the software with random inputs to uncover
unexpected behavior or defects. It aims to find bugs that may
not be identified through traditional testing approaches.
Ad Hoc Testing:
• Ad hoc testing is an informal testing approach where testers
explore the software without predefined test cases. Testers
use their domain knowledge, experience, and intuition to
identify defects, usability issues, and other problems.
V Model:
• The V Model is a software development and testing
methodology that emphasizes a sequential and phased
approach. It depicts the relationship between each phase of
 the development life cycle and its corresponding testing
phase. The left side of the "V" represents the development
phases, while the right side represents the corresponding
testing phases.
Distributed Testing:
• Distributed testing involves executing tests across multiple
environments or locations simultaneously. It allows for
scalability, parallel execution, and efficient use of resources.
Distributed testing helps in simulating real-world scenarios
and improving test coverage.
Alpha vs Beta Testing:
• Alpha Testing: Alpha testing is performed by internal testers or
developers within the organization. It focuses on validating the
software's functionality, usability, and reliability in a controlled
environment before releasing it to external users.
• Beta Testing: Beta testing involves releasing the software to a select
group of external users or customers for real-world testing. The goal
is to gather feedback, identify defects, and assess the software's
performance in diverse environments.
Static vs Dynamic Testing:
• Static Testing: Static testing involves reviewing and analyzing the
software artifacts without executing the code. It includes techniques
such as code reviews, inspections, and walkthroughs to identify
defects and improve quality early in the development process.
• Dynamic Testing: Dynamic testing involves executing the software
and testing its behavior during runtime. It includes techniques such
as unit testing, integration testing, system testing, and acceptance
testing to validate the software's functionality and performance.
Functional vs Non-Functional Testing:
• Functional Testing: Functional testing verifies that the software
functions correctly according to its requirements. It focuses on
testing the features, functionalities, and user interactions of the
software.
 • Non-Functional Testing: Non-functional testing evaluates aspects
of the software other than its functionality, such as performance,
scalability, reliability, security, and usability. It ensures that the
software meets quality attributes and user expectations beyond just
its basic functionalities.
13. Bug Life Cycle:
• Bug life cycle refers to the stages a defect goes through from its
discovery to its resolution. Common stages include New, Assigned,
In Progress, Fixed, Verified, Closed, and Reopened. The bug
progresses through these stages as it is reported, assigned, fixed,
tested, and ultimately closed.
Difference between Error, Bug, and Defect:
• Error: An error is a mistake made by a human that results in incorrect
or unexpected behavior in the software.
• Bug: A bug is a flaw or defect in the software that causes it to deviate
from its expected behavior.
• Defect: Defect is a broader term that encompasses both errors and
bugs. It refers to any imperfection or problem in the software that
affects its quality or functionality.

Resume:
Projects

Graph Route Planner for Rawalpindi & Islamabad

Technical Details:
Let's consider a scenario where a user wants to travel from Location A to Location B.
Here's how our project works:
Graph Construction:
We construct a graph representing the road network, where nodes represent locations
and edges represent roads connecting them.
Each edge is weighted based on factors like distance or travel time between locations.
Shortest Path Calculation:
When the user requests a route from Location A to Location B, our system invokes
Dijkstra's algorithm.
Dijkstra's algorithm iteratively explores the neighboring nodes from the source location
(Location A) to determine the shortest path to all other locations.
It maintains a priority queue of nodes sorted by their tentative distances from the
source.
By continually selecting the node with the shortest tentative distance, it gradually
explores the entire graph until it reaches the destination (Location B).
Once the algorithm completes, we obtain the shortest route from Location A to
Location B.
Conclusion:
By leveraging graph data structures and Dijkstra's algorithm, our Graph Route Planner
project efficiently finds the shortest route between locations in Rawalpindi &
Islamabad.

Scheduling Algorithms (Operating System, Visual Studio, C++)

1. Objective:
• The primary goal was to simulate the behavior of different CPU
scheduling algorithms and evaluate their performance in terms of CPU
utilization and turnaround time.
2. Technologies:
• We used Visual Studio as our development environment and
implemented the project in C++.
CPU Scheduling Algorithms:
1. First-Come, First-Served (FCFS):
• We implemented FCFS by maintaining a queue of processes and
executing them one by one without pre-emption.
2. Shortest Job First (SJF):
 • SJF selects the process with the shortest burst time next, aiming to
minimize average waiting time.
• We implemented SJF by sorting the processes based on their burst times
and executing them accordingly.
3. Round Robin (RR):
• RR allocates a fixed time quantum to each process, allowing them to
execute for a predefined time slice.
• We implemented RR by maintaining a circular queue of processes and
rotating them after each time quantum.

Simulation:
1. Process Generation:
• We generated a set of random processes with varying burst times and
arrival times to simulate real-world scenarios.
• Each process was assigned a unique process ID, burst time, and arrival
time.
2. Algorithm Execution:
• We simulated the execution of each scheduling algorithm on the
generated processes.
• The algorithms were applied to the processes, and their execution order
and turnaround times were recorded.
Performance Evaluation:
1. CPU Utilization:
• We measured CPU utilization as the percentage of time the CPU was
actively executing processes.
• Higher CPU utilization indicates better utilization of computing
resources.
2. Turnaround Time:
• Turnaround time represents the total time taken for a process to
complete execution, including waiting and execution time.
• Lower turnaround time implies faster process completion and better
efficiency.
CNN based lung segmentation:
1. Objective:
• Our goal was to develop a tool that could automatically segment lung
regions from CXR images, aiding medical professionals in diagnosing
respiratory conditions.
2. Technology Stack:
• We utilized PyCharm as our integrated development environment (IDE)
for Python development.
• Python served as the primary programming language for implementing
the CNN-based segmentation model.
3. CNN Architecture:
• We designed a CNN architecture suitable for image segmentation tasks.
• The architecture comprised convolutional layers, pooling layers, and
upsampling layers to extract features and generate segmentation masks.
4. Dataset:
• We trained and evaluated our model using a dataset of labeled CXR
images.
• The dataset contained pairs of input CXR images and corresponding
binary masks indicating the lung regions.
5. Model Training:
• We trained the CNN model using the labeled CXR images and their
corresponding masks.
• During training, the model learned to predict segmentation masks that
accurately delineated the lung regions from the input images.

Infinite Runner game

Technical Details:
1. Game Engine:
• We used Unity, a popular game engine, for developing the game.
• Unity provides essential features like scene management, physics
simulation, and asset importing.
2. 3D Modeling:
• Blender was utilized for creating and editing 3D models of characters,
obstacles, and environment elements.
 • Blender's intuitive interface and powerful tools helped in designing
visually appealing game assets.
3. Game Mechanics:
• We implemented player controls for moving the character left or right to
avoid obstacles.
• Obstacles were randomly generated and spawned in the game world to
provide an endless gameplay experience.
• Additionally, we implemented a scoring system to keep track of the
player's progress and achievements.
4. Unity Scripting:
• C# scripting language was used to write scripts for defining game
behavior, interactions, and game logic.
• Scripts were responsible for controlling player movement, obstacle
spawning, collision detection, and scoring updates.

Snake and Ladder Game

Technical Details:
1. Object-Oriented Design:
• We employed object-oriented principles to design the game, with classes
representing different game entities such as the board, players, dice, and
squares.
• This design approach facilitated modularity, extensibility, and code
reusability.
2. GUI Development:
• We created a graphical user interface (GUI) to display the game board
and player interactions.
• The GUI provided visual feedback to players, including dice rolls, token
movements, and game progress.
3. Event Handling:
• Event handling mechanisms were implemented to respond to player
actions, such as dice rolls and token movements.
• We ensured seamless communication between the GUI components and
the underlying game logic.
4. C# Programming:
 • C# language was used to implement the game logic, event handling, and
GUI interactions.
• We leveraged features like classes, inheritance, and polymorphism to
encapsulate behavior and data within objects.
Example Scenario:
Players take turns rolling a virtual dice, and their tokens move forward based on the
number rolled. If a player lands on a square with a ladder, they climb up to a higher
square, while landing on a square with a snake causes them to slide down to a lower
square. The first player to reach the final square wins the game.

Student's Learning Management System

Technical Details:
1. Database Design:
• We designed a relational database schema to store student information,
course details, grades, and other relevant data.
• The database schema ensured data integrity, normalization, and efficient
data retrieval.
2. Database Management:
• Microsoft SQL Server was used as the database management system
(DBMS) to create and manage the database.
• SQL queries were employed to perform database operations such as
insertion, retrieval, updating, and deletion of records.
3. Data Analysis:
• We utilized Excel for data analysis and visualization, allowing instructors
to track student performance, course enrollment trends, and other
metrics.
• Excel's features for creating charts, graphs, and pivot tables facilitated
data interpretation and decision-making.
4. Integration:
• The database was integrated with the front-end application to enable
seamless data interaction and synchronization.
• We ensured secure data transmission and authentication mechanisms to
protect sensitive information.
Example Scenario:
Instructors can create courses, add assignments, and grade student submissions
within the LMS interface. Students can enroll in courses, access course materials,
submit assignments, and view their grades and feedback. The system also facilitates
communication between students and instructors through messaging features.

FYP:
My final year project was an AI-driven DOOH (Digital Out-of-Home)
advertisement recommender system. The objective was to create a
platform capable of delivering personalized and targeted advertisements,
with the aim of maximizing impact and return on investment (ROI). We had
to collect a diverse data-set of labelled images, training a CNN model for
accurate age and gender detection, and implementing the system on the
hardware and software platform. Additionally, we developed an ad
recommendation algorithm to personalize the displayed advertisements
based on the detected age and gender information.

My role:
my role was managing the MySQL database, which includes setting up the connection
between the server and the database, ensuring data integrity, handling CRUD
operations (Create, Read, Update, Delete) for advertisements, and optimizing database
performance for efficient data retrieval and storage..
1. Data Sources:
• You obtained the primary dataset, the UTKFace dataset, from Kaggle. This
dataset contains a diverse collection of facial images with annotations
for age and gender, making it suitable for training and evaluating the
model.
2. Directory Structure:
• You organized the dataset into a structured directory format. This
organization includes subdirectories for age and gender, making it easy to
navigate and access specific subsets of data based on age and gender
labels.
3. File Naming Convention:
 • You established a consistent file naming convention for the images in the
dataset. This convention encodes essential attributes such as age and
gender directly into the filenames, simplifying the data preprocessing
process.
4. File Path Construction:
• You constructed file paths to access and process the images in the
dataset. By using Python's os module, you combined the base directory
path with the filename to obtain the complete file path of each image.
5. Label Extraction:
• You extracted age and gender labels from the filenames of the images. By
splitting the filenames using a delimiter, you separated the age and
gender labels, which were later used for creating a DataFrame.
6. DataFrame Creation:
• You created a pandas DataFrame to organize and store the image paths,
age labels, and gender labels. This DataFrame provides a tabular
structure for efficiently handling and manipulating the data during
preprocessing and model training.
7. Mapping Labels for Gender:
• You defined a gender dictionary to map numeric gender labels to
meaningful categories (e.g., 'Male' and 'Female'). This mapping enhances
the interpretability of the dataset.
8. Exploratory Data Analysis (EDA):
• You performed exploratory data analysis to visualize the dataset and gain
insights into the distribution of age and gender labels. This analysis
provides valuable insights that inform subsequent preprocessing and
modeling decisions.
9. Feature Extraction:
• You implemented feature extraction techniques to capture relevant
features from the facial images. This process involved converting images
to grayscale, resizing them, and converting them into NumPy arrays for
efficient handling and manipulation.
10. Normalization:
• You normalized the extracted features to scale the pixel values between 0
and 1. This normalization ensures standardized input data, improving the
training performance and convergence of the model.
CLIENT SERVER APP:
1. Understanding the Need:
• You recognized the importance of effective advertisement management
in today's digital age and identified the limitations of traditional methods.
Understanding the need for efficient tools, you embarked on developing a
client-server application to streamline advertisement management
processes.
2. Defining Objectives:
• You delineated clear objectives for the project, aiming to automate
various advertisement-related tasks and centralize the management
process. Your focus on user-friendly interfaces and data-driven decision-
making reflects a deep understanding of the project's goals.
3. Selecting Technologies:
• You made informed decisions regarding the choice of technologies for
both the client-side and server-side implementation. Opting for React for
the client-side and Express framework with MySQL for the server-side
demonstrates your expertise in selecting appropriate tools for specific
project requirements.
4. Client-Side Implementation:
• You were responsible for developing the client-side of the application
using React. This involved creating React components, managing state
with useState hook, and handling user interactions. The Signin
component, in particular, showcases your proficiency in implementing
user authentication logic.
5. Server-Side Implementation:
• You undertook the development of the server-side using Express and
MySQL. This included setting up the Express server, establishing
connections to the MySQL database, and implementing endpoints for
fetching, adding, and deleting advertisements. Your attention to detail
ensured robust backend infrastructure and secure handling of server
requests.
6. Integration and Testing:
• You seamlessly integrated the client-side and server-side components to
create a cohesive application. Your thorough testing procedures ensured
the reliability and functionality of the application, providing users with a
seamless experience.
7. Documentation and Presentation:
 • Your comprehensive documentation and presentation of the project's
implementation details demonstrate your ability to communicate
complex technical concepts effectively. Clear explanations and
structured organization facilitate understanding and showcase your
project management skills.

Difficulty i faced:
During my Final Year Project, our supervisor asked us to scale up the database volume in the
final weeks of the project.

It was quite unexpected. It was quite a challenge because of time constraints and also the
complexity involved in changing the whole infrastructure of our project.

But my teammate and I made sur that we don’t fall behind and I remember we developed this
whole plan, basically a timeline of how we will get the expected results. It was a one week plan.

1. first of all we had to check current database capacity

2. Add more database nodes for scaling.
3. Set up new nodes and configure them.
4. Move data smoothly to new nodes.
5. Test and tweak configurations for better performance.
6. Apply changes to the live system. ( and this worked out well for us at the end )