Goodwill for Automation Code

I had an interesting dream, thought, or inspiration last night.  It could have been codeine induced based on the horrible cough I have been battling, but no the less it was an important thought.

What happens to legacy code?  Does it simply get deleted and gone eternally?  Does it fall into an abyss?

No!  We take it to Goodwill for Automation Code.

It occurred to me that one of the key takeaways from STP conference was mentoring.  The "Ah Ha moment" was that we could leverage legacy code to educate others.  We have some Software Engineers in test that are struggling with TDD, test driven development.  So my concept is to look at our code repository and find code that has matured over time.  We can then share this evolution of code with the testers that struggle with TDD.

I also struggled a bit with TDD, until I saw the light.  Even for test automation it is important to unit test your code.  How did I learn?  What turned on the light?

Mentoring by my colleague certainly was key. The knowledge of knowing my new methods would potentially be used by many tests forced me to write better code, that could easily and repeatably be tested.  I still struggle because I simply want to get a test implemented quickly, so I admit sometimes I write my unit tests after the fact.  One rule of thumb I do have is that if I struggle at all to write a piece of code, I immediately stop and write the unit tests.  Breaking the complexity into simpler chunks helps me to get to a more robust solution.

So I am going to go into the office today, then search for learning examples of code.  These legacy jewels will then be moved into Goodwill for future education opportunities.

Cast off code will be used to assist others.  Amazing the thoughts that come to you during sleep and I do not recommend the codeine!

Keep on testing!

Complexity

I know I have not posted in quite some time.  Being busy is not a good excuse!

I do have numerous random ramblings floating through my brain with respect to testing.  But my key thought for the day is that testing web applications can be extremely complex.  Besides complexity the simplest deformity can cause the most chaos.

Are web applications similar to macromolecular complex assembly?  Macromolecular complex assembly is the aggregation, arrangement and bonding together of a set of components to form a complex.

I guess I would consider the combining of a bunch of disparate technology stacks an aggregation.  The integration of these technologies certainly must be arranged and bonded.  I believe today that tiny aspects of this complex are under the scrutiny of a microscope.

Someone of importance notices that an implementation in a specific browser causes a line to wrap.  This is a tiny deformity on the surface of a cell causes concern, yet the neighboring system which is about to go into complete cardiac arrest goes unnoticed.

Why is it that the tiniest blemish on a complex system gets noticed first?  Why is it that the most insignificant concern causes the most chaos for a tester?

Unfortunately it becomes difficult for testers to inspect the entire surface of a cell, when the internal organs (mitochondria) are in need of some much attention.  As we inspect and flush out the issues with the key features we get the most demerits for a cosmetic blemish on the user interface.

So I guess the resolution is to perform CPR on the failing feature while fixing the blemish.  The complex will endure!

Testing for the Super Bowl Ad

I am sitting at HomeAway's Super Bowl Command Center patiently waiting for the game to begin.  I have not posted in awhile due to an enormous amount of testing.

We have been conducting performance tests for almost 4 weeks.  Usually on Sunday we could do our most impacting performance tests.  We ran tests every Tuesday, Thursday and Sunday.  Is our site ready?  We should know in about 5 hours.  Thanks to tools like jMeter and BrowserMob I believe we are ready!

Not only was I involved with a great team for performance testing, I also had to test some new applications developed specifically for the Super Bowl.  This testing effort was exhausting.  The final build was delivered at 1:00 PM Saturday.  Yep, that is right!  Just 28 hours before the Super Bowl.

I am confident in the software, but there are some known issues.  Very difficult to test across the variety of OS and browser configurations.  Throw in different versions of flash and media players you have an infinite amount of testing.  If I had not read Gerald Weinberg's book "Perfect Software", I think I would be freaking out right about now.

So what would be the lessons learned over the past four weeks.

• You must performance test with a great group of technical people, because collaboration is the key.
• You must insist on testing third party applications early and often.
• You must learn to let go, because unfortunately with a small time line and infinite number of test cases, you can only do so much.
• You must have good performance testing tools and a cloud vendor like Browser Mob who will go the extra mile.
• You must have a dedicated team who are willing to put in long hours.
• You must have testers who are willing to report all of their observations.
• You must not use a Google Shared document to track and collaborate on issues.  Use a web based defect tracking tool. (Primary mistake I made for Super Bowl)
• You must think about process as soon as you engage a third party vendor
• You must have network monitoring in place.

I am sure I can think of more things later, but it is now time to enjoy the game and festivities.

Why stay in a hotel when you can HOME AWAY!

Vote for HomeAway's Super Bowl commercial!

Presentation sponsored by Thoughtworks and Agile Austin

I am shifting gears a bit here, but I had the absolute pleasure of listening to Jim Highsmith speak here in Austin Texas.  Last Wednesday Thoughtworks and Agile Austin sponsored a talk by Mr. Highsmith on the topic of Agile Leadership.

I could never articulate all of the great content presented by Mr. Highsmith, so I will toss out some key concepts I managed to snag.  I am hoping Thoughtworks will distribute the slide deck so I can remember even more.

Focusing on Organizational Agility I recall one fundamental distinction.  Is your business focus based on Responsiveness or Efficiency?  If it is Responsiveness then it is probably important to learn Agile Management skills.

The core tenants according to Mr. Highsmith were Do less, Quality, Speed to Value, and Engage & Inspire. 

Do less is definitely applicable to my recent experiences with kanban. 

Of course Quality is important to me.  Quality really does matter to management and it is a proven fact that reducing defects reduces cost.

I am not so enthusiastic about increasing speed, but speed to value is a key to success.   We really do not want to be focusing on things that add little value.  In my opinion, we need to find a sustainable pace.

Now Engage and Inspire is a prime theme for me these days.  After attending the STP Conference in the fall of 2010, I certainly became inspired.  I am seeking the opportunity to engage with other testers and be inspired.  Hopefully I can inspire too.

Mr. Highsmith recommended several books.  You can find those recommendations on his blog.  I recall two suggestions: Drive by Dan Pink and Organizing Genius by Warren Bennis.

Software companies should have a focus on value and delivering features.  Wow!  That certainly makes sense to me. An interesting point was that companies should not permit product owners to do all of the prioritization.  If you let product determine the priority, then there is no room to work on technical debt, defects, or useful tools.  His point was many companies suffer from technical debt.

The talk inspired me to do my best to participate more in the Agile community in Austin.  I was speaking with Matt, the president of Agile Austin and I found out there is a group of testers that meet monthly over lunch.   I definitely want to get plugged in to that group.

My final point is if you get a chance to go hear these great speakers, please do so!  There are bits of goodness for everyone to take home.

Happy Testing!

Build Blocked at the end of Week 1

The team implemented their new process and this was the first week in action.  They started off with a large bottleneck in the acceptance test column.  The team quickly moved through the bottleneck.

As an outside observer the testers seemed to be happier.  They were actively involved at the start of the process rather than at the end.  Developers were completing acceptance test quickly and what appeared to be efficiently.  Blocked stories were obviously labeled on the board.  There definitely was a buzz in the air.

I did over hear a couple of developers wondering why the hell are we doing this, "Seems like we are reinventing the wheel!"  There were a couple of developers who were blocked.  So there was more time for foosball.

The teams goal was to have a branched release candidate by the close of business on Thursday.  Unfortunately at the close of business on Friday testers had found enough defects that a clean build did not exist.  The release is due out Tuesday.

It will be very interesting to see how things go on Monday.  Will the testers be able to adjust their regression testing pattern in order to get out a solid release.

As an outside observer I really enjoy collaborating with the test and development leads.  I shared two observations with respect to their kanban board.  Looking at the board there were numerous stories that were marked as blocked.  To me it was not clear from the board who owned the action item to unblock the story.  The other suggestion that I made was that they also need some sort of issue board or list, so everyone on the team knows what things are impeding the process flow.

The new 9 foot magnetic board is in.  The team has created some magnetic buttons with their personal avatars.  Lets just say some of the avatars are quite interesting, but I think it adds a bit of fun to the process.  They also created the yuck face buttons, which they can apply to blocked stories.  I am looking forward to seeing this board in action.

Oh one more very positive observation was that the team was able to move a few more defects through the process than were original scheduled.  I liked the buzz of the new process and testers know what to test.

Several of the team members were able to collaborate over an 18 page Power Point document and condense the material down into a handful of cukes.  Cukes are executable requirements from the open source tool, Cucumber.  Soon we will implement the strategy to automate the cukes.

Laissez les bons temps rouler!

Diving into the Abyss

We had a couple more brain storming sessions on moving a team onto the kanban train.

The biggest concern during these two sessions focused on our build process and software control systems.  We currently use Subversion.  Much of the discussion was around the complexities of checking in and backing out code.  How can our cadence flow in order to give testers builds of high quality and builds of trust.  I believe the final solution discussed was that we need to move from Subversion to GIT.

The development team believes GIT is a more friendly change control system for moving software around.  We shall see, but we do not have GIT today and we are about to jump into the abyss.

From my perspective, there are two potential issues when the team arrives for work on Tuesday.  One concern is that not all of the stakeholders were present during our brainstorming sessions.  I believe some team members will be surprised on Tuesday, but most will jump into the kanban abyss with both feet.  The other concern is that the WIP is already way over the estimated capacity.

Despite the WIP we decided to make the leap.  I stopped by the office on Friday and the Development Lead had a carefully crafted kanban board drawn across a couple of white boards.  He has a 9 foot magnetized board on order, but it has not arrived.  "See the team is already adjusting."  The large portion of the WIP is currently in the completed state and ready for acceptance testing.  The entire team (developers and testers) is going to start with this phase, write acceptance tests when they are not available, actuate the code, and test the pending features.  Viewing the kanban board I also noticed several key stories and defects have been placed in the ready state.

I am looking forward as an observer/consultant to see the giant green start button get pushed on Tuesday and the new process will begin to flow.  During our brain storming sessions to other key concepts were often mentioned.  During daily stand up meetings we have the ability to make minor adjustments.  Communication will be important.  The second concept was the big RED button.  The big RED button is "stop the presses" button.  I am hoping that for the first one week release cycle the red button is not used.

Unfortunately there is a high volume of risk with this release as the team jumps into the abyss.  If the team does a good job conducting thorough code reviews, acceptance tests and the test team stays on top of their game, then we may have the parachutes to float gently to the bottom of the abyss.  If we happen to land hard then we have the retrospective and make the first adjustments to the process.

The team is leaping and I believe 2011 is going to be a great year!

Kanban - Part II

Yesterday we had a brain storming session on what kanban would look like for the team.  I must say it generated a ton of good conversation.  Here are a couple of key points that I remember.

Someone mentioned that a team of testers could spend a majority of their time in the design phase, especially facilitating the development of Cucumber scripts.  It was suggested that one tester each week focus on this area and rotate the responsibility each week.  Another suggestion was to pair a tester and developer for each story.  The primary premise discussed was that if effective Cucumber scripts are developed then further down the process testers would know what to test even though they did not participate in the design phase.

Another key point was with respect to the current defect backlog.  How do we keep the defect backlog from building?  The team concluded that we need a dedicated swim lane in the process dedicated to fixing defects.  Dan Anderson shows in his book a good example where X% of the capacity is dedicated to defect resolution. 

What happens if a story is full of defects?  The conclusion was that the story remains in the process and is not released.  Since the team is inspecting the process daily, they can make adjustments to provide potential solutions.  One approach might be paired-development practices which provides real time training and retrospectives on what is happening with the story.  The ultimate conclusion is that if the team only got one story deployed each week they were adding incremental value to the business.  This should not happen often, but the bottom line is that it is OK to tweak the process on a daily basis and focus on deploying high quality valued features.

The one scary piece that we did not resolve was dealing with complexity.  Occasionally an Epic story comes into the team's backlog.  During the design phase we should be able to dissect and break the Epic into smaller stories, but the concern became how do we make sure the stories get implemented in the right order and that all of the stories that comprise the whole get assembled, tested, and deployed.  Adjusting for complexity will be a fun challenge, but a challenge never the less.

We talked about buffer zones and capacity limits.  We have no clue where to set the capacity limits.  It was suggested that we minimize the WIP so that we can gain confidence in the process and trust in the quality of the features being produced.

I must admit I am excited about this approach.  I know we will fall flat on our face a couple of times, but we will get up, collaborate, and continuous improve the process.

Stay tuned for Part 3.  We plan to walk through some real scenarios.

Kanban

I am wide awake Christmas Eve day at 5:20 AM.  I should be sleeping!  Instead I am reading a book by David Anderson, Kanban.  Why as a tester am I reading Kanban?  Well one of the teams I work closely with is about to implement kanban in 2011 as an attempt to improve their process.  So I ponder how does test have to change on order to fit into this paradigm.

I am not even going to attempt to describe kanban in this post, but I do want to convey I get a bit excited when I see the first step David Anderson recommends for moving to kanban.  He says the first step is to "Focus on Quality".  As a tester you have to like hearing those words.

I also agree with these points.

• Both Agile and traditional development approaches to quality have merit.
• Code inspections if done right can improve quality.
• Collaborative analysis and design improve quality. I believe testers should get involved early in the process!
• Using design patterns improve quality.
• Use of modern development tools improve quality.

As pointed out in the book all of these things improve trust and confidence in the process.

The team using kanban will be doing weekly releases.  They have been doing weekly releases, but development and test cycles were taking four weeks (2 in development and 2 in test).  The product owners were not getting their new features in a timely manner.

In December the team has been focusing on reducing the backlog of defects and discussing the implications of kanban.  In my opinion, the biggest fear of this change is coming from the testers.

I contend there is nothing to fear.  A story will move through this flow:

Idea > Design > Work in Progress (code, unit test, code review, automation) > acceptance test > final test > production

If there are 10 stories in the pipeline and 5 testers.  Then a tester is responsible for 2 stories.  Testers should be able to test 2 stories in a week.  Right?  OK it does depend on the size of the story.  The fear comes from the regression test phase.  My philosophy is automate regression tests where possible and focus on Exploratory Testing.  If testers cannot get over their fear perhaps any manual regression testing should be focused on the area(s) of highest risk.

I predict that the process will be bottle-necked in two areas.  The first bottleneck will be in design.  As part of design the team will be writing Cucumber tests.   Through collaboration the cucumber tests will make sure everyone is understanding the feature and testers will know what to test early in the process.  This process will take time.

I believe acceptance testing will go fast, but the second bottleneck will be the final testing phase.  Unfortunately testers are still focused on "Perfect Software".  I contend that the testers will have to implement test strategies that can be completed in 1-2 days.

I am looking forward to seeing this in action.

The extremely nice thing about kanban is that you know your pain points because you see them on the flow chart.  More importantly kanban expects you to change the process in order to remove the pain points.

Over simplification?  Maybe!  As Larry the Cable Guy might say "Git R done"!

I am definitely looking forward to this challenge in 2011.  I would welcome any comments from testers who are actively doing kanban.  I suspect there are not many.

Waterfall vs Agile

This past week Lanette Creamer posted on her great blog some statements with respect to her current team.  She implies that Waterfall teams are better at communication than Agile teams.

I would contend that the methodology has little to do with it.  You take a motivated and well spoken tester like Lanette, then combine other motivated members to her team and you will get good communication.

Motivated people make communication happen.  I will go one step further and say good communication makes for successful projects.

I have worked on waterfall, v-model, and agile projects.  If given the choice I will choose agile.

With waterfall and v-model I always found the massive amounts of documentation, document review, and the cumbersome process of reviewing changes to the documentation to be tedious.  In my opinion at times the process hindered communication.

With agile, lean, or Kanban we are afforded the opportunity to learn from our mistakes and quickly change the process.

But as to Lanette's point, agile projects can only be successful with excellent team communication.

So everyone who would like their projects to be successful sharpen your communication skills.

Books I am currently reading

All testers MUST read Perfect Software and Other Illusions about Testing by Gerald Weinberg.  I just finished reading this book and I found the content extremely useful and inspiring.  If you test software, read this book.

Now I am reading Lessons Learned in Software Testing by Cem Kaner, James Bach, and Brett Pettichord.  I am only a little ways into this book, but I am finding it to be spot on.

Next in the queue is Kanban - Successful Evolutionary Change for Your Technology Business by David J. Anderson.

If you are reading a great testing or development book, please make a comment so I can get more books into my queue.

Read on!

Think Times for Performance Testing

After only 10 years in the software industry, I am probably naive, but a recent post by Dan Barstow has caused me to question the use of think times.

Our current performance testing approach does not have think times.  I have used think times in the past for various applications.  I always have found think times to be somewhat arbitrary and subjective.  I can definitely see the value if your objective is to really understand the number of concurrent users the application can handle, but typically our objectives are focused on the number of transactions a system can process.    Also if you are using virtual users you truly are not representing a browser,.  A browser, depending on type, could leverage 6 threads at a time making requests.  So how do you adjust the think time between thread A getting an image and thread B retrieving javascript and firing the script?

Specifically we look for what is the optimal TPS value where 95% of requests latencies are less than 1 second and 99% of all requests are less than 4 seconds.

In my previous career I was a chemist.  On some regular frequency we had to calibrate our analytical instrumentation.  We would generate a 5-point curve using known standards.  Typically we sought a linear relationship of this curve where the low point was near the detection limit and the high point was near to the maximum detection point of the analytical instrumentation (e.g. – Gas Chromatographs).

When performance testing ramping VU in time intervals is similar to generating this calibration curve.  What I am typically looking for is how high can we generate the curve, yet still be below the high point of the instruments capability, which in this case the instrument is a configuration of servers and services.

I guess my philosophy might be that by eliminating think time I can get to that high point a bit faster.  Since we are testing a system, then my criteria is applicable to the total request and response.  So if the request is for an image or for a database object, as long as that request is returned within the criteria stated above, then we are within calibration.

My opinion is that if you are using virtual users then transactions per second is the important metric.  If you are using real browser users, then I think that think times might be important, but still subjective.  Regardless the objective is to do the best job possible to validate that your site gives customers a good experience.  I guess this can be achieved with or without think times.

For the record I have done some performance testing of JSON API where you could not even conduct the test without some level of think time.  So I will refine my conclusion to state that it depends on your objective and the application under test.

Please help educate me, because I am not in the think time camp unless it is necessary.

Selenium Fury has been released!

In my humble opinion, the page object pattern can be extremely important for a test framework.

Do you have an ever changing UI that causes your locators to frequently break?

With ASP.net do your developers frequently move elements around the page?

Do you have a brand new page and you quickly want locators to work with?

Selenium Fury just might be the tool to assist you.

I have posted in the past about generators and validators.  Scott Sims has rolled this functionality up into a nice gem.  The gem is easily extensible.

Check out Scott's post, use the gem and let him know what you think!

http://scottcsims.com/wordpress/?p=251

Oh, it is so fun being a tester!

Pirates vs Ninjas make it to Prime Time

I was catching up on some recorded shows.  I was watching my new favorite show, The Defenders.  Funny that it is set in Las Vegas the last location of STPCon.  Any rate last nights episode involved a hacker.  The main characters mentioned pirates and ninjas when talking about the hacker.  Were they observing Adam's and Lanette's Lightning talks at STPCon.  I found it very funny to hear pirates and ninjas mentioned regarding software on a prime time show.

The lightning talks were one of the highlights of the conference.  They were put on as breakfast bytes by Matt Heuser.  I love the format of lightning talks.

Since STPCon I have done some thinking about "pirates being better than Ninjas".  I have to respectively disagree with Adam Goucher.  I think ninjas are better than pirates.  Pirates might support developers in a loud and boisterous manner.  Ninjas would support developers in a silent and stealthy manner.  The good news is that testers exist to support development.

I guess it was obvious that I lean toward ninjas, hence the title of this blog.  That reminds me I need to get my ninjapus image uploaded to this humble blog.  My kids worked really hard prior to STPCon to help me create my logo.  I need to shrink it to appear on the blog, but I can certainly include it in this post.  You have to love the power of a ninja with 8 arms and multiple weapons for testing.  I think my kids 11 & 14 did an excellent job!  Go Ninjas!

Tester and Developer Pairing

I know at STPcon Lanette Creamer gave a session on "Pairing with Developers".  In hind site I truly wish I had attended that session. 

Currently one of our development teams is pushing out two releases per week.  There are a couple of issues in that the code is actually complete in the previous sprint and it takes test 1-2 weeks to execute regression.  This is not meeting the needs of the business, so we have added in "quick releases" with minimum code changes and minimal testing.  On top of that we are also injecting releases where we are conducting A/B testing (more on that latter).  In order to keep up an efficient pace, the team is now considering daily releases.  Wow!

This is essentially a shift to Kanban.  If you listen to Kent Beck, moving to this type of SDLC a team would essentially remove the testers.  I respectively disagree.  Testers can still play a critical role in the reporting of quality and making sure the releases are meeting business and customer needs.  As I ponder this paradigm shift, I believe "Pairing with Developers" becomes essential.

Developer grabs the next story and pairs with an experienced tester.  They work together design the unit tests.  As the developer implements the unit tests, the tester designs the acceptance tests (Cucumber) and developer does a code read.  As the developer writes the code, the tester implements the acceptance tests.  The tester should also collaborate with the developer to design and implement any browser facing tests (Selenium).  Integration tests should also be considered.  At the end of the day the code should be complete and all of the tests pass.  If all tests pass, then automated deployment pushes the release for UAT.  UAT Testers evaluate the functionality in a non-customer facing production environment.  If the user acceptance tests pass, then switch the environment to be customer facing.  In the A/B world we can expose only 20% of the customers to the new feature.  If there are no issues raised by the customers, then we push live. 

There may be other ways to complete the test automation, but this paradigm makes sense to me.  Not all testers have automation experience, so this places the emphasis on education and training.  How quickly will we get there? I do not know.  Is it possible?  Absolutely!

I am looking forward to this challenge.  If any of you are actively doing this style of rapid development please share you thoughts.

Gotta LOVE testing!

Top Ten STP Conference Experiences

I plan to write up individual posts on some of the sessions attended at the STP Conference.  In the mean time I thought I would rank the sessions and experiences in order of value to me. 

1. Session 103 - Testers! Get out of the Quality Assurance business - Michael Bolton
2. Keynote - G Forces in the Organization - Kent Beck
3. Keynote - Nice Bike: Fueling Performance with Passion - Mark Scharenbroich
4. Breakfast bytes - Agile Testing Ninjas - Lanette Creamer
5. Breakfast bytes - Pirates are better than Ninjas Even in the Agile World - Adam Goucher
6. Workshop - Hands on Performance Testing Dan Downing and Goranka Bjedov
7. Session 403 - Ever Been fooled by Performance Testing Results? - Mieke Gevers
8. Session 305 - From Start to Success with Web Automation - Adam Goucher
9. Keynote - Top Ten Leadership Skills: Surviving and thriving in 21st Century - Kelli Vria
10. Party on the Strip - Christian Audigier at Treasure Island (met many great Testers!)

If you attended, what were your top ten?

Better Late than never

I finally realized that there are many great blogs that I follow, so I had better add a blog list to my tiny space of free thought on testing.

What really inspired me to do this was this post:

http://cartoontester.blogspot.com/2010/10/monotonous-context-and-certification.html

The cartoon absolutely illustrates that testers can get caught in a rut.  Collectively we need to continuously remind ourselves to get out of the rut. 

Think, experiment, and do!

I wish I had the creative mind to do great cartoons like Andy Glover.

AWK and GREP are your friends!

I definitely plan to write up some lessons learned from the STP Conference, but I thought I would share this quick tidbit for performance testers.

Our website profile is constantly changing so we inspect our log files to determine the correct mix for our performance testing.  There are many ways to do this and you can get as complex as you want.  Typically we choose our peak traffic day.

You have an access log and you want to know ratio of the number of GETS to the number of POSTS.

This command should give you the total number of requests.

cat | awk '{ print $7 }' | wc

This command should give you the total number of GETS.

 cat |grep \"GET | awk '{ print $7 }' | wc

This command should give you the number of POSTS.

 cat |grep \"POST | awk '{ print $7 }' | wc 

You can substitute "less" for the "wc" and you will see on your screen all of the GET requests.

You can use multiple grep segments to further refine your data. 

cat |grep \"GET | grep " 200 " | awk '{ print $7 }' | wc 

So my specific test I am only interesting in GETS with response code of "200".  I could write these results to a file.

cat |grep \"GET | grep " 200 " | awk '{ print $7 }' | wc >> foo.txt 

Yes some of you already know this stuff, but my main point is that you can learn a ton about your site traffic simply by dissecting the access logs.  You can generate a flat file that can be used by your performance tool of choice to randomly send requests to your system.  You can write a simple shell script that can take any access log and generate a quick breakdown on the request profile.  This profile can be used to proportion your performance test traffic in a similar pattern as your current user base.


Go ahead and karate chop your access logs!

 

Short Post on STP Conference

It is pouring down rain in Las Vegas.  Yes I said pouring down rain.  The rain and long taxi line is preventing us from going back to our condo.  So we are hanging out waiting to go to the big party at Treasure Island.  We will be true geeks and take our computer backpacks to the party.

So here are my short thoughts.

• Great people
• Extremely engaging
• Some material unfortunately is not applicable to the things we are currently focused on
• Some speakers I could listen to all day long
• I am eating way to much food
• I am doing tons of walking, but not off setting the amount of food and mmmm alcohol
• I am having a great time
• And the organizers of the event are doing a FABULOUS job!
• I hope I can be a presenter in the near future.
• I hope I can continue to collaborate with some of these smart people.
• And final note - I wish I had a large volume of cash

Hopefully I will find the time to post future blogs on all of the things that are currently floating around in my two brain cells.

Have fun!

STP Conference are you ready for me?

On Sunday I depart with 2 colleagues for Las Vegas to attend the STP Conference.  I am pumped up.  I am ready to learn what is happening in the wonderful world of testing.

On Monday I am attending an all day hands workshop about Performance Testing.  I do know how to use JMeter, but I am hoping to learn more tricks and gain insight as to how others approach performance testing.  Perhaps I have a few tricks up my sleeve to share!

Here are some of the other sessions I am hoping to actively participate in.

1. Testers!  Get Out of the Quality Assurance Business by Michael Bolton
2. Becoming an Automation Entrepreneur by Linda Hayes
3. From Start to Success with Web Automation by Adam Goucher
4. Ever Been Fooled by Performance Test Results? by Mieke Gevers
5. Testing in an Agile Environment by Rob Walsh
6. Test Faster: Model Your Test Process to Test Faster by John Ruberto
7. Using Open Source Testing at Ford by Frank Cohen
8. What You Need to Know About Performance Testing by Michael Czeiszperger

I may switch gears and attend other sessions, depending on the value.  There are so many excellent topics to choose from.  I am hoping to meet and network with as many testing gurus as possible.

There are a couple of key note speakers I am curious about Kelli Vrla and Kent Beck.  I am sure they will all be interesting.   The real key is to keep me away from poker tables.  :o)

Stay tuned for future posts on various topics spinning in my two brain cells after the conference.

Happy Testing!

Page Generator Example

Last time I posted I promised some code.  I finally got around to compiling the code into a format that could be placed on this blog.  I borrowed some of these methods from our framework library, but I think this code illustrates how efficient a generator can be for formatting page locators.  Page object pattern is a valuable approach to an automation framework.

Note that this code calls a test helper file.  I have not included that here, but basically it is a file that specifies the gems that are necessary.

require 'rubygems'
gem "rspec", "=1.1.12"
require "spec"
gem "selenium-client", ">=1.2.18"
require "selenium/client"

In the code below there are two generators.  One can be used to get all of the links on the page and the other is used for other html elements.

Once these generators are executed the locators can be placed in a page file.  At the bottom of the output the labels are formatted into the correct accessor format for a page object file.

Below is a ton of code so enjoy!  Let me know if you have any questions.

One final comment in that not of all the links on Google's home page get formatted nicely.  I did not have time to fix the formats.

Hopefully on the next post I will provide the page file and an example of using the page file.

Enjoy!


require File.dirname(__FILE__) + "/../../spec/test_helper"

describe "Generate home page locators for google" do

  append_after(:each) do
    browser.close_current_browser_session
  end

  it "should generate locators for check boxes, text boxes, text areas, input images,and select boxes for the google home page" do

    my_setup("http://www.google.com/")

    browser.open ("/")

    get_source_and_print_elements(browser)
  end

  it "should generate and format the links from the google home page" do

    my_setup("http://www.google.com/")

    browser.open ("/")

    html = browser.get_html_source

    generate_link_instance_variables_from_html(html)
  end


  #  Below are the methods that help to extract out the components from the html and format them into locators and accessors

  def my_setup(target)

    @browser = Selenium::Client::Driver.new \
    :host => ENV['Host'] || "localhost",
    :port => 4444,
    :browser => ENV['SELENIUM_RC_BROWSER'] || "*firefox",
    :url => target,
    :timeout_in_second => 60

    browser.start_new_browser_session

  end

  def browser
    return @browser
  end

  def get_source_and_print_elements(browser)
    html =browser.get_html_source
    html_elements_check_boxes = GooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "input[type='checkbox']")
    html_elements_text = GooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "input[type='text']")
    html_elements_selectGooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "select")
    html_elements_text_area=GooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "textarea")
    html_elements_image = GoogleBasePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "input[type='image']")
    html_elements_radio = GooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "input[type='radio']")
    html_elements_form = GooglePage.generate_instance_variables_from_html(:html =>html, :locator_type => "css", :locator => "form")
    merge_and_print_elements([html_elements_check_boxes, html_elements_select, html_elements_text,
                              html_elements_text_area, html_elements_image, html_elements_radio, html_elements_form])
  end


  def generate_instance_variables_from_html(options)
    if options.kind_of?(Hash)
      @html = options[:html]
      @locator_type = options[:locator_type]
      @locator = options[:locator]
    end
    doc = Nokogiri::HTML(@html)
    html_elements = {}
    if (@locator_type=="css")
      doc.css(@locator).each do |html_element|
        attribute_name =  html_element.get_attribute("id")
        attribute_value = html_element.get_attribute("id")
        if !attribute_name.nil?
          attribute_name.gsub!('input-', '')
          attribute_name.gsub!('select-', '')
#          attribute_name.gsub!(/([A-Z]+)/, '_\1')
          attribute_name.gsub!('\\', '')
          attribute_name.gsub!(' ', '_')
          attribute_name.gsub!('.', '_')
          attribute_name.gsub!('-', '_')
          attribute_name.gsub!('__', '_')
          attribute_name = attribute_name.to_s.downcase
          puts "@#{attribute_name} = \"#{attribute_value}\"" if $debug
          html_elements[attribute_name]= attribute_value
        end
      end
    end
    return html_elements
  end

  def merge_and_print_elements(page_elements_types)
    html_elements={}
    page_elements_types.each do |element_type|
      html_elements.merge!(element_type)
    end

    puts "found (#{html_elements.length} elements)"

    html_elements.keys.sort.each do |key|
      puts "@#{key} = \"#{html_elements[key]}\""
    end
    html_elements.keys.sort.each do |key|
      print ":#{key}, "
    end
  end

  def generate_link_instance_variables_from_html(html)

    doc = Nokogiri::HTML(html)
    links = {}
    doc.css("a").each do |link|
    #  puts link
      link.text

      links =  format_link_text_from_label(link, links)
    end

    links.each_pair { |key, value| puts "@#{key} =  \"css=a:contains(\\\"#{value}\\\")\"" }
    links.each_key { |key| print ":#{key}, " }

    return links
  end

  def format_link_text(link, links)
    link_content=link.content.to_s.downcase
    link_content = link_content.strip
    link_content.gsub!(' ', '_')
    link_content.gsub!('"', '')
    link_content.gsub!('-', '_')
    link_content.gsub!('+', '_')
    link_content.gsub!('*', '')
    link_content.gsub!('\'', '')
    link_content.chomp
    #puts "#{link_content} --->     #{link.get_attribute("href")} "
    links[link_content] = link.get_attribute("href")
    return links
  end

  def format_link_text_from_label(link, links)
    link_text=link.text.strip
    link_text=link_text.chomp
    link_content=link.content.to_s.downcase
    link_content = link_content.strip
    link_content.gsub!(' ', '_')
    link_content.gsub!('"', '')
    link_content.gsub!('-', '_')
    link_content.gsub!('+', '_')
    link_content.gsub!('*', '')
    link_content.gsub!('\'', '')
    link_content.gsub!('_&_', '_')
    link_content.gsub!('(', '')
    link_content.gsub!(')', '')
    link_content.gsub!(':', '')
    link_content.gsub!('.', '_')
    link_content.gsub!('@', '_')
    link_content.chomp
    links[link_content] = link_text
    return links
  end

end