If someone's doing a good job of writing the test infrastructure it's probably not that hard. Page objects should obscure a lot of the details if they're well written.
Based on what you just said I think Chuck's comment makes a lot of sense. Cucumber is probably a really good tool for your QA folks. They will have to write their tests in plain English using step definitions written by your developers or whatever team's managing the framework infrastructure. Here's an example that's probably not pretty good but hopefully give you an idea (but I'm probably already telling you stuff you know since you're using rails) *As a person who wants to sign up for the Foo organization *Given that I go to the Foo signup page and create a new account using blah for my username and blah for my password *I should be able to go to the database and confirm that blah is a member of the Foo organization. Personally, Cucumber drives me a little batty but one thing it does a really good job at is providing a firewall between the QA engineers and code they are using to test the app. The step definitions typically utilize regular expressions and can be pretty flexible (e.g., the third step could also be set up to also check that blah is not a member of Foo). And to keep score you use a unit testing framework like test unit or rspec (which the tester is also shielded from). RSpec is nice because it has built-in html reporting. I think it's probably best to have someone really good at coding to start the writing of the page objects and cucumber steps. And then let the QA folks start writing tests using the Cucumber step definitions. As they get more comfortable with that then a few will probably want to start contributing. That's where it can get dicey. Somebody, really, really needs to mind the storewhen QAstarts to contribute (QA folks typically are not full blown programmers by nature.) But as long as standards and procedures are set up in advance and checkins are carefully controlled then you'll probably end up with a good test automation effort involving both dev and QA. ________________________________ From: Jorge Gastaldi <[email protected]> To: [email protected] Sent: Monday, August 26, 2013 2:30 PM Subject: Re: [wtr-general] Re: Testing Methodology with Watir In this particular case, we develop a using code generation tool called Genexus. If you don't know about it... consider yourself lucky. It doesn't look like another language and it's quite hard to apply anything you know from another language, development process (BDD in particular) or even architecture (and we don't have a choice about using it, although we have some Java and php projects). I have some personal projects using Rails, but most of development team has only programmed in Genexus. That's why I want to introduce them quite slowly to Ruby and automated testing. And that's why I think that Te Right now, all the testing (unit, integration, etc.) is made manually. Given the nature of the development tool, unit test are just running the page you developed in the browser. The integration and regression tests are made mainly by the testing team. The testing team, right now it's quite small and not much oriented to programming. If it grows, I think it would be good to still keep them as far as possible of the implementation details. Most of your answers point to the development team side of the problem. My main concern now is, in fact, the testing team. I want them to be able to design and run automated tests without knowing about web page elements names and other details (mostly because the web page code that the tool generates is _incredibly_ ugly). And that leads me to think that maybe I'm wrong about wanting the testing team to use Watir. Maybe is better suited to development, or big testing teams that have an specialized automation team. Are there testing only teams using Watir? How do they interact with development? On Mon, Aug 26, 2013 at 4:54 PM, John Fitisoff <[email protected]> wrote: Jorge, > >If I were in that situation I'd try to get the developers to write page >objects. I'd write some info about what page objects are out there and about >how the page objects should be defined, maybe with an example, so that the >developers could talk about it come up with a consensus and implement things >in a consistent way. Actually, I haven't used any of the page objects >libraries yet as it's pretty simple to come up with a container. I plan to >play around with them at some point though when I have more time. > >It's also useful to create non page object classes for commonly used things in >the ecosystem (e.g., Person, Organization). You can do some interesting things >with these classes. One thing I really like to do is to use Activerecord to >give the object access to relevant tables. For example, you could have a Person class and then use Activerecord to write a method to return all of the organizations that the Person belongs to (probably as Organization objects). Then you can do stuff like: > >p = Person.new(:name=>'blah') >o = Organization.new(:name=>'BLAH') >assert(o.persons.include?(p), "Org #{o.name} did not include person >#{p.name}") #Even better, make string representation of the Org and Person >classes to be the name > > > >b = Watir::Browser.new >p = Person.new(:name=>'blah') >p.organizations.each do |org| > page = OrganizationPage.new(b) > > assert(page.person_name == p.name) > >end > > >For all of the CRUD stuff, creating an object that has mapping to the relevant >DB tables for the object is awesome. Then you can use the page object to >delete the person from the org and then call the person object to see if it >still thinks it belongs to the org. No SQL. You just need to do a little setup >in activerecord to get everything in a table for a particular ID. > > > >There are nicer ways to do the stuff above. I'm sure other people will have >other ideas. > > >One thing you want to do (no matter what): treat the automation effort as a >serious development task. It's really important to keep things organized and >done in a consistent way. But it sounds like you're already thinking about that > > > > >________________________________ > From: Jorge Gastaldi <[email protected]> >To: [email protected] >Sent: Monday, August 26, 2013 12:02 PM >Subject: [wtr-general] Re: Testing Methodology with Watir > > > >Thanks for your response! > >Those patterns point directly to some of the problems that I want to attack. >But most of my developers never touched ruby, so maybe a "just make some >procedures" approach can be better for a first stage, and then move to a >better structured one. > >But my main concern is at a higher level. Let's say we have two teams: >development and testing. Testing wants to automate some tests with Watir, but >that implies that they need an intimate knowledge of the application >implementation. I want to avoid that, because both effectivity and efficiency. >So my plan tries to answer: How can the Testing team do automation with Watir keeping some separation of concerns between Testing and Development? > >I guess my question for the group should be more general: How Testing teams >use Watir? > > > >On Friday, August 2, 2013 6:43:33 PM UTC-3, Chuck van der Linden wrote: >On Monday, July 22, 2013 11:05:38 PM UTC-7, Jorge Gastaldi wrote: >> >> >>> >>> >>> >>> This is something that must be somewhere on the net, but I couldn't >>>find. >>> >>> >>> I have used Watir for some scripts, small things. But I think that could >>>be very nice to use it at work as an integral part of the development and >>>testing cycle. So I want to know about the best practices and usual >>>methodology for Watir for development and/or testing teams. One of my main >>>concerns is: if the testing team builds the Watir tests, they have to know >>>deep details of the web page implementation? That's something I would like >>>to avoid. >>> >>> >>> >>> >>> As couldn't find information about it, I've thinking and came up with a >>>little plan. I would be very grateful about any feedback about it. >>> >>> >>> We work mostly with CRUDs or CRUD-like web pages, so this could be a >>>generic work flow: >>> >>> * The developer finish a web page. >>> * He builds a set of Watir functions that only covers the Create, >>>Restore, Update, Delete functionality (if applies) and little more. For >>>example, "addPerson(personId, organisationId)". >>> * Then the testing team build the integration tests using this "high >>>level" functions. Something like: >>> >>> >>> organisationId = createOrganisation(...) >>> personId = createPerson(...) >>> addPerson(organisationId, personId) >>> >>> >>> >>> >>> >>> I see several advantages with this approach (that maybe is what >>>everybody is doing): >>> >>> >>> * The developers and testers get some useful functions to work with. >>>Very practical to setup some testing data for unit or other tests. >>> * If you have the functions, there was _at least_ a basic unit >>>testing. This shouldn't be a big advantage... but at some teams it is >>> * The testers don't have to know how the web page was implemented. >>> * The maintenance of the test cases should be pretty straight >>>forward: every time you change a web page, you now quite easily which >>>functions you should update. The integration tests will be also pretty easy >>>to find and even easier to fix. >>> >>> >>> Again, any feedback or advice is more than welcome. >>> >>> >>> >>> >>> Thanks in advance, >>> Jorge >>> >>> >>> >>> >>> (sorry about my English) >>> >>> >>> >> >> >>So my take on this is a little different. I'm a big fan of 'test first', at >>the code level this tends to mean unit tests. At the feature level a good >>approach is to use an "Executable Specification", and a good way to do that >>is "Specification by Example" (see http://www.manning.com/adzic/ ) >> >> >>What tool you use for that depends on what languages you and your developers >>are comfortable with. If they are happy with Ruby, then using Cucumber along >>with Watir for those tests that are UI facing is a great choice. and in that >>case I strongly recommend reading 'the cucumber book' to get started in the >>right direction. >> >> >>Cucumber gives you one aspect of re-usable and maintainable code which is the >>idea of common steps that can be re-used. >> >> >>The other good practice is the Page Object and Data Object patterns. >> >> >>Page objects model the application's web pages and consist of logical names >>for page elements along with how those elements are identified. That gives >>you a way to address page elements by name in your scripts so that if the >>site changes, you have one place to change in order to update your scripts. >> >> >> Data objects do a similar thing for having a logical way to persist a 'test >>side copy' of data objects (such as users, items for sale in a store, a >>shopping cart) and also provide a way to pass that test data from one step >>to another in your code. Similar to page objects this also gives you one >>place to have methods for things like say updating a user profile, logging >>in, etc. Data objects typically have a set of default values for an object >>of that type, and you can create them using entirely the defaults, or overide >>any or all parameters as needed. A similar approach is used for methods that >>do things for filling out a form. >> >> >>Both of those are what are referred to as 'abstraction layers' -- >-- >Before posting, please read http://watir.com/support. In short: search before >you ask, be nice. > >[email protected] >http://groups.google.com/group/watir-general >[email protected] > >--- > You received this message because you are subscribed to the Google Groups "Watir General" group. >To unsubscribe from this group and stop receiving emails from it, send an >email to [email protected]. > >For more options, visit https://groups.google.com/groups/opt_out. > > > > -- >-- >Before posting, please read http://watir.com/support. In short: search before >you ask, be nice. > >[email protected] >http://groups.google.com/group/watir-general >[email protected] > >--- >You received this message because you are subscribed to a topic in the Google >Groups "Watir General" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/watir-general/echLeFNHtwk/unsubscribe. >To unsubscribe from this group and all its topics, send an email to >[email protected]. >For more options, visit https://groups.google.com/groups/opt_out. > -- -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected] --- You received this message because you are subscribed to the Google Groups "Watir General" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected] --- You received this message because you are subscribed to the Google Groups "Watir General" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
