DEV Community: Arlene Andrews

Redefining my Role

Arlene Andrews — Tue, 30 Jul 2024 17:19:00 +0000

[ "Photo by Pixabay: https://www.pexels.com/photo/pile-of-covered-books-159751/"]

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: I'm standing in for them, so confusion or anger (and on the better days, delight that something works, and gives me a better-than-expected experience) is the first reaction - and sometimes the second, too. I have high standards, and want them met with minimal fuss.

This has also added 'more work' for me: I'm communicating these expectations in planning documents, test plans, and in and on the tests themselves. This was a shift for me - there are times that these documents are not wanted up front, but are needed later. Having them out, where they can be discussed, looked at, and added to is a help to be certain that work is done correctly, and small things don't get missed.

My users are the focus - even if they aren't human. And that, by itself, requires a different outlook on testing. I'm happy I can still test, find the things that are not clear and usable, and advocate for them to be changed, updated, or removed.

My next challenge in this area is to remember that it isn't my role to make that final decision: I will point out, offer examples, and document the risk that I see. The decision of what to do with that information isn't my role - but I'm going to be nice, and make sure you have that information and a record of where it was found.

Drop-down values for injection

Arlene Andrews — Wed, 05 Jun 2024 18:52:00 +0000

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 each step done. Getting the contract was somewhat easy: the drop-down is a select element, so QuerySelectorAllAsync() with option as the items I wanted to get was only slightly frustrating. I think this is my first time working with IElementHandles, but if they are all this easy, then I’m good! I had hard-coded a specific option for a previous test, so I knew the information I needed. And to make sure, I checked with that hard-coded information – and yes, this works!

Well, I THOUGHT I was good – to make sure I had the correct information (we had just updated the certificate, so there was a better option for connecting to the environment) I added extra items to the drop-down for the test account. Being newer to C Sharp, I didn’t know what effect the change would have, but wanted to make very sure that the information I had returned was correct! It turned out that one of the changes updated the SqlConnectionString I’m using: I was pulling from the wrong environment! One of the developers kindly took the time to look at my code, and to verify that it was correct. We kept looking, and they checked the connection string. That turned out to be the issue, and thankfully, it was a simple correction I could do without having to ask for assistance. I did ask, then figured it out while waiting for the meeting to start.

Step 1 is done: I can access the correct data. Getting the user information was a more-familiar process for me. This is a “match the email to the user ID” call and assign it to a variable. I’m doing these tests in small steps, and this will be used many times. I decided to keep the code a bit cleaner. There are going to be several methods that access user-specific information, so they are going to be tucked away in their own class. It will make future code-reading easier, and hopefully more organized.

I now know my user’s id, and the drop-down options that are available. It’s time for the one I’m hoping will be easy: cycling through the options. I knew a foreach loop was a decent choice for now. It may not be the correct choice longer-term, but I’m approaching this with the “Make it work, then make it pretty” attitude. And the system complained at me. It wanted to know what would happen if the selectors were null. And this was a reasonable thing, but I wanted to complete the task! So off to a rabbit hole of “how to do a null check”. This turned out to be a simple one-line update that would use the data and to use a hard-coded value that was a default option if there happened to be no data (and an urgent log message to be sent!).

Some research, and it seems that EvaluateAsync(value => value.textContent should give me the information I need! And it didn’t. Running it with the debugger (and a break point on the next line) shows that it gives me the text shown in the drop-down, but not the value. Looking at what’s evaluated shows that it’s doing what I asked. Now to figure out how to get it to do what I want! I can see the value in the debugger, under preview – now how to get it?

Some research into JSHandle@ showed me yet another area I need to focus on for skilling up. And several other attempts to get the correct information. It’s been a generous 45 minutes: it’s time to ask for help, again. A different one of the developers has a few moments, and I see the typing indicator. It’s almost at the point that I worry.

It seems that a lambda is used to be able to input more-complex functions – something that one of the team was not familiar with. But, as I suspected, I was using the wrong value types to get the correct answer. A quick change to select => select.value got me the information I needed!

Now to get the rest of the section to accept this information. The original hard-coded statement had that value, including the semicolon, in the statement. Using it as a variable, the system is complaining about the semicolon. I’m going to try and use Regex to get the value before the semicolon, and input that. But first, I think another cup of coffee is called for.

I’m not happy with how I’m coding this, and the coffee helped. I have two lambdas being passed, so I’m going to try and combine them, and see it things will work. And so far, it looks promising. And it worked! Other than my foreach loop, but that’s a problem for another session.

Compare HTML in Playwright .NET

Arlene Andrews — Tue, 14 May 2024 16:27:00 +0000

Photo by Miguel Á. Padriñán from Pexels

Automating checking text (and its HTML) can be a challenge if you aren't comfortable with the language and framework you are using. Having a limited time for learning and exploring is its own challenge. One of my tasks for automating a smoke test for our project was to verify the text in each environment, with each specific set-up having its own welcoming message. And, I admit, I wasn't quite sure where to start. I knew what I needed, and found out where to fetch it. But getting all the parts together was not as simple as it looked.

I started off with needing to get database access. And then work with our setup to make sure that I could use application settings (that tells the framework where to find information and works with the configuration settings to keep information private) to connect with the database during a run. I could then put pieces together, and get the information from the database, and compare it with the displayed information for testing.

Manually, it was simple - I should have guessed that this means it wasn't going to be quite as easy as I'd hoped. Looking at the HTML, and verifying that things were in the proper layout was simple. I understand enough of the simple HTML layout that this was a quick check to make sure that the words were correct and go on. I had made this smoke test with many pauses for manual verification for a reason. Between this and the list of things I needed to check, I was going to be encouraged to learn, explore, and ask for help to make this automation successful, and apply it in the other tests.

Once database access (and the proper connection string!) was created, I was able to set the text of the pages as a variable. This was the easy part: I knew what I was doing here and felt accomplished in getting it done. I ran the Playwright test, with an Expect that the text on the page would match word-wise, but not the HTML components. And I was correct - the proper words were there, but the test failed with the HTML added in.

Research time! The first attempt was with using Page.ContentAsync(), which is the command to get the full HTML of the page, including the headers. This should allow me to search it, and find the sub-string of the text, correct? As a first idea, it wasn’t too horrid – I had the HTML I was looking for saved, and all I needed to do was walk the whole document contents to locate it. Not efficient, and certainly not good practice! It should get me the result I needed and could then be iterated on.

It did not. Finding a sub-string in the entire page was not quickly possible, and I wanted my automation to be fast. After a few dozen attempts to get this to work as I wanted it to and keeping in mind the business’ rule (if you can’t solve it in 45 minutes of effort, it’s time to ask someone else), I made a meeting with one of the developers. I know they are busy and creating a very-needed update: the meeting went out with a “we can reschedule if needed” note attached.

While waiting for the meeting, I continued to fuss with it: one of the challenges in getting the area narrowed down was the class of the div – it was not named well, and with Bootstrap, the potential for duplicate divs with the same name had run me into problems on other pages. Talking to someone who had been here much longer than I had, I found out this was ALWAYS the third div on the page.

Now I had a new plan to find it – use the Nth() locator, and find correct div. I’d love to solve this, write the post I am now typing up, and be on to the next issue before the meeting. As many of you may know and/or suspect, this is a good trigger for something urgent to come up, and it did. The plans got copied from page to page in the organizer for several days, until it was time for us to pair develop.

Working with this developer is always a treat: we have much in common and respect for each other. As a bonus, they are good at teaching! After a quick review of what the goal was, we went over the attempts I had made to solve this. I’d left the last one, with the errors in the IDE, in hopes that would be helpful. And now to make progress!

Using the debugger, we verified that the HTML was being pulled in correctly. This was one area I had not checked completely – and it thankfully was correct. We agreed that the div name was not very useful – the work they had done recently had created other div with this same name, but on a different page. That was noted but tabled until I got to that point in the test.

The skills in NUnit they have was needed – the easier way to verify this section was to use the AreEqual command. This allowed the test to check the strings were equal. Playwright was being stubborn. It wanted locators rather than strings – or the other way around – that were simply taking too much time to craft. And I was happy to learn this technique – I can see it being useful in the future!

After a few attempts to get Nth() to work, we resorted to using that odd div class – after making sure it was only used this one time on the page. That gave us a starting point – now to figure out how to get the HTML in there (thankfully, this was the only thing in that specific div). A few more false starts, and me finally giving up on the idea that ContentAsync() for that div was not going to work, lead them to the solution that I had tried and discarded.

InnerHtmlAsync() gave us the exact contents of the div! Spaces and all. And that was the next stumbling block – and we were out of time for the meeting. They were willing to give me a few more minutes, thankfully, mostly because this was an issue that they had solved before. Just needed the syntax to remove the spaces: Replace(" ", "") if you were curious. And that let the test run, until the next PauseAsync() I’d added for manual verification stopped it for a moment.

They went off to lunch, and I spent the next block of time getting notes ready. I had other things to find – and now more of a clue how to go about it.

Bitten By Async

Arlene Andrews — Mon, 11 Dec 2023 22:37:00 +0000

(Thank you to the skilled James Jordan for the cover image - https://www.flickr.com/photos/jamesjordan)

I am working on earning my SDET title - and have made some progress. I'm slowly catching up on the manual tests that we need and starting some automation. One thing that is slowing me down is there are no records of requirements for many of the features of the application, so I'm diving into legacy code, teasing out what should happen "if". Some of them are obvious - if you try and log in with a correct account, you should be given access at that level. But very few are this simple, and planning for tests and time with people who have helped the system grow into the way it is has been a challenge all by itself.

The first automation I wrote checks the log in page - a simple task. There had been recent changes, but the tests have finally been code-reviewed to be placed into the pipeline. Still reeling from this, I started the next series of tests. These were more challenging: the page that any user would open after logging in. I have been discovering Playwright, and teaching myself the C# that we use at work, so I was far from an expert at any of this. Following our plan to make sure that the items that have been reported are considered for automation, I located a simple thing to add for check - a link could open from that page. I wanted this test to work, even if I had set this as a manual check temporarily. And running the tests in debug mode made it easier to see any errors. I know pipelines for CI/CD can be finicky, and I didn't want any of my tests to cause problems.

I verified that the link would open correctly while doing a morning smoke test, and it did. The creation of this test was simple for most of it. I assumed that the link would simply open as it did when working in the usual environments, even with the Incognito browser that the test runner would use. Copying some of the test code from other tests in this series made sure the test would work for the basics, and just add this one small thing. With high hopes, I ran this single test of the series in headed mode, to make sure everything worked as it should. And the first run did something unexpected!

The browser happily opened and did all the things I needed it to do to get to the link I had to verify. Clicking the link brought up a surprise - a time out which I had not anticipated. Which meant figuring out what the code needed. Digging out my tester toolbox, I set to work.

Incognito browser, check. Successfully figuring out my password before I locked myself out of the system, check. Opening the page and clicking on the link, check.

A new tab opened - and a log in to a larger system was presented. I mentally reversed this: I should have suspected that this would happen -- the link lead to a site I use often, and it has a "remember to close all browser windows!" note once you log off. There was the problem - no, two or more, tackle one thing at a time. Getting Playwright to open a new page should be simple, I'd seen it in the documentation. Or I could use the tools that were there and try it with CodeGen - and get the correct answers to several of the issues at once.

A few minutes with CodeGen got me the basic things I needed (I certainly would not have considered the new tab a "popup")! I still had to enter my information and had links that I suspected would not repeat - but I had a lot more than I did. To make sure I had everything in the test, I copied and pasted it in - long links and all - then saved the file and committed the test to Git.

Enough for one day - I remembered to leave on a high note.

Back to it, after a morning of manual tests. I added the needed information to log in into the appSettings file (knowing that this would be replaced later with environment-specific information by the pipeline) and spent some time catching the specific pages that would load. This was just a matter of sitting down and finding the locators that would appear, and the need to add a wait to let the window fully load after the button was clicked. The first one was a slog to get it to finish waiting. For the next two I was able to mostly copy the line to repeat the wait time. Then the locator was visible, and the URL of the final page confirmed.

And then another error while running this in debug mode - some of you may suspect what it was. I had the system log off. The closing on the second page, however, caused an error.

System.ObjectDisposedException: Cannot access a disposed object.

Now what? The context was right in front of me - why did Playwright think that it had been disposed?

At work, we have a rule that you can work if you are stuck for 45 minutes, then you need to ask for help. I admit, I don't always follow this - I spent too much time needing to research why something was written in the documentation, and what was presumed to be known before starting for it to be of much use. After several tries and an upcoming meeting with Our Database Wizard - many other skills in his tools make him a popular target for asking questions. But since we were meeting anyways, I mentioned that I was having an issue, and he kindly agreed to look.

Once we got the documentation figured out - the original purpose of the meeting, I brought up the IDE with the Playwright code on it and prepared to move the text as needed for him. After a few seconds of reading, I heard a happy "Oh!" from him. Playwright is written in async code - I knew this. I did not, however, realize that the window for logging into the larger system had already shut, behind the scenes. A few moments of explanation, commenting out the single line where that secondary page was going to be closed, and the test worked correctly. And it was a decent test, he agreed: this link had not worked at points in the past, so it did need a test for it.

I learned a lot, and now plan some extra time to research what async code might do in the situation I'm going to be testing. I felt silly for not catching that myself. But one does need to learn, and having someone that will look at the code before it's ready is sometimes the best way to learn, as well as make the changes that are needed.

Thankfulness 2022

Arlene Andrews — Thu, 01 Dec 2022 22:41:44 +0000

I've been quiet here - my life has taken a turn for the better with a new job that keeps me challenged and learning. I've been quietly thankful for many things this year. And with all the changes that have happened, it's time to share them.

This will be a short post - with many stories and people behind the words here.

To all of you who I've crafted for: know that you are a blessing, and I'm glad I could contribute to your lives in this manner.

To those generous folks who have created and allowed me to have some of your work: thank you. These are placed around the house, and nearly always bring a smile and a thought of you.

To those who have worked with me, formally or informally: your patience, ability to explain things, and help me find the answers on my own is a great gift. I love having you in my world - and am thankful that we could share ideas.

And last but very not least. . .

Those I have worked with professionally this year: You have been a needed source of so much more than income. Thank you for sharing your skills, knowledge, and -at times - frustration to help me stay on track, growing, and contributing.

30 Days of Postman - for Testers!

Arlene Andrews — Wed, 23 Mar 2022 17:05:00 +0000

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.

So when it was suggested that I try the 30 Days of Postman challenge, I was delighted - and a bit scared. I don't code much on my job, and I knew just enough about Postman to know that coding was part of it - at least to create custom steps. A quick visit to https://www.postman.com/postman/workspace/30-days-of-postman-for-developers/overview showed that the steps were well-explained, and ranked by difficulty, I was tempted to try it.

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 you in other ways , such as Swagger,make API testing not only a chance to explore, but for me served a a way to connect with the team on a different level. Most of them enjoyed teaching, so this was good chance to learn.

I admit - some of the terms and activities may not be as familiar to testers as they are to the development team - this is also a chance to make sure we are using the same terms for activities. Unless you have used either Node or some flavor of JavaScript in your learning, this may slow you down. But that's okay- learning this tool at your own pace without needed to be worried about a deadline may help you learn more - and give you time to set up some scripts that will not only help you, but those in the future that may need them, and quickly.

Working with your developers, once you have tried a few times, is a way to build trust and learning in the team. The skills that this exercise brings can include that you are trying to understand what they experience, as well as the fact that you can be even more valuable to the team. Getting these scripts set up will save everyone time in the future, and make it easier for the next person.

You may be lucky enough to have someone on your team that is skilled with Postman - make sure both of you count this time someplace! It may only be a few minutes a week that you will need, but the fact that their is another person that is skilled will leave them a bit more free time - and you can gain experience in where the tool is used in your organization.

And if you happen to be the only one who uses it? Then you can share this at a lunch and learn, or with your manager - and show the benefit of having these skills. They YOU get to teach: there is no faster way to cement your learning that making sure you have correct answers to questions.

Getting to Explore: WSL2!

Arlene Andrews — Wed, 14 Jul 2021 18:35:00 +0000

Photo by Prateek Katyal from Pexels

Working on a graphical interface system is a delight, but every once in a while, I want to return to the command line style of computing - it's fast, and can have impressive results for a system. Even before Windows came up with a full subsystem, having a virtual machine and a Linux terminal for using some things wasn't uncommon.Thankfully, the Windows Subsystem for Linux (WSL) now exists, and is mature enough to handle most things. And once I experienced this style of computing, and the knowledge that most things were as simple to do with command-line terminals, I want to go back to the command line often.

But being invited to see how much use replay.io would be for a tester helped make this choice easy. Not only did I get a chance to return to a method I enjoy, but a new tool that could help communication between team members. And, now that I think about it, with stakeholders and others that want a visual look at how a project is working, to minimize rework.

I knew I had this on my system at one point, so this wasn't totally new to me. And the changes from WSL1 made the process much easier. I made it through the steps - my chosen distro of Ubuntu is installed.

Now to get replay.io installed!The steps to do this for Windows are not obvious - I located them in a Notion.io document, under construction at the moment. Since this is still in beta, I suspect that more-complete directions will be easier to find.For now, however, this is a great place to start.

One of the delightful, and yet frustrating things about WSL: it's a minimal installation. This does not take up as much space on the computer as a full second operating system would, but it also means that you need to sometimes install packages in ways that Windows users don't expect. And they are a very different thing than installing a new 'app' on Windows.

cURL isn't difficult to do, but sometimes finding the correct package is a challenge. For me, looking in https://packages.ubuntu.com was the fastest way to ensure that the correct, newest versions were installed. And the small thrill of getting a command line item to work for the first time can be its own reward.

The Notion instructions are wonderful, and written to be easy to follow. But I ran into a missing item, and was getting Error: no DISPLAY environment variable specified. This seems to be another missing library. After exploring a bit further, the documentation now notes that this is a Windows Insiders build. But, there are directions elsewhere to add a graphical interface without this build. I think I will take the time and explore this option, since I have no current plans to move to Windows 11.

More soon!

Where Is It? Part 1 - Inputs

Arlene Andrews — Thu, 04 Mar 2021 03:28:00 +0000

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, 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 use a more-graphical interface.

Which means, as you may have guessed, that the program was not done in time to let me be considered for the job. It still isn't totally done - I just now solved a section that had me confounded.

This was taking two separate inputs - the item, and then its location (still working out how to insure that multiple items stored in the same location can be found), and adding them to a Python dictionary. Which has its own restrictions, but it's a good learning tool. If I figure this out, and need to change types later, I'll still have learned some valuable things.

Like how to get these inputs, typed separately, into the key:value pairs that are needed to add them to a dictionary.

Of course, the first thing I did was to set up limits on the input fields - so far, they are unique item name between 1 and 50 characters, and the same restrictions for the location (no naming everything "Shoes" and putting them in "closet"!), and adding a word to type in to stop the entry. So far, this worked - I was delighted! And without wanting to toss the computer through the nearest wall.

But, the next day, these guards got removed - I wanted to get the item name and location into a dictionary, and print out the items already listed. If I placed things in the dictionary, they would show nicely. So that part worked.

But, adding things to the dictionary was not going well - it needs the information in a form that it could accept. And the easiest thing was a dictionary. But making a dictionary to fill a dictionary? Why can't I just toss these two into the update, and be done with it?

After multiple error messages (I'm expecting 2 items you have given me 4, or 1) I finally resorted to looking at StackOverflow. This is something I try NOT to do - I prefer documentation and a bit of freedom to play. But there, on the first page of search results, was a simple one-line command to get the inputs separated, and then get them into pairs.

All right, I don't like it, but I can have the item and its location typed in at one time. Which is why the guards went away. And that didn't work. I missed something. So back to staring at the screen - which only makes me less likely to see the error.

It's a nice day - and someone else wants to go for a walk. This should help me figure this out, or at least stop me from trying the same thing multiple times, and getting upset because it doesn't work. And the breeze felt good - the sunshine even better, and feeling like it was too warm outside was a change.

So back to looking at the situation after a break - they are using two separate variables to get this in, so I can use my old style, and have them input the item and its location. So back the guards go!

Type the formula in - since it's simple, I don't need to copy it - and try. And, it doesn't work. It's getting late, and I have to cook tonight, so back over to the SO page, and copy the line.

And feel very silly - the syntax is {[]} (or square braces inside curly braces). And I'd forgotten the inner square braces. Try this, add some silly data, and it worked! I was able to see both the updated dictionary, and get back the item that I'd added to the dictionary.

So this worked - and now I can move on to the next part of the issue. These lessons are going to be valuable as I make larger projects.

I hope you think of sharing what you learn, so the rest of us can learn from your errors and successes!

Do Your Tests Wobble?

Arlene Andrews — Fri, 12 Jun 2020 15:04:00 +0000

Cover image by delo from Pixabay

“The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.”
― Confucius

I was asked to pair Blog with Lena Weiberg - much to my shock and delight. This was the perfect opportunity to hear another point of view on something, and share it with the wider community. Thank you so much, Lena: it is a delight reading your words, and even better working with you! Please take a read of her look at this topic at https://testing.pejgan.se/2020/06/13/reacting-to-change/ - I think you'll be delightfully surprised.

Part of being a good tester, to me, is making sure I stay aware of the trends in development. Knowing how the team is working can help get comments and questions to them at the proper times, and has the information that can be acted on. In this quest, I attended a recent online conversation where the topic was primarily on the size of 'steps' taken in software development: making sure each step takes a reasonable amount of time, that it leaves the system in a state that isn't worse than it was before the change, and that could - if needed - be deployed at this point.

The concept of “wobble” (I'm not sure who originated the term)- how much the entire system is going to react to a change in one area – was presented, and caught my attention. Thankfully, this was near a break time, so I had a few moments to explore what this means to a team. And found several ways that this might change how they look at both ‘done’ and stability in a system. Does this fit the model they are using? And is the model wrong in this way?

And I wonder how much this concept has shaped the 'normal' path software goes through. Is this one of the reasons that testing has traditionally been placed at the end of the process? Either by those writing the code itself, or as a chance to make sure that a release has what it needs to be able to get into the user’s hands?

I will use the example from the quote above: a clump of reeds with many points of contact – intentional and otherwise – is close to a flurry of tiny changes. This could be produced by having any change instantly sent out to everyone. So a button could shift colors several times in one day, or flip into a different position – as a deliberately extreme example. None of these are going to ‘break’ the system, but would certainly irritate me!

Or it could be more like an older, stiff tree: reacting quickly to a potentially damaging threat just isn’t possible. Large changes that appear with infrequent updates happen, but it is a shock to the user's workflow. They may have to puzzle out where the information is now accessed – and if the frustration of finding and relearning the ‘tree’ is large enough, you may lose that user, or a lot of them!

I mulled this over for a few hours, and got this clarified in my mind. When a system changes during coding, it should be easy to see how those changes influence nearby code, as well as the code it touches. This is a normal thing for many developers: it allows them a chance to make sure that the system isn't going to collapse. A change of something like a variable name will cause waves across the application - but this will settle out unless there is a conflict. Changing the way data is collected or displayed may cause more reaction, and might lead to a cleaner code base. This, to me, is an area of little wobbles: things are deliberately changing, but we minimize the wobble to avoid future work.

Deliberately causing a large wobble is something that should be thought over carefully. Making sure the team knows of potential questions and issues, and a way forward to resolve them opens a chance to take time to look at the entire section. The amount of influence on the system as a whole is one consideration for how carefully you need to look. Changes like this most often are without problems, but they may infrequently cause damage, or at least confusion. And since the code has changed, there are the test and automated checks to update, and add to - no better time to make sure that this section of the code has more coverage than it did.

A bunch of small changes can add up to a lot of 'tech debt'. It is very easy to lose focus, in this situation, on the larger change we are wanting to make. Changing the name of a variable (a legitimate change, and a 'step' of the proper size) shouldn't set off a flurry of tests. The 'flow' of the development would be disrupted, and cause even more wobble. But always waiting until the very end of the process might cause large wobbles, if a functionality is missing or changed beyond recognition.

Our tests themselves suffer from wobble. Exploratory testing, in some ways, seems to be built on the concept of wobble, and where it will take us. The tools we use to help find the errors – even something as simple as a set of tester notes – can suffer from changes that might appear simple. Those changes may have an effect on more-distant parts of the application, and don't get captured in the original set of notes on an area. Future testing and checking might be incomplete, and adds to the potential of missing things and ‘tech debt’.

Our developers have a focus on getting through the application for the specific use they see. Users, however, will very likely not follow this path, at points - or at all. Letting the system wobble may save hours of coding updates, even if it seems to be needless duplication in finding alternate ways to get to information. Ensuring that all of these ways work to make the user’s experience easier is not always the priority, but it should at least be thought about. This helpful wobble may delight someone who has been frustrated by a less flexible “happy path’ that other solutions offer.

Wobble, by itself, isn't bad. Reeds bend in wind, and the resistance they gain makes them stronger. Allowing the system to wobble a bit will help reinforce and guide future changes, rather than allowing the system to be inflexible. Change will happen, and the whole team is responsible for making sure that this is a positive thing.

On the boat with Women In Agile Open in Cleveland, 2019

Arlene Andrews — Wed, 16 Oct 2019 22:05:36 +0000

I want to open with a sincere “thank you!” to Matt Heusser and all the rest who made this trip possible: it provided an experience with many firsts for me: I am still absorbing all the different perspectives that I was exposed to, and now can use to further my career. I have a few articles that I want to write, both expanding on the topics I was involved in, and the general principles that governed the conference.

My trip took more out of me than I anticipated: this was my first time taking a flight of this length. The change of altitude and water made me reluctant to go out, as much as I wanted to. A quick text to April Jefferson went unanswered: a look at my clock told me why - I’d missed the opening of the networking evening, and there were plans for later that night.

The text of “You will be there when it’s right” made the whole mess worthwhile, proved that the Open Space principals were alive and in practice at the conference, and gave me permission to take the time I needed to recover. I took a day recovering, and explored the neighborhood a bit. I wanted to go, and was mostly delighted that social media was quiet about the event - that, I hoped, meant that what was happening was more important than sharing pictures and thoughts instantly.

I was able to go out and visit with a friend, enjoying a meal and tagging along while she got dessert for the family. A short drive to the waterfront, and the quiet of the lake after dark was a contrast to the rush of people and cars downtown. This was a good hint that I would be able to attend the next day. And that, I was looking forward to.

I made darn sure that the alarm was set - I wasn’t going to miss the chance to at least meet some of these wonderful folks in person. Having a driver who wasn’t sure where I was going made it an adventure for both of us, but a successful one. The Lean Dog office is a lovely spot, and outdoor tables provided a spot so I could enjoy the morning come in. Since I was the first one there, I had the option to take a quiet stroll around the boat, and enjoy both the ducks nearby, and watch the sky change as morning arrived more fully.

I felt welcomed from the moment April arrived, and finding myself in charge of getting the coffee ready, I was able to interact with a portion of them as they came in. The sense of adventure increased with every person that came in the door. There were some that I wanted to speak to, because of the conversation that was happening as they came in. The team from Lean Dog made us very welcome, and made a good backbone for the conference: you could see that they used these ideas and communication techniques on a daily basis.

From opening Circle through the shared Lyft to the airport, the offerings and generous sharing of information, ideas, and suggestions flowed naturally. Laughter and willingness to support each other, and the teams we would be returning to made the impact even larger - since the concepts were often ones that needed to be discussed both now, and after much thought. Watching the people who had things to share, and being willing to combine sessions in order to expand the perspectives that each had to offer on similar topics made the openness of the sessions even more welcome: being able to switch groups and contribute to multiple areas was a necessary thing a few times!

I was sad to leave the physical group: I didn’t get a chance to explore ideas with everyone I wanted to (nor could I have with even a week of time!) but the probability of staying in contact via the Slack channel makes it an ongoing conversation. As we all wish could happen with some conferences. I look forward to continuing the connections made, and joining the group in person again in the future.

Hello World for Testers: Basics Part One

Arlene Andrews — Tue, 10 Sep 2019 20:00:00 +0000

Photo by slon_dot_pics from Pexels

Learning on your own is fun: you have the option to chase a concept until you are satisfied that you fully understand the concept, to the level you need it. But that is also the downside: as a tester, you have few public sites that offer a series of exercises to ensure that you can build that mental list of conditions that you need to ensure are covered in a testing situation.

I am slightly envious of my developer friends: they have established problem sets that they can use to upgrade their skills, and assist in learning the tricks of their particular programming language. The sites are set up to allow both individual learning and competition as an individual, or as a group. This, for many people, is a great incentive to do these exercises on an infrequent basis, or to reinforce a concept that you recently mastered, but aren't likely to use again quickly.

But for me, these resources are hiding - they are included in some classes, yes, but not in this form. And I have heard from developers that they are frustrated doing more than functional tests: they look for something similar to the "katas" they are familiar with for practicing code concepts, and ask about them. And fail to find them

So imagine my delight when I found a 'simple' exercise: go to [shopping site], type in [item], add all items on the first page that have [special tag] to the shopping cart. Thankfully, since this exercise was using a live site, they didn't want you to try and check out! I figuratively pounced on it, and asked for more things like this. And rushed off to make a mind map of what I needed to do.

Anyone who does do testing can see where this is going - what looks to be a simple four-step task can turn into a large project.

My first approach was, of course, an Experiential Testing one. There is no way I would be able to figure out exactly what was required to complete this exercise without taking a look at what was needed to complete the steps. Was there a "Buy now!" button, or did you have to go to the item description? Were the tags scattered. or grouped? And how does one find these tags? So many questions! And the only way to figure them out, plus find out if there are other tasks that need done is to go to the page, and find out.

An online mind map, and a notebook, were also available. I set the map with the task, and started listing what I encountered. Notes handwritten to make sure that what I find isn't forgotten, and so I have a list of tags and routes to items. And, after a few minutes of exploring the task, I was thankful that I had a large virtual sheet - the potential for testing both the correct, easy path and all the other areas grew quickly. As was expected: this is one of the fun parts about testing. Not only do you need to figure out the 'correct' way to do things, but find all the other actions that you might do during the task, either intentionally or not!

After about a half-hour, I had the basic plan on how I would, with unlimited time and budget, test this process. Since I'm still learning, I needed to narrow this down to a more-simple item, and build on it. So I explored a bit more on my chosen site, and found a page that had only one item with the tag, and wrote down what I needed to type, and where, to automate this process.

Returning to the groups that I had asked if there were more exercises like this, I found that no one had found a page with these. I was disappointed - how are we going to be able to skill ourselves up, and let others who are looking at a career in software find the delight that is testing to me? I placed on social media that this might be a good addition to one of the sites, but except for a bit of support, I haven't seen it come up yet.

Even if you just challenge yourself, this is still a good idea. Take what you know, and in a limited environment, expand on it to see how much you can do within that framework. You may not find a serious issue, but may discover limits on yourself, your views, and your tools that need to be examined and evaluated for your future.

Speaking at Develop Denver

Arlene Andrews — Wed, 04 Sep 2019 23:03:00 +0000

I was delighted to be asked, what seems like ages ago, to submit to Develop Denver (https://developdenver.org/). I had gotten most of the way through the process to gain an internship, and had hit a snag on the housing. I was asked to make a GoFundMe (which I disliked - I always want to give back in kind!) , and made it, more than my goal - partly thanks to the community of developers that is out there on social media.

The internship fell through - my background was part of the issue. But that still left the invitation to submit that had come in during this - I would have been back in the area literally the day of the event. I couldn't talk on what I'd experienced, but I could talk about what I'd learned about hiring and myself during these three months.

Sounds easy? Not at all - as you know, the tech space shifts rapidly, and the hiring landscape moves slowly. Many of the answers in hiring have already been formulated, and the influx of new people, with different educational choices, was starting to show. The announcements from Google and Apple that a degree was no longer required got me thinking. How are companies handling this?

With social media, within hours I had many answers - not all of them useful. And a lot to think on, and add to my store of data to pull from. I heard from all sides of the table - employees that were trying to get hired, and had both good and bad experiences; employers who were trying to navigate the rules, regulations, and experiences that hiring has around it; and those that had given up on working - some that had resorted to freelance work, and others who had become so discouraged that they went into minimum wage jobs.

And, always, there were those out there that were happy to talk about their experiences, and to support the idea of a talk on these topics. And many requests for links - more than I would ever have anticipated.

The team this year had a new person, and was offering not only their time on Slack, but in-person workshops! You could meet the people that were thinking of submitting, and get some assistance on refining your topic, and how to present it. The group was excited about this, then I had to throw a monkey wrench in their plans (I'm a tester, this should have been expected): I wanted to attend remotely: I was a good two hours away from the live sessions.

Someone was generous enough to make their laptop available so I could attend - and I am so thankful for this. I got to hear live discussion of some topics that hadn't even crossed my mind, and the feedback to help focus the talk more clearly. I was surprised to discover that I could speak from an expert's point of view - not only were these my experiences, but I'd also worked in recruiting, and knew some of the headaches that a large disruption could cause.

The next few weeks were a flurry of preparation - another submission had been accepted, and they wanted a transcript and slides a month in advance. Thankfully, some of the slides could be reused for both talks: I was nervous enough about making them. I had advice from several sources, including two who do a lot of public speaking, and the wonderful folks in my Slack channels that also speak. Getting the slides to follow the 10/20/30 rule advocated by one person (10 slides for 20 minutes - no smaller than 30 point type) helped guide how much I was able to fit on each slide, and the community again was able to assist in making sure that the slides and images were not only free to use, but were visible to those who might have had vision problems.

I don't sign, but I knew those that were hard of hearing wouldn't have an issue: I had been on stage before without a microphone. Yes, I'm loud, at points.

The second get together - they now had adjusted their plans to include remote workshops (thank you all!) - I missed due to it being on the day the transcript was due, and a full-on panic about it. And it would have been valuable - helping people work through their openings and closings for impact, and making sure that you had the resources that were needed to make your talk a success. I could have asked for this, but was busy making sure I had a recording, and input from other people, and discovered I can't talk as well sitting down in a quiet room. Much to my distress - it cut into my practice time for both talks.

The cover picture is from my talk - I was delighted to have someone take that picture, even if I prefer to be on the other side of the camera under normal circumstances. The talk went well - my audience was outstanding, the room was open enough that I didn't feel crowded, and the questions after the talk helped me focus on the next one.

As always happens when you do something live, there were bobbles and errors. Most of them, I could recover from, and thankfully it was nothing technical. The pleasure of having an audience is something I enjoy - even one person that you feel you've been able to share a concept or an idea with is a great treasure of mine - and this group was giving that feedback quite frequently. They understood the errors - and wanted this to be a success. Thank s to them, it was - I still give myself a barely-passing grade.

If you ever get the chance to speak - I urge you to try it. You don't have to be up there alone, but finding that connection with your audience: being able to connect with them afterwards and hear their thoughts is such a delight.