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,908 other followers

Archive for the ‘Testing’ Category

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:



On Reserved Top Level DNS Names

These lists all reserved and special domain names:

From [Wayback] RFC2606: Reserved Top Level DNS Names (RFC):

2. TLDs for Testing, & Documentation Examples

   ... four domain names are reserved as listed and described below.


      ".test" is recommended for use in testing of current or new DNS
      related code.

      ".example" is recommended for use in documentation or as examples.

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

3. Reserved Example Second Level Domain Names

   The Internet Assigned Numbers Authority (IANA) also currently has the
   following second level domain names reserved which can be used as


From [Wayback] RFC6761: Special-Use Domain Names (RFC):

   This document describes what it means to say that a Domain Name (DNS
   name) is reserved for special use, when reserving such a name is
   appropriate, and the procedure for doing so.  It establishes an IANA
   registry for such domain names, and seeds it with entries for some of
   the already established special domain names.

From [Wayback] RFC6762: Multicast DNS (RFC):

   this document allows any computer user to
   elect to give their computers link-local Multicast DNS host names of
   the form: "single-dns-label.local.".  For example, a laptop computer
   may answer to the name "MyComputer.local.".  Any computer user is
   granted the authority to name their computer this way, provided that
   the chosen host name is not already in use on that link.

From [Wayback] RFC7686: The “.onion” Special-Use Domain Name (RFC)

   The Tor network is designed to not be subject to any central
   controlling authorities with regards to routing and service
   publication, so .onion names cannot be registered, assigned,
   transferred or revoked.  "Ownership" of a .onion name is derived
   solely from control of a public/private key pair that corresponds to
   the algorithmic derivation of the name.

From [Wayback] draft-ellermann-idnabis-test-tlds-04: Reserved Top Level DNS Names (Internet-Draft, 2008):

Appendix A.  Educational Info

   This informative appendix tries to answer three frequently asked

   1.  As of 2008 IANA is the registrant of ""; TLD ".edu"
       has no contract with ICANN; its administration is based on a five
       years contract with the US DoC renewed in 2006; see
       <>.  Under amendment
       6 of their current policy generic names cannot be registered.
       This is not exactly the same situation as for say "",
       where IANA is the registrant *and* registrar.

   2.  As of 2008 IANA is the registrant of ""; TLD ".info"
       was created by ICANN in 2001.  The ".info" registry agreement
       lists reserved DNS labels including "example"; see
       <> appendix 6 (2006)
       and K (2001), respectively.  This is not exactly the same
       situation as for say "", where IANA is the registrant
       *and* registrar.

   3.  Ignoring [RFC2965] the TLD ".local" issue was discussed in a
       bunch of Internet-Drafts related to AS112, zeroconf, and
       [RFC3927].  Presumably TLD ".local" should be registered as
       reserved for technical reasons, but deserves its own document
       with the fine print.

From [Wayback] draft-wkumari-dnsop-internal-00: The .internal TLD. (Internet-Draft, 2017):

   It has become clear that many users would like to use the DNS
   resolution system for names which do not have meaning in the global
   context but do have meaning in a context internal to their network.
   This document reserves the string ".internal" for this purpose.


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 »

Why a study with only 7 respondents can be good – from Dutch paper “De Volkskrant”

Posted by jpluimers on 2021/01/07

[] Waarom een onderzoek met maar 7 respondenten toch goed kan zijn | De Volkskrant: Denkfouten in het hedendaags ontwerp gefileerd door innovatie-expert (en cabaretier) Jasper van Kuijk. Deze week: gebruikstest.

Google translated in English.


Quantitative studies often require large numbers of respondents, but quantitative studies can be done with a very small group.

While quantitative studies often will get you just one result (I rate this application a 7 out of 10, or with this A/B change, click through increases by 5%), qualitative studies will get you much more specific comments like “the main menu is cluttered”, or “the design is slick” (translated from the Image in the article).

Extensive research was done for a 2003 published paper [] Beyond the five-user assumption: Benefits of increased sample sizes in usability testing which you can read as PDF [WayBack].


[WayBack] Jasper van Kuijk on Twitter: “Mijn ‘Hoe moeilijk kan het zijn?’ van vandaag. Waarom voor gebruiksgemak een gebruikstest met 7 participanten nuttiger is dan een enquête met 1500 respondenten. #HMKHZ via de @volkskrant”


[WayBack] Ionica Smeets on Twitter: “Hear, hear! Aldus een wiskundige die heel wat jaren nodig had om waarde van kwalitatief onderzoek in te zien…”




Read the rest of this entry »

Posted in Development, Software Development, Testing, Usability, User Experience (ux) | Leave a Comment »

%d bloggers like this: