FocusLogic Development & Testing Rules

Mandatory Working Process for Every Developer and Tester

Team,

We are repeatedly working on the same issues again and again. This is causing unnecessary rework, delaying project completion, reducing delivery quality, and seriously affecting overall company progress.

This is a serious concern.

From now on, every developer and tester must take stronger ownership, work more efficiently, and follow the below rules on every ticket without exception.

1. Core Expectation

Every team member must work with:

• Clear ownership
• Better responsibility
• Proper communication
• Root cause understanding
• Efficient execution
• Quality-focused delivery

We should not just “fix and move.”
We must understand why the issue happened, how to prevent it again, and how to complete work with clarity and accountability.

A. Rules for Developers

1. Root Cause Must Be Shared Before Fixing Any Bug

Before starting any bug fix, the developer must share:

• Ticket Number
• Issue Summary
• Root Cause
• What exactly is causing the issue
• Proposed fix approach

No one should directly start fixing a bug without first understanding and sharing the root cause.

Expected format:

• Ticket No:
• Bug Summary:
• Root Cause:
• Impacted Module/Page:
• Fix Plan:
• ETA:

2. Ticket Number Must Be Mentioned for Every Bug

For every bug update, always mention the ticket number.
No update should be shared without ticket reference.

This is mandatory for:

• Starting update
• Root cause update
• Completion update
• Testing update
• Reopen update

3. New Feature Work Must Be Discussed Before Development

If any new feature, screen, or flow is being introduced in any project:

Before development starts, the developer must discuss with me:

• How the screen will look
• How the flow will work
• What changes are being planned
• What impact it may have on existing flow

No new feature should be implemented based on assumption alone.

4. Immediate Feedback Required for Some Features

For certain new features, once completed, the screen/flow must be shown immediately for feedback before proceeding further.

This is to avoid:

• Rework
• Wrong assumptions
• UI/UX mismatch
• Flow corrections at the end

5. Completion Update Is Mandatory for Every Ticket

Once a ticket is completed, the developer must share a proper completion update.

Completion update should include:

• Ticket No
• What has been fixed/implemented
• Root cause summary
• Files/modules changed
• Any DB/API/UI changes
• Self-tested scenarios
• Pending items if any
• Ready for tester / review

No ticket should be marked as completed without a proper update.

6. Ownership of the Page/Module

If you are working on a page, you are the owner of that page for that duration.

Do not focus only on one small bug and ignore:

• UI issues
• alignment issues
• validation issues
• flow mismatch
• obvious mistakes
• consistency problems

If you see something wrong while working on that page, raise it or fix it responsibly.

7. Avoid Repeated Fixes for the Same Problem

When fixing any issue, developers must verify:

• Is this the actual root cause?
• Will this issue repeat in another screen/module?
• Is this a one-time patch or a proper solution?
• Are similar cases validated?

We should stop temporary patching and start solving issues properly.

8. ETA Commitment Must Be Respected

If you commit an ETA, you must:

• Complete it on or before ETA, or
• Update early if there is a blocker or delay

Do not wait until the end of the day to say it is not completed.

B. Rules for Testers

1. Daily Bug Reporting Must Include Cause Analysis

While raising bugs daily, testers must clearly mention:

• Ticket No / Bug No
• Module / Screen Name
• Exact issue
• Steps to reproduce
• Expected result
• Actual result
• Which recent change may have caused this bug
• Screenshot / video / evidence
• Data used for testing

I need to know which changes caused the bug wherever possible.

Testing should not only report “what failed.”
It should also help identify what change may have introduced the issue.

2. Bug Reports Must Be Clear and Actionable

A bug should never be raised with vague comments like:

• not working
• issue here
• please check
• wrong data

Instead, every bug must explain:

• What action was performed
• What happened
• What should have happened
• Under what condition it occurred

3. Validate Related Flows, Not Just One Case

While testing any fix, testers must also validate:

• adjacent flow
• impacted screen
• save/update/delete effect
• list/detail consistency
• filter/report/export effects if relevant

This helps reduce repeated reopening of issues.

4. Repeated Bugs Must Be Flagged

If the same type of bug is happening repeatedly, testers must highlight it clearly as:

• repeated issue
• regression issue
• root cause not fully fixed

This helps us identify weak implementation areas faster.

C. Common Rules for Both Developers and Testers

1. Every Ticket Must Have Proper Lifecycle Updates

Each ticket should contain:

• Started
• Root cause identified
• Working in progress
• Completed
• Ready for testing
• Tested
• Reopened if needed
• Closed

2. Communication Must Be Clear

If you are stuck, communicate:

• where you are stuck
• what support you need
• what dependency is pending
• when you can complete after blocker is cleared

Do not stay silent.

3. No Assumptions

If requirement, screen, UI, or flow is unclear:

• ask
• confirm
• discuss

Do not assume and build.

4. Quality Is Everyone’s Responsibility

Quality is not only tester responsibility.
Quality is also developer responsibility.

Testing is not only about finding bugs.
It is also about validating the business flow correctly.

D. Why This Must Be Followed Strictly

We are currently losing time because:

• same issues are being fixed repeatedly
• root cause is not identified properly
• updates are incomplete
• features are implemented without enough flow discussion
• bugs are raised without full clarity
• ownership is weak in some cases

This is delaying project completion and affecting company growth.

At FocusLogic, we need to build a culture of:

• ownership
• clarity
• accountability
• efficiency
• quality delivery

If we improve this process, we can:

• reduce rework
• improve delivery speed
• increase client confidence
• complete projects faster
• grow the company stronger

E. Suggested Working Format for FocusLogic

Developer Daily Ticket Update Format

For every ticket:

Ticket No:
Module/Page:
Task Type: Bug / Feature / Improvement
Root Cause:
Fix Plan:
ETA:
Status:
Blocker:
Completed Work:
Self-Test Done: Yes / No
Ready for Testing: Yes / No

Tester Bug Report Format

Bug No / Related Ticket No:
Module/Page:
Build/Date:
Issue Summary:
Steps to Reproduce:
Expected Result:
Actual Result:
Possible Change That Caused This:
Screenshot/Video:
Test Data Used:
Priority:

F. My Suggestions to Implement This Properly

For Developers

1. Maintain one daily tracker with:
   • ticket no
   • root cause
   • ETA
   • current status
   • blocker
   • completed time
2. Before fixing any bug, post root cause in:
   • project group or ticket comments
3. Before new feature development:
   • share quick screen flow
   • get approval
   • then start development
4. Before marking completed:
   • self-test at least 3–5 scenarios

For Testers

1. Maintain a daily bug register
2. Mention exact build/date for each bug
3. Link bug to:
   • ticket number
   • recent change
   • impacted flow
4. Re-verify related modules after major fixes

For Team Leads / Coordination

1. Review repeated bugs weekly
2. Track:
   • reopened tickets
   • root-cause-less tickets
   • delayed ETA tickets
   • poor bug reports
3. Identify which modules are causing maximum rework
4. Conduct short review on:
   • what repeated
   • why repeated
   • how to prevent again

Final Instruction

From now onward, all developers and testers are expected to follow the above process strictly for every ticket.

This is not optional.
This is required to improve our delivery quality, reduce repeated work, and support the growth of FocusLogic.

Let us all take more responsibility, work with more clarity, and contribute more effectively to company progress.

After reading, everyone is required to comment with the confirmation:
“I have read the FocusLogic Development & Testing Rules and commit to following them.”

This is mandatory for all developers and testers. Let’s ensure we follow the process strictly and improve our delivery quality.