Monday, August 29, 2016

That's No Game! It's a Project Management Trainer!

"A strong woman looks a challenge dead in the eye 

and gives it a wink" - Gina Carey

About a week ago, I bought a game called Planetbase. It was part of a Humble Bundle I purchased with several other games that hopefully I'll get around to, but right now, for a lot of reasons, I'm really digging this game.

It's based on colonization and sending a bunch of people to a barren planet to set up a base camp. They have different planet types that you can unlock once you reach a certain amount of successes on the previous planet type. You have a crew and starting resources, but you have to get to the survival stage and then self-sustaining fairly quickly or the crew starts having problems, you start running low on all kinds of things like spare parts and bots and sometimes even people. 

The opening mission is on a Mars type planet. You can pick anywhere on the planet to start your base and the idea is expansion for as far and long as you have resources, colonists and room to grow. It really is like a Sim game in a lot of ways. Until you get to the challenge section.

I started the first challenge Wednesday night. It was pretty simple:

Scenario:  Accumulate 100 ore
Given I have 5 people (2 biologists, 3 engineers)
And 9 robots (4 drilling, 1 construction, 4 carrier)
And a limited supplies 
And only trade ships available
Then I should be able to accumulate 100 ore

What you find out when you click into the challenge is that the game has removed abilities. The first limitation you are told when you enter the challenge, no more colonists than what you start off with. You lose someone or a bot, you are probably in for a rough ride.
This is from normal game play - but it's still a cool day shot.

Working Towards A Goal

As you can see from the gherkin above, I had to manage people, robots and resources. When you get into the challenge, you realize it's also removed any way to make building materials from the raw sources you produce. So you either have to trade/buy the materials or recycle them from something else. It also disabled any way for you to build more robots. If I wanted more, I was going to have to trade or buy them from the trading ships. 

One of the first things I did was recycle the construction bot and two carrier bots after the initial construction was done. More building resources! Yeah! 

With limited resource come limited ways to produce power to power everything, and store energy. My first problem was with the power grid. I had enough resources dedicated to it until I realized I was going to need a landing pad, and I couldn't recycle anything else. I had used the resources I pilfered from the bots to build out a bigger power grid and now, I was going to have to adjust that, and use what I had left to build the landing pad, or I wasn't going to have a way to get trading ships to my base. I recycled one of my solar panels to build a landing pad.

This is a great example of making initial decisions and the modifying them in the iterations that come later. When something looks acceptable, and then a customer or a tester detects an issue, this triggers (or it should trigger) a triage process by which resources and people can be moved and pointed at the problem. And then, solving one problem can lead to another.

Night shot of Ice Planet Colony (called it Hoth Rebel Base)
Because I took out part of my power grid, I was had to manage the power resources during the night cycle. I had one turbine that was there when there was any wind, which was rarely, but enough to keep producing energy. The real energy makers were the solar panels. I would shut off solar panels and even the landing pad to keep power for as long as possible. When I later added storage areas for the raw materials, I would shut off power to those as well. I also would shut down a mine if a bot wasn't working in it.

The power management problem, produced previously by the landing pad problem is pretty typical in project management. If you take resources or people away from a project which had a balanced, predictable cadence of production, you have to compensate in other ways, by reassigning people, moving other resources or limiting/restricting access to a resource so it isn't used up too quickly. This is project management basics. Mistakes aren't mistakes, they are really just resource problems. It only becomes a mistake if you can't compensate fast enough with another resource.

 Once the trading ships started showing up, I traded off any extra I thought I could safely trade away for building materials, semi-conductors or other needs. Eventually I was able to build out another storage unit, another solar panel, and other power collector and a second robot repair station. At this point, I was about 75 percent done with my goal. And my project was self-sustaining. I walked away for 15 minutes to do other things around the house and came back. All was well. I completed the challenge with 100 ore, all the people and the robots I didn't recycle, and had a few resources left over.

When projects hit this point, of self-sustaining, you basically watch for any serious issues, but it becomes a hands-off affair. Everybody knows the goal, knows what they are doing, and progress is reported on a regular basis. Progress can and should also be verified. In this game, it was seeing the storage rooms fill up. In the real world, it's demos, releases, defect reports and product sales/usage. This is the time when you start working towards your next goal, setting up for the next project. It's the quiet before the next storm. 

All of this is people and resource management. It happens every day in every business on every project imaginable. The trick is knowing who to put where and what to use to get the job done. If you are any good at these games, then you might have a career in project management. You just have to learn how to deal with real people instead of the meeple that run around in your sim. And that's a different blog post. 

#ChangeTheRatio - More Voices In STEM

"Remember Red, hope is a good thing, maybe the best of things, and no good thing ever dies."
- Andy Dufresne, Shawshank Redemption

Not so long ago, I jumped out of my comfort zone and into a group of lady developers, developers-to-be, and even a few testers, like me, in that group of women at a meetup, all hoping to make a difference in the day-to-day practices of software development. 

That group was Women Who Code. I also have to acknowledge that I wouldn't have thought to do that without the stalwart support Ministry of Testing, another group, run and promoted by a woman named Rosie Sherry. That group is constantly pushing forward creating a presence and acceptance of the testing profession as something valid in the software development world, and they are huge advocates of inclusion of women into the testing/development arena.

I'm on a Skype channel which has voices and new ideas from a wonderful group of ladies every day. They are from all walks of life, all over the planet; a 24/7 channel of ideas and support for women working in the testing profession and the tech industry. They advocate, discuss and disagree and have a large amount of hope for the future. I think most women do. 

From the young 20-something navigating a world, to the 40-year-old professional looking at reinventing herself, to the retired woman who did the work, got little recognition for it, and is still active in the community, we all want to change STEM for the better.  

Today, I applied for CodingHouse developer scholarship. It's a 14 week in-house program in which you live, eat and breath coding.

Testing is changing. And unfortunately, many of us are finding we aren't changing with it. Or as fast as we would hope. It's the classic problem of learning and working at the same time. The one that feeds you is going to get the priority over the one that extends what might feed you. 

It's not that I haven't been trying to learn, but I feel like the minute I focus on one thing, the next thing is hitting the shelves and then the next. I'm excited about these changes, and excited it's getting easier and easier to learn how to do all of these things. 

But what should I learn? Is Java more important than Ruby? Should I focus on back-end services or front end tech? Can I learn it all and still do a good job? Do I focus on this one thing, and learn it completely, or can I take concepts and move them from one thing to the next? 

I feel like I'm missing the Rosetta Stone here where coding languages are concerned. I feel like I'm being aged out of an industry I've loved for years. But I'm out here, pushing, trying and continuing because I can't stop - won't stop. I love this too much to stop. 

If you're out there, whether you're young or old and love this industry, tell your story. Get it out there, let other people, especially women, know they aren't alone. It may take time, but it's going to happen. Women are here to stay and they aren't giving up hope.

Wednesday, August 24, 2016

Are You Thinking About Attending a Conference?

"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." 

- Maya Angelou

I've been extremely lucky in the experiences I've had at conferences. The last two years have been wonderful in the quality of topics, an excellent environment of learning, and the peer relationships I have built with those who attended.

TestBash NYC was a one day conference put on by the Ministry of Testing. I had the opportunity to go via a contest, where I wrote an essay which won me a ticket. It was eight hours of topics presented by wonderful people, many of whom I still have contact with today. {Here is a link to the essay I wrote about the conference itself.}

I also met other people who are industry leaders, thought leaders and testers, and had great discussions about topics, all relating to testing. The overwhelming feeling of community stayed with me long after I went home. I still talk about that experience like it was yesterday.

So this time, I want to talk about several conferences, if you are planning to go to one, or want to go but aren't sure which ones are worth the money and time. Here are a few I would suggest you check out no matter where you are on the planet.

Test Bash  - any Test Bash, there are four of them now! Get to the one nearest you and have your very own mind nova! The Ministry of Testing organizes these and I can tell you this group of people are about developing the community in ways that will definitely shape the industry to come. Passionate people about their profession and the time they invest in content and community shows in this showcase of talks and talent. The next one is in Philadelphia, Pennsylvania and it's shaping up to be pretty epic!

European Testing Conference (ETC) - this was another one that had a good mix of people who have roots in Ministry of Testing. There are others involved with this conference that made three days in Romania some of the most mind opening and educational days I've spent in another country. The organizers are wonderful and understand what it takes to have an event succeed. They are also mindful of the cost to speakers and those that attend. I'm very glad I had this experience and I wouldn't hesitate to recommend this conference which will be in Finland in 2017.

Agile Testing Days - Seven days of testing and development heaven with some of the worlds best and brightest speaking and exchanging ideas. I have not personally attended one yet, but it's on my bucket list. This year it's in Berlin. Next year it will be in Boston, and I hope I can attend. There are smaller events around Europe and I recommend those as well. I've heard nothing but good things from people attending the smaller conferences. And a great number of good things from people who attend the week-long one as well.

If you are planning on attending Agile Testing Days in Germany and would like to receive a 10% discount, use the following code: MelTheTester_010 - full disclosure, for everybody that uses my discount code, I have the chance to get a conference ticket. So if you haven't purchased your ticket yet, here's a good discount!

Regardless of what conference(s) you choose, go with an open mind and get out of your comfort zone and meet some of your fellow testers. The experience will stay with you for years to come.
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.
Read more at:
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at:
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at:
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at:
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at:

Thursday, August 11, 2016

Finding Allies in Testing

Hello World! Hello Friend!
can be a lot to take in when you first move into a new environment, with a new job, and new applications to learn. Some of the basics are the same, but the little things, the details that matter, that do trip up users, are the issues that you need to learn quickly to make headway on any project with longevity.

Maybe you aren't the best tester for that particular product, with a lack of knowledge, but you want to be. How do you get to that point? Reading documentation can get you part of the way, but that can be time consuming and often out-of-date.

How can you get the latest and greatest info, and understand some of the pain-points your app users are going through without necessarily doing an intensive week long training pouring over every inch of GUI and code available? Well, if you have other testers on your team, that could be as easy as doing some pair testing sessions with them to get up-to-speed. If you don't, where could you go then?

Customer Service Reps are an ally

For anyone with a team or even the lone tester, if you don't have deep knowledge of the application, the next stop for you should be your customer service department. Whatever the CS manager will let you sit in on or experience with their CSRs, do it. Plan to shadow calls or chats. Sit in on trainings they have. Talk with feature experts and get their first hand knowledge about the app and about the users.

Not only does this get you valuable information right from the start of any kind of job, this also develops a model of goodwill and trust with the customer service people. This alone is worth it's weight in gold. Having a good reputation with the CS team, means they will communicate with you trends that they see happening with the application, or customer complaints that could give you valuable information when looking at the next feature story or upgrades to an app. If your acceptance criteria could affect things with customer service, having a customer service viewpoint could be invaluable for that feature story. Working on defects becomes much easier having access to the person that wrote the defect and understanding the customer that reported it.

Go out of your way to understand this team and you have created the best ally you can have in the fight to raise the quality of any application.

Professional Trainers are the Front Line

If you are lucky enough to have a customer service team and professional trainers who routinely go into the field and demo your product, or perform the set up, definitely find a few friendly ones that are willing to share their experiences.

Professional trainers could be training users with different parts of the product. Especially areas that deal with billing or finances. They could be doing setup and initial on-boarding for a client that doesn't have the internal structure to train people to use the application they want to use. {Often this happens in the domains of education, health/medicine, logistics,  human resources, finance. There are probably others, but those are the ones I have experience with personally.} Going onsite with a professional trainer can be a wealth of information in observing users and understanding the questions users are asking. Those questions should serve as beacons for testers when looking at usability and accessibility for their users. You also gain first hand information about issues rather than waiting for the first draft of the story or the first draft of the feature code to land on your desk.

In return, fostering a relationship with a professional trainer can give them credibility when they talk about the product with first hand knowledge from the development team. Communicating in an informal way, letting them understand the process the development team is in can give a trainer ways to help work around current issues they might be having with the app. This can also foster a better client relationship for the professional trainer since they can say they know someone on the development team that is willing to listen to issues.

A Story: I once sat in on a professional training session for medical software. They were demonstrating the billing section. I had used the application for a year or so now, and I was one of the main people testing the billing section with the updated reports and transaction logs. I went to the training because it was offered to the company, not just the other trainers, and I thought it would be a good way to get more knowledge about what I was working on as well. During the session, the trainer presented the workflow and I was surprised. How I had been taught internally to use it, wasn't at all the workflow the users were using or the trainers were training. I showed the trainer the workflow I knew  and she indicated users literally couldn't use it that way because they needed to wait for a 3rd party process to happen before they could go to the next part of the workflow. Also, the order of the tabs were not it the process order customers were using, making the workflow even harder for users since they had to wait for this 3rd party acknowledgement to happen. Our internal tool, that mimicked the process of the 3rd party inadvertently caused us to change how we were using the billing section for testing. When I brought this information back, people on the development team were as shocked, if not more so, than I was to discover this issue. They wanted it to be easy to use, and thought it was, but we had made it harder without realizing it. Doing the professional training suddenly became a value add and more people were encouraged to go to the next one.

Product Management/ Product Development are Natural Advocates

 I haven't worked a job yet where the product management team, along with business analysts and product development folks, {or whatever flavor you have driving your development cycles} lacked a deep product knowledge and customer understanding. This knowledge is absolutely valuable and when you are on any project, and some of the best, most immediate answers to questions usually come from this team of people doing market research and study. They hope that decisions they are making will further the future of the product and be profitable. They often comb through defects, understand what usability problems plague users {and already have ideas to fix them}, while maintaining a high level knowledge of the tech stack and talent pool they are working with. I have personally worked as a business analyst for a week, writing up two stories, researching issues that might come up and then dealing with all the questions and acceptance demos that resulted once those stories made it to the pipeline.

Another Story: I will never, ever say product development or business analyst job is easy work. First of all, you have to be able to write effectively, communicate with developers and management on two different levels, and think about how to resolve problems that come up during the development cycle. And if your solution wasn't correct, you have to own that too. I once covered a BA's vacation. I created two stories, based on defects we had in the backlog. I wrote the acceptance criteria and even created some screen shots about how I thought the UI should change to fix those issues. I'd been doing QA for about four years now and thought about switching to the BA position because I can write pretty well and communicate well. And it seemed like a way to add another level to my ever growing skill set.  Writing the stories was the easy part, and that was still pretty complicated. They were reviewed and PDs asked questions about my requirements and acceptance criteria. Both stories went through several revisions. But once they were done, the real work started. It took about three weeks before they ended up in the development pipeline. I was responsible for seeing these two very small defect fixes through to deployment. I was asked questions on a regular basis for two weeks. I even attended the scrum meetings for the team the stories were assigned to. This was all while I was doing my own testing work and attending my own team meetings. I can say, without hesitation, that shit is hard. You have to be on point in meetings and you have to have answers in a reasonable amount of time. You have to have your team trust the answers you give them and you need to trust their feedback. It's a lot of freaking trust. A lot. Anyone that says otherwise is bullshitting or doesn't understand the amount of work needed to make sure one story, let alone a whole project, works and won't mess up other pieces of the puzzle. Additionally, if you are bad at product development, it shows, faster than any other job on the development team. It's a lot of pressure and I have a lot of respect for people that stay in that role for a long period of time.

I know for a certain that you can work with your product team to gather more information or understand usability problems. They should be a go-to source for any tester, any developer, really anyone on a team, for product knowledge. That might be stating the obvious, but sometimes that has to be done. People forget that they have access to someone that can help and you can certainly help them. Cultivate these relationships and keep them going even after you move onto another team or another company. You never know when someone might have knowledge which can help you solve a problem.

The Valued Customer

If you can have customer contacts, absolutely make them. Customers can be a wealth of information and knowledge about your system under test. They might not know all the in's and out's but they can tell you what they like and don't like about the product. Getting this information directly instead of via Customer Service puts a face on the users. When you ask the users questions and they can answer because they know the domain they are working in well, and they can see what you are trying to do with a product, you are getting insight into your user. Some companies advocate "Dog Fooding", and that's OK too. But the biggest problem with that is you know too much sometimes. You know more than a normal customer, so it's easy to dismiss minor issues because you might know what's causing them or that they might never be fixed. But those are the things you should go after and advocate fixing, even if it's only a minor annoyance. Those minor things can turn into major losses depending on the product and the customer.

The more contact you have with customers the more your work means to them as well. They might not understand what you do in software development, but they understand that you are trying to make the product work for them. They will tell you things they might not tell a customer service person or even their sales rep because you might listen more or be willing to bring an issue up in a product meeting when you can.

A Small Caveat

Be somewhat careful with cultivating these relationships to not accidentally circumvent a process or divulge information which shouldn't be used outside of the company or a department.The goal here is to be cooperative and open, but not so much that the relationship becomes an issue and the company takes steps to mitigate or manage contact between the departments or people and customers.

Allies are everywhere, if you understand what you are looking for and who might best help you with your questions, they can be easy to find. They are also some of the best unskilled testers available. They use the product just as much as you would, maybe even more, and understand things at different levels that could give you valuable insight. That insight alone can be your first line of defense in preventing defects and a poor user experience.

Wednesday, August 3, 2016

The First Full Hour - An Experience in Public Speaking

"No plan survives first contact with the enemy" 

Nineteenth-century Prussian military commander Helmuth van Moltke

I prepped for a month an a half. I initially thought about all the ways to help the developer group I was speaking to understand that testing would be good for them to get a handle on. I had a lot of starts and stops. Different slide views. Different ideas even. And what came out in the end was more of a "Let's talk mindset and how I think about testing and what you can do." rather than a "Let me preach the word of testing!!"

I read my notes. Spoke them out loud. Modified for context. Modified for approach. Paced the floor of my office. Mumbled to myself until my dogs looked worried about me and hoped that it was enough to explain to the group and have the group understand what I was trying to get across to them.

Talking for a whole freaking hour is really, really hard! I didn't appreciate how hard it was until I was standing at the front of the room, with 18 people staring at me. Friendly faces, some I had even spoken with. All I could think of was, please don't let me do something stupid like burp, or pick my nose or flail around needlessly.

I started with the introduction, like just about everyone does. I then I explained this concept I have about the mindsets of problem solvers. There were some nods and people were still looking at me which was good. But I think maybe I spent too much time on it if I was honest, or I just could have jumped into explaining how I think and then ask them how they think about testing and then try to explain, but alas, that method only occurred later while I was driving back to work, thinking about what I said.

The second part of the talk was meant to be more interactive and I asked questions about what testing they already had, about processes and even about development styles. People didn't mind and it even sparked some conversations. I think this was good, but it could have been more interactive to a degree. I could have had volunteers explain what they were doing on those projects as well, instead of just noting that they did certain things like unit tests or acceptance testing. One kudos for me on that; when I ask if anyone was doing acceptance testing, and immediately I was asked to clarify what I meant, and I had a definition ready. I had managed to think ahead and the definition it was in my notes because I wasn't sure I would actually remember the definition. Trust me, I didn't. It's not that I didn't know it, it just that I for the life of me, couldn't have given a clear definition if it wasn't right in front of my face. I don't think in definitions. I just do because I understand the concept. But it was a huge win for me that small moment, because it meant, at least to me, that I understood my audience.

The third part a little better I think. I spoke about a cross section of testing that could be done by coding types, which involves code reviews, unit testing, pair developing, and code or commit comments. This was taken fairly well. The idea of doing positive code reviews and being less attack and more questioning, and maintaining a positive level of interaction so that they can all better their work through critiques seemed to be also well received. I also talked about risk based testing as a way of planning at least some testing efforts. I also mentioned Test Fests and Unit test parties as a way of getting help and making things eventful. People seemed to like that concept a lot.

I took questions at the end. I felt like I did well with those. I felt though, when I was asked about the agency experience, and having to maintain different tech stacks and moving around on different projects, how could they handle that better and my comment was - "LEAVE NOTES. If you aren't going to stay on the project but know about an optimization or a part that could give someone issues in the future, comment on it in the code. It takes less than 30 seconds and it pays a lot forward." I don't know if that was the only thing they could have done, but it was my best answer to that question. If there are other ideas out there, I'd like to get to know about them.

It was over a lot quicker than I thought it would be. I planned ahead and had water ready when my throat went dry. I'm not sure how people speak without drinking water during some part of the hour they are speaking. I had an immense sympathy for speakers then. Water also helped when my voice started to waver a little. It caused me to have a small panic because to me it sounded like it was nerves coming through. But it was just dry throat. Funny how the sound of your voice can freak you out and put you in a state you weren't in only mere moments before. Actually, it's not funny, but I'm glad I planned ahead and I was brave enough to stop and take a drink.

I also clung to my notes like they were a life raft. It's amazing how much practice and time you can put into a talk and suddenly have it all woosh out of your head like a speeding train with no breaks leaving you standing at the station of "doh!". The notes definitely saved my bacon several times over. It's why I make them, it's why they are there, but I was a little disappointed in myself for having to refer to them so often.

And being on the train of self analysis, I could have added more slides with the talking points on them instead of just sticking with one main talking point slide. I had five slides total. I figured since it was a conversation, and I practiced, the slides weren't really that big a deal. I could have done better with that and helped myself out with not looking at my notes so much. I know now for next time.

It was a absolutely thrilling learning experience. It was very much like the lighting talks I have done but much longer and with a bit more pressure since I was getting paid for this one and people expected some useful information out of it. I was also recorded, so the vid should be interesting once I get a copy of it. I don't know if I'm going to be brave enough to watch it myself. While I feel like I did well, and I got a lot of head nods and agreements and such, which are all good signs in my book, I rambled on with some points. And I worried that wasn't connecting with my audience on everything I was trying to convey.

Also, I'm really good at telling stories, and the experiences I've had could have highlighted a lot of my points, but I didn't get comfortable with that concept until the end and I had a chance to tell a story that related to code comments. The story connected very well. People got it. I had a small AHa! moment to tuck away for later. 

Mostly, I'd really like to speak again. I don't think I'm horrible at it and I might even be mostly good. The thought that sticks with me most, which comes back to me when I start panicking that I completely bombed is knowing that even the most talented people that speak for a living have these problems. Stand up comedians have these problems every time they work on new material. I've seen some prep shows. Not everything lands, not all the bits work. Sometimes they have to rework things so that it makes sense or they just toss it out. If I look at it from that point of view, I have lots I did well, and things I can do better for next time. I think that's all anyone could ask from a speaking experience. I'm not at the level of Mrs. and Mr. Obama, but it was also a solid first effort. And hopefully there will be many more to come.

Postscript: The quote above isn't about developers, hopefully people understand that. I included it, and this goes back to the telling stories part, which it appears I'm still learning, because, one of the team members I spoke with asked me how I prepped for the talk and I explained it and then mentioned the quote about plans not surviving and such. He actually finished the quote I started to say. It was a nice beginning. So I made it the beginning of my article here. Best laid plans and all that.