Blog
Writing, notes, and occasional rambles.
new board games rundown
I spent the better part of five days last week playing the newest board games at a convention in Seattle. It was quite a change from the board game convention I usually go to, where players have about 40 hours to get through at least 30 games. This one was more relaxed time-wise, but the games were considerably more intense. I played a lot of “heavy” games, which took up to about five hours for one game. Altogether, I got through 27. The games were of a much higher caliber than my other convention too, so that made me happy. Here’s the rundown of the games I played:
Oct 2018pair testing adventures
Last week, I finally did what I’ve been wanting to do for months (years) and engaged in pair testing three times with some differing results. what is pair testing? Pair testing is a lot like pair programming, where you have two sets of eyes and two minds engaged in the same problem. There can be a lot of benefits to it (Lisa Crispin talks about it here ), such as increased creativity, better quality, and more exploration, but, just like pair programming, it can be difficult to start and requires a lot of focus and energy. I wanted to learn strong-style pairing , as it seems to involve the most engagement from both people.
Aug 2018CAST retrospective
I attended the Conference of the Association for Software Testing (CAST) two weeks ago in Cocoa Beach, Florida. It was a fantastic learning and networking experience over four days, and I’m still reeling a little bit. I started with a full-day tutorial about how to coach testing with Anne-Marie Charrett (her site is here ). She and James Bach built the coaching model together but have added their own flavors to it. Anne-Marie emphasized understanding the person and starting from where they are. We had a couple of exercises where we paired up to teach a concept or test something, and we realized how easy it was to move in and out of pairing and coaching alternately. It gave me a lot to think about if I move into coaching, and Anne-Marie’s style of teaching was engaging and thorough. The overarching theme of the weekend was “Bridging Between Communities”, so a lot of the talks and workshops ended up stressing communication. This ranged from communicating in healthy ways to defuse situations (Don’t Take It Personally by Bailey Hanna - her blog post is here ) to a keynote about Cynefin by Liz Keogh where she said:
Dec 2017automation thoughts - an update
Last year, I wrote some thoughts about the benefits of manual testing. The posts are here and here . Now that I’ve been on an agile team for over a year, and doing some automation, I think (hope) I have some more sophisticated thoughts about automation. Our team has two “manual testers” and one “automation engineer”. The automation engineer does all of the UI automation (for now), but I’ve written a lot of service layer tests using SOAP UI, and the other tester has been learning to write them too. The idea is to have the two of us start running (and eventually writing) UI automated tests as well, and we’re taking steps towards that end. The benefits of the API testing through SOAP have become clear, but so have the challenges. It has cut down on our need to test all flows in regression testing manually. I can write service tests while the UI is still being coded, and it’s a good way to start our monthly testing cycle. After all, if something is broken at the service level, there’s no point in testing manually, and we can pinpoint the error more quickly and precisely. We have everything in our app that can be tested at the service level automated, which I feel really good about. Or, at least, we have all the calls exercised. There’s always more to test, isn’t there? A big weakness of service testing is that it is more brittle than manual testing, because if something changes in the call (for instance, a value changes from being taken from a detail to being taken from a cookie), it breaks the test, though you wouldn’t notice a difference at the UI level. You also can’t run all the negative tests (like lockout tests) you might want to run, particularly if you think you’ll run the suite repeatedly through the day. We have two test cases that can only be run once every half hour, and one test case that requires a person to reset the user every time. Those test cases are fairly essential, so we make do with them. I still very strongly believe that there is no substitute for getting in the features and playing around, or, to be more formal about it, doing exploratory testing. That’s how we find all the interesting bugs. Automated testing is checking; it ensures certain things are stable, not that a product is “good”. However, automated testing is (can be?) fast, and it can be an efficient use of time, particularly for regression testing. Automated testing can make sure that bugs that are found and fixed don’t break again, but would a person writing automated test think to try refreshing a page without first finding an issue in exploratory testing? Perhaps I’ll have more thoughts about this later, but this is what I’ve been thinking about recently. Thoughts from y’all? Criticism? Questions?
Oct 2017two years of dates
For Christmas of 2015, Carl and I decided to plan a year of dates. We alternated months and planned an activity around town (or at least within driving distance), trying to keep the overall budget down, but allowing for a splurge. We liked it so much that we did it again this last year and are planning on doing it this Christmas too. We haven’t done all of them, whether because of time constraints or budget constraints or something else, but we’ve managed to get to about 3/4 of them. Without further ado, here they are!
Oct 2017training a tester
I may have mentioned a few months ago that I’m training a tester who is new to mobile. We’re four months in, and I’m surprised to find that I’m still answering (many) questions daily. Language does play an important role, and sometimes I realize that concepts that are organized in a certain way in my head don’t translate well to words or the way other people think. But also, for a long time, I was just answering questions, imparting information. I’ve changed tactics, now that she’s been on our team for several months, to being more socratic. If she thinks she’s found a bug, I press her, ask her why she thinks it’s a bug, and how she can get additional information about the bug. Eventually, I want to know what her oracles are, what devices/OSes/app versions she’s tried on, what environments she’s been in, what the logs that we have access to say, and on and on. I know I don’t always follow all the steps myself, but I have a checklist published for our team that talks about all the different things to try. If she asks whether a feature is supposed to be in a specific app version, I push her to explain why it should or should not be before I give her an answer. Just this last week, I included her in writing SOAP tests, asking her questions about how we could modify certain things to get the right thing tested, instead of talking through my own thought process. I think this method is more effective. Instead of trying to describe how my own synapses fire, I’m making her form her own way of thinking about things. It’s frustrating sometimes, because it takes a lot more effort to work with someone for fifteen minutes so they come to their own answer instead of just providing it, but the goal is for it to save time in the future. In the couple months where I was the only tester on the team, I revamped how testing was documented, and how things in general were documented, to a way that made the most sense to me. I documented what I did rather than what I was going to do. My notes for things to test for were for my reference, not for anyone else to consume, and I made mind maps as artifacts. This worked great for me, and I think it’s working well for my partner, but I’m trying to be sensitive to the idea that not everyone thinks like me (nor should they), and to be open to doing things another way, should she come up with something better.
Oct 2017finding purpose
I like my employer, and I like my new career as a software tester, and though I strive to be excellent, when I leave work, I do my best not to think about it until the next day. I’ll sometimes try to learn a new skill or read a book related to software testing, or write a blog post, but software testing is not what gives me purpose in life. I grew up thinking I was going to be exceptional. Maybe every kid does. Maybe it’s my generation. And though I’m a little disappointed that I’m not running the world or making a widely known name for myself, I’m really happy with the life I’ve built. My marriage is nearly perfect - we have similar goals, complementary interests, a genuine enjoyment of conversation and companionship with each other, and a desire to see the other one succeed and be happy. I’ve found solid friends and fun groups to be around. I am getting better at singing and am truly enjoying it. I always have a project or two going, usually knitting. I’m very involved at church and am trying to get more involved in my community. I’ve taken up rock climbing. My depression is mostly kept at bay, though some days, it’s hard to get out of bed. But is this my purpose in life? I hope I bring joy to others, I think I inspire people in some way, and I’m pretty happy right now, so is this what I can hope to achieve? I try not to be selfish, though that is my nature, and I can be rather self-indulgent some (a lot) of the time. I’ve been looking into ikigai and hygge - it seems that a lot of people are seeking purpose (and contentment) in life. I don’t have one all-consuming passion that makes me happy to get out of bed (and pays me), but I do have rituals and little things that bring meaning to everyday life. This is a hard concept for me. My life is pretty ordinary viewed from the outside, I think, but it feels special from the inside. Where do you find purpose? How do you define it?
Jul 2017SOAP testing and finding the right assertions
I’ve been delving into the more technical side of testing, that of using tools to exercise code precisely rather than galumphing through UI, which really is my preferred method. Our mobile app uses a lightweight service to connect to the other moving pieces at the company and our vendors, so we can test those calls directly through SOAP, which, for you non-software people out there, is also called API testing. The developers of our software took kind of a blanket approach to the envelopes for the service calls, so there are tons of superfluous fields for each of the calls, and it’s kind of a guessing game as to which are required for any particular service call. My developers didn’t create all the service calls, so I’ve actually been able to figure things out and share my envelopes with them (so, you know, I feel pretty cool). Once I figure out which fields are necessary to get a call working, then it’s time to figure out an assertion. These are what the testing software checks against to make sure things are working appropriately. In our testing, they’re usually related to the content of a field, whether it is a “success” or “failure” message, or, in a case I was working on recently, whether the name of a document started with a specific year or not. With this case, we modified the call to pull documents one year at a time, so the call for each year needed to return only documents for that year and none others. I ended up doing a check that the count of docs that started with something other than the year I was looking for was 0. This may sound simple, but it took quite awhile to get the xpath right, and I had some (a lot of?) help from a developer. The SOAP tests are nothing without the correct assertions. You can go ahead and get all the information you want, but without an automated check on the information, the tests have very little advantage over UI testing in terms of speed, though they do have the ability to cut down on some of the noise that is inevitable with UI testing. API testing is another tool in the box. It cannot be the only thing, and it should not be ignored. It’s great for getting precise information, for making sure you exercise calls at a lower level, and it can be faster than UI testing, but it is not a substitute for a full complement of testing, including exploratory testing (galumphing), scripted tests run manually, and scripted tests run through automation. And, of course, if your developers unit test their code, that helps too. :)
Jul 2017language and learning
We have a new tester on my team. I recruited her, and I talked her up to my team. They liked her, and I was excited when it worked out. She’s not new to testing, but she’s new to mobile, and it’s a different beast and a different set of systems from what she was doing before. We’re now four weeks in. I’m exhausted. I think the fault is mine. I expected to train someone like me, and not to talk a big game, but I didn’t get tons of help when I started, and I made it through okay. But I also expected to be able to use my own language, with my own mental images and way of explaining things. That hasn’t worked so well. I’m being asked to show my work, like in math or law, for everything, and it takes so much effort to put things in terms that make sense to her rather than just to me. She’s a very visual learner, and though I make diagrams in my head of things, they don’t necessarily translate well. It’s gotten me thinking about how language is used to convey such complex ideas without many words. It’s like the Star Trek TNG episode Darmok, right? This society speaks entirely in metaphors, communicating deep ideas to each other but making it difficult for outsiders to come in. Carl and I have our shorthand, where one of us will mention a few words about a memory or an emotion and the other will instantly understand the meaning behind those words. We were at a conference once, and we ate with a couple who had been married for 50+ years and who were both deaf. Their translator explained that she didn’t know some of their signs, because deaf couples will make up signs that apply just to them. I found that fascinating, but it’s really no different from what we do with spoken word in our close relationships. I fear I’m just becoming lazy with language, and assuming that, if people don’t understand me, it’s on them and not me. I know that’s the wrong attitude, and I’m working on it. But it’s just… exhausting.
Jun 2017essential board games
I know I talk a lot about board games, but I’ve never talked about which ones are actually good starter games for anyone interested in building a modern board game collection. So what games do you need? In no particular order, here’s my list: