Tags
Software Testing
internal newsletter items - security edition
This edition goes into some security issues and what we can do as testers about them. Plus lots of stuff about AI! Always With the Learning UX and security can go hand-in-hand, according to Josh Ben-David in this Medium article . In considering how a person authenticates, it is important to understand the tradeoffs and the ease with which it can be done. A quote attributed to Jared Spool lands hard: “if it’s not usable, it’s not secure.”
May 2026internal newsletter items - testing in production
This issue talks about testing in production, how to make staging more prod-like, has a very healthy dose of AI stuff, and more! Always With the Learning Cindy Sridharan has a great series of posts about testing in production. Worth the long read, especially for those of us with distributed systems and microservices.
May 2026internal newsletter items - catching up
I’ve released 17 issues of the newsletter at this point, and I have only posted three times here, so let’s catch up on stuff I love! Always With the Learning Each issue will have some blog posts or articles to read. We’re starting out with a series by Maria Kedemo about testability. Four parts, but they’re nicely consumable.
May 2026internal newsletter items - accessibility edition
Initially published internally on Global Accessibility Awareness Day (May 18th). I also added a new feature specifically devoted to AI (“Model Citizen” - get it?) so that the entire newsletter wouldn’t be just AI each time. Always With the Learning Vitaly Friedman wrote about designing for neurodiversity and how that is part of accessibility. It’s chock full of further resources and great information.
May 2026internal newsletter items - ALL ABOUT AI
Newsletter items from my internal company newsletter, the week of May 4
Feb 2026internal newsletter items - systems thinking and more
I publish a biweekly newsletter for the QE organization at my company, and I thought I’d start sharing some of what I have there. This edition is about systems thinking, as well as some other stuff. Always With the Learning Konstantinos Konstantakopoulos wrote about systems thinking and automation for the Ministry of Testing. Short read with some good insights.
Jun 2024where I'll be in 2024
I’m going to be at software testing conferences this year! It’s June as I’m writing this, and the first is in eight days, but I guess it’s better late than never! Romanian Testing Conference : June 12-14, Cluj-Napoca, Romania opening keynote - Real Life Is Not an Edge Case PNSQC : Oct 14-16, Portland, Oregon, US invited speaker - Mistakes I Made So You Don’t Have To workshop - Leveraging the Power of AI in Software Testing Testing United : Nov 7-8, Vienna, Austria opening keynote - Artificial Intelligence: the Good, the Bad, and the Bias Agile Testing Days : Nov 19-22, Potsdam, Germany musical - The Owl Problem talk - Mission Possible: Leading as an Individual Contributor I am THRILLED to be at these conferences. I couldn’t have imagined that these doors would open, and I can’t wait to meet people, learn a bunch, and share some of what I think about!
Oct 2018pair testing adventures
Last week, I finally did what I’ve been wanting to do for months (years) and engaged in pair testing three times with some differing results. what is pair testing? Pair testing is a lot like pair programming, where you have two sets of eyes and two minds engaged in the same problem. There can be a lot of benefits to it (Lisa Crispin talks about it here ), such as increased creativity, better quality, and more exploration, but, just like pair programming, it can be difficult to start and requires a lot of focus and energy. I wanted to learn strong-style pairing , as it seems to involve the most engagement from both people.
Aug 2018CAST retrospective
I attended the Conference of the Association for Software Testing (CAST) two weeks ago in Cocoa Beach, Florida. It was a fantastic learning and networking experience over four days, and I’m still reeling a little bit. I started with a full-day tutorial about how to coach testing with Anne-Marie Charrett (her site is here ). She and James Bach built the coaching model together but have added their own flavors to it. Anne-Marie emphasized understanding the person and starting from where they are. We had a couple of exercises where we paired up to teach a concept or test something, and we realized how easy it was to move in and out of pairing and coaching alternately. It gave me a lot to think about if I move into coaching, and Anne-Marie’s style of teaching was engaging and thorough. The overarching theme of the weekend was “Bridging Between Communities”, so a lot of the talks and workshops ended up stressing communication. This ranged from communicating in healthy ways to defuse situations (Don’t Take It Personally by Bailey Hanna - her blog post is here ) to a keynote about Cynefin by Liz Keogh where she said:
Dec 2017automation thoughts - an update
Last year, I wrote some thoughts about the benefits of manual testing. The posts are here and here . Now that I’ve been on an agile team for over a year, and doing some automation, I think (hope) I have some more sophisticated thoughts about automation. Our team has two “manual testers” and one “automation engineer”. The automation engineer does all of the UI automation (for now), but I’ve written a lot of service layer tests using SOAP UI, and the other tester has been learning to write them too. The idea is to have the two of us start running (and eventually writing) UI automated tests as well, and we’re taking steps towards that end. The benefits of the API testing through SOAP have become clear, but so have the challenges. It has cut down on our need to test all flows in regression testing manually. I can write service tests while the UI is still being coded, and it’s a good way to start our monthly testing cycle. After all, if something is broken at the service level, there’s no point in testing manually, and we can pinpoint the error more quickly and precisely. We have everything in our app that can be tested at the service level automated, which I feel really good about. Or, at least, we have all the calls exercised. There’s always more to test, isn’t there? A big weakness of service testing is that it is more brittle than manual testing, because if something changes in the call (for instance, a value changes from being taken from a detail to being taken from a cookie), it breaks the test, though you wouldn’t notice a difference at the UI level. You also can’t run all the negative tests (like lockout tests) you might want to run, particularly if you think you’ll run the suite repeatedly through the day. We have two test cases that can only be run once every half hour, and one test case that requires a person to reset the user every time. Those test cases are fairly essential, so we make do with them. I still very strongly believe that there is no substitute for getting in the features and playing around, or, to be more formal about it, doing exploratory testing. That’s how we find all the interesting bugs. Automated testing is checking; it ensures certain things are stable, not that a product is “good”. However, automated testing is (can be?) fast, and it can be an efficient use of time, particularly for regression testing. Automated testing can make sure that bugs that are found and fixed don’t break again, but would a person writing automated test think to try refreshing a page without first finding an issue in exploratory testing? Perhaps I’ll have more thoughts about this later, but this is what I’ve been thinking about recently. Thoughts from y’all? Criticism? Questions?