Software problems that really ought to be solved by now
-
the thing you really need is defining the workflow
Wrong. The thing I need is a simple, unified place to get both automated and test results side-by-side so I can make recommendations on whether a product is ready to ship. Trello won't give me that. Testlink had a clunky, awkward UI and (from what I recall) wouldn't play nice with my existing Webdriver tests and unit tests.
-
I'll just define the three axes I believe exist:
- When the defect is encountered, how bad is it?
- How commonly is the defect encountered?
- How important is it that we fix the defect?
Not only that. Whoever is filing the bug is not able to fill these. Definitely not the third one. I am going to argue that most of the time you should not ask them to even try, because they'll get analysis paralysis and that is what actually kills usage of these tools.
The tester can distinguish the first two only crudely. They can distinguish between bug happening always, often, sometimes and rarely when using the feature and between crash, incorrect result and bad workflow, but they probably won't have good feel for the actual process to tell how bad it really is.
So what you really need is for the team leader and product owner to sit together and go through all the reported bugs and assign the severities/priorities. Without that the system is not going to work. And for that they need to read the descriptions anyway, so having the tester fill the first two, even to the point they can do it, is not that useful.
authors, developers, and testers to manage their workflow.
Those won't. The team leader and product owner have to manage the workflow. Without the team lead keeping an eye on the system it will quickly fall into disuse. People problem. Not fixable with technology.
-
Whoever is filing the bug is not able to fill these. Definitely not the third one. I am going to argue that most of the time you should not ask them to even try, because they'll get analysis paralysis and that is what actually kills usage of these tools
Sounds like a mandatory triage step could be a useful idea? Someone with a higher level overview than the tester classifying these things before the developers see it. The trouble is, that doesn't really fit in with any workflow I've encountered in the wild
-
Well, it kind of is how Scrum is supposed to work, at least as far as I understood, because I've never been in a place that used more than random bits of Scrum.
But in fact this seems to mostly work for us now. We have the bugs simply slapped in a column in Trello, so there is not really much structured information there, but that's actually advantage, because it makes it easier to fill them in. And the team leader watches the board and assigns priority labels (discussing with the boss when he can catch him online) and adds people to it so they know what they should be looking at. And we have a daily sit-down¹ meeting where he explicitly assigns “fix bugs you have in Trello” to people who have some important bugs in Trello and “test whether the bugs in Trello are fixed” to people who have time to test, so the others don't forget to look at it and update it.
¹ It was always intended to be a stand-up meeting, but with the ~15 people and discussion of problems always spinning off we rarely manage to squeeze it under 30 minutes. And we do it over VOIP; many, including me, telecommute, so we really have to.
-
eschew it in favor of emails, which are even simpler...
We often eschew it in favour of IM (Skype in particular), because that's what we usually use to communicate.
I always considered both notification and actually accepting new issues and replies via email to be a mandatory feature for bug tracking and would not consider being able to do the same over IM an important feature too.
-
We would be permitted, I think, but we use Oracle, so....
But it should be easy enough to set up separate schemas, no? That's what we do.
-
Not only that. Whoever is filing the bug is not able to fill these. Definitely not the third one. I am going to argue that most of the time you should not ask them to even try, because they'll get analysis paralysis and that is what actually kills usage of these tools.
The tester can distinguish the first two only crudely. They can distinguish between bug happening always, often, sometimes and rarely when using the feature and between crash, incorrect result and bad workflow, but they probably won't have good feel for the actual process to tell how bad it really is.
So what you really need is for the team leader and product owner to sit together and go through all the reported bugs and assign the severities/priorities. Without that the system is not going to work. And for that they need to read the descriptions anyway, so having the tester fill the first two, even to the point they can do it, is not that useful.
I think the ability of the reporter to fill in the first two depends on who the reporter is. In my organization, we often get bug reports from our field consultants who are working directly with customers (and therefore experience the defect directly) or from our support team, who are high-level technical types and have a very high level of product and customer knowledge. In those cases, they can often do a pretty good assessment of how bad and common a defect is.
In other situations, though, you are completely right - the initial assessment of degree and frequency of a defect may only be a crude one and needs later refinement.
The importance question, though, does need triage from people with a big-picture view, as @Jaloopa suggested.
In fact, triage is definitely an important part of a functional defect tracking system. While my company doesn't have a formal process, my team has an informal process, and it makes a huge difference.
-
Sounds like a mandatory triage step could be a useful idea? Someone with a higher level overview than the tester classifying these things before the developers see it. The trouble is, that doesn't really fit in with any workflow I've encountered in the wild
We have weekly meetings with the customer to go over this sort of thing for all new issues.
-
We had that in theory at my last job, but what actually happened was that everybody would say their ticket numbers, they'd all go into the sprint, then we'd do maybe half of them before the next sprint. Triage is hard
-
I dunno...that doesn't sound at all like what we have.
-
MediaWiki adds features WikiPedia wants,
Meaning: features that appeal to dickhead pedants.
-
@RobFreundlich said:
authors, developers, and testers to manage their workflow.
Those won't. The team leader and product owner have to manage the workflow. Without the team lead keeping an eye on the system it will quickly fall into disuse. People problem. Not fixable with technology.
You're right - it's a people or cultural problem:
- Most mono-functional teams (dev-only, testers-only, doc-only, etc) have the problem of "no one knows what anyone else is working on at the moment"
- Most cross-functional teams (dev + testers + doc + etc) have the problem of "hey, what's going on with that defect I submitted last week/month/year?"
- Most management has the problem of "I need to be able to quickly tell [person above me] what's going on at the moment"
A regular stand-up (or sit-down if the team is large) is a decent start for the first problem. But even that isn't perfect - my team had ours two days ago, and I don't really remember what Fred (name changed to protect the innocent) said he was working on.
So what's needed is a cultural change enabled by tools and (as you noted) encouraged by official leadership (e.g. management) and unofficial leadership (e.g. respected peers who demonstrate that it is easy and useful).
The tools can be as simple as a single field in the defect tracking system for "Resolver working status", or as complex as I described in my original post. It depends on what you want to get out of the system.
If it's just the above three issues, all you need is the one field and a simple way for the resolver to update that field.
If you want to provide a way for people other than the resolver to use the system to gain a fuller understanding of the issue now and in the future, then more of the fields I described are necessary. For example, we often run into the problem in which a defect is marked as fixed, and the notes describe the fix, and the checkin comment describes the fix, but we have no clue WHY the fix was done the way it was done. That makes future changes (or related changes, or similar ones) hard to do.
If some system somewhere provided a way for the resolver to track his/her thought process, we'd have that information.
Again, it's a cultural problem, but tools can help when encouraged and monitored by leadership. And I think a defect tracking system is perhaps the right tool for this, since it keeps all of the information in a single place.
-
If you want to provide a way for people other than the resolver to use the system to gain a fuller understanding of the issue now and in the future, then more of the fields I described are necessary. For example, we often run into the problem in which a defect is marked as fixed, and the notes describe the fix, and the checkin comment describes the fix, but we have no clue WHY the fix was done the way it was done. That makes future changes (or related changes, or similar ones) hard to do.
If some system somewhere provided a way for the resolver to track his/her thought process, we'd have that information.
This sort of thing is why some open source projects have grown stuffy procedures (such as Python's PEPs). You have to have that to get an average developer to take time to write down why they doing this stuff in the first place. It does suppress creativity, but it also allows the code to be maintained in a sane way.
“Sorry” might be the hardest word, but “why” runs it a close second.
-
For example, we often run into the problem in which a defect is marked as fixed, and the notes describe the fix, and the checkin comment describes the fix, but we have no clue WHY the fix was done the way it was done.
Then the commit comment does not describe the fix. A good commit comment should describe the rationale behind the change, because that's the thing you won't see by looking at the diff.
It should be in the commit message and not the bug tracker, because you also need to find it next time you need to modify the code and from there it is easy to find the relevant commit logs with log, pickaxe or blame, but difficult to find the bug reports. The bug reports need to record the revision that fixes them to make this available and for other reasons too like so you can tell in which release the fix made it.
Enforcing good commit messages is again a social problem that can be addressed by doing reviews before integration, possibly supported by Gerrit.
-
It should be in the commit message and not the bug tracker
I prefer to have the bug tracker and the commits fused into a single event stream. If you've got one, you've got the other. Like that, all a commit really needs to do is to refer to the issue number, and the issue can have the full details.
Git doesn't do this. I don't really like git very much.
-
A commit message can be a lot more technical than a bugtracker resolution, because of the different audiences. If I've modified a complex algorithm, the next programmer to come along might need to see what internals I've changed and why. The bug reporter just needs "Searching for Fridge no longer shows Door as the first result"
-
You put markup in your commit messages?
-
A commit message can be a lot more technical than a tracker resolution, because of the different audiences.
I think of the commit message and the tracker resolution/comments the same way, although I also prefer to document algorithms in the code that implements them and will often leave the complex details out of the commit message for that reason.
The point I was trying to get across, though, is that sometimes a simple summary statement (or even a complex summary statement) in source control or the tracker isn't enough. Ditto for a design document. I just spent several months reworking a visual layout algorithm. Even though the end result is well-documented, what's just as important is the process by which I got there - all of the wrong turns I went down, little prototypes that failed or succeeded and ultimately led to the decisions to both include and exclude particular features and/or bits of code.
For that, you need the developer to write stuff down as they are going through the entire process, not just after the fact. And all of that needs to be available to everyone, technical and otherwise, so that when questions of "why is it that way" come up a year from now (or even harder, "why isn't it that way?") the answers can be found.
The answer I'm playing with for now is to include a "Working Notes" section at the end of our design doc. Putting it at the end makes it easy for the developer to append to during a coding session or design discussion and lets people who are only interested in the here-and-now to ignore it. We'll see how it works out.
To tie everything together, the commit comment has a reference to the bug tracking number and the bug tracker has a reference to the commit number(s) - we have automated tools that verify that in both direction - and I have started putting the bug tracking number into the design doc. Again, we'll see how that all works out.
-
Meanwhile, this is what's wrong with SQA:
Oh no, writing code! How will he ever cope!
-
But it should be easy enough to set up separate schemas, no? That's what we do.
This is one of those things that sounds fairly simple in theory, but as often happens, it becomes quite complex when the rubber hits the road.
The applications I spend most my time on have their fingers in many schemas, so just creating one copy per developer is already hundreds of copied schemas.
The schemas are inter-dependant and have views and procedures that refer to each other by name. Copies would have different names. There may be a way to work around this, it's probably the simplest of the problems we have.
The suite of applications are all highly dependant. Creating a copy of the environment means a copy of all the applications, which means copies of virtual servers to run them on, configuring them all so no cross-talk, I'm getting a headache just thinking about it.
Our databases are on the large side, and until recently this organisation had a problem with persistent "out of disk space" errors. The CIO had to threaten a firing the next time that message occurred to get it fixed. So more space for more copies isn't going to happen.
And we have one application that's out of support (the company that makes it went bust) that we're not allowed to touch the database for because it's a black box of risk just waiting to explode. Old Oracle version, no schema changes, etc. Creating a copy of that would be a fun exercise.
So yes, we could do it, but no, we don't. It's not worth it. We schedule changes (somewhat) carefully and all use the same shared dev environment. We talk to each other and try not to fuck each other up too often.
-
The applications I spend most my time on have their fingers in many schemas, so just creating one copy per developer is already hundreds of copied schemas.
Ah, I can see how that would suck. We just have two, and one of them is for some particular COTS piece of junk that doesn't really need to know about our schema. Just our app and our schema poke into it. In development, we share a version of the 3rd party schema and all have our own versions of the schema for our app.
So yes, we could do it, but no, we don't. It's not worth it.
After hearing your tale, I agree.
-
Like that, all a commit really needs to do is to refer to the issue number, and the issue can have the full details.
And pray you never change bug tracking systems and lose access to those old bugs...
(If I remember, they did merge open bugs into the new system - but old/closed ones were effectively lost. There was one person who had access to the old data - it was a major PITA trying to research those.)
-
They left our bugzilla VM up for a year or so after the transition. Since that it's been on a couple times to research old issues, but it's rarely relevant nowadays (6 years later)
-
And pray you never change bug tracking systems and lose access to those old bugs...
That's why we integrate the bug tracking with the version control. It's wrong to consider either as being independent of the other.
-
Well I'm glad that I at least cursorily checked your link before weighing in with "Fossil does that!".
-
Integration is nice. We get automatic linking between VCS transactions, code review, and the bug database. If I need to know what I did to fix a bug half a year later, everything is easy to pull up wherever I start.
Especially the code review tool makes up for a lot of the VCS's warts.
-
Well I'm glad that I at least cursorily checked your link before weighing in with "Fossil does that!".
I like Fossil a lot. I particularly like how it does a useful timeline view; I've not found anything quite like that with git (some projects use one, some the other) though the history viewer in Eclipse at least tries. Most git tools are just a bit too misanthropic, and too focused around the patch as opposed to the history tree.
I really ought to investigate what Mercurial does in this area, even if I just end up saying “no, not for me”.
-
I really ought to investigate what Mercurial does in this area, even if I just end up saying “no, not for me”.
It has a built-in web server mode (
hg serve) that includes a reasonable graph view. There are other 3rd party tools, too, of course.
-
So does TFS.
-
After hearing your tale, I agree.
And I forgot to mention the database links, because nothing here is simple.
-
It has a built-in web server mode (
hg serve) that includes a reasonable graph view. There are other 3rd party tools, too, of course.I was just poking around at the history of mercurial, as rendered in mercurial (always an interesting way to look at things) when I noticed this…
Something screwy going on, either in their timeline management or in how they handle timestamps.
-
I like Fossil a lot. I particularly like how it does a useful timeline view...
I actually wound up setting up a fossil instance as a bug tracking database for a personal project—all my bug resolutions are filed against SVN revision numbers!
D:The ease of setting up a fossil server is an embarrassment to other bug-trackers—"What do you mean, copy the
fossilexecutable to the server, run it, and we're already finished? I haven't even spent hours fiddlling with apache yet..."But seeing as now I have the DVCS just sitting there, integrated with a project wiki and bug tracker, I am sorely tempted to start using it... There's no way on earth that it'll be harder to get to grips with than git...
-
Another software problem that should be solved by now: Case sensitivity, or at least fonts where case is distinguishable!
Is that a lowercase L (ELL) or an uppercase I (EYE)? And more importantly, how much will I screw up my system if I guess wrong?
-
WTF is dokg?
-
I didn't even notice that one!
-
Something screwy going on, either in their timeline management or in how they handle timestamps.
Hmm...those timestamps are probably initial commit times, but they're displayed here in the order in which they're pushed. So...
-
Is that a lowercase L (ell) or an uppercase I (eye)?
http://manpages.ubuntu.com/manpages/hardy/man1/dpkg.1.html says uppercaseI. No lowercase L option listed.
-
Hmm, I was using lowercase L and it did what I wanted...
-
package manager for debian based systems.apt-get is a front end for it.nevermind. missed the tyop
-
Oops, you're right. I didn't read carefully.
-Iis one of the options it will pass todpkg-deb.dpkg's own options are described much further down the page.
-
Is that a lowercase L (ell) or an uppercase I (eye)? And more importantly, how much will I screw up my system if I guess wrong?
dpkgbrought to you by the Linux Foundation for Font Recognition Awareness.
-
Fonts where two chаrаcters look the sаme аre the worst.
-
Hmm...those timestamps are probably initial commit times, but they're displayed here in the order in which they're pushed. So...
Oh, it managed to handle the post-divergence merge (automatically?) and so used the old timestamp? Not sure I like that.
-
-
-
-
http://i.telegraph.co.uk/multimedia/archive/01298/bacon-sandwich_1298224c.jpg
That.
Is heaven right there.So long as the sauce is brown.
-
-
Fonts where two chаrаcters look the sаme аre the worst.
Strangely the same font family is both the worst and the best. The DejaVu Sans Mono seems to be the only font which properly¹ distinguishes both ‘O’ and ‘0’ and ‘I’, ‘l’ and ‘1’ while at the same time DejaVu Sans does not distinguish ‘I’ and ‘l’ at all.
¹ Of monospace font I require that 0 must be struck or dotted.
-
@Telegraph
