Browse Groups

• Is the single output a single number, or is this a report-generation program (or something like Excel)? The posting below talks about some filter functions I
Message 1 of 8 , Dec 5 7:45 AM
View Source
Is the single output a single number, or is this a report-generation
program (or something like Excel)?

The posting below talks about some filter functions I worked on that
having 2 to 10 possible values, others having potentially infinite
possible values...

<http://homepage.mac.com/keithray/blog/2005/09/28/>
"...Then I wrote 900 one-line unit tests to this parameterized unit
test with the various permutations of the input parameters and
expected output values. (I actually worked in a spreadsheet for a
while and copied-pasted from the spreadsheet to the unit test source
code.) The test would also generate the output PDF file, which I
could visually examine...

On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:

> Thanks for the recent responses on Excel testing. I was just reading
> Keith Ray's blog on testing
> http://homepage.mac.com/keithray/blog/2005/12/04/:
>
> "Fortunately for people doing incremental design work with
> refactoring,
> most automated tests do not have to change when the code is
> changed. The
> tests are acting as executable specifications for the requirements, so
> if the requirements haven't changed, then the tests should not have to
> change. Of course, when the tests are very close to the
> implementation,
> they do sometimes need to be change, but the majority of tests should
> not change when someone need to alter the design to handle
> requirements
> being address in the current iteration."
>
> (This is an oversimplification but it makes the point.) We have an
> application that takes 137 inputs and produces a single output. We
> have
> tests that test the various inputs against the output. For
> example, one
> input may be a 5 choice selection - there will be tests to make sure
> that the output is correct for each of the five input choices. The
> problem is that a change in (calculation of the output due to) any of
> the 137 inputs necessarily changes the output for all of the inputs
> hence all of the tests change. Adding inputs (which change the
> result)
> and changing the calculations on existing inputs is common,
> resulting in
> the need to change virtually every test.
>
> Any suggestions?
>
> Neil Kenig
> PRICE Systems, L.L.C.
>
>
> Attention: PRICE Systems, L.L.C. maintains a safe computing
> environment but accepts no liability for any unintended effects
> arising from your receipt of data originating from PRICE Systems
> including this email and its attachments. Unintended effects
> include, but are not limited to, loss of data or service due to
> harmful or malicious software such as computer viruses. Computer
> viruses can be transmitted via email. The recipient should check
> this email and any attachments for the presence of viruses. PRICE
> Systems accepts no liability for any damage caused by any virus
> transmitted by this email. E-mail transmission cannot be guaranteed
> to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain
> viruses. The sender therefore does not accept liability for any
> errors or omissions in the contents of this message, which arise as
> a result of e-mail transmission.
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@...
>
>
>
>
>
>
>
>
• Did you have an Excel model that mimicked the model in your code? Is that how you generated the 900 cases? If not, even though your unit test was
Message 1 of 8 , Dec 5 8:45 AM
View Source
Did you have an Excel 'model' that mimicked the model in your code? Is
that how you generated the 900 cases? If not, even though your unit
test was parameterized, changing the results means changing some (most)
of the 900 cases; that's quite a bit of maintenance.

Neil.

-----Original Message-----
From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
Sent: Monday, December 05, 2005 10:45 AM
To: extremeprogramming@yahoogroups.com
Cc: agile-testing@yahoogroups.com
Subject: Re: [XP] Test de-coupling

Is the single output a single number, or is this a report-generation
program (or something like Excel)?

The posting below talks about some filter functions I worked on that had
about 7 inputs (not including the image itself), each inputs having 2 to
10 possible values, others having potentially infinite possible
values...

<http://homepage.mac.com/keithray/blog/2005/09/28/>
"...Then I wrote 900 one-line unit tests to this parameterized unit test
with the various permutations of the input parameters and expected
output values. (I actually worked in a spreadsheet for a while and
copied-pasted from the spreadsheet to the unit test source
code.) The test would also generate the output PDF file, which I could
visually examine...

On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:

> Thanks for the recent responses on Excel testing. I was just reading
> Keith Ray's blog on testing
> http://homepage.mac.com/keithray/blog/2005/12/04/:
>
> "Fortunately for people doing incremental design work with
> refactoring, most automated tests do not have to change when the code
> is changed. The tests are acting as executable specifications for the
> requirements, so if the requirements haven't changed, then the tests
> should not have to change. Of course, when the tests are very close to

> the implementation, they do sometimes need to be change, but the
> majority of tests should not change when someone need to alter the
> design to handle requirements being address in the current iteration."
>
> (This is an oversimplification but it makes the point.) We have an
> application that takes 137 inputs and produces a single output. We
> have tests that test the various inputs against the output. For
> example, one input may be a 5 choice selection - there will be tests
> to make sure that the output is correct for each of the five input
> choices. The problem is that a change in (calculation of the output
> due to) any of the 137 inputs necessarily changes the output for all
> of the inputs hence all of the tests change. Adding inputs (which
> change the
> result)
> and changing the calculations on existing inputs is common, resulting
> in the need to change virtually every test.
>
> Any suggestions?
>
> Neil Kenig
> PRICE Systems, L.L.C.
>
>
> Attention: PRICE Systems, L.L.C. maintains a safe computing
> environment but accepts no liability for any unintended effects
> arising from your receipt of data originating from PRICE Systems
> including this email and its attachments. Unintended effects include,

> but are not limited to, loss of data or service due to harmful or
> malicious software such as computer viruses. Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. PRICE Systems accepts no
> liability for any damage caused by any virus transmitted by this
> email. E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the

> contents of this message, which arise as a result of e-mail
> transmission.
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@...
>
>
>
>
>
>
>
>

To Post a message, send it to: extremeprogramming@...

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@...

• ... I ve never dealt with anything that complex, but a good chunk of my tests for complex algorithms isolate particular conditions, so that most of the
Message 1 of 8 , Dec 5 12:27 PM
View Source
Kenig, Neil wrote:

>[...] We have an
>application that takes 137 inputs and produces a single output. We have
>tests that test the various inputs against the output. For example, one
>input may be a 5 choice selection - there will be tests to make sure
>that the output is correct for each of the five input choices. The
>problem is that a change in (calculation of the output due to) any of
>the 137 inputs necessarily changes the output for all of the inputs
>hence all of the tests change. Adding inputs (which change the result)
>and changing the calculations on existing inputs is common, resulting in
>the need to change virtually every test.
>
>Any suggestions?
>
>

I've never dealt with anything that complex, but a good chunk of my
tests for complex algorithms isolate particular conditions, so that most
of the variables are in some neutral setting that doesn't affect
results. Then I have a relatively small number of tests that use all the
variables together.

When you add variable 138, how will you know what the right answer is

William
• ... any of the 137 ... of the tests change If a test is an executable specification, then it should only be changing if the specification changes, regardless
Message 1 of 8 , Dec 5 5:26 PM
View Source
On 12/5/05, Kenig, Neil <neil.kenig@...> wrote:

>The problem is that a change in (calculation of the output due to)
any of the 137
>inputs necessarily changes the output for all of the inputs hence all
of the tests change

If a test is an executable specification, then it should only be
changing if the specification changes, regardless of the number of
inputs and outputs.

If my JPEG implementation is composed of 10 classes, 100 methods
total, changing one method might result in rendering every JPEG image
decoded differently than before [for example, with a different gamma
curve], but only a very few of my 300 unit tests would have to change,
and very likely the acceptance tests would not change their
implementations at all, just their "expected" image data files.

--

C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>
• first question: no I ll never have to change those unit tests again, so no maintenance. I m working from experience here, are you?
Message 1 of 8 , Dec 5 7:59 PM
View Source
first question: no

I'll never have to change those unit tests again, so no maintenance.

I'm working from experience here, are you?

On Dec 5, 2005, at 8:45 AM, Kenig, Neil wrote:

> Did you have an Excel 'model' that mimicked the model in your
> code? Is
> that how you generated the 900 cases? If not, even though your unit
> test was parameterized, changing the results means changing some
> (most)
> of the 900 cases; that's quite a bit of maintenance.
>
> Neil.
>
> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
> Sent: Monday, December 05, 2005 10:45 AM
> To: extremeprogramming@yahoogroups.com
> Cc: agile-testing@yahoogroups.com
> Subject: Re: [XP] Test de-coupling
>
> Is the single output a single number, or is this a report-generation
> program (or something like Excel)?
>
> The posting below talks about some filter functions I worked on
> about 7 inputs (not including the image itself), each inputs having
> 2 to
> 10 possible values, others having potentially infinite possible
> values...
>
> <http://homepage.mac.com/keithray/blog/2005/09/28/>
> "...Then I wrote 900 one-line unit tests to this parameterized unit
> test
> with the various permutations of the input parameters and expected
> output values. (I actually worked in a spreadsheet for a while and
> copied-pasted from the spreadsheet to the unit test source
> code.) The test would also generate the output PDF file, which I could
> visually examine...
>
>
> On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:
>
>> Thanks for the recent responses on Excel testing. I was just reading
>> Keith Ray's blog on testing
>> http://homepage.mac.com/keithray/blog/2005/12/04/:
>>
>> "Fortunately for people doing incremental design work with
>> refactoring, most automated tests do not have to change when the code
>> is changed. The tests are acting as executable specifications for the
>> requirements, so if the requirements haven't changed, then the tests
>> should not have to change. Of course, when the tests are very
>> close to
>
>> the implementation, they do sometimes need to be change, but the
>> majority of tests should not change when someone need to alter the
>> design to handle requirements being address in the current
>> iteration."
>>
>> (This is an oversimplification but it makes the point.) We have an
>> application that takes 137 inputs and produces a single output. We
>> have tests that test the various inputs against the output. For
>> example, one input may be a 5 choice selection - there will be tests
>> to make sure that the output is correct for each of the five input
>> choices. The problem is that a change in (calculation of the output
>> due to) any of the 137 inputs necessarily changes the output for all
>> of the inputs hence all of the tests change. Adding inputs (which
>> change the
>> result)
>> and changing the calculations on existing inputs is common, resulting
>> in the need to change virtually every test.
>>
>> Any suggestions?
>>
>> Neil Kenig
>> PRICE Systems, L.L.C.
>>
>>
>> Attention: PRICE Systems, L.L.C. maintains a safe computing
>> environment but accepts no liability for any unintended effects
>> arising from your receipt of data originating from PRICE Systems
>> including this email and its attachments. Unintended effects
>> include,
>
>> but are not limited to, loss of data or service due to harmful or
>> malicious software such as computer viruses. Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. PRICE Systems accepts no
>> liability for any damage caused by any virus transmitted by this
>> email. E-mail transmission cannot be guaranteed to be secure or
>> error-free as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender
>> therefore does not accept liability for any errors or omissions in
>> the
>
>> contents of this message, which arise as a result of e-mail
>> transmission.
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> To Post a message, send it to: extremeprogramming@...
>>
>> To Unsubscribe, send a blank message to: extremeprogramming-
>> unsubscribe@...
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@...
>
>
>
>
>
>
>
• Yes, we currently have a suite of 13,000 Fitnesse assertions on our application. In thinking about the problem some more we have figured out a way to decouple
Message 1 of 8 , Dec 6 6:09 AM
View Source
Yes, we currently have a suite of 13,000 Fitnesse assertions on our
application. In thinking about the problem some more we have figured
out a way to decouple some of our tests by using a certain set of
inputs. As Stefan Steurs points out on the agile-testing list,
decoupling does make tests more like unit tests and makes them less
likely to find errors in interactions among features. An analogy might
be feeding an "all white" image into your system. Much of the
functionality can be exercised although much of the core processing
cannot.

-----Original Message-----
From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
Sent: Monday, December 05, 2005 10:59 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Test de-coupling

first question: no

I'll never have to change those unit tests again, so no maintenance.

I'm working from experience here, are you?

On Dec 5, 2005, at 8:45 AM, Kenig, Neil wrote:

> Did you have an Excel 'model' that mimicked the model in your code?
> Is that how you generated the 900 cases? If not, even though your
> unit test was parameterized, changing the results means changing some
> (most)
> of the 900 cases; that's quite a bit of maintenance.
>
> Neil.
>
> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
> Sent: Monday, December 05, 2005 10:45 AM
> To: extremeprogramming@yahoogroups.com
> Cc: agile-testing@yahoogroups.com
> Subject: Re: [XP] Test de-coupling
>
> Is the single output a single number, or is this a report-generation
> program (or something like Excel)?
>
> The posting below talks about some filter functions I worked on that
> had about 7 inputs (not including the image itself), each inputs
> having
> 2 to
> 10 possible values, others having potentially infinite possible
> values...
>
> <http://homepage.mac.com/keithray/blog/2005/09/28/>
> "...Then I wrote 900 one-line unit tests to this parameterized unit
> test with the various permutations of the input parameters and
> expected output values. (I actually worked in a spreadsheet for a
> while and copied-pasted from the spreadsheet to the unit test source
> code.) The test would also generate the output PDF file, which I could

> visually examine...
>
>
> On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:
>
>> Thanks for the recent responses on Excel testing. I was just reading

>> Keith Ray's blog on testing
>> http://homepage.mac.com/keithray/blog/2005/12/04/:
>>
>> "Fortunately for people doing incremental design work with
>> refactoring, most automated tests do not have to change when the code

>> is changed. The tests are acting as executable specifications for the

>> requirements, so if the requirements haven't changed, then the tests
>> should not have to change. Of course, when the tests are very close
>> to
>
>> the implementation, they do sometimes need to be change, but the
>> majority of tests should not change when someone need to alter the
>> design to handle requirements being address in the current
>> iteration."
>>
>> (This is an oversimplification but it makes the point.) We have an
>> application that takes 137 inputs and produces a single output. We
>> have tests that test the various inputs against the output. For
>> example, one input may be a 5 choice selection - there will be tests
>> to make sure that the output is correct for each of the five input
>> choices. The problem is that a change in (calculation of the output
>> due to) any of the 137 inputs necessarily changes the output for all
>> of the inputs hence all of the tests change. Adding inputs (which
>> change the
>> result)
>> and changing the calculations on existing inputs is common, resulting

>> in the need to change virtually every test.
>>
>> Any suggestions?
>>
>> Neil Kenig
>> PRICE Systems, L.L.C.
>>
>>
>> Attention: PRICE Systems, L.L.C. maintains a safe computing
>> environment but accepts no liability for any unintended effects
>> arising from your receipt of data originating from PRICE Systems
>> including this email and its attachments. Unintended effects
>> include,
>
>> but are not limited to, loss of data or service due to harmful or
>> malicious software such as computer viruses. Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. PRICE Systems accepts no
>> liability for any damage caused by any virus transmitted by this
>> email. E-mail transmission cannot be guaranteed to be secure or
>> error-free as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender
>> therefore does not accept liability for any errors or omissions in
>> the
>
>> contents of this message, which arise as a result of e-mail
>> transmission.
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> To Post a message, send it to: extremeprogramming@...
>>
>> To Unsubscribe, send a blank message to: extremeprogramming-
>> unsubscribe@...
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@...
>
>
>
>
>
>
>

To Post a message, send it to: extremeprogramming@...

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@...

• Well stated. This nature of coupling/de-coupling tests and designing/refactoring tests for speed/maintainability is one of the most difficult challenges that
Message 1 of 8 , Dec 6 6:12 AM
View Source
Well stated. This nature of coupling/de-coupling tests and
designing/refactoring tests for speed/maintainability is one of the most
difficult challenges that my organization currently faces in agile
development.

________________________________

From: agile-testing@yahoogroups.com
[mailto:agile-testing@yahoogroups.com] On Behalf Of STEURS Stefan
Sent: Tuesday, December 06, 2005 4:31 AM
To: 'agile-testing@yahoogroups.com'
Cc: extremeprogramming@yahoogroups.com
Subject: RE: [agile-testing] Test de-coupling

I have also encountered many situations where a transversal change
affects many of the features/functions so tests have to be
modified/added over a wide range of objects/methods. It is easy to
state that change should be localised and affect only a few aspects of
the tests that have been automated without requiring a rewrite of the
tests.

The way I see it, a well structured set of tests is affected
proportionally to the changes in the code - from an over-all
perspective. This is only true when the tests are at the same level of
cohesion and dependency as the code. Abstract tests will be less
sensitive to changes but consequently will be less senstive to errors.

Localised changes are easy to deal with.

Take the following example: in release 1 the application provides
functions to provide CRUD on business objects. From release 2 onwards,
all business objects become versioned. The user can only affect the
present and future of an object but no longer the past. The change must
be implemented for all objects at the same time since the associations
that exist between them also have to be versioned.

A test to create data, retrieve data, update data, delete data, may
still continue to work as it was created initially but, since versioning
was not taken into account, cannot provide any evidence that versioning
actually works.

Tests may not be affected but if they are decoupled they provide no
evidence that feature interactions function as intended.

That is one of the major problems I keep encountering when I look at
automated tests. The tests isolate the feature to be tested but there
are too few tests that actually look at the interactions of these
features. True that such feature interaction tests are hard to design,
implement, and maintain, but most of the tough problems are also hiding
in the interactions (initial/intermediate state, order, timing,

For all that it's worth, tests are software and de-coupling of tests is
probably no different from de-coupling in the code. The tests have to
rely on a proper framework. But, this is only my own opinion and I
don't know enough, decoupling of tests should not become an obsession
and optimisation driven too far in the direction of decoupling will

Regards, Stefan.

-----Original Message-----
From: agile-testing@yahoogroups.com
[mailto:agile-testing@yahoogroups.com]On Behalf Of Kenig, Neil
Sent: Monday, December 05, 2005 3:48 PM
To: agile-testing@yahoogroups.com
Cc: extremeprogramming@yahoogroups.com
Subject: [agile-testing] Test de-coupling

Thanks for the recent responses on Excel testing. I was just
reading Keith Ray's blog on testing
http://homepage.mac.com/keithray/blog/2005/12/04/:

"Fortunately for people doing incremental design work with
refactoring, most automated tests do not have to change when the code is
changed. The tests are acting as executable specifications for the
requirements, so if the requirements haven't changed, then the tests
should not have to change. Of course, when the tests are very close to
the implementation, they do sometimes need to be change, but the
majority of tests should not change when someone need to alter the
design to handle requirements being address in the current iteration."

(This is an oversimplification but it makes the point.) We have
an application that takes 137 inputs and produces a single output. We
have tests that test the various inputs against the output. For
example, one input may be a 5 choice selection - there will be tests to
make sure that the output is correct for each of the five input choices.
The problem is that a change in (calculation of the output due to) any
of the 137 inputs necessarily changes the output for all of the inputs
hence all of the tests change. Adding inputs (which change the result)
and changing the calculations on existing inputs is common, resulting in
the need to change virtually every test.

Any suggestions?

Neil Kenig
PRICE Systems, L.L.C.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<

Attention: PRICE Systems, L.L.C. maintains a safe computing
environment but accepts no liability for any unintended effects arising
from your receipt of data originating from PRICE Systems including this
email and its attachments. Unintended effects include, but are not
limited to, loss of data or servic! e due to harmful or malicious
software such as computer viruses. Computer viruses can be transmitted
via email. The recipient should check this email and any attachments for
the presence of viruses. PRICE Systems accepts no liability for any
damage caused by any virus transmitted by this email. E-mail
transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message, which arise as a result of e-mail transmission.

Agile software development
+software+development&w2=Software+development+project+management&w3=Soft
ware+development+project+plan&w4=Acceptance+testing&c=4&s=140&.sig=pC2Cb
nCaCxN6ZXsti0jF1w> Software development project management
ment&w1=Agile+software+development&w2=Software+development+project+manag
ement&w3=Software+development+project+plan&w4=Acceptance+testing&c=4&s=1
40&.sig=XgHMtgcekJphRllzaR6aTg> Software development project
plan
1=Agile+software+development&w2=Software+development+project+management&
w3=Software+development+project+plan&w4=Acceptance+testing&c=4&s=140&.si
g=aQrjNeF6aY20fE1yGHeE0A>
Acceptance testing
e+development&w2=Software+development+project+management&w3=Software+dev
elopment+project+plan&w4=Acceptance+testing&c=4&s=140&.sig=QTlO0GX7jnlD3
gwtcKedZw>

________________________________

<http://groups.yahoo.com/group/agile-testing> " on the web.

* To unsubscribe from this group, send an email to:
agile-testing-unsubscribe@yahoogroups.com
<mailto:agile-testing-unsubscribe@yahoogroups.com?subject=Unsubscribe>

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .

________________________________

____

This message and any files transmitted with it are legally privileged
and intended for the sole use of the individual(s) or entity to whom
they are addressed. If you are not the intended recipient, please notify
the sender by reply and delete the message and any attachments from your
system. Any unauthorised use or disclosure of the content of this
message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal
commitment on the part of EUROCONTROL unless it is confirmed by
appropriately signed hard copy.

Any views expressed in this message are those of the sender.

[Non-text portions of this message have been removed]
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.