Kent Beck

"Our documentation is great!" said no one ever. It is always interesting to talk to folks about this problem. It'ss a problem that can be hard to grasp, measure, and even harder to solve. That is; unless you think about it in a different way. A little bit of simplification, structure, and even some AI might do the trick. I also found a new AI tool, Unblocked, while at LambdaConf this week. I am excited to start experimenting with Unblocked and think it could be a game changer when it comes to managing documents across an organization. Check out my latest article where I talk about #knowledgemanagment. Dennis Pilarinos Daniel Horton

28

1 Comment

I'm a fan of a good mnemonic and I'm liking the simplisticy of this example is explaining the trade offs when considering automation test characteristics https://lnkd.in/gfrutx8N

5

1 Comment

A question to my friends, colleagues, and Linked-In associations that are full TDD developers. Folks who consider themselves proficient or have mastered TDD. 1. How long did it take you to to become very proficient (e.g. to start thinking fully test first)? 2. Did you have a mentor or some aid that helped you along the way? 3. What kept you going down the proficiency/mastery path? I'll start: 1. It took me about 3 years to make it a habit and for me to truly embrace TDD and find that it could replace "test after" development. 2. I did not have a mentor. I did not have YouTube or trainings. I had constraints about creating automated tests. I had teammates that were similarly inclined (constrained). 3. I immediately saw the value of automated tests. I struggled with test first getting in the way of me feeling productive (because I was not proficient and in the learning/gaining proficiency phase) with test first. I'd start every day test first and quickly transition to test after, because it was getting in the way of my "productivity and programming...damn it I just want to write the implementation!" At the end of the day I'd reflect and most days realize that writing tests after was so much slower. Slowly, my time spent test first increased. At some point I transitioned to pseudo coding my intended implementation (to satiate my need to "just write the damn code and not be bothered with tests"). More time passed and I realized that my pseudo code was an inaccurate crutch, I ditched that too and would start with a test. There was a period of time where I'd start with a test and get lost in implementing more than just making the test pass (cycles of sunk cost fallacy here, until I learned it's ok to delete and write it later - faster, better, stronger). There were periods of time where I'd forget to run the test first to see it red before making it green. Too many years messing around with mocking frameworks before learning better design. Struggles with testing internal implementation details instead of external behavior. A whole bunch of stuff I can't think of now and am probably blocking out. I stuck with it though and yikes, does it pay off. I can't imagine not doing TDD now. Coding w/o it is like running through a vat of molasses. So much time wasted in the debugger and writing things that my evil programmer monkey brain distracts me with that YAGNI. I'm writing and asking about this because last week I attended a conference where I talked with a fellow TDDer who'd heard me mention that it took me 3 years to become fully TDD proficient and he shared a similar story even though he was much younger than myself (I attribute my slow adoption due to lack of a mentor/coach and training aids like Pluralsite, YouTube, Jon Reid live coding sessions). I'm curious about others mileage on this. I'll add that I am currently 100% on board with TDD. I am also 100% always on the lookout for a new and better way to replace it. That's off topic though.

45

70 Comments

Hey LinkedIn, a gap I consistently see in the world of test automation is managers understanding how to hold automation folks accountable. Particularly in startups or non-traditional software companies, QA automation falls under the CTO/Director of Engineering and they have enough other priorities where they just tell the automation engineer to go off and do their thing. I've tried to lay out some very basic questions/checkpoints for managers to quickly touch base on: Before starting, 30 days in, 90 days in & 180 days in. The article provides a 6-month strategy to prevent automation projects from failing. It outlines key questions to ask, expectations at different stages, and common pitfalls to avoid. This guide aims to help technical leaders ensure their test automation initiatives deliver real value and don't become abandoned projects. Hope it is helpful! Check out the full article here: https://lnkd.in/gSyPAmwE #TestAutomation #QualityAssurance #TechLeadership

53

15 Comments

The difference between tests absolutely is vibes. Especially when it comes to things that aren't traditionally "software", like infrastructure. The entire difference between unit, integration, and end to end becomes mostly meaningless By the way: test your infrastructure. It's hard and it sucks, but it's also super important. That said, unit tests for infrastructure are basically end to end tests for anything else. It's fine, lean into it and don't worry too hard about semantics. (but it does mean test driven development probably isn't happening the traditional way. Waiting 20 minutes to launch a fleet of infrastructure in the cloud is absolutely a unit test but it's not a thing you're gonna do hundreds of times a day and expect to get work done, much less in a "run the tests on save" style of work)

25

I see we've hit the top of "Selenium and WedDriver are crap and you're awful if you still use it" cycle again... and I despair. Either people are saying these things to get clicks since social algorithms promote controversy or they don't understand how these tools or browsers work. And I can't tell the difference. What I think people should be doing is looking at how they test their software. * Should we do everything in E2E tests? God no.... * Should we do everything in Unit Tests or Integration tests? God no... but there should be more E2E tests I can guarantee if you were to rewrite your test suite from scratch from Selenium to Selenium since your flakiness is nothing to do with the framework. It has more to do with your thinking through of how to test. I wrote about this before... Next time you see some putting hate on ANY framework ignore them, don't engage. They're showing they're other "karma" fishing or don't know the space. A rising tide lifts all ships... If you want to go fast, go alone, if you want to go far go together. https://lnkd.in/e4HYxZNy

83

16 Comments

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

Seeing a lot of discussions around Shift Left testing lately, and it seems like there's a bit of confusion. Shift Left is fundamentally an approach to development, NOT a standalone test strategy. Yes, shifting testing to earlier stages of development is part of Shift Left, but we must not lose sight of the bigger picture. Over-relying on Shift Left can narrow our focus to mainly functional testing, often leaving out crucial aspects like performance, security, and accessibility. These non-functional requirements, if not addressed early, become costly and complex to fix later on. Additionally, putting too much emphasis on Shift Left can sometimes reduce collaboration between development and testing teams. Developers might not always grasp the depth of effective testing, and testers might feel their expertise is underutilized, impacting overall software quality. Instead, embracing Continuous Testing offers a more holistic approach. It promotes testing throughout the entire development lifecycle and encourages ongoing collaboration among developers, testers, and other stakeholders. This ensures a comprehensive understanding and improvement of software quality over time. Let's focus on continuous learning and improvement, integrating a wide range of testing activities to truly enhance software quality. Remember, it's not about just shifting testing left; it's about continuous, collaborative testing throughout the development process. #softwaretesting #shiftleft #continuoustesting #softwaredevelopment #collaboration #testautomation #brijeshsays

72

16 Comments

Use Cases are a great tool for capturing requirements that a lot of newer arrivals into the software development field aren't familiar with. They only know User Stories from Scrum. The following book is a great intro to Use Cases for those who aren't familiar with them: https://a.co/d/5VQt5vS I've used Use Cases to establish consensus across a wide variety of stakeholders so they are excellent for requirements traceability. Well-written Use Cases also convert cleanly into high quality, high level software designs. I can easily auto-generate automated test cases (eg React Testing Library) with ChatGPT by using Use Case documents as inputs. I would love to hear opinions from any TDD fans here who might *disagree* with this approach. And if so then why? Or do even TDD purists give the nod to this streamlined approach which provides exceptional end-to-end traceability - given the latest advancements in AI? Alistair Cockburn Kent Beck #TestDrivenDevelopment #TDD #UseCases #AutomatedTesting

1

Please seriously consider learning how to practice TDD properly. That way, if anything doesn't work as intended, the failed tests will tell you exactly what went wrong. Tests are our best debugging buddy.

5

3 Comments

Here's a thought inspired by my friend Krystian Kubowicz. He wrote a post recently about performing tests and I started thinking more about it. The space in the comments box was too tight so I thought about writing a post “You don’t write a test; you design it.” We often talk about “writing tests,” but what if that’s framing testing all wrong? Testing is about performing experiments— crafted to reveal the current state of a product within a specific context. And you don’t write an experiment; you design it. So why do we say we “write tests”? At its core, testing is investigative. It’s about posing questions, setting up conditions, and observing outcomes. Like any experiment, a well-designed test doesn’t just verify—it discovers, informs, and challenges assumptions. Some might call this a matter of semantics or a linguistic issue, but it’s more than that—it’s a shift in mindset and purpose. When we say “writing a test,” we risk reducing testing to documentation or a checklist. By calling it “designing a test,” we elevate testing as an intellectual, exploratory pursuit that brings value by uncovering insights about the product’s resilience and behavior. It’s the difference between: - Following steps versus crafting a hypothesis - Executing tasks versus creating conditions to explore unknowns - Checking a box versus analyzing outcomes and challenging assumptions Testing, then, becomes a design-driven, experimental practice that brings clarity, perspective, and insight to everyone committed to quality. Testing isn’t a checklist. It’s an experiment with purpose. What do you think? #softwaretesting #softwareengineering #testdesign #brijeshsays

26

6 Comments

Playwright's new --only-changed CLI option has already been a huge time savor for our team. I can't stress enough how much I think it should be a part of your maintenance workflow. Run only tests with uncommitted changes: npx playwright test --only-changed Run tests changed relative to a specific branch: npx playwright test --only-changed=main The ability to update a Locator in a class file and then run only the associated tests is amazing. It streamlines our workflow, reduces unnecessary test runs, and allows for faster iterations. This feature is particularly useful in large projects where running the entire test suite can be time-consuming. Now, we can focus on the impacted areas, making our testing process more efficient and targeted. #Playwright #TestAutomation #QA #SoftwareTesting #DeveloperProductivity

302

27 Comments

Not sure why the Vue community was and (pretty much) is, scared of the composition API. I was too, to be honest. But I have loved it for the past few weeks as I use it more and more. If you are still hanging in limbo, there is a great series on Laracasts by the great Jeffery Way, himself. There are also a couple of free courses on Vue School for Vue3 composition API. You should be up and running in 2-3 days if you have used Vue 2 in the past. #vue #vue3 #compositionapi

25

8 Comments

15 years ago I contributed 2 chapters to Clean Code(https://a.co/d/5guLEzq), both related to threading. A second edition is coming out, and it occurs to me that while I don't do much direct threaded/parallel programming anymore, many issues around parallel execution still occur in systems where the stack "takes care" of all those details. Here's a collection of recent examples. This is a draft of a personal blog. The second version will go on the Industrial Logic, Inc. website. The final version will likely be added as an update for the 2nd Edition of Clean Code. Comments welcome, enjoy! https://lnkd.in/gWCUkK6V

9

Are you making the most out of online communities for automation testing? 🤔 In this TestGuild's Automation Podcast episode, I chat with Mike Verinder, a community leader for testing tools like Playwright and Selenium, about how engaging with these groups can boost your knowledge and job prospects.   Mike shares the behind-the-scenes magic of building vibrant communities and offers tips on how you can leverage them for career growth. From connecting with experts to learning about the latest tools and trends, Mike’s advice is practical and actionable.   Don’t miss out on learning how to make online communities your secret weapon for automation success. 👇👇👇 https://lnkd.in/eqXW5yM7   #techcommunities #onlinecommunities #testingcommunities #onlinecommunitiesfortesters #LinkedInGroups #testguildpodcast

22

3 Comments

This article is consistently one of our top performers. Lately, I've been thinking about giving it a new spin and diving deeper into some of the concepts it covers. For anyone working in UX/UI automation, seeing web pages as a series of grids with unique elements is incredibly beneficial. These unique elements can be referenced within parent elements for non-unique ones, which can make your automation tasks much more efficient. It might sound a bit tricky, but once you get the hang of it, you'll find it makes your work a lot easier. You'll encounter this almost daily in automation, so understanding this concept can really give you an edge. I'm considering expanding on this topic and would love to know if you think it would be helpful. Drop a comment if you're interested, or if you have any questions about it. Your feedback is always appreciated! In the meantime, feel free to check out the article if you haven't already. It's packed with useful insights and tips that I think you'll find valuable. Looking forward to your thoughts! #Automation #AutomationEngineer #Playwright

13

The danger is major functionality gaps. Legacy is so cockamamy that it's nearly, if not absolutely, impossible to test the legacy and "rewrite" for behavioral equivalence. It's not that you mustn't replace. It's that you must learn, innovate on, and outdo the legacy to replace. That's not a rewrite.

60

3 Comments

For any KDP Select authors out there, I just published a blog post about setting up a book promotion. It's also the last day to get the Agile Discovery & Delivery eBook for $1! :) Book: https://a.co/d/0czdZYa Blog Post: https://lnkd.in/g9eUTTCd #kdpselect #bookpromotions #agile

8