On Tue, Aug 13, 2013 at 11:42 AM, Sony Kovoor <sonyckov...@gmail.com> wrote:
> Hi all,
>
> I am an open source enthusiast and when I heard about ASF Mentoring
> program[1] conducted in association with ICFOSS[2] in India by Luciano
> Resende[3], i attended it
>
> As a part of the program, we have to take up an idea from 2013 ICFOSS
> Programme Project Ideas JIRA[4] and solve it under a formal mentor. I have
> submitted my proposal for COMDEV 76[5] [6] and was approved.
>
Hi Sony,
Welcome to the QA team. I'm looking forward to working with you on
this project.
> So before starting the work, i would like to do a brief analysis of the
> present strategies and testing systems. So if any one could briefly explain
> the present testing system, it would be of great help. Also i would like to
> know what you expect from a Test Document Generator/Permutator.
>
The current formal testing is done using test management system called
TestLink. It lists steps for the tester to attempt, along with the
expected results. A test case, for example, could say to load a
particular document file and verify that it renders correctly. There
are 100's of test cases which we try to run on all of our supported
platforms for each release.
A document generator could help us make more test documents,
especially ones that would be difficult to create by hand.
To understand why it is good to think of what makes a good QA test
case. Suppose you have a program that is a simple 4-function
calculator applications. There are an infinite number of possible
test cases. So you cannot test everything. So what test cases would
you try?
An experienced QA expert would do three main things:
1) Write some test cases for the main stream functionality, e.g., 1+2,
4/2.3, 5*6.2, 0-17.2
2) Test the error handling of the application, e.g., 0/0, 1/0, -+-3//2, etc.
3) Test the "limits" and the "edge cases", e.g, tests with extremely
long expressions, deeply nested parentheses, extremely large and small
numbers, etc.
Everyone knows to test the cases in #1, but the other two are key,
This is what it means to "think like a bug". These are the areas
where developers are most likely to make errors. Every competent
programmer will get the mainstream functionality correct. But the
edge cases, these are where the bugs often are.
So what does this mean for an application like OpenOffice? What are
our limits and edge cases?
I think of things like:
1) Extremely long documents
2) Documents with very large number of styles
3) Documents with deeply nested lists
4) Documents that use every color in the color palette
5) Documents that have 100 footnotes on a single page.
6) Documents that use every system font available
Things like that.
It would be wonderful to have a tool that could be used, with very
little programmer required, for testers to generate test documents
like this.
It is even possible to generate mainstream test cases in some cases.
For example, with spreadsheet functions. A trivial example. the OR()
function takes a list of parameters and returns TRUE if any one of
the parameters evaluates to TRUE, otherwise it returns FALSE. So
OR('B'>'A';0;-1) will return TRUE.
It should be possible, to describe the arguments of a spreadsheet
function formally and then to generate numerous test cases for it,
including edge cases and limits tests.
Regina (cc'ed) might have some ideas here as well regarding
spreadsheet function testing.
Regards,
-Rob
> All your valuable suggestions would be of a great help.
>
> Thanking you all,
>
> Regards,
>
> [1] http://community.apache.org/mentoringprogramme-icfoss-pilot.html
>
> [2] http://icfoss.org/
>
> [3] http://people.apache.org/~lresende
>
> [4] https://issues.apache.org/jira/issues/?filter=12324056
>
> [5] https://issues.apache.org/jira/browse/COMDEV-76
>
> [6]
> https://cwiki.apache.org/confluence/display/COMDEV/Test+Document+Generator+or+Permutator+for+Apache+OpenOffice
>
>
> --
> Sony Cyriac
> Kovoor Puthen Purayil
>
> E Mail : sonyckov...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
