Is there anyone having experience with [Wayback/Archive] HttpMaster | Master HTTP Testing and Debugging?
Via [Wayback/Archive] HttpMaster (@http_master)
–jeroen
Archive for the ‘Testing’ Category
Anyone having experience with HttpMaster | Master HTTP Testing and Debugging?
Posted by jpluimers on 2025/09/30
Posted in .NET, Development, Software Development, Testing, Web Development | Leave a Comment »
On my wish list for reading: Effective Software Testing
Posted by jpluimers on 2025/07/02
Always learning, I put this book on my wish list for reading: [Wayback/Archive] Effective Software Testing as from what I read it is a pragmatic book aimed at developers and suitable for teaching. That sounds right the niche I am in.
From [Wayback/Archive] Using the book in classroom:
Share this:
Posted in Agile, Development, Software Development, Testing, Unit Testing | Leave a Comment »
“How come these shapes are so DIFFICULT??”
Posted by jpluimers on 2025/06/03
Cool video about how developers feel when others (like QA) test or use the software they have just built:
[Wayback/Archive] Devs watching QA test the product – YouTube
I got to the video via [Wayback/Archive] sanja zakovska 🌱 on Twitter: “Devs watching QA test the product… “ to which the author responded with
[Wayback/Archive] Alison Burke on Twitter: “@sanjazakovska Incase anyone needs the resolution 😂😂 follow me on tiktok! vm.tiktok.com/ZMJKeK29a“
Share this:
Posted in Conference Topics, Conferences, Dark Pattern, Development, Event, Software Development, Testing, User Experience (ux) | Tagged: 2020, 2021, babyfur, comedy, crying, duet, firstpost, foryou, foryoupage, funny, fyp, newyear, RareAesthetic, viral, Welcome2021 | Leave a Comment »
Test Automation Code Smells – Angie Jones
Posted by jpluimers on 2024/12/25
Cool presentation: [Wayback/Archive] Test Automation Code Smells – Angie Jones.
A recording is at [Wayback/Archive] What’s That Smell? Tidying Up Our Test Code – YouTube (and embedded below the signature).
The code is at [Wayback] code_smells_workshop.zip.
Share this:
Posted in Agile, Development, Software Development, Testing, Unit Testing | Leave a Comment »
For my link archive – AndreaJensen on Twitter: “Hi testers, What do you find difficult, tricky, or challenging about #ExploratoryTesting? Please share your thoughts”
Posted by jpluimers on 2024/10/30
Since there is a lot of confusion about exploratory testing (for one: it is not ad hoc testing!), I need to revisit this some 2 year old tweet and learn more: [Wayback/Archive] AndreaJensen on Twitter: “Hi testers, What do you find difficult, tricky, or challenging about #ExploratoryTesting? Please share your thoughts. Rt are also highly appreciated. Thanks”
Share this:
Posted in Development, Testing | Tagged: ExploratoryTesting | Leave a Comment »
Two Ways of Solo Programming – Seaside Testing
Posted by jpluimers on 2023/09/05
Food for thought from Stephan Kämper: [Wayback/Archive] Two Ways of Solo Programming – Seaside Testing
TL;DR:
- it is about the time in between paid projects
- mode 1: learning; each day ends with a working state (compiling source, passing tests)
- mode 2: personal projects (libraries, tools); each day ends with a failing test as a guidance what to keep working on
The last one refers to [Wayback/Archive] Try ending today with a failing test for a great start tomorrow – DEV Community by [Archive] Nick Holden (@NickyHolden) / Twitter.
Via: [Wayback/Archive] Stephan Kämper on Twitter: “A new short-ish blog post about two slightly different ways of programming, when work ‘solo’ ➙ …” / Twitter
–jeroen
Share this:
Posted in Agile, Awareness, Development, Software Development, TDD, Testing | Leave a Comment »
Great tags: #BugMagnet #IAmATester
Posted by jpluimers on 2022/11/24
I should use the great tags #BugMagnet #IAmATester more often.
Via: [Archive.is] 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”
–jeroen
Share this:
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
Note
Though there are .example.edu and .example.info, 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 ".example.org", where IANA is the registrant *and* registrar.
Wikipedia links:
-
- .example – Wikipedia
- .invalid – Wikipedia
- .local – Wikipedia
- .localhost – Wikipedia
- .test – Wikipedia
- localhost – Wikipedia
- Email address: Reserved domains – Wikipedia
Of note for e-mail are
example,invalid,example.com,example.net, andexample.org. - Example.com – Wikipedia (which puts
example.eduon the same level asexample.com,example.netandexample.org; this is not true, despite the domain being registered by the IANA, the IANA is not the registrar of the.edudomain) - Top-level domain: Reserved domains – Wikipedia
Reserved by RFC 2606 and explained further in RFC 6761:
- .test
- .example
- .invalid
- .localhost
Reserved by RFC 6762: .local
Reserved by RFC 7686: .onion
Reservation proposal by Internet-Draft draft-wkumari-dnsop-internal-00: .internal
Share this:
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: … “
–jeroen
Share this:
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) 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/- 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. /
- 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. /
- 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. /
- 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. /
- 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. /
- 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. /
- 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. /
- 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. /
- “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. /
- 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. /
- 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. /
- 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. /
- 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. /
- 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. /
- 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,… /
- 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. /
- 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. /
- 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] developsense.com/blog/2018/02/h…
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.
–jeroen
Share this:
Posted in Development, Software Development, Testing | Leave a Comment »
The Wiert Corner - irregular stream of stuff 