DEV Community: Maric Run Test

DevOps vs Testing: Same Goal, Different Roads

Maric Run Test — Sun, 24 Aug 2025 05:20:35 +0000

When people first step into the software world, it’s easy to confuse DevOps and Testing (QA). Both roles care about ensuring software runs smoothly, both are involved in deployment and release cycles, and both deal with “quality.” But in reality, they serve different purposes and complement each other in the software delivery pipeline.

Let’s break it down.

🔹DevOps
DevOps = Development + Operations

Main tasks of DevOps:

CI/CD (Continuous Integration / Continuous Deployment): ensure code from dev to production is fast, safe, and error-free.
Automation: write scripts to automatically build, test, and deploy.
Monitoring & Logging: monitor the system (CPU, memory, uptime, logs, alerts).
Infrastructure as Code: use Docker, Kubernetes, Terraform to manage servers and environments.

👉 In short: DevOps makes sure the system runs and scales reliably.

🔹 Testing / QA
Tester = ensure software quality before release.

Main tasks of Testing:

Design test cases, test plans.
Execute tests (manual/automation).
Identify bugs, log bugs, track bug fixes.
Ensure the system meets requirements and has no functional errors.

🔹 Where They Meet

DevOps will create a CI/CD pipeline with an automation test run step written by QA.
DevOps monitors the system, but if logic/business errors are detected, QA testers will verify and report.
QA cares whether users can use it, DevOps cares whether the system runs smoothly.

🔹 Why Understanding Both Matters

For QA: Knowing DevOps basics helps you integrate your tests into CI/CD pipelines and collaborate better with engineers.
For DevOps: Understanding QA helps you design pipelines that catch bugs earlier.

The modern software world is collaborative. QA and DevOps don’t replace each other—they work hand in hand.

✅ Takeaway

DevOps = System reliability, automation, deployment. -** QA/Testing = Product quality, correctness, user experience.**
Together, they ensure software is both stable and valuable.

So the next time you hear “DevOps checks deployments” or “QA ensures no bugs,” remember—they’re two sides of the same coin: delivering quality software.

Test Case Is Not a Form — It’s a Thought Process

Maric Run Test — Sun, 03 Aug 2025 14:22:27 +0000

❓ Have you ever written a test case that nobody else could understand?

Maybe a dev asked, “What exactly are you testing here?”
Or another QA messaged you: “How do I run this case again?”

That usually means the test case lacks clarity — not in format, but in thinking.

A professional test case isn’t just a checklist. It’s how you show your QA logic.

🎯 A great test case answers 5 key questions:

1. What am I testing?

What's the specific feature or behavior under test?
Does the title make that obvious?

📌 The test case title should describe exactly what’s being verified.

Example:

✔️ Transfer money between two internal accounts (valid input)
❌ Check transfer function

2. What do I need before I start?

Logged in? Proper role? Required test data?
Any setup needed?

📌 Preconditions make your case reproducible.

3. What are the test steps?

Logical, numbered steps
No skipped or combined actions

📌 Steps are your script — make them easy to follow.

4. What should happen? (Expected Result)

What’s the correct outcome after each step?
Does it match the requirement?

📌 Clear expectations = clear pass/fail decision.

5. What happens if something goes wrong?

Have you tested invalid input, unexpected actions, or edge cases?
Is the system handling it properly?

📌 Good testers don’t just test what works — they test what breaks.

✅ Summary Table

#	Question	Why it matters
1	What am I testing?	Defines the goal
2	What do I need before I start?	Ensures repeatability
3	What are the test steps?	Makes execution clear
4	What should happen?	Validates the result
5	What if something goes wrong?	Checks system resilience

🧠 Final Thought: It's About Thinking, Not Filling a Template
Yes, every tester knows the test case structure:
Title, Precondition, Steps, Expected, Actual.

But if you only fill the form, and don’t think through the why,
then your test case might pass review — but fail in real use.

✍️ A real QA doesn’t just write a test case.
They design a thought process others can follow, trust, and learn from.

🧪 Example: Applying the Thought Process to a Real Test Case
Let’s say you’re testing the “Transfer Money” feature between user accounts.

✅ Instead of writing this (too vague):

Title: Test transfer
Steps: 
1. Go to transfer screen  
2. Enter amount  
3. Submit  
Expected: Transfer successful

⛔ This tells us nothing. What are you testing exactly? What amount? Logged in as who? What if the input is invalid?

🧠 Now apply the 5-question mindset:

Field	Content
Test Case ID	TC-001
Title	Transfer money between two internal accounts (valid input)
Precondition	User is logged in as "Standard User" Both accounts are active Account A has balance ≥ 100
Test Steps	1. Navigate to "Transfer" screen 2. Select Account A as source, Account B as target 3. Enter amount = 100 4. Click “Submit”
Expected Result	Success message is displayed: “Transfer completed” Account A balance reduced by 100 Account B balance increased by 100
Negative Case Reminder	Covered in TC-002: Input negative amount Covered in TC-003: Target account locked
Linked Requirement	USER-STORY-TRANSFER-01
Assumptions	No network errors during transaction

🔍 Why this works:

✅ "What am I testing?" → Clearly defined in title
✅ "What do I need?" → All preconditions listed
✅ "What are the steps?" → Step-by-step, actionable
✅ "What should happen?" → Detailed and measurable expected outcome
✅ "What if something goes wrong?" → Negative cases listed separately, traceable

🧠 A test case like this is not just executable — it’s transferable.
Anyone on the team can run it, review it, or use it to debug without chasing you down.

No Docs? No Figma? No Worries – QA Can Still Test

Maric Run Test — Mon, 28 Jul 2025 09:24:04 +0000

Type: Real-world QA Scenario
Severity: High (affects early test planning)
Environment: Agile, missing/unclear user stories
Status: Happens more often than you think

🧪 Problem
You’re assigned a feature.
But there’s no detailed spec, no flow, no Figma, and no acceptance criteria.

🔍 Root Cause
In fast-moving Agile teams, features often move into dev/test before specs are 100% finalized.
Waiting for perfect documentation = missed deadlines.
Testing blindly = missed bugs.

✅ Expected Behavior (Mindset)
A professional tester:

Starts with what’s available
Thinks like a user
Documents assumptions
Asks sharp, focused questions
Iterates test cases as info improves

🛠 Suggested Approach

1. Use the User Story to Map a Flow
Even if it’s vague, extract:

Actor (user/role)

Action (what they do)

Goal (why they do it)

Example: “As a user, I want to update my profile to keep my info current.”

→ That gives you: input fields, update action, confirmation, possible validations.

2. Write Draft Test Cases with Assumptions

✅ Clearly mark assumptions so devs/BA can confirm later.

3. Ask Specific, Context-Based Questions
“What’s the max/min value for this field?”

“What happens if the user clicks Submit twice?”

“Does this feature require login? Specific roles?”

“What should happen if the API fails?”

🎯 Ask like someone who already tried testing — not someone waiting for answers.

4. Prioritize: Cover Happy Path First
Start with:

Valid input → success flow

Most common user actions

Basic validation

Add negative & edge cases once info is confirmed.

5. Flag Test Cases as Draft / Pending
Always note test cases written under incomplete info as:

Status: Draft

Waiting for spec confirmation

🧠 Final Thought
Writing test cases without a full spec isn’t impossible — it’s a core skill.

Don’t block the team waiting for clarity.
Be the one who brings clarity through smart assumptions and good questions.

The Core Mindset of a Manual Tester

Maric Run Test — Thu, 24 Jul 2025 06:07:12 +0000

❓Is a Manual Tester just someone who “clicks around”?

No.

A great Manual Tester doesn’t just follow test cases and log bugs.

They are the ones who understand the product, analyze the logic, and spot problems before they even happen.

🎯 Tools may change. But with the right mindset, any tool becomes powerful.

🧩 So what is the core mindset of a Manual Tester?

1. User Perspective: “What would I do if I were the user?”
Don’t just follow the test flow.

A good tester puts themselves in the user’s shoes:

What mistakes might users make?
Will they understand what this feature does?
Will they try something unexpected that devs didn’t anticipate?

🧠 Some bugs are “so user-like” that only testers catch them — not developers.

2. Critical Thinking: “Does this requirement make sense?”
Not all specs are perfect.

A professional tester must question and challenge unclear, inconsistent, or illogical requirements.

Examples:

“What happens if a user enters a negative number?”
“If a user reloads halfway, does the app keep their progress?”

✅ Good testers don’t stay silent when things seem off.

3. System Awareness: “What else does this feature affect?”
Manual Testers don’t test features in isolation.

They understand how parts of the system are connected — a change in A might affect B and C.

Example: Adding a new user role → affects permissions, UI display, menu visibility...

🧠 That’s how Manual Testers ensure broad test coverage, even without automation.

4. Risk-Based Thinking: “Which bugs matter most?”
Not every bug needs an urgent fix.

Skilled testers know how to assess:

How many users are affected?
Does it cause data loss or money loss?
Is it easy to reproduce?
Will fixing it break something else?

🎯 Prioritizing risk helps the team stay focused on what really matters.

5. Process Mindset: “How can we test smarter, not just harder?”
Manual Testers don’t just follow tasks.

They observe and suggest improvements:

Write reusable, clear test cases
Create checklists for repetitive steps
Recommend logs or error messages for faster debugging
Give early feedback on unclear logic to Devs or BAs

🔄 A good tester doesn’t just find bugs — they help prevent them.

🔧 Summary: Core Tester Mindsets

Mindset	Key Question
User Perspective	“What would a real user do here?”
Critical Thinking	“Does this requirement make sense?”
System Awareness	“What else could this impact?”
Risk-Based	“Which bug is the most critical?”
Process Improvement	“How can we test faster and better?”

✅ Final Thoughts

You may not know automation yet.
You may not use fancy tools.

But if you’ve got the right mindset — you’re already ahead of 80% of other Manual Testers.

🧠 Manual Testing isn’t a “low-level” job.
A Manual Tester with sharp thinking = a professional QA.

What Testers Should Know About Specs ?

Maric Run Test — Sat, 19 Jul 2025 12:05:10 +0000

👉 Spec (Specification) = The answer to “How should this system work?”

🎯 To test effectively, you need to clearly understand the system before you start testing.

📚 Common Types of Specs

Depending on your development process (Waterfall, Agile, Scrum…), you may encounter various types of specs.

1. Business Requirement Document (BRD)

👉 Describes the business-level needs and goals.

Explains the problem the system is solving
Doesn’t go into technical details
Read by: Business Analysts (BA), clients, PMs, and QA

2. User Story (Agile)

👉 Describes features from the user’s perspective.

Example:

"As a user, I want to transfer money between accounts so I can manage my finances."

Usually includes:

Acceptance Criteria (when the feature is considered acceptable)
Definition of Done (when the feature is complete)

3. Design Spec (Figma / Wireframe / UI Flow)

👉 Describes the UI layout and navigation.

4. API Spec (Swagger / Postman)

👉 Describes backend API details: endpoints, methods, parameters, responses, error codes.

5. Use Case / Flow Chart / Sequence Diagram

👉 Visual representations of process or user flow.

✅ Conclusion

As a tester, you're not just someone who follows checklists.

You're responsible for ensuring product quality, and that starts with understanding the requirements.

Want to test right? → Read the spec.
Want to test thoroughly? → Analyze the spec.
Want to test smart? → Think like a user, a BA, and a developer.

Tester QA QC: Stop Mixing Them Up

Maric Run Test — Thu, 17 Jul 2025 15:57:35 +0000

👨‍💻 1. Tester

A Tester checks the product to find defects — manually or automationlly.

Main tasks:

Understand requirements
Write test cases & data
Execute tests
Report & retest bugs

📍 Tester is part of QC, focused on the product, not the process.

🛠️ 2. QC = Quality Control

QC checks the final product to ensure it meets requirements and works as expected.

What QC does:

Test after development
Validate features
Verify output matches input

🎯 QC = Is the product right?

🧠 3. QA = Quality Assurance

QA focuses on the process to prevent defects from happening in the first place.

What QA does:

Define standards & workflows
Improve team practices
Ensure consistent quality

🎯 QA = Are we building it the right way?

🔍 Quick Comparison

Role	Focus	Main Goal	Involves Testing?
Tester	The software	Find bugs	✅ Yes
QC	The final product	Match requirements	✅ Yes
QA	The process	Prevent bugs from the start	❌ Not directly

✅ Final Thought

Tester ≠ QA ≠ QC.

Each role plays a different part in delivering quality software. If you're starting out, begin as a Tester — but understand where QA and QC fit into the bigger picture. That’s how you level up.

Testing a Crypto Exchange: Key Things to Understand

Maric Run Test — Thu, 17 Jul 2025 02:17:41 +0000

If you're a QA stepping into the crypto world, testing a Centralized Exchange (CEX) platform is both exciting and challenging.

This post walks you through key concepts and areas you must understand before testing a CEX platform effectively:

🧠 What is a CEX?

CEX stands for Centralized Exchange, a type of cryptocurrency platform where users create an account, go through identity verification (KYC), and perform trading directly through the system controlled by the exchange.

🧩 Key Modules Testers Should Understand in a CEX

Here are the core flows you'll most likely be testing:

1. 🧾 Account & Authentication

Sign up, login, reset password
Two-Factor Authentication (2FA)
Session/token management
Rate limiting (prevent brute force attacks)

2. 🧍 KYC Verification

Upload documents: ID card, passport, selfie
Different KYC levels and statuses (Pending / Approved / Rejected)
Validations for file format, size, clarity
Error handling and notification messages

Example Test: What happens if I upload a blurry passport photo? Is the rejection reason clear?

3. 💰 Wallet & Balance

Deposit & withdrawal flows
Balance updates in real-time
Display of available vs frozen funds
Blockchain transaction hash display

Example Test: Does the wallet balance update correctly after a failed withdrawal?

4. 📈 Trading Engine

Placing Market / Limit / Stop orders
Order book updates in real-time
Slippage handling and fee calculation
Cancel / Edit open orders

Example Test: What if I place a Market Buy with insufficient balance?

5. 🧮 Market Info & Charts

Price updates and volume display
Real-time candlestick charts
Refresh behavior and chart syncing

6. 🔐 Security

Password rules, session timeouts
Detect suspicious behavior (e.g. multiple logins)
Frontend and API error masking (no sensitive info leaked)

🧪 What Makes Testing CEX Platforms Unique?

Unlike typical e-commerce or web apps, CEX platforms involve real money, fast-paced transactions, and legal compliance. That means:

✅ Small bugs = big risks (funds may be lost)

✅ Real-time testing is crucial (prices, balances, trades)

✅ Tester must understand both UI and business logic

✅ Need for test data planning (fake KYC, sandbox wallets)

💡 Final Thoughts

Testing a crypto exchange like Coin12 isn’t just about checking buttons and forms. It’s about thinking like a real user, understanding financial flows, and making sure everything works safely and accurately.

The more you understand the business logic behind trading, the more valuable you’ll become as a QA in this field.

Not Every App That Connects MetaMask Is a dApp

Maric Run Test — Tue, 15 Jul 2025 03:28:12 +0000

📌 A mindset bug I personally ran into

Bug Description:
I was testing a trading platform that allowed users to:

Connect their Web3 wallets (MetaMask, Tronlink, etc.)
Deposit and withdraw tokens
See transaction hashes on-chain
Use tokens for P2P trading or spot trading

Naturally, I assumed:

"This must be a dApp! It connects MetaMask and writes to the blockchain."

But after digging deeper, I realized:

❌ This is not a dApp. It’s a CEX (Centralized Exchange) with Web3 wallet support.

💡 So what is a dApp?
A dApp isn’t about “connecting MetaMask” — it’s about decentralized execution.
A dApp (Decentralized Application) must:

Run its core logic through smart contracts
The user controls their assets
Interact on-chain for actions like swap, stake, mint
There’s no backend doing the core processing

—> That’s a real dApp

📌 Real examples: Uniswap, Aave, OpenSea, PancakeSwap...

🧩 For New Web3 QA Testers:
🔍 Don’t just test the UI — understand the architecture behind it

💬 Ask devs which smart contracts are involved

🔗 Compare UI actions with results on Etherscan or BscScan

🧠 Test your own mindset before testing the product

How to Fully Test a Feature in Software

Maric Run Test — Sat, 12 Jul 2025 08:53:07 +0000

🧩 Pre-condition:

Feature deployed (dev/staging)
Requirement/spec available
Test account & data ready
Tools ready (browser, Postman, DevTools)

🧪 Steps:

Link Mindmap: https://xmind.ai/share/JnBiJ6a1?xid=zWPEj9o6

1. UI / UX

Review the layout and visual display
User interaction (click, button, input, hover, links) → any response?
Responsive design (MB, Tablet,...) → does it adapt?
Enter invalid inputs → error messages?
Usability (experience smooth?)

2. Functionality (Business Logic)

Valid input → correct result?
Invalid input → validation triggered?
Edge cases (empty, max, special chars)
Test different logic paths, if-else branches
API & backend integration
Error handling (network, timeout)

3. Non-Functional

Security (unauthorized access)
Performance (speed, heavy data)
Use DevTools → check console errors, network issues, response times
Are there proper logs for debugging?

4. Extra Checks (If applicable)

Multi-language support
Tracking/analytics
Accessibility (keyboard, screen reader)

✅ Expected:

UI displays correctly with no visual issues or broken layout
All flows and logic work as expected.
No unexpected errors in console or API responses.
Proper permission checks and security handling.
Feature performs smoothly even with large or edge-case data.
Supports all required environments, devices, and users.

🧠 Tip

Use this as a QA checklist before raising a bug. Covering all these areas helps ensure you're not missing important cases — and helps developers reproduce and fix issues faster.

How to Practice JMeter with a Real-Life Scenario - J4.2

Maric Run Test — Thu, 10 Jul 2025 04:52:09 +0000

Testing GET APIs with View Results Tree

📌 Pre-condition

Tool: Apache JMeter
Objective: Test the GET API https://dev.to/pod with 1000 users
Environment: Local test, no token required
Listener: View Results Tree

🧪 Steps:

Open JMeter and Add a Thread Group: Number of Threads (users): 1000 , Ramp-Up Period: 20 seconds, Loop Count: 1
Add an HTTP Request: Method: GET, URL: https://dev.to/pod
Add Listener: View Results Tree
Run the test and observe each request in the result tree

📊 Expected:

All requests return status code 200 OK
Response content correctly displays the Podcast page
No HTTP errors or timeouts
Response time is reasonable (under 2000ms)

🔍 Analyzing the Results from View Results Tree

The View Results Tree listener shows each individual request, allowing you to analyze:

Request details: URL, method, headers, and sent parameters
Response body: Helps verify if the returned data is correct
Status code: Confirm if the response is 200 OK or has errors
Time taken: Check which requests are slowest

💡 Example: A test might pass with 200 OK, but the body could show an error message, empty data, or the wrong structure — View Results Tree reveals that.

🧠 Lessons Learned

View Results Tree is best for validating individual responses

Not suitable for performance metrics (use Summary Report / Aggregate Report instead)

Helps identify API logic issues and validate content accuracy

Ideal for QA doing functional testing alongside load testing

🛠 Practice Tips

Compare View Results Tree and Summary Report to understand each listener’s purpose

Use Regular Expression Extractor to validate key values in responses

Combine with CSV Data Set Config to test dynamic input data at scale

Why Testing in Web3 Is Not Like Traditional QA?

Maric Run Test — Wed, 09 Jul 2025 06:26:52 +0000

When I first switched from Web2 to Web3, I thought,

“It’s just UI and API testing, right?”

But, I realized I had stepped into a completely different world.
Here are the biggest differences that every QA needs to understand before testing blockchain apps.

🔐 1. Immutable Data
In Web2, we can roll back, reset test data, or fix mistakes easily.
In Web3? Not possible.

Every transaction is permanent on the blockchain.
One small bug in a smart contract can cause real money loss.
No "admin" to change data.

💡 Lesson: Be extra careful when testing anything that writes to the blockchain.

🌐 2. Decentralized Architecture
No more single backend with easy logs or debugging.
Web3 systems have many parts:

UI: runs in browser
Wallet: signs & sends transactions (e.g., MetaMask)
Smart Contract: runs on-chain logic
Node/Provider: connects to blockchain (Infura, Alchemy...)
Subgraph/Indexer: stores & queries blockchain data

💡Lesson: Bugs can happen anywhere in this stack. As a QA, you need to understand the full picture.

⛽ 3. Gas fee
Every on-chain action costs gas (real crypto, even on testnet).

Need ETH (testnet) to run tests
Spamming tests = run out of gas = testing stops
Performance testing must consider gas cost

💡 Lesson: Plan your tests carefully to avoid wasting resources. And check gas usage in your test cases.

⚙ 4. Smart Contracts ≠ Normal Backend
Smart contracts cannot be modified after deployment (unless a proxy is used). The logic handling is also very different from the backend API:

💡 Lesson: Don't just check the result. Understand the contract logic too. Sometimes it “works” but is badly designed.

🔄 5. On-chain vs Off-chain Testing
Not all data is on the blockchain.

On-chain: balances, transactions, smart contract state

→ Test using explorers, Hardhat, JSON-RPC

Off-chain: UI state, indexers, caches

→ Test using Postman, browser tools, etc.

💡 Lesson: UI testing is not enough. Use blockchain tools to see the full picture.

🧩 Final Thought
Testing in Web3 is more than just checking UI or APIs.
It’s about understanding a decentralized system—where bugs can affect real assets, real users, and can’t be undone.

The first step to becoming a good Web3 QA isn’t learning tools — it’s fixing the mindset bug.

How to Practice JMeter with a Real-Life Scenario - J4.1

Maric Run Test — Tue, 08 Jul 2025 04:22:46 +0000

Testing GET APIs with Summary Report

🧪 Scenario: Load Testing a Podcast Page
It handles 1000 users
Response times stay under 2s
No errors occur

🛠️ Test Plan:
Number of Threads (users): 1000
Ramp-Up Period (in seconds): 20
Loop Count: 1

🌐 HTTP Request Sampler:
Method: GET
Path: https://dev.to/pod

📈 Listeners: Summary Report

📊 Expected Metrics to Watch
Average Response Time should be < 2000ms
Error = 0% ideally
Throughput > 80 req/sec
Standard Deviation: Lower = more stable server

🔍Analyzing the Results from Summary Report

Samples: 1000 | Average: 1224 ms | Error %: 0% | Throughput: 48.5/sec

✅ Average Response Time = 1224ms < 2000ms
✅ Error = 0 => No error, all 1000 requests were successful, API is functionally stable.
⚠️ Throughput = 48.5 req/sec < 80 req/sec => Indicates that while stable, the system could struggle under heavier loads.

🛠️ Tips for Practice
Change concurrency: Try 100, 500, 2000 users and compare.
Add timers: To simulate real-user delays.
Use CSV DataSet: Feed dynamic data like usernames.

🧠 Wrap-Up
Practicing JMeter isn’t just about throwing traffic—it’s about:
Understanding behavior under load.
Catching bottlenecks early.
Delivering stable apps.

Start with one endpoint. Read the graphs. Tune as you go.