Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


I am adding QA list to recipients, because I can foresee this work
being useful in the preparation of bug reports.

On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:
*Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll be
working with the UI Testing framework. The first task will be to log the UI
actions in a log file according to a Domain Specific Language. Then, the
next task will be to automate the replay of the same actions using the
generated log file.I am ready with a fresh build of LibreOffice and am
currently browsing the relevant code parts to get more knowledge about the
different UI elements and how events work in LibreOffice.The timeline I
proposed in my GsoC proposal is at [2]. Suggestions regarding prioritising
of tasks, refining of the timeline or anything else to improve on are
welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
chirania) or by sending me an email.Looking forward to an enjoyable
summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
<https://tinyurl.com/yba6cnpc>[2] https://tinyurl.com/ydgax9vk
<https://tinyurl.com/ydgax9vk>*

Whoopee!

Please let me offer some random thoughts.

I have often been unsure what I did to provoke LO to misbehave:
sometimes my attention was absorbed by actual work I was doing,
sometimes I had given up trying carefully to reproduce a bug report
only to see the bug come up later.  So it would be good if the logging
is cheap enough to use routinely during regular work.

For a couple of reasons, I expect that the log file will not replace
the STR in a bug report: (1) The log file will contain irrelevant
operations, everything from a slip-of-the-fingers corrected promptly
to completely different tasks imposed on the user during the LO
session.  Determination of just which operations are relevant may be
tedious, but confidence that the misbehaviour can be reproduced will
justify much more effort than would mere knowledge that LO misbehaved
once.  (2) Part of the QA process for bug reports involves testing
older LO versions.

From this, I conclude that it is important that the log file be
decipherable.  Indeed, for the preparation of bug reports, the
automated playback is mostly important for proving that the bug is
reproducible, thus motivating the decipherment of the log file.  So,
an easily readable log file is better than one which is hard to read,
but the difference is less important than one might guess.

If the log file is not easily readable, then we would eventually want
a program to express it in user-level terms.  As a hack, this program
might not be quite "easy", but it could be undertaken so that it would
not hold up other work.  Perhaps it could be so specified that
language-level programming knowledge (as opposed to knowledge of LO)
would be sufficient for the task.

Thank you, Saurav, for undertaking this work.  Is there a place where
we can follow your progress?

Terry.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.