Skip to main content

Tangents and rants




Anyone else feel like planning out a release is a series of tangents and rants? The goal of allowing our customers a good, usable, and delightful way to empower their world seems to be overwhelmed in the rush to be first, and unique, and the fastest changes. Which may not be what our customers want, or at least a significant subsection of them. In an attempt to be the first to showcase the newest, we may leave our customers in a fog, unsure of where they are at, or how to get where they are going.

Making plans for testing and goal-focused development seems to have been forgotten, or overlooked in the rush to get the next release out. Having the ability to insure that the potential risks are focused on, rather than the tangent of "But we need to do this- we'll fix it later" or, worse "This shouldn't affect anything else", are the hints that we need, as an organization, to step back and look at where we are headed. And make sure that our plans for getting there have an awareness of the risk. Many companies who try and be the first to market with ideas then feel obligated to stay first - even if a longer time frame is sensible, and can allow a better experience. Some of what is rushed into releases has no noticeable effect on me, as a consumer. So time spent insuring that there are no unexpected side effects is more value to me.

Forgetting how your product is going to be used in real life is something that subsections of your teams will rant about: you may hear that they would not use it that way- or that it shouldn't be used that way - in contrast to the sections that state that no human in a situation where they would need this would use it in this manner.  My personal peeve for this is driving directions - at 60 mph (95 kph), telling me I need a lane change around a minute before a turn is needed is both frustrating and dangerous in a new city.

There have been several comments recently in my world: those who feel that the testing they are advocating for is being pushed aside in the thought that "this isn't needed" or "it would take too much time!" Which, as professionals, we know both aren't entirely true: it may not be needed, but would be necessary. if you are lacking a strong relationship with all the team members - or have a person that is willing to listen to your concerns - anyone with a doubt about why and how this change is supposed to help may end up feeling pushed aside - if something breaks, a not-so-silent statement of blame, or a rant, is likely forthcoming, and could have been avoided.  Another case of "We don't have resources to do it correctly, but we have them to do it twice (author unknown)" rules supreme.

In addition, in the rush to get a product out, with the newest features isn't allowing time for knowledge transfer - a new person, coming in at the start of a plan, or even and Aglie sprint, reels away from the workplace, overwhelmed by the amount they don't know, and no one has taken the time to explain -in many cases, this continues for an extended period of time, and is never truly filled in. I have listened, with silent horror, to people who have worked at a place for years, and still have the questions they asked about the product in their first weeks remain unanswered.

I am hoping that the business mindset shifts from the outlook of the ability to release multiple times a day means we must, into a more-confident mode of releases come when they are the best possible changes, and the entire team is comfortable. Listening to concerns may prevent the company from being the next disaster headline.

Popular posts from this blog

30 Days of Postman - for Testers!

  https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels   Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that ...

Drop-down values for injection

cover_image: https://www.pexels.com/photo/flat-lay-photography-of-gold-iphone-on-opened-notebook-beside-pen-583847/ canonical_url:  --- Photo by Jessica Lewis 🦋 thepaintedsquare   Learning in public is grand, and when you have a team that is willing to help with something that seems simple, but you fall into overthink for the wrong items, it can really help to type out your thoughts, actions, and what the program does to frustrate you. And in this case, getting a value I could see in the debugger was the issue The automation needs to check for page elements – and the drop-down selector triggers potentially different elements. Plus, depending on the user logged in, there may well be different options available in that drop-down. Then, I can get the options available for the user on the drop down, get their values, cycle through them, and verify each set of elements on the page. My test account for this has four options on the drop-down, so I budgeted a couple of hours to get ...

Redefining my Role

Confession: I am a nice person. I'm the one that will check on people - and be concerned if someone is acting off. Or donate money to make sure the potluck I can't attend has everything it needs. This has had an effect on my career: I was less willing to point out 'in public' errors in the code or things that just felt off to me while testing. And this stopped me from being the best tester I could be. Trying to be kind to someone that was having a rough patch, or simply not wanting to expose them to a potential attack was both me trying to get things correct, but care for them. I've decided to embrace this aspect of myself, and shift my focus. Being 'nice' to the product, or company must include being the voice for both end users and the team. Finding things that will be difficult for them, confusing, or flat-out wrong is a major part of my job. And this was also one reason I don't 'delight', at first, when something doesn't work as expected:...