All posts by jonathankohl

android, cloud, messaging, mobile

Android Cloud to Device Messaging Framework

The Android Cloud to Device Messaging Framework is a fascinating tool. I see a lot of possibility for tools like this to push mobile devices and applications into more useful spaces. We’re just scratching the surface on some of the potential, but I like ideas that help connect our mobile devices with other things we use and depend on.

Here is an example of pushing information from your web browser to your mobile device: Push map information from Chrome browser to Android phone. It can be a pain to navigate and type on a smartphone, particularly when you are traveling and stressed out about where to find your destination. A colleague showed me how he used this for a recent trip – he plotted out his paths with Google maps prior to leaving his home, so his directions were pre-loaded on his device when he got off the plane. The hard part was done on his laptop, where navigation and typing are easier, and his phone had everything he needed for his trip.

This is just one example. As mobile devices integrate more seamlessly with our environments, they become easier to use and more valuable. Instead of clunky syncing, lots of typing and gesturing, the phones can just operate almost like they are self-aware. This is a space to watch.

productivity, project management

Productivity and Projects

A couple of years ago I collaborated with David Hussman. David likes to use music metaphors, and one in particular got me thinking. David talks about music production, and studio work, and describes three phases of work in a studio:

  1. Pre-production
  2. Finding your groove
  3. Keeping the band together

I have experience playing in bands and recording in studios, so those concepts grabbed me immediately. Preproduction: If you don’t figure out where you want to go prior to getting started, you can burn up your studio time and not have a good finished project. Finding your groove: it takes time and practice to get your work to be at its best.

Keeping the band together: recording and writing music is stressful, and there are a lot of things that can cause friction, dooming your project. Furthermore, if you play together for a while, you can get bored, or in a creative rut, so you need to do things to keep things fresh and interesting. (For more on music production, check out Bobby Oswinski’s work and think of how his descriptions and advice might relate to software projects.)

This led me to think about software projects, and I re-framed those concepts like this:

  1. planning and getting started
  2. getting productive
  3. staying productive

As an industry, we’ve done a lot of work on #1 Planning and getting started, so much so that we often ended up over-planning, and working on too much speculative, up-front design and didn’t leave much time for the actual product creation. When I started out, I could find books on software development topics that were filled with planning ideas. Often, actual implementation ideas were a bit light.

The backlash against too much up-front planning came in the form of processes like Rapid Application Development, the Spiral model, Evo, and eventually the Agile methods. These have helped us address #2, Getting Productive: we have a lot of processes and tools that helps us get productive. We have practical advice on how to execute the technical aspects of our work, and manage them.

That leads me to #3, Staying Productive. How do you keep a team productive in the face of so many threats?

  • following a process that worked in the past, even though it isn’t working very well now
  • getting bored with the technology and tools
  • personality and team conflicts
  • changes in the market and demand for your product
  • disruptive technology threatening your existing stack
  • teams becoming too cohesive and comfortable, so they stop innovating and productivity drops
  • others

We have a lot to draw on for planning and getting productive, but the concept of staying productive is often lost on us. How a team can sustain value creation over the long haul can be fascinating, and we overlook it at our peril.

mobile, tutorials

New Tutorial:Testing Mobile Applications

I’ve been working in various roles on mobile application products, and I’ve channeled that experience into a new tutorial that is available this year. I found that there was little guidance on how to test mobile applications, particularly for manual testing, or tool-supported testing. I decided to start sharing my own ideas publicly, and demand has grown.The course description is available here: Testing Mobile Applications Course.

If your team is transitioning to develop mobile applications, I can help. Email me for more details if you are interested.

Update: I am offering this course through SQE Training in North America, and SoftEd in Australia and New Zealand.

app development, mobile, tutorials

Test Mobile Apps with I SLICED UP FUN!

I unveiled a new testing mnemonic I use for testing mobile apps at Star West last week. I adapted it from James Bach’s SFDPOT, but with a special focus on some unique challenges mobile apps can provide. Several people who saw the talk asked me to publish it so they could use it with their teams, and here it is: Test Mobile Apps with I SLICED UP FUN!.

I’ve used this on mission critical medical apps all the way down to simple entertainment apps to help generate test ideas, and I hope you also find it useful.

Update, Sep. 29/2012:
This framework is elaborated on in much more detail in my book: Tap Into Mobile Application Testing, available on Leanpub.

This mnemonic has appeared in many publications, such as the book “The Everything Guide to Mobile Apps: A Practical Guide to Affordable Mobile App Development for Your Business“, magazine articles, conference talks, and most importantly, has helped thousands of people around the world find important bugs in the mobile apps they test.

management

Content Pointer: Management Anti-Patterns

My latest article Management Anti-Patterns, or “My Manager Thinks I’m Holding Her Hostage” is available on Stickyminds.

A couple of years ago, I was the technical editor for a Linda Hayes article called “Held Hostage by Coders”. I was working with a team performing a technical audit when the article was published. Linda’s piece was timely and appropriate for the team to read, but there wasn’t anything for managers to look at to improve their work. In fact, a technical lead admitted that the technical team were exhibiting the behavior described in Linda’s article, but said: “What about the managers? They aren’t behaving that well either. Do you have something for us?” I developed three management anti-patterns based on my own experiences and observation in the software industry and presented them to the team. They loved the concepts, and management and technical people felt there was a balance. I’ve brought up these anti-patterns in other organizations, and it seems to strike a chord. If you look at one set of behaviors (management or technical) be sure to look at the other side as well. I hope you find it useful.

testing, value

How do I Create Value with my Testing?

I wrote an article for EuroStar last year about creating value with testing. Some of you have asked for more specific ideas about determining whether your testing is creating value or not. In the article, I talk about getting feedback from stakeholders, but that isn’t always easy or possible. One of the most important stakeholders on any project is you, so how do you go about satisfying yourself with your testing value?

The easiest way to get feedback is from other stakeholders. What does your manager think about your testing? How about the programmers, business analysts and customers (users) of your software?

The hard part with that answer is you may not be able to talk to all of those stakeholders. Or, they may not know what good testing looks like so they won’t have answers that satisfy you. In some cases, the stakeholders around you may have such low expectations that their feedback might not help you at all. They may expect you to provide testing work that you might consider shoddy and negligent. In that case, you have to show them what great testing looks like. When that happens it’s like graduating from a cheap box of wine to the good stuff. Once they’ve tasted the good stuff, it’s hard for them to go back to expecting poor testing.

Even if you have good direction from other stakeholders, I recommend asking yourself some questions to help determine if you are creating value or not. This is hard to do, and will result in work for you over the long-term, much like personal growth endeavours. Don’t expect quick fixes, but if you work in these areas over time, you will see changes in your testing. Here are some things to think about:

  • Is my testing work defensible? (Cem Kaner, a lawyer and teacher of testers talks a lot about this.) Think of a court case. What would a jury think if you testified and described what you did as a tester and why. How did you determine priority? Why did you test some things and not test others? (100% complete testing is impossible, so you have to make decisions to optimize your work.) Are those decisions well thought out, or more subconscious? What sorts of things might you be missing that you haven’t thought of?
  • Do I have a superficial or thorough approach to testing?James Bach, a teacher of testers talks about how important it is to have thought out and varied approaches to testing. What kind of approach do I have to testing? Do I consciously choose to have a varied approach using as many models of coverage as I can to discover important information about the product? Do I make the best use of tools, testing techniques and management approaches that I can? Or do I just do what the programmers or someone else tells me to do?
  • Would someone I respect like what they see? In the absence of getting real feedback from real people on my project, what would happen if a well-known consultant came to visit me? Could I answer their questions about why I chose to test this way? What kinds of holes might they spot in my thinking? Would they see weak spots? More importantly, would I be proud to have Cem Kaner or someone else I look up to see what I actually do? (For example, I often share ideas with Jared Quinert, and if he shoots holes in my approach, I know it is time for a rework.) Have I used ideas from testing thought leaders in my work and found out what works well for me and what might not work so well? Could I communicate my work to an expert outsider clearly and thoughtfully? If so, what might they think?
  • Do I adapt my test plans and strategies from project to project based on the risks and rewards our project environment has at a particular point in time, or do I just copy and paste what I did last time, and repeat the same thing over and over?
  • Do I track down and find repeatable cases for important intermittent bugs, or do I just file them and forget about them?
  • Do I feel energetic, creative and proud of my work as a tester, or do I just feel like I am doing the same boring things over and over and filling in paper work and forms to please a manager?
  • Can I look at a released product and identify ways in which my testing has improved the product experience for our end users?
  • Do others on my team feel better with me around? Do they miss me and my creative input when I am away, or do they welcome the break from my negativity? Do they request that I work with them on other projects?
  • Is my testing service in demand? Am I the person team members come to when they need help solving a particular problem that I am really good at helping solve?
  • Am I aware of other approaches to testing that challenge my favorites? Do I understand approaches that I may not favor or I may even dislike, or do I just dismiss anything unfamiliar and threatening out of hand? Do I have an open-mind and look to challenge my ideas in testing to help improve?
  • Am I learning about different ways I could improve my work? Am I aware of recent changes in testing techniques and tools? Do I know where to find information to learn from?
  • Do I consistently try to do better than I did last time?

These are the kinds of questions I ask myself regularly. I don’t always have the best answers to my own questions, but as time goes on, I feel much more confident about both my own answers to those questions, and more importantly, the value I know my testing work provides.

agile, process, value

Content Pointer: The Next Wave: Valuable Products First, Process Second

I wrote an article for Modern Analyst that describes some of my process thinking over the past several years. They asked for a piece on post-Agilism, but I prefer talking about value now, so I wrote this piece for them instead.

I introduce my thoughts on a trend I have witnessed for a while now where people move from software ideas (let’s build this killer app!), to process (let’s go Agile!), to value (let’s ensure our application blows our customers away, and everything we do feeds that effort.)

Three years ago, I didn’t hear people talk about value that much at all. It was all process, process, process, and how following an Agile or other process would lead us to success. Now, I am seeing the “value” word pop up more and more, and more teams are using an overall vision to help focus their efforts (process and otherwise) towards creating value for their customers and themselves.