Skip to main content

Looking forward

https://blog.internetcreations.com

I recently attended the Online Test Conference, and enjoyed not only the first professional-level conference I ever attended , but most of the sessions were informative and enjoyable, even if slightly over my head, being new to this world.

A few of the talks were on what to expect in the future. These, of course, I anxiously awaited - what better way to make sure I have a position, than to make sure I have value going forward. There were many things to learn, and a lightning talk at the end provided more insight.

But they missed some things, as all seers do.

Thinking things over after the excitement of finding a place where I fit in, I ended up talking to a mentor, and finally figuring out some of what I felt was missed.

The developer world is entering a mode that will help maybe balance out the the congestion of larger cities: remote work. This is an exciting, innovative time, where the choices and challenges are thrown into the spotlight. And testers have a new place that they can insert themselves into the normal workflow.

However, it means that "asking to be walked through the code", or "pairing with the other sections of the team" isn't as easy as finding the correct office or sending an internal note any more. Even in the same building, these have been issues; they are going to have to be in our thoughts when presenting results, getting feedback, and encouraging quality.

My original plan for the company I joined is having to change: I am still going to ask if I can have a meal or a drink (coffee or tea, for me, please) with people in each department. But I have to now presume that that may involve me speaking to them through the computer, and might be at awkward times. But having the social contact with the members of the development group still will pay off in the long run. I can listen to the challenges and triumphs of what they are doing, and gain a bit of insight on them. And my goal is to leave an impression that I am someone they would want to work with, and float ideas to.

Remote work is just one of the things that has to be thought about and ideas considered to go forward. Some other areas that were skimmed, but to me look important:


  • Code sharing tools - is the security on these at the level where NDAs and business confidence seems to hope they are?
  • The now-larger awareness of the impact on the resources and health of the devices is changing how our products are being used currently, and this will likely change even more as new markets open, and old markets are forced to change to compete.
  • Changes in regulation, and in the demographics of users - where both ends of the age spectrum are using the things we build more.
  • Work flow is shifting to what should be a more constant stream of feedback: how is this going to affect the traditional manual and automated tests that we need for quality?
  • Following on that, the devices we use are now spanning several incarnations - which adds to the burden of quality parity for all the potential ways to access what we build.

Is future-proofing what we build and learn today a possibility?


Yes, it can be. But this is a time where the theory some businesses have been working under is going to start showing signs of stress - as a team dedicated to ensuring our customers get the highest quality product, we need to be able to shift our focus going into the next phases along with the rest of the teams.

As always, the talent to unlearn and relearn is a major section of the life in software. The amount we have to learn and know makes this the best time to be in the business - and can help us move our customers and our products to a level that makes it less of a task to meet the next big change.

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:...