Matt Heusser

Imagine having a co-pilot in your testing process that ensures efficiency and comprehensiveness. Spec2test, as discussed by Scott Aziz and John Ferguson Smart on TestGuild, offers just that.   It's not only about improving your user stories but also about automatically generating test cases that cover all bases—from functionality to security. This tool exemplifies how AI can act as both a guide and a guard in the software testing landscape.   Learn how to make AI work for you, elevating your testing strategy to new heights. Catch the full episode now! 👇👇👇 https://lnkd.in/ejHm25ui   #BDD #behaviordrivendevelopment #ai #aiintesting #Aidriventool #Spec2Test #softwaretesting #userstoryoptimization #testgeneration #InnovationInTesting #AIDrivenSuccess #testautomation #automationtesting #testguildpodcast

37

1 Comment

In this video I propose the idea that developers are essentially people pleasers who want to be loved and praised while QAs are essentially sadists who want to prove that you're not as smart as you think you are. Am I wrong? Watch this video and let's see!

10

Ugh, I keep hearing this thing lately... that there aren't enough great testers out there compared to developers. It bugs me so much, I finally asked why. The answer? Basically, "They miss too many bugs! Devs seem to have a better vision for the product." That felt way off, but it also got me thinking: is there any truth to it, and if so, how do we fix it? Here's the thing: I think we all need to take a good look at ourselves (and I mean that in the nicest way!). How can we change this perception? Let's ask ourselves some tough questions: - Do I truly get what this product is all about? - Am I on the same page as the people who will use it? - Can I spot potential problems before they become disasters? - Am I stuck in a testing bubble, doing the same old thing? - Have I learned any new tricks lately, whether it's a cool tool, a different coding language, or a fresh way to design tests? - Do I work well with others on the team? - Am I always pushing myself to be better? If any of those answers are "No," then it's time to roll up our sleeves and turn those "no's" into "yesses!" Feeling stuck? We gotta find a way out of that rut. Let's take pride in being testers! #testing #Introspection #brijeshsays

36

8 Comments

James Grenning course is top notch - well explained, easy to follow, and appropriately deep.

3

The article discusses various strategies for preventing users from making mistakes or taking dangerous actions in user interfaces. It covers different methods such as modal dialogs, two-factor authorization confirmation, delaying actions, the undo option, and inline guards. The article also discusses the concept of a "danger zone" for grouping critical actions, as well as the idea of second-person confirmation, where an approver is involved in the process. Read it at https://lnkd.in/gq6GEw2D

2

I’m happy to release a conversation I had last winter with Nathan Smalley, former CTO of Radiance Holdings and current CTO at IEQmax. Nathan highlights the various career paths within QA and discusses the implementation of continuous integration and deployment (CI/CD) in development environments. He points out the dangers of a one-size-fits-all approach and stresses the significance of understanding each role's pathway to success. This conversation is a great resource for anyone looking to deepen their understanding of QA’s impact on long-term organizational success and the nuances of technological advancement. It’s been a while since I’ve released consistent new content, but re-watching old conversations with industry leaders like Nathan has reignited my passion for these in-depth discussions. I’m looking forward to bringing more quality conversations your way. Check out the full video here: https://lnkd.in/gZVyp7BE If you’re interested in QA, leadership, or software development, let’s connect! #QualityAssurance #Leadership #SoftwareDevelopment #ContinuousDelivery #TechTalks

20

Recently, during a discussion with a prospective client about software specifications, a common question came up: "Could you share a template for drafting the specifications?" While templates are widely available online (and via chatgpt) and can be helpful, but in my experience I’ve found the moment you start working with a template, your focus turns to the syntax of the template rather than the actual semantics of the process – which becomes very counter-productive. To avoid this trap, I tend follow a more pragmatic approach for documenting critical processes which are going to be affected by software being developed. Here’s a list of elements to be captured for processes: - **Overview:** Begin with a brief summary of the process. - **Workflow Diagram:** Develop a clear, detailed diagram, ensuring it's understandable by breaking down complex parts if needed. It should mostly fit into 1 A4 paper to ensure that its useful and easier to comprehend. If it’s going beyond that, break it down into sub-processes and further diagrams.  - **Notes/Steps:** Incorporate fluid notes or steps covering essential actions, combining system names and process elements. - **Exceptions:** Record potential exceptions to anticipate unforeseen scenarios. - **Systems & Teams:** List the involved systems and teams to clarify responsibilities. I invite you to share your thoughts on this approach or engage in further discussions. Feel free to comment below or reach out directly! #ProcessDocumentation #SoftwareDevelopment #BusinessProcess #ProjectManagement

30

4 Comments

Testing software is quite a bit more than seeing if it can do something right. Testing is about trying "everything". Most importantly values that are on the edges and especially values outside valid ranges. https://xkcd.com/2928/

11

James Causey Guilherme de Paula There are really a few issues with the current pumps and making the cell phone into the controller introduces another set of issues. I'll try to break them down below (but certain I've missed as many as I've named). . 0] I still hold that almost all pump/sensor instructions are missing a LOT of information, and the general design of the software is for someone who knows what they are doing. How many type 1 people do NO adjustments of their pumps and just have them adjusted at the 3 month medical visit (if they mention to their team that things aren't "perfect"). * WE NEED TO DEVELOP EDUCATIONAL MATERIAL to teach both diabetes care in general as well as pump/sensor optimization. [this is an area I am definitely interested in pursuing, but everyone in the industry seem to be interested in the algorithms and "cuteness" of devices, not education and aid for the actual users! . 1] If the pump is controlled by the phone (as opposed to onboard controls and/or a separate controller) then I not only need to have the phone with me almost all the time AND keep it charged (as well as both the pump and sensor being charged, the phone in "reach" of the device for communication, the device being in reach of the sensor, etc.) BUT I've got to ensure that playing games or engaging in video conference or anything else won't take priority and reduce communication with the pump (especially if the software to control the pump is IN the phone, like the DIY systems and others coming onboard) . 2] There is very little (from a user or even a medical perspective) to differentiate between devices - how do I choose the correct device for THIS patient. Almost all clinics and even major diabetes centers have one or at most two devices they recommend (and a few they won't touch) despite both efficacy of the device and desire of the patient (I know numbers of people pushed to a very wrong choice due to the center they were using being "tied" to a device). . 3] Someone(s) need(s) to do a better job of differentiating devices and indicating who it's really built for, what it requires for maximum efficacy and pluses/minuses to system to make medical/logical evaluation of systems possible. #diabetes #insulinpump #t1d #type1diabetes #t2d #medicaltechnology

3

4 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

A reorganisation won't fix a broken system design. This should be a warning on every book about software team management. https://lnkd.in/g8rqGBAN

127

17 Comments

Planning to write your own technical book? 📚 Learn how we wrote Stratopsheric @stratospheric42 with three authors using @leanpub 🚀 https://lnkd.in/d29Cupii

12

4 Comments

What do you do, if you want to hire an Senior C++ Developer? Do you include a technical test, a trial working day or other IT specialists in the process to ensure they fit the role and skills are at the level needed? And what do you do when hiring a leader? This is a critical decision that can significantly impact your organization's success. How do we ensure our new leader can inspire, guide and elevate their team? Here's are 5 ideas on how to spot the signs early and make informed decisions: ❓Ask behavioural questions: Asking candidates how they have handled situations in the past, might be a good predictor of future behavior, here are some examples: o  “How have you supported the growth and development of your team members in the past?" or o  "Tell me about a difficult decision you made in your previous role. What were your thoughts and your feelings in this situation? What was the outcome? What would you do different the next time?"   🎭 Do a role-Play exercise: Candidates can talk extensively about their experiences but observing their behavior in real-life scenarios is invaluable! Role-playing exercises, such as handling a conflict with an employee, can provide insights into their practical leadership skills. Check on consistency in their answers to the behavioural questions and their behavior in this situation.   💎 Explore their values: Use values cards to let candidates select their top five values. This exercise can speak volumes about their character and alignment with your company’s values. Ask them to sort these values from most to least important, and discuss how they live these values in their leadership role. You might also want to inquire about situations where they found it challenging to uphold their values. This gives insights into their self-awareness.   💭 Challenge your own bias: It's easy to let personal biases influence our judgment, but doing so can lead to poor hiring decisions. Therefore, familiarize yourself with different sorts of bias beforehand, e.g. affinity bias (when we favor someone because they are similar to us or share common interests), confirmation bias (when we seek out information that confirms our preconceptions while ignoring contrary evidence), and halo effect (when one positive trait influences our overall perception of a candidate) to name just three!   👥  Involve the right people in the process: Engage the team and stakeholders who will be working closely with the new leader. Clearly define who holds decision-making power or veto rights. Listen to the feedback from those involved and thus reduce bias and gain a 360 degree view.   Hiring the right leader is not just about filling a position - it's about investing in the future success and well-being of your team and organization. So, the next time you're hiring for a leadership position, reflect: Are you looking BEYOND the resume to truly understand the person who will lead your team?   #LeadershipRecruitment #CompanyCulture #EQLead

16

1 Comment

If celebrating software maintenance is something you want to do, you should check out the Legacy Code Rocks conference MenderCon on May 16th! I’ll be giving the opening keynote: “Community Is Just as Important as Code” Registration link is in the comments.

25

2 Comments

I've been seeing posts lately about Developer value, productivity and refactoring versus "fix the bug and move on with your life." I thought I'd give it a ramble, just for grins. One post illustrated at their shop each dev averages 1.48 releases to production every day. (I don't remember the exact number it was > 1 and a max of like 2.5 but it was an EXACT number, which is impressive). The post was actually about Push and Pray versus Staging. However, what caught my attention was the highlighting of a number of pushes on average versus what did those releases do to A) Increase Revenue, and by how much. B) Increase customer/user happiness and by how much. C) Increase Profits, and by how much. I've always held to the notion that Developer time is gold. Pure gold. Not only do we command relatively large salaries, but opportunity costs are astronomical in some cases. Developer time wasted is too big of a risk. Each task given to a developer should be measured in A, B or C above. If those metrics, revenue, profit and customer satisfaction can't match what one would pay to have the ticket completed, then you should enter tickets that DO. And focus on tasks that will exceed in value what you pay in development costs. Not only is that sustainable business but it is also better for Developer morale, happiness and productivity. We love to hear about how we helped the business, in those terms (A, B, C). Not so much we completed X amount of busy work last quarter. Another sort of theme I've seen by the magic of social media feed AI is the age old debate of refactoring versus patching. I wanted to write down some stuff about that versus A, B and C above. I think if your codebase has significant design flaws that are affecting those it should be evaluated as a ticket. Negative impacts can be accounted in the same way. Prohibiting growth can also be accounted against development costs. Most of the time if it's not broken, we don't fix it. And SHOULDN'T fix it, because revenue, profit and customer satisfaction are not impacted at all. But sometimes those issues DO affect those things significantly. My recent case is I have a code base I wrote completely myself, years ago, and it was fairly unfinished. It involved a manual 30–60-minute process of collecting data, sorting data, massaging data, pasting data, 3x each, etc. Not a huge deal, easily automated yet if you have to do that once or twice per quarter, you can't justify hiring a dev to automate it. Until you forget to do it. And the "business" loses money. It wasn't broken, I didn't fix it. Because fixing it meant refactoring the entire data model, switching the entire data source, introducing a 3rd party tool (which actually became 2 3rd party tools) and all the joy that comes with that sort of thing. Until the "business" lost enough money to where the 12-18 story points required to complete that work got backlogged and the "dev team" picked it up. Dev Time is gold. Use it wisely.

2

Many non-technical people involved in product development and close to the technical teams are unaware that all developers are not created equal. In addition to the obvious skills differences that occur there are different developer archetypes. You need to ensure when creating a team that you have the right mix of archetypes for the team to be successful. It’s yet another challenge when creating high-performance teams. Some companies, such as Facebook, do this formally. Many companies do it informally, and then some don’t do it at all (much to their detriment).

9

One of the hard things about Agile Software Development is letting go of the idea of irreducible complexity in solutions. This is a conversation I have often with teams who cling on to the idea that "Well, obviously we need to build registration first. Can't go live without that." Can't you? I have. I've launched apps where, for the first release, users emailed us and asked for an account, which we set up for them with a little bit of SQL. I know, right? Gasp! "Obviously, for our job search engine, we'll need a way to enter job specs." Do you? The first version of totaljobs went live with jobs being manually entered by our own team. There is almost always - in fact, IME so far, *always* - something simpler we can do that will move us forward. Yesterday, I illustrated this with a training group by spit-balling how I might iterate an automated solution for managing attendees at my workshops. The primary goal would be for joining instructions to be sent to all attendees automatically. So, of course, attendees will need a way to register through my site, right? But maybe for Iteration #1, the client just sends me a list of names with email addresses, and I do a BCC to them all? That would *work*. Clunky? Sure. So maybe for Iteration #2, they can provide that info themselves through the site? That would still *work*, and it's a step forward. And perhaps in Iteration #3, the email is generated and sent automatically using a simple template? So now I can just click a button and it just happens. That would still *work*. Maybe for Iteration #4, have specific email templates for different workshops (e.g., one for TDD in Java, one for TDD in Python etc)? Now my design will need to know which workshop they're registering for. And that would still *work*. Maybe for iteration #5, use the Zoom API to automatically schedule a new meeting for each workshop and insert the meeting URL into the emails? And that would still *work*. And of course, with each iteration, there'll be feedback. So it could go in quite a different direction based on that. But I would start from a 100% manual process that *works*, and rapidly iterate towards something highly automated, making sure with each iteration that we still get the right joining instructions for the right workshops being sent to the right people. (i.e., it *works*) - evolving from manual, to hard-coded, to dynamic as new scenarios come into focus. Fake It 'Til You Make It. And you might say: "But Jason, we can't go live to millions of users with the software equivalent of cardboard cutouts!" Then don't. Go live to 10 tame users. Buy them a really nice lunch. Give them some freebies. Blow smoke up their you-know-whats. As the solution evolves, there'll come a point when what you've got is no longer a Minimum Viable Product, but a Minimal Launchable Product (MLP). Or you may be barking up entirely the wrong tree. But at least you didn't build a whole house just to find you only needed a shed.

56

5 Comments