Select Page
Automate or die: Achieving continuous mobile app security and performance testing

Automate or die: Achieving continuous mobile app security and performance testing


Check this out! Recently, I had the privilege to be the first guest blogger for NowSecure, by far the leaders in mobile device security! These guys rock, and sweet lordie do they know their stuff.

The focus of the article was all about “Shifting Left” in that moving your testing earlier in the process and thereby reduce bugs, reduce product maintenance costs, get immediate strategic feedback on those products, and most importantly, get real value to your customer faster.
Check it out and let me know what you think.

IoT and the Wisdom of Mobile

IoT and the Wisdom of Mobile

Industrial revolutions come and they go. Their impact measured over time by the progress their disruptions brings and, typically, measured in how we reacted and evolved due to that disruption. Personal computing, the Internet, and Mobile devices are all prime examples of such massively disruptive forces and now the Internet Of Things (IoT) has taken the world by storm with it’s tentacles of connectivity growing exponentially by the minute. Sound a bit dramatic? Well, it’s not. With over 12 billion (yes, I said “billion”) devices connected today and 5000 more wired up by the time you’re done reading this article, the hyper-connectivity of IoT is here with it’s promise of dramatically increasing the quality of our lives.

Rough estimates give the IoT impact an economic impact north of $11 trillion per year by 2025. This is relatively the same about of fiscal value Mobile will have by then, but mobile’s been around the block a heck of a lot longer so to say IoT is the greater disruptor is an understatement.


Since Mobile’s been around so long, what have we learned from that revolution that can help us in this new connected age of IoT? A great deal, when you break it down! Pretty much all the big aspects of mobile development and testing can be applied to IoT.  From firmware on the device, to the network protocols and APIs they use to communicate, the security of those connections, the data transferred to and from the device are all existing technologies used in Mobile. Meaning we already have the knowledge to be prepared for and thrive in a hyper-connected world.  That’s a good part of the message.  The challenging part is in managing the scale, managing and maintaining the software on the devices, managing the increasing demands on APIs and big data management, and managing the increased security threats that this hyper-connectivity will create.

To that, security, data management, and test automation become even greater aspects of IoT that absolutely must be mastered to not just keep pace but, if you do it right, stay ahead of the curve.


Managing security, alone, is shaping up to by a big IoT market differentiator as the key threats research tells us, when breaking it down to it’s most simple form, is that you have more access points to a network generating potentially mass amounts of data about you.  Device fragmentation, over the air software updates, 3rd party API integrations, big data, and all of it networked are all the big challenges we’ve seen from mobile are all present in the world of IoT but at greater scale.


With the big friction points being security, data management, API management, and software and firmware updates to the connected devices, we see that we have the knowledge to thrive in the new IoT world!  Don’t let the hype scare you away from this new reality, that if you’ve been on top of your mobile game, which most of the industrialized world has for some time, then you have what it takes.





Start with what’s right.

Start with what’s right.


I’m a simple man. Hard as I try to look cool, I’m but a simple being. And I sure get caught up in the details of things more than I really want to.
What I tend to find, time and time again, is that the root solution to all problems, issues, and challenges is usually a pretty simple one. And, it seems like the more years I walk this earth the more I seek out the simple answer first and try to reduce the over analysis and complicated stuff that invariably ensues. At least I try to, anyway.

One of the mantras I evangelize to my teams is “Start with what’s right, not with what’s available.” I’m sure their sick of hearing me say it. I admit it’s cliché, but it’s truth. My point in preaching this is to push them to stop, take a big fat deep breath, and bring there awareness up to broader level.  In the case of test planning, it’s absolutely critical that you define your test scope based on what you should be testing, not just what’s available to be tested.  For example, one of the areas that gets skipped over for some software teams is performance testing.  They may not have the tools or expertise to pull off proper load testing so they don’t even consider writing up that test plan. They just focus on what then can cover in the moment and then hope that is good enough. Wrong…!

That’s lame.

I want to know what the RIGHT things to test are, regardless if I have tools or know-how or whatever.  I want to make sure I’ve got the best damn map of the land I can get. THEN, and only then, do I start digging into the logistics of execution.  That fact that I may not presently have a vehicle to get me from point A to point B does not mean that I’m stuck.  It’s means I have some tactical logistics to figure out, and that’s an entirely different problem to solve. Which, likely, has a very simple answer. Like maybe I’ll just ask to borrow my mom’s car? 😉



Why the hell “Guerrilla QA”?

Why the hell “Guerrilla QA”?


How many times has QA played the medic role at the end of a software release cycle?

Gaining great advantages due to its adaptivity, guerrilla warfare tactics closely resemble many of the same methods used by the QA organizations I’ve been involved with in that:

  • We’ve never had all the resources we desperately needed
  • We continually dealt with changing environments, requirements, and expectations
  • Improvisation, creativity, and heightened sensitivities to change have all been at the core of QA
  • QA has always been composed of many small, high-functioning, high-precision sub teams
  • QA has always carried a slightly rebellious flag given the nature of their work

This has been my experience thus far on my 19+ year march in QA land. Though I’ve been part of many successful and innovative teams I have much to learn and will enjoy being a student the rest of my life.
Plus, it’s a bonus for me that students tend to get away with being more the rebellious sort, which suits me just fine.

Guerrilla QA seemed to encapsulate my experience very efficiently and conjures a less-than-center attitude.
I believe that every QA team, no matter what discipline or technology, have gone through or are currently going through some level of challenges that force them into guerrilla tactics.
Assume change, value adaptability and precision with the highest regard, reward your teams for self-sufficiency and creativity, and never ever assume you have found all the gotchas.