I mean this as a constructive suggestion to the CS-Cart management:
I have worked with the bug trackers of many software development companies but the responses of CS-Cart bug tracking staff is mind boggling to me. Bugs get closed so easily without an apparent fix. Even showstopper bugs and issues that will drive many CSC customers away.
CS-Cart is amazing software but it will never be really successful if it does not adopt a relentless bug fixing attitude. Currently Simbirsk is handicapping itself.
Its evident that you have a serious problem in your bug scrubbing methods and that CS-Cart as a product could benefit significantly if you would completely overhaul your bug scrubbing process and your bug tracker.
Its very nice that you promise quick bug fixing time frames, but as long as serious bugs and concerns are closed without getting fixed this means that CS-Cart will still have many bugs and not the rock solid software that your customers need.
Agreed, CSCART better get it's act together or they will go out of business.
They don't understand that OUR success is THERE success. If we cant sell product or compete against our competitors then we cant pay our support fees… its a circle.
Something needs to change ASAP!!!
Agreed.
Defect systems I’ve worked with are transactional between the submitter and the evaluator.
Submitter sets user’s priority and severity, provides steps to recreate, indicates symptoms and expectations.
Evaluator use steps to recreate, get feedback if needed.
Development priority/severity is not even set until defect is confirmed. Then if it’s to be different than Submitter, collaboration occurs.
Others can comment, but they’re just that, comments.
Evaluator (or organization) is not authority, they are being responsive. A defect IS a big deal. Don’t want to be responsive, don’t have any defects! 
Defect is not closed until either fix is provided or released in next version AND CONFIRMED AS FIXED BY THE SUBMITTER.
This is all pretty standard stuff.
It would not hurt to add a milestone in the bug tracker. This way we will know when a bug will be addressed. It will also make it easier to plan releases.
[quote name='P-Pharma' timestamp='1409455828' post='191142']
It would not hurt to add a milestone in the bug tracker. This way we will know when a bug will be addressed. It will also make it easier to plan releases.
[/quote]
P-Pharma,
What do you mean under milestone?
There is a version in which an issue was find and there is a separate field “Fixed in” in case this is a confirmed bug.
In most cases if your issue is confirmed the fix will be included in the next minor release.
Trouble is (as expressed originally) also that there are many bugs marked “awaiting feedback” where feedback has been given but there has been no response after weeks of inactivity (same goes for bugs that have been closed but the closer missed the point). The severity should be set by the submitter and confirmed/negoatiated with the developers. But there are no real setting available to the submitter.
It's not a tracking system with checks and balances. It's an information system with poor information. Still don't understand why you are reluctant to use a real bug-tracking system where a bug is never closed until the solution is confirmed by the submitter (within a reasonable time frame). This is not an area where you need to reinvent the wheel. The bug tracking system doesn't need to be integrated with your community forum to be effective.
Imac. what is too bad is that things like this; http://forum.cs-cart.com/tracker/issue-5074-extended-features-problem/ are usually simply forgotten. It seems like people handling the bug tracker are too eager to close tickets, without putting them in some kind of system so that things are being picked up and improved. Or maybe things are put into a system but then not taken on, I don't know.
Yes, it is NOT a system. May work for cs-cart on your end, but certainly isn't working for me on this end. Just look up the bugs I've reported in the past month to see the lack of communication and/or lack of confirmation of an attempt to recreate.
[quote name='imac' timestamp='1410179874' post='191663']
P-Pharma,
What do you mean under milestone?
There is a version in which an issue was find and there is a separate field “Fixed in” in case this is a confirmed bug.
In most cases if your issue is confirmed the fix will be included in the next minor release.
[/quote]
A milestone is the software version in which you schedule a bug fix, improvement or suggestion to be implemented.
Currently you seem (correct me if I am wrong) to use the 'fixed in' function for after a bug is fixed. Though I rarely see it used.
The way milestones are normally used in software development projects I have encountered, is that after you confirm an issue, you schedule it for a future release. This is the milestone.
Its logical that most bugs should be scheduled for the next release, but when a bug or improvement requires significant work then its useful to schedule it for a later milestone. By having milestones your development team all knows what should be in a release. If you use a decent tracker you can easily make a milestone visible and see all bugs, and improvements for a future version.
IP.Tracker is without a doubt one of the worst bug tracker software on the internet. I cant imagine that you can keep project overview with it. You would make life much easier for your team and for customers if you replace it.
But most important is to make sure that valid bug reports are not closed without a fix. If valid bugs are dismissed in the tracker then customers give up reporting. And thats bad for quality.
I really think you would benefit from changing your bug triage protocol. Your current protocol is not effective and allows a large number of bugs to remain unfixed. This stands in the way of success of an otherwise marvellous product.
If you do not have a bug triage protocol, then please provide your triage team with it so they can be more effective.
Main problem I see is the “Fixed In” … As in the following thread it shows fixed in V4.2.2 yet it was not fixed. So now what, just gets forgotten…
http://forum.cs-cart.com/tracker/issue-5149-google-rich-snippet-errors/
[quote name='CarStickersDecals' timestamp='1410227000' post='191716']
Main problem I see is the “Fixed In” … As in the following thread it shows fixed in V4.2.2 yet it was not fixed. So now what, just gets forgotten…
http://forum.cs-cart…snippet-errors/
[/quote]
CarStickersDecals, thank you for the feedback.
We will review this ticket.
It would be nice if fixes could be posted too.
Some fixes are important to daily operations of some store fronts and waiting may only hurt if the release is not due out for sometime.
[quote name='jimmyod' timestamp='1410537657' post='192143']
It would be nice if fixes could be posted too.
Some fixes are important to daily operations of some store fronts and waiting may only hurt if the release is not due out for sometime.
[/quote]
Hi jimmymod,
At the moment we post fixes only in case we were asked for a fix or a fix is rather simple to implement.
We do this in order to avoid problems during patch applying that occur from time to time with the CS-Cart owners who is not very good with programming and server administration.
[quote name='P-Pharma' timestamp='1410225964' post='191715']
A milestone is the software version in which you schedule a bug fix, improvement or suggestion to be implemented.
Currently you seem (correct me if I am wrong) to use the 'fixed in' function for after a bug is fixed. Though I rarely see it used.
The way milestones are normally used in software development projects I have encountered, is that after you confirm an issue, you schedule it for a future release. This is the milestone.
Its logical that most bugs should be scheduled for the next release, but when a bug or improvement requires significant work then its useful to schedule it for a later milestone. By having milestones your development team all knows what should be in a release. If you use a decent tracker you can easily make a milestone visible and see all bugs, and improvements for a future version.
IP.Tracker is without a doubt one of the worst bug tracker software on the internet. I cant imagine that you can keep project overview with it. You would make life much easier for your team and for customers if you replace it.
[/quote]
Unfortunately milestones can do more harm than good. The main point is that some bugs can lead to a lot of work and sometimes we exclude such bugs from a selected milestone. This is because we have a lot of relations in CS-Cart like reward points depend on gift certificates, and order placing and promotions and etc. And sometime during fix development it turns out that we have to make some code refactoring.
So we set the version number which contains a bugfix included only after this fix is done and tested completely.
[quote name='P-Pharma' timestamp='1410225964' post='191715']
But most important is to make sure that valid bug reports are not closed without a fix. If valid bugs are dismissed in the tracker then customers give up reporting. And thats bad for quality.
I really think you would benefit from changing your bug triage protocol. Your current protocol is not effective and allows a large number of bugs to remain unfixed. This stands in the way of success of an otherwise marvellous product.
If you do not have a bug triage protocol, then please provide your triage team with it so they can be more effective.
[/quote]
I absolutely agree with you. Missing a valid bug in Bug tracker is unacceptable.
At the moment out testers review all the new messages and try to reproduce a bug using its description. We confirm a bug (change its status to Confirmed) only after one of CS-Cart members reproduce it.
There are some reports that indeed aare minor improvements or default functionality. And we do inform reporters about that.
If you have some thoughts on how we can improve this process. Or may be some bugs that were missed please let me know.
Thank you for the contribution. We do appreciate this!
IMac _ unfortunately your assumptions and reality don't match. Take a look at the last three bugs I reported. And also, you keep getting the same feedback and requests, but only rationalize what you do. No reason in your triage process you can't validate the work and establish a release where the problem will be fixed. From a costumer perspective it is and unworkable system where many problems reported are dismissed without an attempt to duplicate.
[quote name='imac' timestamp='1410793069' post='192264']
Hi jimmymod,
At the moment we post fixes only in case we were asked for a fix or a fix is rather simple to implement.
We do this in order to avoid problems during patch applying that occur from time to time with the CS-Cart owners who is not very good with programming and server administration.
[/quote]Imac,
I understand what you are saying, but I think shop owners know their limitations and know whether to apply the patch themselves or wait for an update to be released.As for the shop owner that does know how to apply patch, it would be great to be able to apply the fix and continue using our store without a problem. I am still waiting for a response on this issue [url=“http://forum.cs-cart.com/tracker/issue-5213-pop-up-window-not-working-in-contents-pages/”]http://forum.cs-cart.com/tracker/issue-5213-pop-up-window-not-working-in-contents-pages/[/url]
[quote name='imac' timestamp='1410794174' post='192268']
Unfortunately milestones can do more harm than good. The main point is that some bugs can lead to a lot of work and sometimes we exclude such bugs from a selected milestone. This is because we have a lot of relations in CS-Cart like reward points depend on gift certificates, and order placing and promotions and etc. And sometime during fix development it turns out that we have to make some code refactoring.
So we set the version number which contains a bugfix included only after this fix is done and tested completely.[/quote]
This is not a logical or normal way of development. Normally the milestone for a bug fix of any severity is in the next release (if a release is not imminent). If it is clear that a bug fix needs significant work and has a severity of medium or low, then it should be scheduled for a subsequent release. If a bug fix needs significant work and has a severity of high, critical or showstopper then it should still be scheduled for the next release. This also explains why you need to have severities.
CS-Cart is a fairly large application, but its not more complex than other php website software. Yet other software companies manage to set milestones and benefit greatly.
The problem with not setting milestones is that you do not have a clear overview of all open bugs and you risk forgetting about bugs. Bugs stay up in the air instead of getting fixed. This is happening a lot.
You can see on this forum that customers are tired of having so many bugs and are wanting to abandon CS-Cart for this reason. And I will tell you right now that I will also move away from CS-Cart if my companies keep encountering bugs this year.
What you and customers need is a clear overview of open bugs and when a list of bug fixes per milestone. This allows you to work in sprints.
[quote name='imac' timestamp='1410794174' post='192268']
I absolutely agree with you. Missing a valid bug in Bug tracker is unacceptable.
At the moment out testers review all the new messages and try to reproduce a bug using its description. We confirm a bug (change its status to Confirmed) only after one of CS-Cart members reproduce it.[/quote]
I am sorry to say that this is not working. Your staff is often not able to reproduce very obvious bugs.
There are major communication problems as well.
Your staff is also not using the bug tracker in a logical and consistent way.
This is why I advise you to implement better triage protocol.
[quote name='imac' timestamp='1410794174' post='192268']
If you have some thoughts on how we can improve this process. … please let me know.
[/quote]
Improve this by:[list=1]
[]replacing the bug tracker software.
[]implement a standard bug triage protocol and make sure everyone on staff follows it strictly.
[]add someone to the triage bug team who is customer oriented and experienced in Q&A.
[]add a clearly visible function in admin panel that shows new database errors and all information that your staff needs to identify the problem. This will make it easy for people to report bugs.
[/list]
[quote name='imac' timestamp='1410794174' post='192268']Or may be some bugs that were missed please let me know.
[/quote]
Your bug tracking staff currently dismisses a lot of valid bug reports. Just read my posts in the bug tracker to see examples. If I and others would not have stepped in in those bug reports then the bugs would still have been dismissed.
It is really bad for your business if customers need to fight your staff to get bugs accepted. But unfortunately this is the reality.
Another issue that I really advise you to address is that customers need to pay for support tickets about bugs. You should not punish your customers for telling you about bugs. You should reward them instead, because the quicker bugs are discovered, the more stable your product will get and this translates into sales.
imac, how is it possible that official bug fixing timeframes are within 3 days, but bug tracking staff does not reply to bugs for weeks?
[quote name='P-Pharma' timestamp='1412033751' post='193083']
imac, how is it possible that official bug fixing timeframes are within 3 days, but bug tracking staff does not reply to bugs for weeks?
[/quote]
Please take our apologies for the existing situation.
Unfortunately, we were not able to process bugs in the bug tracker for some time because our specialists were heavily loaded.
We need 10 business days to resolve this situation. We will keep you informed.
Once again we are terribly sorry for any possible inconvenience.