IxDA and QA

27 Oct 2008 - 9:36am
5 years ago
6 replies
271 reads
Damon Dimmick
2008

Hi Guys,

The company I work for is a very lean, fast moving company, and we're
constantly looking for ways to tighten our product life cycle timelines.

One thing we've noticed in the last few months is that IxDA (and general
design practitioners) have been extremely valuable not just during the
design phase of a product, but also during the ongoing Quality Assurance
/ Quality Control phases as well as the final Quality Acceptance phases
of the product lifecycle.

This being the case, we're experimenting with the idea of putting IxDA
people in charge (or in review positions within) the QA process. I've
been playing around with this model myself on a couple of projects with
very strong results. The net benefit seems to derive from the fact that
there is really no one better to certify that a product meets QA
requirements than the very people that identified the necessary
interactions, UI results, and full design elements to begin with.

So far, this also seems to fit in nicely with the fact that our design
team tends to be very busy at the start of the project (front loading
interaction design and then visual design) and then gets much less busy
as the development cycle begins and ends. It seems a really good use of
our time to swoop back in after the design phase and act as part of the
QA process, making sure that developers are conforming to our
specifications via a formal testing structure.

I was wondering if anyone else has had experience with this kind of
structure, and if so, what challenges, results, and tips can you share?
We're sort of excited about the idea on our end, as our initial forays
into this model have really helped projects move along faster and with
better results. Being a small/midsized team, we don't have a large QA
department, so this allocation of resources seems to fill a lot of gaps.

Any thoughts out there among my colleagues?

Sincerely,
Damon Dimmick
Interaction Design (and newly QA)
SitePen, Inc.
dojotoolkit.org
sitepen.com

Comments

27 Oct 2008 - 9:48am
SemanticWill
2007

Bravo. Having an IxD/UX person as part of the QA process is fantastic - even
better is having the QA person involved upfront in the design spec/func spec
writing process b/c then they are intimately familiar with the design
trade-offs, compromises and root goals of any particular user scenario and
the interactions actually implemented and aren't just writing test scripts
against production, but also against the original intention. When I possible
can, QA is part of the design process, at least the lead qa on the project,
and the IxD/UX person helps write the QA testplan with the qa lead. The
biggest wins for this approach are clear and obvious - as are the
limitations which mostly are tight resources - the IxD/UX person having to
move onto the next set of rquirements and designs for the next
phase/iteration and not having time to fully devote to making sure what got
implemented and tested is what was actually intended - this is even more
crucial when development is outsourced to a 3rd party or overseas. I first
implemented this type of process change back in late 2004 and have been
doing it ever since, although I am continually astounded at the surprises I
get from mostly PM/upper management - but I have never heard a complaint
from a qa lead - they love being at the beggining of the process, and they
appreciate the help and dialogue writing the test plan, and especially
appreciate having the UX on hand during the actually testing.

On Mon, Oct 27, 2008 at 10:36 AM, Damon Dimmick <damon.dimmick at gmail.com>wrote:

> Hi Guys,
>
> The company I work for is a very lean, fast moving company, and we're
> constantly looking for ways to tighten our product life cycle timelines.
>
> One thing we've noticed in the last few months is that IxDA (and general
> design practitioners) have been extremely valuable not just during the
> design phase of a product, but also during the ongoing Quality Assurance
> / Quality Control phases as well as the final Quality Acceptance phases
> of the product lifecycle.
>
> This being the case, we're experimenting with the idea of putting IxDA
> people in charge (or in review positions within) the QA process. I've
> been playing around with this model myself on a couple of projects with
> very strong results. The net benefit seems to derive from the fact that
> there is really no one better to certify that a product meets QA
> requirements than the very people that identified the necessary
> interactions, UI results, and full design elements to begin with.
>
> So far, this also seems to fit in nicely with the fact that our design
> team tends to be very busy at the start of the project (front loading
> interaction design and then visual design) and then gets much less busy
> as the development cycle begins and ends. It seems a really good use of
> our time to swoop back in after the design phase and act as part of the
> QA process, making sure that developers are conforming to our
> specifications via a formal testing structure.
>
> I was wondering if anyone else has had experience with this kind of
> structure, and if so, what challenges, results, and tips can you share?
> We're sort of excited about the idea on our end, as our initial forays
> into this model have really helped projects move along faster and with
> better results. Being a small/midsized team, we don't have a large QA
> department, so this allocation of resources seems to fill a lot of gaps.
>
> Any thoughts out there among my colleagues?
>
> Sincerely,
> Damon Dimmick
> Interaction Design (and newly QA)
> SitePen, Inc.
> dojotoolkit.org
> sitepen.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"

---------------------------------------------------------------------------------------------
Will Evans | User Experience Architect
tel: +1.617.281.1281 | will at semanticfoundry.com
aim: semanticwill
gtalk: semanticwill
twitter: semanticwill
skype: semanticwill
---------------------------------------------------------------------------------------------

27 Oct 2008 - 10:19am
ELISABETH HUBERT
2007

Hi Damon,

I've been involved in this type of work so much that sometimes it
makes my head spin. To echo Will's bravo and also his explanation of
the benefits which you are seeming to see yourself. I've also found
that being a part of the QA process has helped me to build closer
relationships with my engineering/IT team because we are all in the
thick of it and I can better see their challenges and pains in this
phase of the project.

One of the biggest challenges that I've seen besides resource
constraints is both from a testing data point of view as well as a
testing/defect management software point of view. First I find it
increasingly hard to get the data I need to test the entire
interaction even if I'm only doing high level testing. Usually, at
least in my experience, because IT/engineering/QA are usually closer
physically they can get their hands on this faster and because they
are busy don't always pass it along. This is probably also due to
the fact that I'm a new part of the process and there is nothing
that says get the IA test data so that they can do
interface/interaction testing.

Secondly I'm usually not set up in or familiar with the software
used to manage the defects. There is usually a lag in the time that I
get an id/password and the time i've started testing. Then I need to
account for understanding the software, and the IT/engineering terms
in it that refer to our effort. Obviously once this is set up and
I've used the software a few times I'm good to go.

Hope this helps!
Lis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34881

27 Oct 2008 - 10:48am
Iain Lowe
2008

I'm going to second Will's support for having a QA person in the design/spec phase of the project.

Several years ago I was working on a large scale software project that involved a complete rewrite and redesign of an existing product.

When working through the UI design phase I invited QA department and tech support team members to the design brainstorming meetings, and to review wireframes and prototypes as they were developed.

I have never had more enthusiastic feedback and input as I did from this group. Their experience interacting with the old and mature version of the product gave them insights into existing design problems.

Plus, they were really happy to have been asked for their input in the first place, which I think is uncommon in software QA and support.

Iain

27 Oct 2008 - 12:18pm
Carrie Ritch
2003

Hi Damon,

During the design phase I conduct reviews regularly with the leads
from Development, QA and (System) Architecture and this has been very
successful so far. I'm also the reviewer for the QA test plans.

Before my arrival (the IxD position is brand new at this company) a
very large number of bugs were being reported by QA that are now
hammered out in the design phase. Those bugs created a lot of tension
in the team as the Developers would close these bugs with the remark
that "it works as designed", which is accurate but not good, and then
QA would have to escalate to the PM to intervene and round and round
they went.

All 3 of the leads - QA, Development, Architecture - have expressed
how much they love the reviews. To quote the Architecture lead: "I'm
ecstatic we're working through this on paper first."

Carrie

On Mon, Oct 27, 2008 at 10:36 AM, Damon Dimmick <damon.dimmick at gmail.com> wrote:
> I was wondering if anyone else has had experience with this kind of
> structure, and if so, what challenges, results, and tips can you share?
> We're sort of excited about the idea on our end, as our initial forays
> into this model have really helped projects move along faster and with
> better results. Being a small/midsized team, we don't have a large QA
> department, so this allocation of resources seems to fill a lot of gaps.

13 Nov 2008 - 1:44am
cfmdesigns
2004

In this thinking, turn things around: while you might have a QA
engineer or two who provide great input on design ideas, would you put
QA in charge of the design process? Probably not: their expertise may
sometimes approach or overlap those needed for design, but there will
be holes, gaps, and so forth. Unless you are truly cross-training,
you're going to end up with ultimately inferior results.

Which isn't to say that having QA involved in the design process, or
Design in the QA process, isn't a great idea. It most certainly is.

Watch out as well for asking designers to do QA work on the items they
designed. They can easily be way too picky and/or unable to look at
the pieces they designed with a fresh eye, to see interactions and
different angles. Better to use their designer eye to look at other
aspects of the product.

-- Jim Drew
Seattle, WA
Software QA for 18 years

On Oct 27, 2008, at 7:36 AM, Damon Dimmick wrote:

> The company I work for is a very lean, fast moving company, and we're
> constantly looking for ways to tighten our product life cycle
> timelines.
>
> One thing we've noticed in the last few months is that IxDA (and
> general
> design practitioners) have been extremely valuable not just during the
> design phase of a product, but also during the ongoing Quality
> Assurance
> / Quality Control phases as well as the final Quality Acceptance
> phases
> of the product lifecycle.
>
> This being the case, we're experimenting with the idea of putting IxDA
> people in charge (or in review positions within) the QA process. I've
> been playing around with this model myself on a couple of projects
> with
> very strong results. The net benefit seems to derive from the fact
> that
> there is really no one better to certify that a product meets QA
> requirements than the very people that identified the necessary
> interactions, UI results, and full design elements to begin with.
>
> So far, this also seems to fit in nicely with the fact that our design
> team tends to be very busy at the start of the project (front loading
> interaction design and then visual design) and then gets much less
> busy
> as the development cycle begins and ends. It seems a really good use
> of
> our time to swoop back in after the design phase and act as part of
> the
> QA process, making sure that developers are conforming to our
> specifications via a formal testing structure.
>
> I was wondering if anyone else has had experience with this kind of
> structure, and if so, what challenges, results, and tips can you
> share?
> We're sort of excited about the idea on our end, as our initial forays
> into this model have really helped projects move along faster and with
> better results. Being a small/midsized team, we don't have a large QA
> department, so this allocation of resources seems to fill a lot of
> gaps.
>
> Any thoughts out there among my colleagues?

13 Nov 2008 - 6:31am
Sonica Singh
2008

The current project I am working on, i did the visual design and then
volunteered to be a part of the QA team, I realized that there were so many
things which the QA guys were giving a miss and doing a QA from a designer's
perspective has really been beneficial for the project. Also I am not leading
the QA team but just a team member, doing QA from a different perspective so
in that regard I agree with Jim that a designer should not be in charge of
the QA process, as they are not trained for it. I think that's why its
working in my current project .

Sonica

Visual Designer
New Delhi India

On Thu, Nov 13, 2008 at 12:14 PM, Jim Drew <cfmdesigns at earthlink.net> wrote:

> In this thinking, turn things around: while you might have a QA engineer or
> two who provide great input on design ideas, would you put QA in charge of
> the design process? Probably not: their expertise may sometimes approach or
> overlap those needed for design, but there will be holes, gaps, and so
> forth. Unless you are truly cross-training, you're going to end up with
> ultimately inferior results.
>
> Which isn't to say that having QA involved in the design process, or Design
> in the QA process, isn't a great idea. It most certainly is.
>
> Watch out as well for asking designers to do QA work on the items they
> designed. They can easily be way too picky and/or unable to look at the
> pieces they designed with a fresh eye, to see interactions and different
> angles. Better to use their designer eye to look at other aspects of the
> product.
>
> -- Jim Drew
> Seattle, WA
> Software QA for 18 years
>
>
>
> On Oct 27, 2008, at 7:36 AM, Damon Dimmick wrote:
>
> The company I work for is a very lean, fast moving company, and we're
>> constantly looking for ways to tighten our product life cycle timelines.
>>
>> One thing we've noticed in the last few months is that IxDA (and general
>> design practitioners) have been extremely valuable not just during the
>> design phase of a product, but also during the ongoing Quality Assurance
>> / Quality Control phases as well as the final Quality Acceptance phases
>> of the product lifecycle.
>>
>> This being the case, we're experimenting with the idea of putting IxDA
>> people in charge (or in review positions within) the QA process. I've
>> been playing around with this model myself on a couple of projects with
>> very strong results. The net benefit seems to derive from the fact that
>> there is really no one better to certify that a product meets QA
>> requirements than the very people that identified the necessary
>> interactions, UI results, and full design elements to begin with.
>>
>> So far, this also seems to fit in nicely with the fact that our design
>> team tends to be very busy at the start of the project (front loading
>> interaction design and then visual design) and then gets much less busy
>> as the development cycle begins and ends. It seems a really good use of
>> our time to swoop back in after the design phase and act as part of the
>> QA process, making sure that developers are conforming to our
>> specifications via a formal testing structure.
>>
>> I was wondering if anyone else has had experience with this kind of
>> structure, and if so, what challenges, results, and tips can you share?
>> We're sort of excited about the idea on our end, as our initial forays
>> into this model have really helped projects move along faster and with
>> better results. Being a small/midsized team, we don't have a large QA
>> department, so this allocation of resources seems to fill a lot of gaps.
>>
>> Any thoughts out there among my colleagues?
>>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed