Agile QA In The Millennial Age

Well, it's coming to our second decade of this century and oh what a feeling!  We've seen many changes in our lives.  From our first African-American President, women being appointed to the Supreme Court in numbers, marriage quality, well, we've seen progress and change.

Our software has also been changing.    It used to be Cobol in batch systems, now it's a mixture of Ruby on Rails, Java, J2EE, Hadoop, HBASE, clouds, JSON, AngularJS and so many others live 24/7 and in charge!  We're object oriented to the hilt, can trade on nanoseconds, and have become our own Jessica and Johnny Mnemonic's!

A new , well maybe not so new, SDLC is a must for anyone seeking to be relevant in this landscape , and that is "agile".  Agile is not just one thing.  By definition it is a way that allows you, in short time increments to: develop user requirements, develop the story around those requirements, develop software, test it, ship it, continually learn and improve the process, get to the next cycle, keep it moving.  IT also allows you great flexibility as to time, the definitions of time, your measurements of time, the weight of time, your processes and players.  It's very interesting, very cool, very fast, and very unforgiving to mistakes for those not willing to admit to them.  It exposes how well you do anything, from planning to implementation, from conceptualization to actual product.  It's simple; hit your own goals or you fail.

At this point, I've implemented Agile, and I've heard how great it is over and over again. Mmmmmmmmmmmmyeah!

It's fine, but you still have to make software.  That means that in order to learn you have to have some documents.  These documents outline what the hell you're going to be developing.  Agile , when working works when things are understood.  When they are not understood, they stop being worked on until they are understood.  That means pushing it out to the next iteration, or simply canning the current iteration and restarting anew with the refactored stuff in mind, losing time.  You get NO INSERTIONS.  INSERTIONS are NOT WITHOUT SACRIFICE.  Well, at least they shouldn't be.

Some people see agile....wait, what is agile again....well from my vantage point it is simply, what we used to call, "rapid prototyping" or Rapid Application Development bka "RAD":

http://en.wikipedia.org/wiki/Rapid_application_development

Anyway I put this up to indicate a history of Agile that it is not new and it came from someplace.  And it is a 20th century concept, all be it a late one (90's).  So what's the point?

Agile is good when coupled with great practices and a very rigid doggedness to the rules of engagement once established, with flexibility around the edges of implementation.  There are things you simply cannot forego, such as :Documentation, metrics, planning, common understanding, testing, test plans, acceptance criteria, code freezes, analysis, UAT then promotion to production.  They take time, and that time should be spent as part of the iteration.

So you want to do agile after all of this? GREAT.

My QA Ten Commandments of Doing Agile Right:

1.  Your team is no larger than 10.  If it gets larger form another team with different goals.

2.   Designate the Scrum Master, Product Owner, and the rest of the team.  Scrum Master has to deal with tickets; stop crying.

3.  You will not get this right for almost a year.  So get ready for much learning.  You're gong to make mistakes, cut your own corners and really mess yourself up, so knowing this, try to stay traditional SCRUM Agile (minimal template) until the team is really moving and ready to make improvements.  If they cannot execute in a simple SCRUM there are other issues.  Fix them!

4. Make sure QA's Automation suites and programming of them are in place before the first bit of code hits them.  Account for this infrastructure task in the iteration.  The first SCRUM you do should be building your "machine", testing it out with the basic code, and learning your cadence.  The FIRST mistake people make is the first sprint with a full product in mind.  No, the idea goes to product functionality; start small, plan small and build from there.

5.  QA teaches the team to test, not the other way around.  Got that, tough guys?  If you could test so damned good, you'd be a tester.  If we could develop so damned well, we'd be QA.  See the difference?! :D  The team lets the Test Specialist know how the system is going to be constructed. QA informs the team where they’ll be probing for vulnerability so that the team pays special attention to the unit and integration tests they will build to validate functionality.   It's a cooperative effort not a gotcha.  We all have  game plan; "You're going to build, I'm going to test every thing you make to make sure it's the highest quality output of the team's efforts."

6. Documentation is good.  Try to limit it to one page documents, even if there are a lot of pages.  Test cases should be isolated, unless you're testing e2e.  Functional Tests should be limited to single functional measurement (i.e. what it takes to fully exercise the function)

7. The team is supported by an E2E Team tasked with testing the system in an E2E fashion.  This will also take time to develop and may sit in one of the weeks during the iteration.  What, that slows you down?  No, you'll be planning your next iteration, and that'll take days or weeks or more, you can be at the ready for any issues that come up from testing.

8. Write defects, and lots of them.  If Dev says something is ready to be tested, well test it, and report.  That is our job.  Bugs are not indictments, a developer should know when they are ready to test.  If QA finds something, time to retool, get additional unit tests, test your code and assumptions better.  QA informs how the defect was found, and works with the Dev to inform them of where they'll look for vulnerabilities.  This is not a gotcha, this is an information exchange to allow the dev to harden the hell out of their code.  That is what we're ALL after, bulletproof software.  

9. Use great Open Sourcey tools.  Jira is a great collaboration tool so is TestRails for manual and exploratory testing.  If you're an enterprise, buy them, as they are cheaper than others and have lower costs of upkeep since everyone now uses them.  Stay away from solutions that are $5k a seat.  No software should cost that much, and support should be tens of dollars a month or year at best.

10. Be kind to one another.  Testing is a team effort, our job is to make things better and to help make better software through teaching others HOW to test.  Destruction is a hard business and we get callous.  Especially when we find something careless, as we have to document it, blah, blah blah.  we want to find interesting things, but we're creating interesting software, small things will happen, buck up.  Ask for a raise, take some time off, do what you have to do but it's the small things that matter.  That's why we test!

 Enjoy, Agile is fun!

J