The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,977 other subscribers

Archive for the ‘Testing’ Category

Great tags: #BugMagnet #IAmATester

Posted by jpluimers on 2022/11/24

I should use the great tags #BugMagnet #IAmATester more often.

Via: [] Stephan Kämper on Twitter: “Moin @VIVANI_official, wenn man vom Twitter-Profil auf den Link zur Webseite klick, dann landet man auf einer Login-Seite von @WordPress, nicht beim Impressum, wie es der Link-Text vermuten lässt. #BugMagnet #IchBinEinTester”


Posted in Development, SocialMedia, Software Development, Testing | Leave a Comment »

RFC2606: Reserved Top Level DNS Names (RFC); draft-ellermann-idnabis-test-tlds-04: Reserved Top Level DNS Names (Internet-Draft, 2008)

Posted by jpluimers on 2022/01/20


Though there are and, though used in documentation and  registered by IANA, have a status is different from the official Reserved Top Level DNS Names:

This is not exactly the same situation as for say "", where IANA is the registrant *and* registrar.

Wikipedia links:

Read the rest of this entry »

Posted in Development, DNS, Documentation Development, Internet, Power User, Software Development, Testing | Leave a Comment »

AgileTD Keynote | Happiness is Quality

Posted by jpluimers on 2021/09/16

Hopefully this becomes available on-line, as this will be a great talk, but Potsdam is out of my reach in my current physical condition.

[Wayback] AgileTD Keynote | Happiness is Quality

In Gwen Diagram’s keynote go on a journey of looking at how to improve happiness in teams for the goal of building quality systems.

How can we build teams that strive to build quality systems? By building in happiness early and often.

Each organisation has a culture which directly affects the quality of their work. Organisations with a lower level of quality; that is, systems that fail more often, longer times to fix and longer times to build often have a few things in common; frustration, apathy and cynicism.

On the other side of the coin, teams with slack, time to learn and time to reflect also have the space to improve their systems. Quality is everyone’s responsibility is an oft quoted phrase. But, how do you actually engage people to build quality systems?

Improving quality should not weigh heavy on the shoulders of the test specialist. Their main role should not be attempting to convince people that unit tests should exist, that systems should be testable and observable or that automated tests will speed up development. Instead, we should be building teams that want to find out together how to build a system that breathes quality.

The way to do this is by improving the happiness of the engineers on the team with learning, autonomy and coaching. So, how can we build teams that strive to build quality systems? By building in happiness early and often. In this talk, we will go on a journey of looking at how to improve happiness in teams for the end goal of building quality systems.

Via: [Wayback] Agile Testing Days on Twitter: “☀️ Here comes the happiness! ☀️ @gwendiagram will take us on a journey of looking at how to improve happiness in teams for the end goal of building quality systems. ➡️ Learn more about the keynote and the speaker: … “


Posted in Agile, Conferences, Development, Event, Power User, Software Development, Testing | Leave a Comment »

Counting bugs versus talking about them: a learning opportunity

Posted by jpluimers on 2021/07/07

Counting bugs (or issues for that matter) tells you exactly nothing. Numbers need context, so you need to discuss context. If there the number feels large, you do not even need an exact number: you already are in trouble.

More about this in this excellent twitter thread:

[WayBack] Thread by @michaelbolton: “1) Thinking about counting things to measure quality? You might be able to measure some things that bear on quality. By contrast, you ca […]”

  1. 1) Thinking about counting things to measure quality? You might be able to measure *some things* *that bear on* quality. By contrast, you can’t measure quality itself (as @jamesmarcusbach has said), but you can discuss it.Consider this: s/how many/let’s talk about each/g/
  2. When you suggest “let’s talk about each bug”, you might hear (or think) “No way! We have too many bugs to talk about each one! Let’s just count them instead!” If so, you can already infer some crucial things about the product and project, with no need to bother counting. /
  3. Of course, those inferences are only inferences, not facts. So investigate. When you do, you might be tempted to start counting bugs. But you’ll probably want to make sure that your count is appropriately accurate, precise, valid, reliable… So you need to examine each one. /
  4. Examining and evaluating each bug sounds like a pain. It is, to a degree. Few people like washing or repairing dirty linen in public. Yet a bug is not just a problem; it’s also an opportunity to learn some things. When you count instead of study, you lose that opportunity. /
  5. I love studying bugs. When I study bugs, I can become aware of certain things that go wrong, and some of those things get embedded into tacit knowledge. I can apply that knowledge, maybe consciously, maybe sub-, while testing, pairing with a developer, or coding myself. /
  6. In Rapid Software Testing, we suggest this: when someone asks for a number or a measurement, avoid misleading them by giving them a scalar. Consider offering a description, an assessment, a report, or a list. If you can describe and summarize, you might not NEED a number. /
  7. When you *are* offering a number, it had better be a valid number. When you count items, each item being counted had better be /commensurate/. That is, you must know the difference between “one of these” and “NOT one of these”. You must know how to count to one. /
  8. For a count to make sense, items must be commensurate—of describable size, weight, duration, significance, value, etc. etc., on a scale that people agree upon, accept, *and understand*. Otherwise communication will go pear-shaped in no time. /
  9. To go seriously about the business of getting a *valid* count, you’ll need to examine every bug. To do good analysis work, there’s no getting out of that. The same general principle applies to counting test cases, or “defect escapes”, or “invalid bug reports”. All of them. /
  10. “But management wants numbers!” I doubt that. Management almost certainly wants *to know things*—and from testers, knowledge about the status of the product and problems that threaten its value. Numbers might help to illustrate a story. They don’t, can’t TELL it. Words can. /
  11. Don’t be cowed into giving numbers without context. When asked for them, consider replying “misleading you is not a service that I offer,” and immediately offering a summarized, meaningful description of the state of factors that matter to people who are important. /
  12. All this applies to reports about the status or quality of the product, of the testing, of the project. And it applies to the work of individual testers, too. As an alternative to *measuring* something, analyze it, describe it, assess it, discuss it. Don’t just keep score. /
  13. What might we evaluate a tester’s work? Here’s an example set of elements of excellent testing:

    . It may not be complete, comprehensive, or tailored to your context. If it isn’t, revise it; fix it to fit. /

  14. Evaluating testers’ work? Go through the list and ask “are we happy with the tester’s work with respect to this element?” If Yes, great. If it’s outstanding, considering analyzing and then sharing that tester’s approaches with others; point out positive deviance from norms. /
  15. Unhappy with some element of the tester’s work? Talk about it. Discuss it. Maybe the tester needs to improve it through focus and deliberate practice; maybe the tester needs pairing and collaboration; or maybe others on the team can handle that element just fine. /
  16. As testers, we (supposedly) specialize in evaluating the quality of things via interaction, observation, experience with them. We consider quality criteria: capability, reliability, usability, charisma, security, scalability, compatibility, performance,… /
  17. People aren’t products, of course. And there are patterns common to evaluating the quality of anything: factors that make people happy or bring them value, or that in their absence trigger disappointment, loss, harm, or diminished value. But “Capability: 6” tells us little. /
  18. I was a program manager for a best-selling product. I would never have conceived of shipping a product (or not) by reading a scoring table. I didn’t care about metrics, test case counts, or bug counts. I needed relevant, concise stories about testing and bugs. /
  19. So: avoid agonizing about “measuring quality”. Consider instead learning to tell the product story, the testing story, and the quality-of-testing story. Talk about what’s OK, and move quickly to problem that threaten the product or project. [WayBack]…
Postscript to this thread: in the middle of my writing it, the Twitter client on my iPad got into a state where it was accepting additions to the thread, but when it came time to send them out, the “Tweet All” button was greyed out. Anticipating a problem, I took screen shots. /

Predictably, the active “Cancel” button DID work, and the text was all lost. But, thanks to screen shots, for once I had a backup and was able to recover my work. It took time, but at least I could do it.

A user in this position doesn’t care about bug COUNTS. Only about the bug.


Read the rest of this entry »

Posted in Development, Software Development, Testing | Leave a Comment »

Solved: Very slow speed on SSD |VMware Communities (via “Building a lab with ESXI and Vagrant – DarthSidious”)

Posted by jpluimers on 2021/05/11

Via [WayBack] Building a lab with ESXI and Vagrant – DarthSidious while researching the possibility of running Vagrant (software) – Wikipedia on VMware ESXi – Wikipedia for building and distributing development environments:

[WayBack] Solved: Very slow speed on SSD |VMware Communities “solution” that seems to work for ESXi 6.5 and 6.7:

ESXi 6.5 includes a new native driver (vmw_ahci) for SATA AHCI controllers, but that introduces performance problems with a lot of controllers and/or disks.

Try to disable the native driver and revert to the older sata-ahci driver by running

esxcli system module set --enabled=false --module=vmw_ahci

in an ESXi shell.

Reboot the host to make the change effective.

which solves it for some who now get much faster results:

Your suggestion worked for me, now i am getting avg speed 250Mbps from SATA III SSD .


Hope will get the full I/Ops from SSD.


One issue I still have is that my 4 port Syba PCIe controller card now vanishes after disabling vmw_ahci and I am restricted to using the SATA ports on the motherboard.

and you need backups:

WARNING: Doing this at least for me erases all the VMs on the aforementioned drive. Migrate as needed.

There was no response for a more permanent fix:

What is the permanent fix for this issue, should we expect a corrected native driver from VMware, or will this require a firmware upgrade on the part of the drive vendors?

and there seem to be other bottle-necks:

tried the command on a 6.7.

Deploying an OVA and I am getting 22.82….

I have a Samsung 860 EVO mSATA 1Tb SSD.

i re-enabled it, I got max 11.81.

Kind of crappy either way. Not SSD speeds IMO.



Posted in Development, ESXi6.5, ESXi6.7, Power User, Software Development, Testing, Virtualization, VMware, VMware ESXi | Leave a Comment »

%d bloggers like this: