Forem: Israt Zahan Sathi

5 Things Every Beginner Should Know Before Starting Manual Testing

Israt Zahan Sathi — Sun, 01 Feb 2026 15:15:14 +0000

Hello DEV Community 👋

This is my first post here after a long time, and I’m really excited to start sharing my learning journey.

Currently, I’m working on building my skills in Software Quality Assurance (SQA), especially focusing on Manual Testing.
As a beginner, I realized that manual testing is not just about clicking buttons — it’s about thinking like a user, understanding requirements, and ensuring software quality.

So today, I want to share 5 important things every beginner should know before starting manual testing.

✅1. Manual Testing Is More Than “Just Checking”

Many people think manual testing is only about trying the app and finding bugs.

But actually, manual testing is about:

Understanding the feature
Validating user experience
Ensuring the product meets requirements

A tester’s job is to make sure the software works correctly in real-life scenarios.

✅2. Requirements Are Your Best Friend

Before testing anything, always ask:

What is the expected behavior?
What problem is this feature solving?
What are the acceptance criteria?

Even simple testing becomes much easier when you clearly understand the requirement.

📌 Good testing always starts with good understanding.

✅3. Always Think in Positive and Negative Scenarios

Beginner testers often test only the “happy path.”
But real users don’t always behave perfectly.

Example for a login page:

✅ Positive Test: Login with correct credentials
❌ Negative Test: Login with wrong password
❌ Negative Test: Leave fields empty
❌ Negative Test: Enter invalid phone number

Testing both scenarios helps find real issues.

✅4. Test Cases Help You Stay Organized

Writing test cases is one of the best habits for QA engineers.

A simple test case includes:

Test Steps
Expected Result
Actual Result
Status (Pass/Fail)

Even if you are new, test cases help you test systematically and avoid missing important checks.

✅5. Bug Reporting Is a Skill (Not Just a Message)

Finding a bug is not enough — reporting it properly is equally important.

A good bug report should include:
Clear bug title
Steps to reproduce
Expected vs Actual result
Screenshot or video evidence
Severity/Priority (if applicable)

A well-written bug report saves developers a lot of time.

🌱 Final Thoughts
As a beginner in SQA, I’m learning that manual testing builds the foundation of quality assurance.

It improves:

Attention to detail
Analytical thinking
Communication
Product understanding

I’ll keep sharing more beginner-friendly QA topics as I continue learning.

💬 Let’s Connect!

If you’re also learning QA or working in software testing, feel free to share your thoughts:

👉 What was the first thing you learned in manual testing?

Thanks for reading! 😊

Find Duplicate in an Array in C++

Israt Zahan Sathi — Mon, 15 Jan 2024 06:48:32 +0000

Problem 1
You will be given an array arr of size n. Print "YES" if there is any duplicate value in the array, "NO" otherwise.

Sample Input 1
5
2 8 5 7 3
Sample Output 1
NO

Sample Input 2
7
2 1 3 5 2 1 9
Sample Output 2
YES

Input Format

First line will contain n.
Second line will contain the array arr.

Follow the steps to resolve the problem:

Assuming we get an input.
Now declare n and input its value.
Declare an array name is arr, and take that as input.
Take a tmp _to check if there are duplicate values in the array.[_tmp _is a variable used as a flag to indicate whether there are duplicate elements in the array. The name "_tmp" is often used as a shorthand for "temporary" or "temporary variable." Its purpose is to store a temporary state or result during the execution of the program.]
Then loop through and look for duplicates. If duplicate value is found then I will set "tmp = 1" and also break the loop.
After that I will check, if duplicate value is found I will print "YES", if not found I will print "NO".

Below is the implementation of the above method:

#include <bits/stdc++.h>
using namespace std;
int main()
{
    int n;
    cin >> n;
    int arr[n];
    for (int i = 0; i < n; i++)
        cin >> arr[i];
    int tmp = 0;
    for (int i = 0; i < n; i++)
    {
        for (int j = i + 1; j < n; j++)
        {
            if (arr[i] == arr[j])
            {
                tmp = 1;
                break;
            }
        }
    }
    if (tmp)
        cout << "YES" << endl;
    else
        cout << "NO" << endl;
    return 0;
}

Basic CRUD Operations

Israt Zahan Sathi — Mon, 27 Dec 2021 17:59:58 +0000

CRUD Operations
CRUD is an acronym for Create, Read, Update, and Delete. These are the four basic functions that can be performed with most traditional database systems and they are the backbone for interacting with any database.

Pic collected

HTML Verb: POST , CRUD: Create -
The POST function often uses the new resource "create". In particular, it is used to create subordinate resources. That is, no one else is subject to such parental assets. In other words, when creating a new resource, POST the parent and the service takes care of adding new resources to the parent, assigning an ID (new resource URI), etc.
If created successfully, return HTTP status 201, 201 Return a location header with a link to the newly created resource with HTTP status.
Posts are not secure or indomitable. Therefore it is recommended to request non-indomitable resources. Requesting two identical POSTs will probably result in two resources containing the same information.

/api/service /*{create a service if id not exists ,update otherwise}*/

HTML Verb: GET, CRUD: Read-
The HTTP GET method is used to "read" or retrieve an asset presentation. In the "happy" or non-error path, GET provides a presentation in XML or JSON and an HTTP response code of 200 (OK). In case of an error, it often returns a 404 (not found) or 400 (bad request).
According to the design of the HTTP specification, GET (including HEAD) requests are used to read data only and do not change it. Therefore, when used in this way, they are considered safe. That is, they can be called without the risk of data alteration or corruption. Calling it once has the same effect as calling 10 times, or not at all. Additionally, GET (and HEAD) is idempotent, meaning that multiple identical requests yield the same results as a single request.
Do not publish unsafe activities through GET — it should never change any resources on the server.

/api/service /*{returns a single page of service}*/ /api/service/{id} /*{returns a single service as defined by the id provided}*/

HTML Verb: PUT, CRUD: Update-
PUT is often used for "update" capability, PUT-in a familiar resource URI containing a newly-updated representation of the original resource with the request body.
However, PUT can also be used to create a resource where the resource ID is chosen by the client instead of the server. In other words, if the PUT is in a URI that contains the value of a non-existent resource ID. Again, there is a resource presentation in the request section. Many find it complicated and confusing. As a result, this method of creation should be used sparingly, if at all.
Alternatively, use POST to create a new resource and provide the client-defined ID in the body representation - in a URI that does not include the resource ID.
Upon successful update, return 200 from PUT or 204 if no content is returned to the body. When using PUT to create, return HTTP status 201 on successful creation. A body of feedback is optional and uses one more bandwidth. There is no need to return a link with a location title in case of creation as the client has already set the resource ID.
PUT is not a secure operation, it modifies or creates the status on the server, but it is invincible. In other words, if you create or update a resource using PUT and then make the same call again, the resource is still there and still in the same condition as it did with the first call.
For example, if a PUT call on an asset increases one counter of the asset, the call is no longer invincible. Sometimes this happens and it may be enough to document that the call is not indomitable. However, it is advisable to keep PUT requests in abeyance. It is strongly recommended to use POST for non-refractory requests.
/api/service /*{create a service if id not exists , update otherwise}*/

HTML Verb: DELETE, CRUD: Delete-
DELETE is quite easy to understand. It is used to "delete" a resource identified by a URI.
If successfully deleted, return HTTP status 200 (OK) with a response body, perhaps a presentation of the deleted item (often demanding too much bandwidth), or a wrapping response (see return value below). Either that or return HTTP status 204 (no content) without a response body. In other words, a 204 status without any body, or JSEND-style response and HTTP status 200 is the recommended response.
HTTP-Spec-Wise, Delete operations are indomitable. When you delete an asset, it is removed. Repeated DELETE calls to that resource have the same consequences: the resource is gone. Calling DELETE means reducing a counter (within resources), the DELETE call is no longer invincible. As mentioned earlier, usage statistics and measurements may be updated while still considering the service incomplete unless any resource data is changed. It is recommended to use POST for non-exhaustive resource requests.
However, there is a warning about DELETE disability. A second call to the resource DELETE will often return a 404 (not found) since it has already been removed and is therefore no longer found. This, in some respects, makes DELETE operations more incapacitated, however, the end state of the asset remains the same. A 404 return is acceptable and communicates the status of the call correctly.
/api/service/{id} /*{delete a single service as defined by the id provided}*/

Simple Basic JSX, Component Lifecycle, Hooks

Israt Zahan Sathi — Sun, 26 Dec 2021 16:11:23 +0000

JSX:
JSX is a JavaScript syntax extension and sometimes known as JavaScript XML. It is a responsive extension of syntax in JavaScript language that provides a way to construct content rendering using syntax known to many developers. It looks like HTML.
example:

or,

Component Lifecycle:
The component is created i.e. mounted in DOM, updated and enlarged and then die or unmounted in DOM. This is referred to as a material life cycle. There are different life cycle methods that respond to different stages of life of an element.
Lifecycle Methods:
Initialization
This is the stage where the element sets its state and props and starts its journey. This is usually done inside the constructor method.
example:

Mounting:
The name is self-explanatory. Mounting is the phase where our reactive component is mounted on the DOM, i.e. created and inserted into the DOM.
This episode comes to the scene after the initial phase is over. At this stage, our material renders for the first time. The methods available at this stage are:

componentWillMount()

This method is called just before mounting an element in the DOM or is called the render method. After this procedure, the component is mounted.
NB: You will not make API calls or change any data using this.setstate in this manner as it is called before the render method. So, nothing can be done with the DOM (such as updating data with API feedback) because it is not mounted. Therefore, we cannot update the state with API feedback.

componentDidMount()
This method is called after mounting the component in the DOM. Like component Willmount, it is called once in a life cycle. Before this method is implemented, the render method is called, that is, we can access the DOM. We can make API calls and update states with API responses.

updating:

This is the third stage through which our material passes. After the mounting episode where the component was created, the update episode comes into view. This is where the state of the component changes and, therefore, the rendering takes place.
At this stage, the component's data (state and props) are updated to respond to user events such as clicking, typing, etc. This results in re-rendering of the component.

Unmounting:

This is the last stage of the material life cycle. As the name implies, at this stage the component is unmounted from the DOM.

Hooks:
Hook is a new feature introduced in React 16.8 version. This allows you to use the status and other feedback features without typing the class. A hook is a function that "hooks in" the reaction state and lifecycle properties from the function element. It doesn't work inside the classroom.
The hooks are backwards-compatible, which means there is no broken change. Also, it does not replace your knowledge of the concept of reaction.
When to use a Hooks:
If you write a function element, and then you want to add some state to it, first you do it by converting it into a class. But, now you can do this by using a hook inside the existing function element.

example: