Friday, August 15, 2008

Linked In Question Posting

I just posted a question on LinkedIn,

The most interesting answer I got was a redirect to Chris Butler's Blog, It links to their "Project Anatomy" document. I like the ideas behind it.

To summarize:

"There are three specific steps dedicated to QA. The first two occur during the programming phase of the project, and the third occurs immediately after a site goes live. These QA steps are guided by involvement with almost everyone on the team, requiring a thorough review of every aspect of the site's design and functionality and producing a detailed report that we use to make any necessary corrections. However, there are two other QA steps in our Anatomy that aren't as immediately obvious, but are probably the most important."

The two items were Code Review and Integration. Code Review - is the Development group's role in Quality Assessment, and Integration is where Content Publishing and final fit and finish development occurs where the team as a whole is reviewing the deliverable.

They point to the key to QA is collaboration... hmmm do they have their own Scrum?

Very cool stuff - check out the other answers at my LinkedIn Question: Quality Assurance in a Web Design Firm - Where do you see it fit in?

Blog ya later!

Saturday, August 2, 2008

Writing up a bunch - but nothing is read to go yet - ah the life of a QA person - perfection is not the goal for this blog I swear!

Well while I finish up my next one - check out James Bach at Google...

Saturday, July 19, 2008

Scrum of the Earth? Scrum and QA.

Scrum?

First off - what the heck is Scrum? We talked earlier about it being an Agile methodology that seemed to be more Project Management based - because of that, there must be some more documentation and process about it. So, I did some more digging and found out the following about Scrum (taken from: controlchaos.com)
  • Scrum is a wrapper for existing engineering practices.
  • Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
  • Scrum is a process that controls the chaos of conflicting interests and needs.
  • Scrum is a way to improve communications and maximize co-operation.
  • Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
  • Scrum is a way to maximize productivity.
  • Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.
Next, are the Scrum terms, since they have a bunch which I have not seen before. I will "borrow" the definitions from the Scrum Alliance:
  1. Scrum
    • Proper name of an Agile methodology
    • Named after the rugby term SCRUM -- a group responsible for picking up the ball and moving it forward.
  2. Sprints
    1. An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint.
  3. Burndown Charts
    1. Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward. The Scrum books define a sprint burndown chart as a place to see daily progress, and a product burndown chart as where to show monthly (per sprint) progress.
  4. Backlogs
    • Product Backlog: The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
    • Sprint Backlog: Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
  5. Product Owner
    • In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
  6. Velocity
    • In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
  7. Daily Scrum Meeting
    • A fifteen-minute daily meeting for each team member to answer three questions:
        1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
        2. "What will I do before the next Scrum meeting? (i.e. today)"
        3. "What prevents me from performing my work as efficiently as possible?"
    • The Scrum Master ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.

OK - so here goes for a summary of Scrum now:
Scrum is an Agile methodology
So here we are, a whole lot of terms, and I can't see anything that calls out QA. The more I read - there are two schools of thought, QA as part of the Scrum team from beginning to end, and the other sees QA as an independent group that tests after the Scrum team thinks they have a deliverable product. If you choose the latter, I personally don't think you are performing a Scrum methodology - it's based on a team structure. The moment there is a "Throw over the wall" mentality, it's Waterfall and not Agile.

So, we shoot for Agile, what are the next steps? What do you do to get it going?

  • Company "Buy-in" - this is the biggie. No one will disagree with flexible collaborative design and development. But the practice of it - that's another story. No company can work organically and scale.
  • Training - Get everyone talking the same language and starting on the same foot. new employees should participate in trainings right after they start - to drink the company Kool-Aid and learn how the processes work at your company.
  • Restructure - Your "teams" need to be embedded with every participant to the project including the client. The forming of a dedicated team to the project raises the internal accountability, and eventual release quality.
  • Communication - Meetings are minimal - because the team works together. Reporting is not gut-driven, but milestone, budget and roadblock based. The client is brought in at the end of each sprint - eliminating long periods of time without seeing progress and therefore improving perception and customer satisfaction.
  • Change the perception to QA being just another "developer" on the team. Code is written with the requirements in mind and tests are as well. Because the project contributors are "embedded" with each other on the team, tests are communicated during coding as an "open book test" and issues can be found before the code is delivered to QA to review. Higher standards are created.
QA can do a lot of things on their own to help guide and promote quality deliverables and customer satisfaction, but without a total team effort, it can be tough and sometimes adversarial. Building the blocks for buy-in are my next steps. What are yours?

Informational Links:

Books:
Software:

Saturday, July 5, 2008

Can QA be Agile?

We are in an orderless world. Often it feels like the only barking order we get in the development lifecycle of a project from management is "get it done". What is inferred in that statement that is often lost on the masses in your deliverable team, is that management would like you to "get it done" in the following way:
  • On Time
  • On Budget
  • With a happy client (internal or external)
So you get the next website project handed to you. It's a 4 week development project, and the client wants one of the weeks for review with their internal staff. So with Design, Development and Testing you have 3 weeks to get something presentable to the client and one week after to implement all of their changes and get it to go live.

After the screaming in your head subsides (OH DEAR GOD NO IT'S IMPOSSIBLE, THERE IS NO WAY THIS CAN HAPPEN), you shake it off and see how you and your team can "get it done". Your management team thinks the "Waterfall" methodology is ancient and dusty and wants you to use one of the more flexible methodologies that they have read about recently, so you start surfing to read what they are about.

At a top level, you come across some intriguing development methodologies (Oh, there are more, but they all start looking similar very quickly):
  • Agile - (from the Agile Manifesto)
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
  • XP
    • An Agile method
    • Development-centric
  • Scrum
    • An Agile method
    • Project-centric - "they provide managers with tools to monitor, prioritize, and control projects without specifying anything about how the software is built." (testobsessed.com)
OK Agile Manifesto guys - sounds like something that everyone wants - less process, collaboration, working software, with customer interaction! What could be bad about that? I (Negative Nellie) read other things in your list: No documentation or customer commitment and constant change until the end. All of these things equal $$$ and potential instability. How do you guys get the client to commit to an idea, secure a budget, and stay within it with this method? I could not tell. So I surfed some more, and found:

"Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams with "just enough" ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders." (From Agile Modeling)

OK, the screaming in your QA head is probably starting again - and it comes in one word "HOW??" Have 4 deep breaths, and come back in a minute... Better? Good. Incremental in 3 weeks, hmmm - that doesn't sound like a fit. In 15 business days you need to understand what the client wants and make it. "Agile" is what your team needs to be, but the methodology sounds like nebulous and wishful thinking. When QA people get their hands on it (since there is no QA in the methodology theoretically), it then gets some structure to it.

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing. (From James Bach's Blog)

That sounds a lot more like something that can be utilized by a team. So then I found Elisabeth Hendrickson. QA's role is supporting the development team in their goals and the customers in validating that "they got what they paid for". QA is part of the development process from beginning to end. Overall, it's all about embracing change and planning for maintenance. Her high level bullets to describe an Agile lifecycle are:
  • Adapt
  • Collaborate
  • Get Feedback
  • Communicate
  • Deliver Value
  • ...Continuously
OK - she sold me. I dig it. I can't sell anything that is process laden, and over-planned to my management team, or the individual resources no matter how hard I try. Over-planned does waste time, and is loathed by all. But you can't have no planning - you have to have some way to manage client and team expectations, communicate - and it looks like with a little "structure" it can be done! Check out Elisabeth's Google Presentation for details:
So, with my 4 week project, the team should sit down and break it into logical chunks. Each chunk is an iteration unto itself, and each can be designed, developed (including testing), and run by the client as it is completed. That to me is worth a try.

XP and Scrum are flavors of Agile from different perspectives (Dev and PM). I had tons of opinions on XP prior to this blog, both positive and negative (The founding father of XP, described QA as, "irrelevant in the brave new world of eXtreme programming") as for Scrum, I see terms like "manage" and "control" so that tickles my QA fancy, but it may not be as "agile" as one would like - so I will get back to you on that.

In the cloud world of Web 2.0 with 3.0 biting on its heels, how do you as a QA person bring some order to the hip methodologies that are the recent big buzzwords like Agile, XP, and Scrum to name a few. Agile truly is nebulous, but has some good ideas that can be transformed into goals and a development methodology tailored to your company. XP has tools for how to get it done from a design and development perspective. Scrum - looks promising, with its communication points to management, and I will be looking more into that over the next few weeks. The biggest thing I can see, is that with all of these methodologies, if you don't have your test group work throughout the iterative lifecycle, you don't have an Agile process :)

Night all... more Agile thoughts to come on how to actually do it in a project.

-KZ

Quality Assurance Blog - Why the Heck Would you do that?

I have always said that you do not join the field of QA for the hugs. If you do your job well, people wonder why you are there at all, and if you miss one thing, they wonder why you are there as well.

I joined the field of QA by accident. I was hired in my early 20's to be a developer for the Mac version of an existing application for managing Head Start children's information. I had never written code outside of my Comp Sci classes in college - this was my first chance in the real world. I was TERRIFIED. The fear of failure was humongous. They decided to not go with the Mac version, and asked me to go into Tech Support before I could even start. I was relieved.

In Tech Support, I helped design a support ticketing program with the lead engineer, and started the beta programs, testing the new releases by myself, and then with sample client groups - I LOVED it. I knew where things would probably break, I understood the code, I understood the client. It was the perfect job.

I then moved to new companies with established QA groups. I learned the methodologies that I knew naturally and understood how and when they were used through study and training. Using the word "training" loosely, I learned test methodologies through trial and error in the field.

My career in QA has gone from beta tester to QA Director. I now spend most of my time looking for ways to show how cost effective testing can be. I believe in the need for internal audit and checks and balances. I also think that the most important role for QA is to communicate to the business the accurate status of the product being released so that there are no surprises. Risk communication and mitigation is the key.

In this blog, I hope to chat about what QA can achieve, get some of your opinions from the ether-world of the internet, share practices, links and books as well.

Please come back soon for more!

-KZ