board game review: Scythe

We brought Scythe home a few weeks ago, and we’ve played it a few times. We’ve played one 2-player and two 4-player games, and Carl played the automa version once. I think I can give a decent review of it now.

There are some good tutorials on Scythe (see the Watch It Played video and errata here), so I won’t talk in depth about how to play the game. But briefly, there are five factions and five player mats, for 25 combinations of play. Each faction has a special ability and slightly different powers, and each player mat has a different combination of basic and more expensive actions, and different costs for things. You gain stars (achievements) by gaining power or popularity, building, deploying mechs, winning combats, and other things. Everything–territories, resources, stars, building locations–is converted to coins at the end of the game, and the player with the most coins wins.

For our first game, we were a little confused about the rules, and we did a few things wrong, particularly with workers (allowing workers to have encounters, letting workers do the special mech/character actions), but we got the gist of it, and our next games were more correct. In our last game, I won without building any buildings, and I almost broke 100 coins, but I think I bribed too many people. I felt like it was a pretty nice victory. There’s an achievement sheet that lets you write down your name next to winning scenarios, which makes victory even sweeter.

The first few rounds are a little slow and offer little interaction with the other players, as you try to gather enough resources to do something useful, but once you get out of your little area, there is the potential for more interaction as it becomes a land grab and race to the factory. Combats are not as frequent as you might think, even with four players, and bribery is fun (and effective if done right).

Carl says that the automa version needs more explicit instructions. While he was playing, he called me over a few times to find out what I thought was reasonable. I haven’t tried the automa version myself yet, but I will say so when I do.

I LOVE this game. It’s complex enough to have many different winning scenarios, there’s a little bit of luck involved, and it speeds up as the game goes on. It’s not a simple game, and you have to play with people who REALLY like games, but it’s pretty great.

testing trainings – a comparison

In the past month, I’ve done two trainings on software testing: ASTQB’s Mobile Foundations course, and Satisfice’s Rapid Software Testing Applied course. The difference between them was marked.

Like the SQE training I reviewed earlier and subsequent ISTQB test for the Certified Tester, Foundation Level, the mobile course was heavy on vocabulary and “best practices” and light on how to do a good job. It gave me things to think about, such as using simulators and emulators to increase coverage and getting cell data on some of our phones so our testing can be more real-life and more, well, mobile. But when it came down to it, a lot of the class was about the differences between web-based, native, and hybrid apps, and the risks involved in testing them. Looking at the risks that are inherent to the different types of apps was useful, but three days of vocabulary became a little wearisome. The test, which I took about a week and a half later, went just fine. It included a decision table, which took me by surprise, but the test wasn’t a big deal with a little bit of careful reading. I don’t have much more to say about the training or the test. I wasn’t planning on doing either, but then a spot was offered to me, so… it was fine.

The training that I was really excited about, and that totally lived up to my expectations, was James Bach’s Rapid Software Testing Applied. We tested a vector graphics program called Inkscape, approaching it from some different angles. Each day was a combination of lecture, individual/team work, and review of that work. Some guys from another Utah company invited me to join their team, so I talked with them throughout the day and worked with them on the assignments. We talked about sanity testing, survey testing, risk analysis, coverage, deep testing, testing with tools, and how to report testing. It was a fascinating class, though I did receive criticism, both privately and then publicly the next morning, for some of my bug reports. (I still need to check with my developers to see if they’re annoyed by my reporting.) My ego was a little bruised, but I know he was trying to make me a better tester, and in the end, I appreciated (that might be too strong of a word) the criticism. This training brought out all my insecurities, particularly those surrounding tools, but I was also pleased to have some of my thoughts about testing affirmed. James Bach is something of an icon in software testing, and I really enjoyed learning from him. I’d like to take another RSTA class, as well as his lecture class of Rapid Software Testing.

It’s possible I was just way more excited for RSTA, but I felt like I got more out of it as well. I really appreciated my company letting me do these trainings, particularly as they came so close together. I’m hoping to convince them to bring James Bach to Utah – that would just be fantastic.