I have worked with some excellent testers but I have also worked with a team that literally required us to write down the tests for them.
To be fair, that wasn’t their fault because they weren’t testers. They were finance people that had been seconded to testing because we didn’t have a real test team.
The current team is somewhere in between.
I wish our test team was like that. Ours would respond with something like “How would I test this?”
This is very frustrating! I get so many requests from customers asking why we returned response code 400 when we gave a description of the problem in the response body.
I remember when our company split up and we had to give them the source code of some older versions that they still used. We couldn’t do that because the repo was corrupt meaning that we couldn’t access some older revisions. We had no problems using it day to day so nobody noticed which meant that all backups were also corrupted.
It’s not the mechanism of branching that I prefer.
It’s the fact that Mercurial tags the commit with the name of the branch that it was committed to which makes it much easier to determine whether a commit is included in your current branch or not.
Also, Mercurial has a powerful revision search feature built in which I love (https://www.mercurial-scm.org/doc/hg.1.html#revisions).
It’s definitely up with Git in my opinion. I much prefer the branching in Mercurial.
It’s certainly very offensive to lump it in the same band as SVN and TFVC.
The only reason that we stopped using Mercurial is that Microsoft used Git in Azure DevOps. I still wish that they’d supported Mercurial instead of or as well as Git.
I really liked Mercurial too. It was much easier to follow branches to find out if a branch included a commit.
And worse than all of those options is Visual Sourcesafe.
We don’t get that lag but we do frequently get it when the camera doesn’t work for somebody.
I really can’t understand the separation between teams, channels and chats. We almost never use anything other than group chats.
I think that whether it needs plugins or not to do the job isn’t really relevant.
You can develop software in a large number of languages including writing the code (with intelligent code completion), building it, committing it to source control and running and debugging it.
If it didn’t use plugins to do that then it’d huge and take ages to start up.
Microsoft SQL Server is most commonly set up as case insensitive in my (limited) experience (it does support case sensitivity too).
I used to work on an old DOS product and we didn’t have a debugger so we used to have a DEBUG command line argument with
if (DEBUG) printf(“debugging”);
to try to see what was happening and the number of times that code alone fixed the problem was scary.
I think that from a legal point of view there is no difference between the two. If you do an Alford plea then you still can’t appeal because you pleaded guilty.
The harsh and mild sentence part is a negotiation. The prosecution is interested in getting a plea deal because it saves time and resources and the defendant is interested in getting a lighter sentence if they’re pretty confident that they’ll be convicted anyway.
Maybe it’s not changed then because I was using it in the early 2000s. 😀
We used to use Redmine and it was a fantastic piece of software.
I’m not sure that’s the fault of XML though.
It’s more the fault of the implementation and documentation.
We have a WCF service with an odd configuration and nobody has been able to integrate with it that didn’t use Microsoft tools. It’s definitely not XML’s fault.
(That service has been replaced with a REST API now)
It seems that they intend Microsoft Loop to be the collaborative notes app now.
It’s replaced OneNote as the meeting notes app and it has more flexible access control.
Currently they also only have one version as it’s a progressive web app (that might change with time though).
I guess that that’s all that matters.
Did it take time to get used to or did it work straight away?
I think that the main difference is that developers tend to test for success (i.e. does it work as defined) and that testers should also test that it doesn’t fail when a user gets hold of it.