[Systers-dev] GSOC Systers wishlist project

[erica]

Hi Robin,

Thanks so much for the thoughtful reply!

I've done manual testing before.  I did hundreds of hours of it at a 
life insurance company where I was helping test a software application 
which generated the appropriate forms for their life insurance 
applications.  When performing this testing, I was given a test plan to 
carry out so I'm curious as to how test cases are designed.  It seems 
that at least one case, the one that caused the bug report, would be an 
obvious choice, but how are other scenarios created?

Regards,
Erica

On 4/5/2010 11:32 PM, Robin Jeffries wrote:
> I'll chime in here.  Everyone is going to be testing -- though these 
> are likely to be manual tests, unless the testing automation project 
> proceeds really quickly.  We are going to use a methodology called 
> "test driven development", where you have to think about the (unit) 
> tests (purists would say, write the tests) before you write the code. 
>   Don't worry.  Most students aren't exposed to these ideas, or even 
> how to test (or how to debug well) in their classes -- this is one of 
> the advantages of being in GSOC.  Your future employer and your future 
> open source projects will appreciate you coming in understanding the 
> importance of testing.
>
> For the wishlist project, that means describing one or more test cases 
> that someone else could use to determine whether you really fixed the 
> bug, and doing this before you fix the bug (or at least so close in 
> time that we can't tell the actual order you did them -- but I can 
> tell if you only test the change you made, rather than testing the 
> problem reported in the bug report, really, I can :-)  If you are 
> interested in seeing a bit more what this means, our current testing 
> matrix is at: 
> http://systers.org/systers-dev/doku.php/master_checklist_template
>
> I'm a UI/HCI person, and some of the small features included in the 
> wishlist project have some simple UI design requirements, and chance 
> to learn/put to work your html and javascript skills.  It's not a UI 
> project (our "real" UI project is the UI for the archives, but I 
> suspect you need a couple years more class work before you should 
> tackle something like that), but it will get you a feeling for why UI 
> design is both important and hard.
>
> Robin
>
> On Mon, Apr 5, 2010 at 8:16 PM, Erica Wolfe <ericawolfe at gmail.com 
> <mailto:ericawolfe at gmail.com>> wrote:
>
>     Hi Anne,
>
>     Thanks so much for the post.  I, too, am interested in the
>     wishlist items
>     and bug fix project.
>
>     On Mon, Apr 5, 2010 at 9:36 AM, Anne Gunn <ompeag at wyoming.com
>     <mailto:ompeag at wyoming.com>> wrote:
>
>     > Programming has always been about
>     >   communication, after all, and now with usability becoming such
>     a big
>     >   issue/barrier to progress, our discipline can use all the
>     knowledge of
>     >   human factors we can get.
>     >
>
>     Your words of encouragement are heartening.  I always hope my BA in
>     Sociology from University of Michigan will be handy.  :)
>
>      One thing I would hope/encourage us to develop during this project is
>     >   some level of unit testing.  Python offers a couple of different
>     >   approaches to unit testing, depending on how formal and
>     automated you
>     >   want to get.  Although unit testing is generally talked about
>     in terms
>     >   of greenfield (new code) development, I've had very good luck
>     applying
>     >   it to existing bodies of code.  The interesting thing about
>     fixing bugs
>     >   and/or adding features to relatively large bodies of code is
>     that the
>     >   change itself is often relatively straightforward but the
>     unintended
>     >   side effects can be remarkable and varied.  Unit/regression
>     testing
>     >   allows you to begin to get some telemetry on whether or not
>     you broke
>     >   something else while you fixed the thing you intended.  It's an
>     >   imperfect art and when you start doing it with a legacy code
>     base, you
>     >   are certain to never have enough tests, but 'Don't let the
>     fear that
>     >   testing can't catch all bugs stop you from writing the tests
>     that will
>     >   catch most bugs.'  -- Martin Fowler.
>     >
>
>     As I'm new to programming, and testing has not been covered at all
>     in my
>     coursework, I'm interested in how, or whether, you see this
>     working with the
>     GSOC project on patches, release and testing automation.
>
>     Regards,
>     Erica
>
>
>     To unsubscribe from this conversation, send email to
>     <systers-dev+wishlist+unsubscribe at systers.org
>     <mailto:systers-dev%2Bwishlist%2Bunsubscribe at systers.org>> or
>     visit
>     <http://systers.org/mailman/options/systers-dev?override=96&preference=0
>     <http://systers.org/mailman/options/systers-dev?override=96&preference=0>>
>     To contribute to this conversation, use your mailer's reply-all or
>     reply-group command or send your message to
>     systers-dev+wishlist at systers.org
>     <mailto:systers-dev%2Bwishlist at systers.org>
>     To start a new conversation, send email to
>     <systers-dev+new at systers.org <mailto:systers-dev%2Bnew at systers.org>>
>     To unsubscribe entirely from systers-dev, send email to
>     <systers-dev-request at systers.org
>     <mailto:systers-dev-request at systers.org>> with subject unsubscribe.
>
>