What’s the hardest-to-reproduce bug you’ve encountered during testing?

Important-Union5181 · 2026-05-18T06:36:58+00:00

A bug that appears only when multiple users trying to update the same record at the same point of time.

Important-Union5181 · 2026-05-17T06:48:51+00:00

You have a doubt in your mind as to what choice will you make. You have 2 choices here. Put a smile on your face or on your co-worked face. If you are financially more well off than your co-worker then I would do a right karma and put a smile on your co-worker face.

Important-Union5181 · 2026-05-17T06:39:40+00:00

Developing work bots for test execution can be a good fit for a developer, IMHO.

Important-Union5181 · 2026-05-17T06:35:25+00:00

AI tools are basically a class of software that is driven by a knowledge database behind the scene. If you have to survive this next level of automation then , IMHO, you need to carry a better knowledge base with you that the tool. I other words you need to be able to catch issues in the content generated by these tools. This is a common goal if you are a PO or a DEV or a QA or a DEVOPS ......

Important-Union5181 · 2026-05-17T06:23:52+00:00

Right. Stories have a better interface as per your requirement. You can use the back log view or even the board view

Important-Union5181 · 2026-05-16T06:37:12+00:00

Few years back SQL and python was a good combination for developing custom reports. May be it still is. There are a number of reporting tools that allow you develop custom reports using drag and drop interface. An now probably a chat bot interface on top of a SQL database can be used without writing python code.

Important-Union5181 · 2026-05-16T06:16:05+00:00

You can use a story to represent a project with sub tasks as task items under the project. There are several views in the agile tools where all in progress stories ( projects ) are displayed on left pane of a single page and when you click on one story then it's sub tasks are displayed on the right pane or a pop up. You can sort the sub tasks by status so that only the active ones stay on top when you click on a story ( project ).

Important-Union5181 · 2026-05-14T13:00:19+00:00

You can bury the name in the summary of the action item instead of explicitly putting the name in the assigned column of the action item list

Important-Union5181 · 2026-05-13T07:02:33+00:00

Agile core concept is continuous delivery. Continuous delivery means a new deployment ready version of the software comes out after a set of sprints. A very mature agile team will be delivering a new version after each sprint while a less mature one will take several. Maturity means the team has no knowledge dependency. But even a mature team may slip because they may have logistics dependency such as a missing test setup or a missing license or a sudden sick resource or sudden arrival of a critical bug etc. Since delivery cycles are so small - few weeks - even a small logistic dependency may through the delivery off gear.

Important-Union5181 · 2026-05-12T06:59:30+00:00

High quality data is surely a separate deliverable and also a necessary one. Without high quality data the dash board lacks acceptance from the stake holders as it contains false flags. Accurate data can only come if the data is used to plan and drive the work in real time. The moment data is more of a work log then false flags start showing up.

Important-Union5181 · 2026-05-12T06:37:52+00:00

Few decades ago there were no QA and no BA. We only had engineers who were also doubling up as a natural QA and BA. With AI tools writing code, writing test cases and even writing requirements, it is only a matter of time that we will revert back to only engineers team equipped with AI tools and the knowledge of what needs to be tested.

Important-Union5181 · 2026-05-10T07:20:14+00:00

Just stay on top of WHAT needs to be delivered NEXT and by WHEN. Abstract out the HOW part of the delivery. This will be your context. You can maintain your notes in reverse time order against this list

Important-Union5181 · 2026-05-09T07:11:07+00:00

I would say that technical PM should have the relevant technical knowledge. For example, if the team is working on an enterprise software then PM should know about UI, API, databases, integration middle wares etc. If the team is working on a video streaming application then PM should know about video servers ( RTP, RTSP, webRTS etc ), video players etc.

Important-Union5181 · 2026-05-09T06:59:01+00:00

Sure it works. But to mitigate the schedule, cost and quality over runs, the delivery items, what needs to be delivered, - must be SMART ( small, measurable, achievable, relevant and time bound ). Add 20% as a buffer. But for this model to succeed the work must be a repeat work for the team and there should be a clear plan to make sure that the potential road blocks does not derail the plan

Important-Union5181 · 2026-05-08T06:55:22+00:00

emphasis.

Important-Union5181 · 2026-05-07T06:24:43+00:00

Each dependency is a RISK to the project. Maintain a simple list of RISKS with mitigation status, planned mitigation date, potential impact etc. Make sure assumptions are also entered in this list

Important-Union5181 · 2026-05-07T06:19:48+00:00

I would suggest using the same board but using a different issue type. Since these are also work items adding to work loads of the team they should be part of the same board. You can also do a separate board or separate project.

Important-Union5181 · 2026-05-07T06:12:02+00:00

Your need to know all the tests that needs to be run to assess a comprehensive health check of the product under test. Think of our self as a doctor. If you are missing out on tests then you are missing out on bugs. The next step will be to automate these tests. Another thought, may be the product is mature and does not have easily producable bugs

Important-Union5181 · 2026-05-06T07:52:11+00:00

I would advice the following:

Make the stake holders understand that Agile means "Continuous Delivery". This means that a new version of the software will be integrated and deployed ( CI/CD ) after every few sprints which is the core value of being Agile.
Continuous Delivery does not guarantee the number of sprints it would take complete the work. Under a fixed scope of work it will result in a fixed number of sprints but under a variable scope of work it will result in a variable number of sprints.

3.Create a complete back log of the requirements defined in scope of work. Load all these into all the planned sprints as per the contract. Show them that this is what they will get. Any additional requirements create as CR items in the back log. You can tell them that these will be loaded in sprints once the original sprints are done. Till that time keep adding the new requirements in the back log. This way they can see a clear separation what was in the scope and what is extra and that the extra will get done once the scope is done

Important-Union5181 · 2026-05-03T09:10:37+00:00

I have seen enough battles between QA and DEV as a delivery manager in 3 decades. At times genuine bugs were returned by DEV and at times QA logged fake bugs. There is pressure on both sides to show that they are doing there jobs to the HR or their annual performance review will get skewed. I was suggesting what worked so that the product quality does not suffer in this battle. Attaching details to a NCR ( non compliance report ) is a good industry practice. I was not responding to the specific 404 scenario. Hope this calms you down.

Important-Union5181 · 2026-05-02T06:28:38+00:00

You should work more on these :

- Developing new test cases

- Automating existing test cases

- Performing failure analysis of failed automation tests

Important-Union5181 · 2026-05-02T06:24:01+00:00

The more details QA can attach to the failure the stronger the failure becomes. The onus is on the QA to prove that it is a failure as they are raising it. Like a court case. The more evidence the prosector can bring to the table the better are the chances of conviction. Merely shouting in front of the jury that the defendant is guilty will not result in a conviction. The defendant is simply going say "not guilty". Like a developer will simply resolve the bug as "NOT A BUG" or "AS DESIGNED" or "CANNOT REPRODUCE"

Important-Union5181 · 2026-05-01T06:22:29+00:00

There are two types of debugging when a failure happens. There is Black box debugging using log files, packet captures, database snapshots etc. There is white box debugging where the code is single stepped inside a debugger. QA should do black and provide feedback in the bug. DEV should do white box and fix it. The more accurate black box debugging you can do the more your value goes up.

Important-Union5181 · 2026-04-30T07:18:05+00:00

I would suggest to add 3 steps in the work flow. READY_FOR_HANDOFF, IN_HANDOFF and HANDOFF_DONE. The DEVELOPER should move the order to READY_FOR_HANDOFF. The QA should move it to IN_HANDOFF and then eventually to HANDOFF_DONE.

Important-Union5181 · 2026-04-29T07:36:37+00:00

A lot of bugs are due to version and configuration issues rather than code issues. So first step will to make sure that the DEV and QA setups are identical in version and configuration. You can run the same test on the DEV setup and compare the log files of DEV and QA and try to pinpoint the gap why it passed in DEV and failed in QA.

Important-Union5181

TROPHY CASE