That’s pretty much what CTIA’s 2013 show entailed this week in Las Vegas. Here’s a look at a few things we loved about CTIA 2013:

• Sessions: It was easy to love the sessions this year. Day 1 started off with the “Apps Summit” featuring the latest trends in mobile and a lot of talk around development and design. All the sessions were great, especially “Making Commerce Mobile: Strategy and Trends of Mobile Commerce” led by Sharon Wienbar, member of the uTest board and partner at Scale Venture Partners. The panel was also led by Jake Ward, co-founder and executive director at Application Developer Alliance, and others. The session looked at the latest trends in mobile technology, as well as the challenges brought on by device fragmentation and the ever changing mobile landscape. Another favorite was on day two, and was led by Michael Facemire, Forrester Analyst. The session titled “Technology Solutions for Today’s Mobile App Development Challenges” addressed the variety in mobile technology, time-to-market demands, UX requirements and how to overcome all of these challenges.
• E-Tech Awards: A big highlight of CTIA was the 2013 E-Tech Awards. Attendees voted and an online panel of highly-respected industry experts, reporters and analysts ultimately judged the submissions on “innovation, functionality, technological importance, implementation and overall ‘wow’ factor,” according to the CTIA blog. We’re thrilled that uTest’s Labs’ app analytics tool, Applause, took home 3rd place in the Enterprise Solution – General Business category. Congratulations to Ericsson’s Connected Vehicle Cloud and GPS Dashboard LLC’s “Check in” App for Salesforce.com, which took first and second place – and to all the nominees!
• Cool Brands: The Sands Expo Center was packed this week, with never-ending rows of new and upcoming mobile apps, development tools and countless other types of brands in the mobile space. We had a great time chatting with folks near our booth in the Mobile Apps Pavilion such as Kodak Developer, CallSnap and Speakerfy, as well as all the hundreds of attendees who stopped by our booth to talk about the importance of in-the-wild testing.

So what was the absolute best part about CTIA 2013?

Maybe you won big on the black jack table, or took a gondola ride through the Venetian – but for us it was the continued power of mobile. Every developer, QA Manager, or business exec we talked to, and every keynote or session we sat in on, was further validation of how mobile continues to be the driving force behind brands of all industries and sizes. Businesses know that their app is their brand and source of revenue – and they also know just how important app quality is. We love that.

So there you have it. A big thanks to CTIA for putting on a great show. See you next time, Las Vegas!

Today, he’ll talk about the biggest hang-ups teams have when it comes to testing, how to overcome those hurdles, how he became a fan of “gamification” in testing and a few other words of wisdom.

********

uTest: When speaking or consulting on mobile application testing, what’s the most common question you encounter and what’s your answer?

JK: This is the question that comes up the most after people have heard me talk about testing on mobile projects:

“Is it true that we need to test on real devices, incorporate movement, and test out in the real world, outside of the office?”

My answer: “Yes.”

Mobile technology has been developed to support movement, and it has a lot of dependencies. For example: networking (while moving you change networks, technology, and encounter lots of errors or weak signal conditions), location services (all about movement and spending time in different locations), weather and environmental conditions (temperature and light have an enormous effect on how some apps work), and movement (the devices have movement sensors, and are interacted with using touch screens and voice control. Combining inputs and sensors getting triggered from movement can be tough for apps to handle.). I know of no tool that helps us sort that out without getting physical with the devices. Hopefully we get better ones soon that focus on mobile technology, instead of treating it like a small PC/web browser. 

uTest: You work a lot with startups, when there’s a shoe string budget how do you communicate the importance of testing and QA?

JK: A successful business requires execution on several dimensions, for example, understanding your customers and their needs, having a great product or service offering that solves real problems for people, having enough investment to enable you to deliver, and a strong grasp of your financials. These require different skills and focus, but there is an over-arching need to create value for your customers, and part of that is great customer service. Technology fits directly into that, especially as we view organizations through the window (screen) of a smartphone or tablet. A poor technology experience is another type of poor customer service, so there is a direct line there. If you let down your customer or provide them with a poor first experience (which we are finding is increasingly on mobile devices), you can lose them forever. So not only do we need to have great people skills and a good strategy for satisfying and impressing our customers in our human interactions, but in our technology interactions as well.

A lot of people don’t realize that we are evaluated on our ability to deliver on the technology front, and that technology is a major part of customer service. It fits into the customer experience, but also in our offering of a product or service. Does the technology help, or hinder? Do we have an awkward experience, or is it seamless. It also has an effect on investment and financials, even if it is indirect. A quality product and technology stack is vital to the success of a business over the long term, so we need to invest in ways to make sure that we meet our customer’s needs there as well. Good quality processes, development and testing are part of that, and we ignore them at our peril.

uTest: Part of your consulting work is to help teams adjust to methodology changes. What’s the biggest hurdle these teams need to overcome and how do you help them do that?

JK: Dealing with people issues – different individual people with different agendas, motivations and fears. On one hand, you have people who have bought the marketing of a methodology and think that it will cure all ills. On the other, you have people who are deeply threatened by the change the methodology represents. It is a difficult balance to reign in the exuberance and unrealistic expectations of one group, while encouraging the laggards to get on board and actually try it out. I spend a lot of time myth busting on both groups. The methodology will not make everything perfect (and it won’t work forever), but it will also not cause you to lose your job, or cause bad things to happen to you. I work with teams by doing – getting in there and demonstrating, and helping address their fears. If I can do it, anyone can do it.

It’s also important to help them be able to measure the success of their methodology adoption in real terms: better product, better customer service, saved costs, etc. Just measuring success on adopting a new process misses the point, and will lead to some difficult situations down the road, particularly if that new process isn’t helping you create value for you, for your team, for the company, and for your customers.

People issues are hard to cope with. They aren’t fun, and it means we have to confront people on difficult topics. However, healthy disagreement and healthy confrontation are good, healthy things. If we suppress conflict, it just goes underground. We reach peaceful solutions through negotiation and co-operation, not by suppressing them in a need to “be positive.” There is also nothing quite like trying something out and seeing whether it works or not. Evidence, generated by a team that is committed to getting results, not just in implementing a methodology change, is powerful, and helps build teamwork and consensus towards reaching goals. Talking is one thing, doing and getting feedback on how we are doing helps enormously.

uTest: You’re a fan of “gamification.” What drew you to this concept and why do you think it works?

JK: My colleague David McFadzean can take the blame for that. David and I were looking at various topics: using uncertainty factors and monte carlo simulations when estimating software projects, game theory ideas for helping teams organize their mix of processes, tools, technology and internal policies, and engagement, particularly with regards to mobile apps. I do work in mobile strategy, mobile app design and product management, and I was working on formulating my thoughts on mobile design and dependencies. David kept pointing out how I had used game theory ideas, or gamification ideas in my work without realizing it, so eventually I gave in and started looking at it more seriously. At first, I thought gamification was childish, but he urged me to look into it more deeply, and I was surprised at what I learned.

David is a video game enthusiast, so we started looking at video game design ideas and how they could be applied to a project we were considering working on. I then discovered Jane McGonigal’s book Reality is Broken, and I loved her game creation, the research she had done regarding video games, and her positive urging to help solve real world problems with games. I’m not sure she would agree with how I implement game concepts on software projects, and how I have worked to make software testing activities more like a game (she’d likely prefer we made a real game out of it, rather than gamify something else), but I owe a lot of my energy and inspiration in this space to her. I am drawn to her positivity and her challenge for us to do better things in our lives and to help harness collective productivity to solve problems.

It works because it is a powerful engagement model. Just look at how much time people play games on mobile devices. The game designers are tapping into something powerful, and they know how to develop great apps people want to engage with. Gamification when done well helps motivate people to return to use our apps over and over, and they feel drawn to the activities within the app. Games help provide intrinsic rewards – Jane McGonigal calls games “hard work that we like to do.” Many times, especially in software testing, we avoid the hard work because there is no inner motivation. We just have to do it because it is our job, or it is someone else’s job. I have had success in the past by making testing interesting and even fun on software development teams. It is not uncommon to work on teams I lead where everybody tests, and sometimes it’s hard to get people to do their other jobs like programming, analysis or project management because they are having fun testing.

Gamification isn’t the only engagement model, and because it became a bit of a buzzword, there is an enormous amount of bad gamification out there. But, if you take the time to analyze it systematically, determine that it will be a good thing to try in your software or system, and put the time in to create it from the ground up, it can be a useful tool.

uTest: You’re quite the prolific writer. What’s your favorite topic to write about – the one you never get tired of?

JK: Anything that helps people look beyond their current problems, to look at the big picture and inspire them to create great software. It’s easy for us to get caught up in good practices and tools, and forget about the people we are developing software for. While tools, practices, processes and things like that are very important, they should all serve our efforts to create great software. We often forget that and put other things ahead of that effort.

One thing I never get tired of hearing from people who read my work, is when it helps them. Especially if it inspired them to change their world for the better, even in some small way. That’s always my goal – to inspire people to do something better, and hopefully my experience resonates with them and they can enrich their own experiences by building on those ideas.

uTest: What new thing/trend/innovation are you keeping your eye on at the moment?

JK: I’m watching mobile or pervasive technology that utilizes movement (gestures, eye movement, etc.) rather than depending on keyboards and touch screens. This is a fascinating space, as devices become more embedded in our lives, and (hopefully) easier to interact with. It is also interesting to imagine the unintended or unwanted consequences. In many ways, we are just scratching the surface of what mobile technology can do for us. Mobile technology has taken a big step forward with smartphones and tablets, and network speeds and reliability are getting there, but have a long way to go yet. It reminds me a lot of the rise of the world wide web in the 90s. There is so much potential for fascinating tools, usage and effects both positive and negative on human behavior and interactions.

uTest:   Any brand new advice or words of wisdom that we can be the first to share?

JK: This is a tough question to answer. I think I will leave you with a thought about the lack of permanency in our industry, particularly with regards to software development processes. As a consultant I see a lot of people working very hard to implement a tool, practice or process change, expecting it to solve a lot of their problems. People will push to get something through, hoping for great success, sometimes sacrificing their health, their emotional well-being, and sometimes even political capital or their reputations to try to get adoption. While that particular solution may help, it won’t last forever. We need to adapt and change, and sometimes it really isn’t worth that personal sacrifice. If the team doesn’t want to adopt a tool or practice or development philosophy, there are most likely deeper issues that need to be addressed first.

The hardest problem to point out to people who are desperate for change is that no one solution will last forever. Everything changes, so this new state is not static and is not permanent. Once you have overcome this hurdle, there will be new ones. Many lottery winners have to go back to work, rock stars have to release an album and go on tour when their kids need an expensive university education, etc. There isn’t a lot of permanence in life, so we need to be open to adapting and changing. Getting to X, whatever X might be, is not a permanent solution. It’s just the best next step of a journey. This also applies to our software development processes. What worked last time may not work next time, so we need to carefully evaluate what we do on the basis of how it helps, and to be able to know when it isn’t helping us anymore. Implementing Scrum, buying a new productivity tool, or creating a fantastic new mobile app isn’t the end of the road for us. We haven’t arrived, it’s just (hopefully) the right thing to do at the time.

In this journey of life, we don’t really arrive until our journey ends at the end. Similarly, on software projects, if we get arrogant or complacent and think we have arrived and don’t need to adapt, we are probably already dead. We have to constantly change and adapt to new technology, to market and economic forces, to evaluate new tools, practices and processes and adapt our mix of those elements frequently, or else we will fall behind.

Our Testing the Limits guest this month is Jonathan Kohl, a consultant and technical leader who writes and speaks on a wide range of software development and testing topics.

In this interview we talk to Jonathan about his passion for the field, what’s changed over time, his take on mobile app testing and his advice for new and seasoned testers. To learn more about Jonathan visit his website or follow him on Twitter @jonathan_kohl.

********

uTest: I think it’s safe to say that you’ve jumped into the world of software development and testing whole-heartedly. What drew you to this field and how do you stay passionate about it?

JK: The bottom line: I love to build things, and creating great software with a talented team is incredibly rewarding. Knowing that we have created something that helps make people’s lives easier is gratifying. I have found an ideal mix of problem solving, technology, creativity and satisfying and impressing customers in the software development industry.

I have great friends in the industry, and we keep each other sharp, and work on side projects together. We can talk about the latest technology, tease each other about programming tools we like and dislike, or branch off into just about any topic when we’re together. We also serve as a great support network for each other when someone is struggling, either technically, or personally. When we are working together to solve a difficult problem, nothing describes that energy of collaborating and working past your weaknesses, and that triumph of shipping working software at the end.

I ended up in this field by accident – I got lost on my way to law school. In the mid 90’s, I had three university professors who were incredibly influential: Dr. Michael Kubara (Philosophy), Dr. John Rutland (Management) and Dr. David Cowan (Mathematics). I was taking logic and philosophy classes from Dr. Kubara, and he told me to talk to a Math professor because I was delving into territory that he didn’t have expertise in. Dr. Cowan was teaching me Linear Algebra at the time, and jokingly said: “What are you doing with this ancient logic when the real research is in computer science?” Dr. Rutland had us study Data General for his class, and I was reading Tracy Kidder’s book The Soul of a New Machine.  The quirky nature of the technical people in the book appealed to me (I was playing in a band at the time, and read legal journals and philosophy papers in my spare time, yes, I was pretty quirky myself) and I loved the elegance of logic, and the questioning nature of philosophy. I agreed to try out a computer science class, and ended up getting sucked into an internship at a software company not too long after learning to code.

The software company reminded me of what I had read in Kidder’s book Soul of a New Machine, particularly the interesting, intelligent technical people. I enjoyed hanging out with them, and working on really difficult problems. I loved the fast paced, work-hard, play-hard culture of a software startup. I’ve stayed here ever since, with a brief trip back to university to finish off my undergrad degree. Once in a while I am tempted to pursue the law degree again, but I am invariably sucked back into a great project or opportunity.

uTest: You were an early adopter of Agile and later started talking about “post-Agilism.” What are your thoughts on the Agile movement over the years? (Since you could probably write an entire book on this topic give us the dust jacket version.)

JK: I started looking into Agile methods when I was working on a team in 1999 that was trying a combination of Rapid Application Development (RAD), Open Source, and iterative/incremental models like Spiral. The lead developer sent us this article called “Chrysler Goes to Extremes” which described the very basics of Extreme Programming. We liked that it was open and free (we didn’t have to purchase some tool chain and coaching we couldn’t afford) and we started trying some of the ideas out. We then bought the book “Extreme Programming Explained” by Kent Beck, and started implementing XP as best we could. A year later I was introduced to Scrum, and we had good success with it. After a while, I started noticing failures on Agile projects, and people moving on and doing other things. That was fascinating to me. Sadly, instead of learning why there were failures, there was an overwhelming urge to suppress them, or worse, dehumanize people by blaming them for doing it wrong.

As for Agile methods in general, I am ambivalent.  I am glad that lightweight methodologies are much more common place than they were in the ‘90s, and we have benefited from creating a common language around practices, and our tools are so much better now than they were ten years ago. I enjoy working on many Agile projects, since they fit my process and personality, and how I like to work.

However, there is a lot of snake oil out there, with proponents claiming that merely adopting Agile methods will lead to a successful business (What about having a great product, great customer service, skilled people and strong financials? Don’t those sort of matter too?) That really turns me off.  Furthermore, for years, any Agile failure would inevitably involve blaming the victim: you did it wrong, you don’t get Agile, if you were really Agile it would have been a success, which often sounds like another variation on the “no true Scotsman” argument fallacy. Sure, sometimes people fail because they made some mistakes, or didn’t commit, but every Agile project that fails can’t be blamed on the people.

We should elevate people above processes, practices and tools, not make them subservient to them. The people come first, not the process. Also some of the Agile gatherings feel very religious to me, with conversion stories, wild eyed claims that aren’t questioned and lots of zealotry. Those sorts of meetings make me feel very uncomfortable.

There is also a lot of rigid thinking about implementing Agile methods themselves – do it by the book, or the way the coach describes, and once you have reached a level of mastery, only then may you adapt. That smacks of a priesthood, and that bothers me. I believe teams know what is best for themselves, and should be self-determining in a mix of tools and processes that helps them create valuable software for their customers, value for the shareholders and owners of the company, and value for their teammates and themselves. No one should have the right to dictate how you do that. It’s a personal decision, and in an industry with so many organizations, people, fields and different contexts, there is no such thing as a “one size fits all” solution. By all means gather expertise and learn from people with more experience and different ideas, and really try out concepts instead of just prefixing “Agile” in front of whatever you are doing, but don’t stop there. The world is not a static place. What worked last release may not work the next one, and you have to adapt in this business or fall behind.

Post-Agilism was something I observed that reminded me of post-modernism in architecture and art. Modernism is more rigid in rules of how things should form, while post-modernism rebels against that restriction, and people use combinations or mashups of styles to solve a problem. The problem is solved in the end, just by different means. We see this in music, where much of popular music is a fusion of what has come before, and in much of the food we eat, which is a fusion of many cultures and tastes. I saw this group of people who were grasping their own freedom to create value, not just follow a process. They were not being dictated to by consultants, coaches and books, and were taking information and ideas from many sources creating mashups of processes, tools and technology to create great software. They often had high morale and a good deal of creativity and retained staff, so they were also creating value for themselves, something that gets overlooked if you just think of value as “business value.”

That was interesting to observe, especially at a time when “being Agile” was held up to be the most important thing, and people were losing sight of why Agile was supposed to help us. I felt so strongly about this, in 2009 I presented a keynote at the Better Software conference: “What’s More Important: Being Agile or Creating Value?” I’m happy to see “value” as an overarching concept now on Agile projects, but we still have a ways to go. (There is more to value than just “business value” for example.)

Post-Agilism, as I observe it, is about freedom, about giving you and your team permission to experiment and figure out your current mix of processes, practices and tools to help create value. There is nothing wrong with Agile methods out of the box if they work for you. But if they don’t, or they stop working for you, don’t be afraid to experiment and find your own way, no matter what the Agile experts say. If what you do works, but your Agile coach doesn’t like it, seize your freedom anyway. Post-Agilism is about using what works for that release, and jettisoning what doesn’t.

That way of thinking is heresy to some of my Agile friends. They are great people, but they prefer if you do things the Agile way. I like to see a mix of old practices, new practices, and things in the middle on a team that is doing well. If whatever weird and wild combination of what they are doing works, that’s great. If it works and I haven’t seen it before, that’s even more fascinating. I don’t need to call it Agile or something else. It’s your process, name it what you want. Many of my Agile colleagues are more purist, like the modernist architects. It seems like they are saying: “We want you to create valuable software, but we think it is better if you do it according to the commonly accepted practices of this community, using these approved tools, techniques and practices.” While they might be right in many cases, I want to let people know they have the freedom to choose what they want as well, even if it isn’t something I or my colleagues personally like.

One of my colleagues told me about a team that had implemented Scrum, but were having some quality issues, so they implemented software inspections as well, a very old school tool. They had great success with this mashup or fusion of old and new. My Agile friends are rarely very supportive of this sort of thing, (it isn’t Agile) but I think it’s great. I love to see creative solutions that teams use to create great software, and value for themselves as well as the business. There is so much we can learn from others who do things differently. Furthermore, new technology changes the dynamics, and Agile methods were created in the 1990s, so some new technology projects find they need to adapt processes as well because they may not have the easy fit with Agile process or tool support they had when developing with older technology.

Another area of contention in the Agile movement for me is testing. Many Agilists think manual testing is a bad thing, that all tests should be automated. I prefer a blend, especially when humans are the customers of the software we develop, we need some human involvement, since they use the software. Especially with pervasive computing, like mobile technology, movement and human reactions to the technology are very important to capture, along with tech solutions like test automation. The technology augments, it can’t replace. I have also worked on systems that bridged different computing systems, and most of the testing was automated – our customers for our software were other computers. We still had some humans doing work though.

If labels matter to you, Post-Agilism has a home for you if the Agilists don’t like your weird mashup. If the Agile world works for you, then more power to you and your team. If you are doing something that defies categorization, then that is even better! Take pride in your individuality and uniqueness, don’t feel like you have to follow the crowd. The software we create should be valuable for all the stakeholders – that’s the most important thing, and all processes should help serve that, not the other way around. Be different. Be you. Do some amazing things, and then tell the rest of us about it.

uTest:  Your eBook Tap Into Mobile Application Testing is extremely thorough and easy to consume. What motivated you to create this ebook?

JK: Thank you for the kind words. I couldn’t find a book that dealt with testing modern touchscreen smartphones and tablets. I had experience, and a lot of people asking for help, so I agreed to write a book to help people who are either transitioning to testing mobile from traditional projects, or people familiar with mobile technology, but new to testing. I also created a 2 day training course for the same reason, to help spread knowledge and experience for those looking for a head start.

My wife Elizabeth was the primary motivation behind the book. She really encouraged me to just do it. I had started a book on Agile testing back before I started to lose my faith in Agile methods. I found that if I deleted the word “Agile” out of my manuscript, it was really about testing in different environments.  The key with being a great extreme ironing practitioner isn’t about where you do the ironing, someone has to teach you how to iron clothes first. I wanted to talk about the nuts and bolts, not the environment. That wasn’t my passion – that was someone else’s book. Next, I tried to write a book on exploratory testing, but that’s really a topic I thought James Bach or Cem Kaner would be better suited to tackle. I lost motivation on it and it sat there. Finally, I had a co-authoring project fall through after a lot of effort. That was quite painful, so I wasn’t sure I had a book in me or not. Elizabeth really encouraged me to just write, so I did, and soon I had 400 pages of material. I hope people find it useful.

uTest:  If someone is looking to become a mobile app tester where do you suggest they start?

JK: I would look at resources like my book, look at online forums, discussion groups and articles on blogs you can find, and try a Weekend Testers virtual meetup when they have a mobile theme. Weekend testers is a fantastic place to start and learn. Also, consider contributing to open source projects, they always need help, and it’s a great way to build your experience.

On your own, watch your own mobile usage, and for anything that you find confusing, or note specific examples of when mobile technology lets you down. The systems and software should work for us, not make us feel confused, stupid or frustrated. Combine testing (careful observing and evaluating) with what you know already, and learn about the technology so you understand why or how it can fail, and note anything that bothers you and let the team know about it. After all, James Bach has said, a bug is anything that bugs you. And if it bugs you, it will bug lots of other people.

uTest:  On the flip side, if someone has been a software tester for decades, what’s the best way for them to keep their skills sharp?

JK: It’s important to develop an awareness for new technology information, and just try things out. Don’t be afraid to say you don’t know something, and to get in over your head and ask for help. Testers often take a wait and see approach, because we get brought in to projects once technology questions have been settled, but that means we often get left behind, or aren’t consulted early on in projects. I do the following:

• Read continuously about new technology and announcements.
• Encourage my techie friends to share interesting tech stories with me, and I share with them.
• Try something out that interests me – download a tool or try something out in a store.
• If I get stuck, I ask for help. I have a great network of friends with diverse skills, so I can usually find someone to help bail me out, and then we learn from it.
• Strategically position myself to work on new technology projects that I find interesting.

There’s more! Read Part II of the interview.

So what should one do if they find themselves in this situation? Play Spider Solitaire? Chit chat with co-workers? Name all the South American countries on Sporcle.com? While those ideas are well and good, there are slightly more productive ways of spending your free time. Here are a few suggestions:

Make sure you’re really done! Of course, in the broader sense, there is no such thing as “done” when it comes to software development projects. Certain tasks might be done – iterations even – but there is always work to be completed. This especially true if you’re working in an Agile environment or adhere to continuous integration and testing. Here’s an excerpt from a recent Gartner report on agile development on the importance of properly defining “done”:

It is important that the definition of done be comprehensive. Because of agile’s focus on finding the simplest solution to the problem, there is a tendency to try to have no design, end user or operation documentation. This should be addressed by including the required documents in the definition of done. Done can include a review by stakeholders such as architects, database administrators and security/compliance officers.

Consider the corner cases. This one is specifically for testers. It can be tempting to complete a set of test cases and consider it a job well done. But as others have pointed out, many serious issues won’t be discovered this way. As Michael Bolton once wrote on our blog:

“Real testing, to me, should be based on investigating how the software allows people to deal with what we call ‘exceptions’ or ‘corner cases.’ That’s what we call them, but if we bothered to look, we’d find out that they were a lot more common than we realize; routine, even.”

Figure out what’s next. This is for the independent contractors out there. This very honest answer comes from the Dice.com thread mentioned earlier. Take a look (emphasis added):

All of my projects in the last two years have been completed on time, ahead of schedule or way ahead of schedule. As a consultant working for a client finishing a project early can end my gig early. Try looking within the company for the next project to manage or at least get involved in some existing project as a facilitator. The bottom line is you want to do the best possible job for your client, even if that means you’re looking for another engagement sooner than you had planned. If you just keep busy you hurt the client and yourself. Keep your mind fully engaged and active. Even if the client doesn’t mind paying to keep you on hold until another project comes along, unless you’re in your cubicle studying for a certification or earning PDUs, you’re going to disadvantage yourself in the end.

What do you do when a project is completed ahead of schedule? Let us know in the comments section below.

Since then, Applause has received quite a bit of attention. It is currently a finalist for: the 2013 CTIA E-Tech Awards in the “Enterprise Solution – General Business” category; the 2013 MITX awards in the “Most Insightful: Big Data and Analytics Innovations” category; and the 2013 Stevie Awards in the category of “Tech Innovation of the Year (up to 1,000 employees).”

Well we’re proud to add to that with some great news: Applause has been selected as a “Cool Vendor” by Gartner in the *”Cool Vendors in Mobile Marketing, 2013” report. The recognition comes less than two months after the launch of the Applause Index, the first-ever stock market-like index for the mobile apps economy, and just a few weeks after Applause expanded to begin crawling apps in the Windows Phone Store.

Gartner’s “Cool Vendors in Mobile Marketing, 2013″ “reflects a focus on the areas  Gartner believes form the foundation for any good mobile marketing strategy: platforms, analytics and the ability of a brand or service provider to tie online and offline worlds via mobile devices. Each of the vendors profiled in this year’s research enables or provides one or more of these areas.”

As we know here at Blog Central, mobile apps play an increasingly vital role in how users consume content, conduct commerce and interact with companies.

”Mobile marketers, mobile app developers and digital marketing leaders all have a substantial stake in understanding user engagement with their mobile apps. Flying blind or looking at download metrics alone isn’t sufficient for managing growth and monetization of mobile apps,” stated Gartner in the report.

*”Cool Vendors in Mobile Marketing, 2013” – Mike McGuire and Jake Sorofman, April 26, 2013

If you haven’t noticed already, be on the lookout for:

• New Streamlined Organization and Navigation – We’re retiring projects as an organization method and now enable you to assign your internal team members at a product level.
• A New Start Screen – When logging into uTest you’ll now be greeted by the new Products page. Be on the lookout for additional changes here soon.
• Improved Search – You can now search for Product and Test Cycles from anywhere within the uTest platform.
• New Team Management Controls – Teams can now be created and assigned at the company level.

Coming soon:

• A brand new testing scorecard view
• New filters for sorting issues
• One-page test cycle description reviews
• New ways to manage and select your favorite testers
• The ability to customize your notification preferences

Learn more and stay up to date about the latest features >>>

And of course, if you’re new to uTest and don’t know what this all means, be sure to check out our product tour and intro video.

Ars Technica outlines some of the major issues, while Reddit has a deeper and more technical explanation. Here’s a quick summary:

Deep inside the kernel, in the performance counters subsystem, is a rather innocuous looking signed integer variable. However, in other portions of the code, the same variable is treated as an unsigned integer. The problem is that it’s possible for a user to provide a very large unsigned integer to the process, and when that unsigned integer encounters the signed integer, it gets transformed into a negative number. That means that while I might input BIG_NUMBER, once it finally percolates through the code it becomes -DIFFERENT_BIG_NUMBER.

If you’re a former C developer, you’re probably starting to see how this goes wrong. This particular integer just so happens to be used as an array reference, and C is perfectly happy to reference anywhere in memory an array reference says to look. A clever attacker can use the incorrect negative index to write data into invalid portions of memory which are eventually executed by other processes. Both the bug and the exploit are pretty classic and standard stuff.

The fix is remarkably simple: change the signed integer to an unsigned integer. Most people will need to contact their Linux vendors to get an updated version of the kernel, while those who are true diehards can of course compile a kernel themselves. Either way, if you manage a Linux machine of any kind, you should definitely upgrade as soon as possible. An exploit is already floating around in the wild.

More details are also available from Red Hat. This is CVE-2013-2094, for those of  you keeping track of such things.

We’ve examined and listened to arguments in favor of one versus the another – agile is more fluid and responsive, waterfall is more practical, agile people are flakes, waterfall people are dinosaurs, etc. etc. etc. We tried to be neutral, giving equal weight to the arguments of both sides. Our aim was to educate you – dear reader – in the hopes that we could help you make the right decision when it came to choosing a methodology.

What a waste of time that was! Well, only if you believe that the war of methodologies are over - an idea that was raised in a recent article on PCadvisor.com, and one that I felt was worthy of further consideration. Here’s the gist:

The wars over development methodologies — agile, XP (extreme programming), waterfall, and so on — are  fast giving way to a more fluid and flexible approach to producing and refining  a product. Telerik’s Semeniuk is one of many in the modern development world who  sees development methodologies not as dogmas to be followed to the letter, but  toolkits to be raided for what’s useful. Confining a development team to one methodology is becoming a thing of the past.

In other words, if you are a methodology fundamentalist – that is to say you never waver from the playbook – then you are likely missing out on a number of tactics that can improve the development (and testing) process. Case in point:

Some, however, caution that agile can’t simply be sprayed onto an existing  development process. A former program manager who has declined to be named but has five years of experience as a Scrum master has time and again seen agile used in development, but with no corresponding changes in other facets of  bringing software to market.

“There’s no intermittent QA; instead, there’s old-school ‘toss it over the  wall to QA’-style QA,” he says. “Instead of regular releases, they’re using agile to get a release out, then having the schedule disrupted by support.” In  his purview, there has been a battle between traditional software releases and agile, with a lot of people simply using agile merely to drive old-school models.

So what now? On the one hand, you can continue to stick to the rigid rules of the methodology of your choice. Or you can accept the notion that every methodology has something of value, and to borrow those elements as they are needed.

What are your thoughts? Do you believe the methodology wars are coming to an end?

Please sound off in the comments section below.

For those unaware, Press: Here is a Sunday morning roundtable discussion show featuring the top names in Silicon Valley’s tech industry. Yesterday, Press: Here host, Scott McGrew, along with Fortune writer, Michal Lev-Ram, and eWEEK editor, Chris Preimesberger, asked Matt about uTest’s expert-sourcing model, the apps economy and the factors that make an app stand out and succeed. Check out the video here:

From Cartoon Tester:

If anyone creates Software Bug Twister be sure to stop by the uTest offices so we can play!