SPONSORS:






User Tag List

Results 1 to 7 of 7
  1. #1
    Junior Member
    Join Date
    Feb 2000
    Location
    Shrewsbury, MA
    Posts
    11
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Design for Testability with Silk

    Alright - I just selected SilkTest as tool of choice and we are just starting the development cycle to put our Windows app into brawoser form. The developers will be generating HTML tables for the data etc and generating other Java code.

    Can we get a topic going that
    (a)lists the types of things that a developer can do in writing the code that makes testing easy without sacrificing functionality and
    (b) coding practices that seem okay in development but KILL the testability of the app - particularly if the test tool is Silk?

    As long as we are starting fresh, it would be better to get the design rules straight ahead of time. Seems to me that if they are known, it is just as easy to develop a testable app as an untestable app.

    It is up to US as test engineers to help define this.

    Any ideas?

  2. #2
    JQ
    JQ is offline
    Junior Member
    Join Date
    Jan 2000
    Location
    Maynard,MA,USA
    Posts
    16
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    Great subject and a wonderful idea, Design For Test is. I had been involved in PCB design for the last 12 years before focusing on the tools themselves. Designing a printed circuit board that can't be tested is a sure fire way to the unemployment line. Why is it different when developing software?

    The app I'm testing was not written with automated test tools in mind. If SilkTest wasn't so flexable and powerful, my automated testing would be dead. But I would be a lot farther ahead if some basic analysis of the GUI implementation was done. Embedding test hooks and log outputs for testing and field support purposes are not that uncommon.

    I whole-heartedly encourage you to pursue this effort, it is a concept that is way overdue in the software industry. (IMHO)
    Make it part of your process.

  3. #3
    Member
    Join Date
    Sep 1999
    Location
    Austin, Texas
    Posts
    64
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    Great Idea. Too bad Segue won't document the assumptions SilkTests makes about the application under test. You essentionally have to do this by trial and error: reverse engineering. Your developers won't be happy with this.

    ------------------
    Bret Pettichord
    Tivoli Systems
    Bret Pettichord
    Book - www.testinglessons.com
    Hotlist - www.testinghotlist.com
    Consulting - www.pettichord.com

  4. #4
    Junior Member
    Join Date
    Jan 2000
    Location
    Hillsboro, OR, USA
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    Good luck with this one. I posted a similar question back in January with no response. It would seem that if we could all get together some suggestions we could create a pretty good "Design for Test Checklist"-type document. Seems strange that Segue would not be interested in promoting documentation that would help developers to develop "SilkTest-able" code, as it might directly affect their bottom line.

    Denise Shoup

  5. #5
    rg
    rg is offline
    Member
    Join Date
    Feb 2000
    Posts
    98
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    In ST 5.0.3, the DOM support allows one to use the HTML name to tag objects on the screen. This makes it much easier to maintain the resulting scripts. The table recognition support is also much better. You might find that there isn't that much that needs to be changed to get things working with SilkTest after all.

  6. #6
    Member
    Join Date
    Dec 1999
    Location
    Seattle, WA
    Posts
    64
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    the only problem with going with the DOM is that you can't test netscape that way, so if you are using SilkTest (as we do) for cross browser tests, especially for UI, and error checking done by client side javascript, you can't because of the tags.

    as for a list, at the top would be don't use DHTML. It is incompatible with Silk because the handles change AFTER the page loads and Silk has no way of reacquiring them so you will receive invalid handle errors.

    Also, there are certain programming practices in JavaScript that apparently don't work well with Silk. I was told about a "white paper" that Segue would be writing on the subject that apparently just never came to fruition.

    The main thing I would say is that managerial practices are better than any hard and fast rules. If using SilkTest automation, UI changes MUST come under the same change control scrutiny as other modifications to the app. Otherwise you will spend more time debugging errors in the script than in the AUT (app under test).

    Getting developers to use the same tool for their unit tests [those who do unit test, anyway :-)] is the best way to get backing on the change control piece. If a change breaks the automation, it slows them down as well as you. Remember, above all, that the best programmers are generally lazy (and I mean that in a good way) -- use this to your advantage.

    Just my 2 cents....

    ------------------
    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>It doesn't matter if I go to heaven or to hell, I have friends in both places.<HR></BLOCKQUOTE>

    [This message has been edited by Matt Sullivan (edited 06-09-2000).]
    <BLOCKQUOTE]<font size=1 face=Verdana, Arial, Helvetica]quote:</font]<HR]It doesn't matter if I go to heaven or to hell, I have friends in both places.<HR]</BLOCKQUOTE]

  7. #7
    Senior Member
    Join Date
    Jul 2002
    Location
    Paris (France)
    Posts
    182
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Design for Testability with Silk

    So why not start some type of checklist? With some thought, and some iteration, together we can define a checklist that would benefit everyone.


    So with that note, here is a start:

    Tables:
    1. <LI>Each table row must define the proper number of columns. It is common to see a table defined, with say 3 columns in the table header. After that, some cells were not needed, so only 2 or one columns would be listed for a given row. The web browsers will gracefully handle this, but the coding is not to the HTML standard. To this end, when the Silk object recognition engine try's to "see" the table, it gets all confused and will view the table differently each time it is displayed. This becomes a coding nightmare for automation. So, if the table has three columns, all rows should also have 3 columns.
      <LI>All cells need at least a non-breaking space. Often, with database-driven web pages, some cells in a table may come out with no values. Thus, you have an empty cell. Again, no big thing for web browsers. However, SilkTest may not always read the table correctly. If the data for a cell is null, a non-breaking space should be inserted to properly render the cell.


    Links:
    1. <LI>Horizontal lists of links should have each line in a table row. When a list of links are used such that each link is separated by a break (making a horizontal, closely spaced list) the Silk recognition engine views the entire listing as text (not even a link, just text). I have found a workaround for this by mathematically calculating where the desired link is - but this is not always a good way to go. Placing the list of links into a table would solve the problem - but there is a *but* - but, Silk will only see a table as a table if it has at least 2 rows and 2 columns. I haven't tried if this workaround will work. Could always define an extra column that had a non-breaking space in it.



    There is a whole lot more, this is all I could think of off hand. Would be good if we could keep this going, get all the issues, then produce an HTML document that has everything together. I would be happy to concatenate all of the information and produce the final checklist (subject to more reviews and iterations once we get that far).

    So please, add to this checklist and lets see if we can produce something that would work as a good guideline for everyone.

    Also, since many of these Workarounds are for the HTML World and not so much for the Windows-based world, I would say that the list should be web-specific areas. Or, we could have a separate section for Windows-apps.


    ------------------
    David Genrich
    Icarian
    555 North Mathilda Ave
    Sunnyvale, CA 94086
    davidg@icarian.com

    [This message has been edited by davidg (edited 06-11-2000).]

    [This message has been edited by davidg (edited 06-11-2000).]

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 12:47 AM.

Copyright BetaSoft Inc.