Skip to main content

Would W. Edwards Deming have a QA team if he ran a software company?


Would W. Edwards Deming have a QA team if he ran a software company?



For those of you who don't yet know where all this Agile stuff REALLY got started, here's some homework. reference: http://en.wikipedia.org/wiki/W._Edwards_Deming. The entire nation of Japan might be justified in thinking he's a pretty important guy. When I came across that article and it immediately forced me to question how any company that chooses to claim Agile development practices can have a QA team. My world was rocked just a little.

Fascinating bit of history there, isn't it? If you're cheating and haven't yet read that article while simultaneously not yet knowing the man, his philosophies on Quality, and are simply reading my blog post further, you're cheating. Seriously go read it. I'll wait.

For a quick summary, here are some important points to Deming's methodology:
  1. Quality is everyone's responsibility
  2. Eliminate quality control
  3. Encourage quality over quantity
  4. On-the-job training
In reading through that article and coming back to it from time to time, I've had the chance to crystallize some thoughts surrounding his philosophy. In general my perspective has evolved and these thoughts express how I see things working best, particularly in a mobile-first, software-as-a-service world.

Quality is everyone's responsibility

This one's an easy one. That statement warms my heart even if it comes from a man who would eliminate my job description entirely. I completely agree that Quality (notice the capital) is not the sole concern for the last guy in the production chain before a product ships. It's roots are set down by designers, strategists, and prototype developers who know how to identify risks and refine ideas and designs early in the production cycle. It must be actively and thoughtfully maintained by each person throughout the life-cycle of the project. It goes beyond just pride in your work by acknowledging the impact of your work on others and their work as well.

Eliminate quality control

I take this to mean remove it as a "final check" procedure and replace that with constant evaluation at every stage in the production cycle. This is reflected in practices such as Continuous Integration where developers are not off in the weeds on their own branches for extended periods of a project but instead aware in real-time of the impact their code changes will have on the overall project through constant testing.

I take it to mean that because I'm a QA Engineer, by profession. In some contexts you could correctly identify me as an SDET, in others a build engineer, in others a tester. It keeps my life at work interesting but the constant struggle to push for bugfixes can create tension between those in my role and those trying to ship a product quickly.

If you reference the Agile Manifesto's people vs. process line, that means identifying where your team believes a quality control process or drone will save them from shipping bugs. This is a Huge Problem(tm) for traditional companies to even imagine addressing. They have QA Managers, they have nice graphs, there are test plans, there are tool-chains (HP Quality Center et al)...  ...there is so much built around the notion that QA is a team, separate from the function of the rest of the team that it is easy for people to think QA is responsible for eliminating bugs. I've been asked "why didn't you catch that?" The developers in the room weren't asked "why did you write that?" It is insidious how much the over-emphasis on process offloads the responsibility for Quality onto the hilariously inappropriately named QA team. Just be a tester. Be a Quality evangelist too. But really, just be a tester. Everybody.

Encourage quality over quantity

My work is making it easier for engineers to demonstrate the success of their code by providing faster, more actionable feedback from tests. I'm able to prove the importance of quality by making it alive in detail through CI. The irony is that many in my profession are sent on Sisyphean missions to create piles and piles of test cases. Those responsible for ensuring quality can sometimes be tempted to generate test results from endless test plans and test cases to feel confident in a high standard of quality.

On-the-job training

Interestingly, this is one area where the software industry has the easiest opportunity and behaves the worst. On the one hand collaboration tools and pair-programming practices have made it very easy for senior engineers to mentor junior engineers and improve the quality of the team's output WHILE WORKING. On the other hand over-specialized job requirements (see the growing number of job requirements for "full-stack" engineers) and the purple-squirrel mentality in HR put pressure on the individual to come to work fully trained, with a demonstrated history and capability in every possible area where the company may need work done. Companies that invest in their employees and have systems in place that enable their employees to invest in each other do well here. I'm not talking about endless PowerPoint decks with hours of text to pour through. I'm talking about giving and receiving constructive criticism, portfolio reviews, open study, etc.

Final Closing thoughts

In the course of my post-college career in quality control and test engineering, I've worked in many industries though mostly software. These principles are universal. In order to really take advantage of these principles though, you need an organization that plays the long game. The sad fact is that with careers at any given company often spanning 2 years or fewer, with behaviors that are meant to optimize performance only over the short term, with pump and dump stock-price-motivated CEOs, investment in these principles is a tough sell. However despite having only recently learned about this Deming fellow and despite having an occupation he would certainly eliminate if he ran the company where I work, I find myself compelled to agree with his principles. I don't see myself as a test case wrangler, but as someone who helps teach all team members how to improve their quality and simply facilitates monitoring and feedback systems to that end. Yes, I execute tests. But my style is more exploratory. I investigate assumptions. In characterizing issues I've discovered through that perspective, I share that perspective with my peers and find that over time they begin getting better at managing those tasks within their workflow. It comes down to preventing bugs rather than focusing only on finding them and praying you didn't miss a bad one.

So that was a lot of text. If you're reading this and have some thoughts, please chime in by commenting.

Comments

Popular posts from this blog

Jenkins + Devices + AndroidJUnitRunner

New Android build system and test runner, same goose chase using undocumented features and hacks

As I've posted before, I am a big fan of Jenkins. It is extremely flexible, open source, and supported by a staggering array of plugins actively developed by engineers running over 100,000 instances of the server worldwide. With it's distributed node model, you can even build your own device cloud for hosting enterprise-scale automation, economizing hardware investments by sharing resources across multiple projects as well as speeding up automation by parallelizing test runs. I had been using a Jenkins-based system in the past to support instrumentation automation with Robotium quite happily. For the last couple years however, my work hasn't required that as much and I've found myself doing a lot more manual testing and using UiAutomator which didn't require a tight integration between the product codebase and the test code. As a result, I've been slow to adopt the…

UiAutomator and Watchers: Adding Async Robustness to UI Automation

"I'm looking over your shoulder... only because I've got your back." ~ Stephen Colbert
After my recent UiAutomator review a user brought up an important question about the use of UiWatcher. The watchers serve as async guardians of the test flow, making sure the odd dialog window doesn't completely frustrate your tests. Having a tool that automatically watches your back when you're focused on the functional flow of your tests is awesome. 100% pure awesomesauce. Since the API documentation on watchers is scant and the UI Testing tutorial on the Android dev guide doesn't cover their use in depth, I figured I should add a post here that goes over a simple scenario demonstrating how to use this fundamentally important UI automation tool.

In my example code below, I'm using uiautomator to launch the API Demo app (meaning run this against an Emulator built in API level 17 - I used the Galaxy Nexus image included in the latest ADT and platform tools). The te…

Run-As Like the Wind: Getting private app data off non-rooted devices using adb run-as and a debuggable app

"You're some kind of big, fat, smart-bug aren't you?"
~Johnny Rico, Starship Troopers (1997) One of the most important things about writing bugs is making them descriptive but concise. Screenshots, video, debug logging, and hardware snapshots are all fairly standard or available to Android testers these days and can save you enormously on text when communicating what constitutes the bug. Sometimes though, the app gets into a weird state due to some transient data issue where you may not own the API or the complexity with forcing the app data into a certain state is prohibitively high. In those cases it is very handy to directly inspect the data the app has in its own directories.

Getting at this data is trivial on emulators and rooted devices but due to file system permissions, this data is otherwise completely private to the app itself. If you're like me, you tend to test using devices rather than emulators and you probably prefer not to root your devices since t…