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 help

Thanks Giving 2018

http://thriveology.com/wp-content/uploads/2017/11/ThankfulGrateful.jpg It is that season for we Americans: a time to look back at the past year, and count our blessings.  Thanksgiving has come to mean different things then while I was growing up - the focus is no longer on what has gone right, but what wrongs were (and, in some cases continue to be) done. I try and focus on what I can do to minimize the wrong, and accept that the past has happened. And then the fun begins - finding all the things to be thankful for! Things have been rocky, at points this year, I'm still unemployed for money, and have had some serious personal issues arise and be dealt with. But, all in all, I think the bad is outweighed by the good.  This has been a year of changes: not only have I given up on trying to go back to the way things used to be, I have moved forward - supported, encouraged, and occasionally pulled - into a future that I just now am starting to feel I deserve. I still am

Where Is It? Part 1 - Inputs

Photo by Pixabay from Pexels     I am job-searching, and running into some coding challenges. Most of them are simple - some seem to want one-line solutions that require two cups of coffee and a half-hour to figure out what they want. Others are far above where my skills lie, and these I give a try for, and learn. And then there are the ones that offer, seemingly randomly, a challenge - within my skills (or at least my research skills) - that could be used as part of a larger project that I want to work on. This was the case last week, when I tried for a position that was a bit above what I felt I could do comfortably. The challenge was to let someone enter items, and then give back their location. In a language I am just familiar enough to be a danger to myself in. Happily, and thinking forward about how I could use this as a part of a larger program that would  use something like this to interact with the user. And also, this is command line, and thinking of how to set this up to