Tuesday, December 20, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Monday, December 19, 2011

Side-by-Side Viewing of Mobile Devices

One of the things we've found in our work with testing various mobile devices is that it is often very convenient to be able to see the same page delivered to two different devices in a side-by-side comparison. The visual impact of the changes can be enlightening.

It turns out that this is relatively simple to do, using a special launch page and custom playback script. In the script the UserAgentString is set to a device and a sub-window opens emulating that device. After the two [it could be more, if you have the need] sub-windows are opened eValid pauses playback, leaving both sub-windows open and live.

In this state, you can manipulate either of the two emulated devices in any way you wish, and see what the server renders in response. For backup, you can see the server response for the same page request in the parent screen. Here is a screenshot of Two Smartphones (iPhone and Samsung Galaxy) and of Two Tablets (iPad and Samsung Galaxy Tab). Both screenshots show the same page all three ways. And you can see the UserAgentStrings directly.

Here is the full writeup of how this is done, including a sample script and a typical parameter setting file: Side-by-Side Comparison of Two Devices. Sample screen images are shown in Side-by-Side Sample Screens.

Wednesday, December 14, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Thursday, December 8, 2011

Mobile Device Testing

There has been a lot of interest recently in how to handle quality issues (content, performance, server capacity) for web applications that run on mobile devices. From the eValid perspective the main issues work out to these:

  • Device Simulation: Using the eValid SetUserAgent command to set the User Agent String (UAS) so that the subsequent browser activity is reported to the server as if it was being requested from the specified device. eValid does this without needing the actual hardware and software! The server responses to client-side user requests made in this way behave as if it was talking to the mobile device.

  • Content Validation: Once a script is running, you need to validate that the eValid rendered output matches what you expect in the actual device. Here is a Rendering Comparison for Common Devices Vs. Device Emulator. As you can see, other than the screen size, the rendering by eValid is identical to that for the mobile device. This confirms that evalid is rendering your mobile application correctly.

  • Functional Testing: To illustrate how this works we ran an experiment that applied a simple test to 100 Mobile Devices, and recorded download sizes and times for each cases. A sample of that data is shown here, with some Selected Screenshots of how the server content varied as a function of the different devices and software versions simulated (with download byte counts for each device shown).

    The most interesting thing we saw was that the asymmetric ratio of Download Bytes vs. Download Time, which illustrates that some servers are not prepared to deliver mobile content to every kind of device.

  • Server Loading: Functional tests lift easily to a server loading context, with multiple eValid instances (we call them Browser Users or BUs) working in parallel to create the load. This is illustrated in the experiment that we ran to drive a mobile application from a simulated smartphone up to 1,000 BUs -- up to 1,000 simulated users. The resulting
    Chart of Derived Internal Response Times shows that this particular server began to have a problem beyond ~200 simultaneous users.

The thing to remember is that eValid can effectively drive mobile devices that support web applications perfectly well, and can impose realistic load levels sufficient to identify bottlenecks.



Tuesday, November 22, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.
  1. The settings for sourceIndex and elementValue -- Rules about preserving internal variable values. 
  2. Why doesn't eValid support XPATH? -- eValid's internal XPATH capabilities explained.
  3. The value of sourceIndex -- Ways to retrieve the current value of internal parameters.
  4. Synchronize a playback on an invisible property value. -- Unusual ways of achieving synchronization.
  5. My website changes in the middle of the run -- What to look out for when web pages change rapidly. 
  6. The minimum "settling time" -- How much time is spend "rendering" and "settling" a page? 
  7. Text Synchronization -- Details of how to do synchronization on page text.
  8. How do I turn on Application mode or Desktop mode? -- Internal mode change hints.
  9. How well does eValid scale? -- Details on scaling eValid to high repetition counts.
  10. A Dynamic String -- Methods of manipulating a dynamic string.

Monday, November 21, 2011

Mobile Device Rendering Validation Experiment

We had had some people asking whether the eValid rendering of a mobile web application REALLY matches up with what you actually see in the real device?

To illustrate that it does, we constructed a demo of four four popular smartphone and how they rendered a page compared with the eValid renderingwhen eValid is imitating the same device.The Rendering Comparison for Common Devices results speak for themselves.

As you can see in a side-by-side comparison (click th images and move them so theyare side by side) the HTML that is delivered by the server to the suitably disguised eValid browser is renders identically to what you see in the smartphone.

Monday, November 7, 2011

Webinar: Load Testing Mobile Web Apps

Simulate 1,000's of Mobile Browser Users
Full AJAX Realism on All Mobile Devices
Quick Identification of Bottlenecks

Register
Wednesday, 16 November 2011
2:00 PM Eastern Time / 11:00 AM Pacific Time
QA/Testing/Tuning/Performance projects need to qualify performance of complex AJAX web applications -- within strict budget and time constraints -- to make sure their server-stack setups can meet the load.

The traditional methods of ramping up load, based on using HTTP/S simulations or "VUs", don't always work when asynchronous AJAX applications are involved. VU's don't do AJAX. You need a browser.

eValid server loading methods offer both quick-to-create, realistic, and fully synchronized AJAX functional tests. Plus you can lift those tests into performance/loading scenarios that can involve 100's or 1,000's or 10,000's of Browser Users ("BUs") per machine.

In this webinar you'll learn: how special eValid commands overcome problems with variable-time playback dependency; how to create full-reality AJAX tests quickly; how to adjust tests to be totally self-synchronizing under stressed AJAX conditions; how to incorporate tests in an eValid LoadTest scenario; how to launch 100's or 1,000's or 10,000's of Browser User (BU) instances; and, how to analyze consolidated performance summary data to identify server-stack bottlenecks.

This unique approach demonstrates how eValid becomes a genuine force multiplier in your web application performance testing efforts.


Webinar
Topic
Summary
  • eValid Architecture and Structure: How eValid functional and performance testing works.
  • Functional Testing: How to make reliable recordings of AJAX applications.
  • Making AJAX Tests "LoadTest Safe": How to augment tests for complete AJAX synchronization.
  • Creating LoadTest Scenarios: How to use the LoadTest scenario editor to organize realistic LoadTest control scripts.
  • Running LoadTests: How to launch single and multiple-instance runs using "cloud computing" resources.
  • Finding Bottlenecks: How to read the LoadTest and other raw data to help spot server-stack issues.

You are cordially invited to attend this free Webinar.

Register now

Thursday, November 3, 2011

Mobile Device Loading Experiment

Using eValid's ability to mimic being a mobile device, we engineered a simple demonstration of a 1,000 browser user (1,000 BU) test of a public transportation system's schedule information page, which is intended to be delivered to users of mobile devices. You're in the station and you want to know when the next train for your destination is? But you don't want it to take too long to show you the results, or you might miss your connection.

We set eValid up to imitate an iPhone, and configured the LoadTest scenario to launch successive eValid instances at 1 second intervals. The test script takes about 15 seconds to navigate to the website and download the key schedule data page. We put the playback in "repeat mode" so that, after all 1,000 BUs were launched there would be the equivalent of 1,000 users driving the mobile device.

Finally, the single data point taken from each and every repetition — some 5,587 data points in total — was the time that the actual data page took to download. Here's the chart of the results as a function ot time within the scenario:

Chart of Derived Internal Response Times (Click to See Full Image)

The payoff information here can be seen at the beginning of the chart, when the download time was pretty much independent of the applied load -- up to about 200 BUs. After that, the more users requesting that page, the longer it took, so that at the end, with 1,000 BUs asking the download time was as long as 5 minutes. It looks like someone'll be missing the bus!

Here is the link to the full solution description: Mobile Device Loading Experiment – 1,000 BUs

Friday, October 28, 2011

Testing Mobile Web Apps

An eValid user wrote:
Can you please explain in more detail how eValid simulates web applications on mobile devices? Also, you claim that your tests done by eValid when simulating mobile devices are functionally equivalent to using the mobile device? Can you elaborate?

Background
First, some background information and details... The underlying question here is, what does it mean to test a mobile web application?

It is important to make sure of the distinctions between how a mobile web application responds and how a mobile device responds. In other words, you have to ask yourself: are you testing a mobile device; or, are you testing an application that runs on a mobile device.

If it is the latter — testing a mobile device — then eValid is not well suited to that type of work. eValid is not a device tester — it is a web application tester.

But if it is the former then the question really reduces to, "what does it mean to test a mobile web application?"

eValid Solution
Being primarily a web application testing system the main focus for eValid is, from a user's perspective (that is, from inside a browser), how does the application behave? The key word is "behave," and to eValid that means the kind of content is delivered (is it correct or not?) and how fast is it delivered (does it meet performance thresholds).

When you use the eValid SetUserAgent command to set up eValid to act like a mobile device, the data eValid generates in response to requests from the server is no different from what the actual device generates from the server. In other words, if you change the "identity" of the browser as a test driver, you change the response from the server, and you effectively test the server's ability to support the "identity" of the browser.

And the key facts about quality — validation of response data and quantification of response times — are perfectly measurable from the eValid desktop. In most instances, mobile device download speeds are nominally in the same range as those for most desktop applications. The data delivered to a mobile device passes through a wireless gateway of some kind before reaching the device, whereas the same data has to pass through some kind of internet service provided before it reaches your desktop.

In other words, you don't need the actual device to stimulate the server responses, and you don't need the actual device to validate content and to measure performance timing data.

_________________

eValid Support

Thursday, October 27, 2011

Recent eValid Technology Questions

Recently there have been a number of eValid User Forum postings that raise interesting questions about eValid's architecture and underlying technology.

Monday, October 24, 2011

Using evalid With An AJAX Autocomplete Functionality

This scripting example investigates how eValid can be used to validate an AJAX autocomplete function. The two variants of the script shown below operate as follows:
  1. Introduce a partial string into the text area, for example evali.
  2. Capture the contents of the DOM after the AJAX activity has provided some suggested completions.
  3. Confirm that a required string, for example evalid, is present within the available suggestions presented by the autocomplete feature.

The goal of the script is to confirm that, among all of the possible suggested completions, that the target evalid string is among the options presented. If successful, this process effectively validates operation of the AJAX autocomplete function by confirming its results with known (expected) data.

Here is the link to the full solution description: Checking AJAX Autocomplete Functionality

Friday, October 21, 2011

Manipulating the Target Window

How do you use the eValid DOM manipulation commands to modify an anchor-tag's attributes to deliver the page to a different specified new window than the one given in the HTML passage.

In this typical HTML passage if you click on the link the new page is opened in a new window named "NEW-WINDOW":


<A HREF=../URL TARGET=NEW-WINDOW>Title Of Page</A>

The key to modifying this link target dynamically is to recognize that any anchor tag that has a specified target will have the name of the target stored as one of the attributes in the defining DOM element. All you need to do is find the right element, and then put in a new string for the target page.


Here is the link to the solution description: Change the Target of an Anchor Tag Link To A New Window

Wednesday, October 19, 2011

Modifying DOM Elements Dynamically

How do you use the DOM manipulation commands to modify a specific DOM element dynamically?

In this illustrative solution an eValid script demonstrates the ability to modify the DOM dynamically by using eValid DOM manipulation commands to change the background color.

  1. Navigates to a page
  2. Changes the background color for one element to COLOR1.
  3. Waits 5 seconds (so you can see the effect).
  4. Changes the background color for one element to COLOR2
  5. Waits 5 seconds (so you can see the effect).
  6. Changes the background color back to the original background color.
  7. Waits 5 seconds (so you can see the effect).

Here is the link to the full solution description: Modify a DOM Element Dynamically

Monday, October 17, 2011

Update on Mobile Application Performance

Some months ago we ran a small experiment on the Beta site of a mobile application in which we ran a small 100-BU (Browser User) test to see how performance of the application changed as the load increased, linearly, from 1 BU to 100 BUs.

As a followup, we repeated the experiment on the same application -- which now has become a full-scale "non-Beta" application -- with the results shown here:

Further Comparative Improvement of Performance Under Load

As you can see from the charts, things didn't necessarily get better, and you could say that there was some deterioration. But remember, that later data -- from over four months ago when the tests were first run -- is now from a live application. Right now it appears this application is "good" for up to about 25 simultaneous users, but performance drops off quickly after that -- as much as a 5x degradation beyond 50 simultaneous users.

Friday, October 14, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

  1. Can eValid test applications using GWT and Vaadim? -- Tricks in testing a specialzed application
  2. Complex Synchronizations -- Is there a resource problem?
  3. Keep Separate Cookies -- More about saving your cookies!
  4. Can eValid detect graphic differences in my app's GUI? -- Methods to confirm graphics are described.
  5. Use of the cache during server load test -- Details on cache locking.
  6. Can you guys run a monitor on a smart phone app? -- Mobile monitoring.
  7. Run a batch mode scan? -- Background site analysis.
  8. Why does eValid base its operation on IE? -- Justifications for IE dependence.
  9. Can eValid test IPhones? -- How to spoof iPhones.
  10. Pretending to be a mobile client -- More about mobile client emulation.

Thursday, October 6, 2011

Webinar: Structural Testing for Mobile/AJAX/Web 2.0

Run Functional/Regression Tests on
Complex, Dynamic AJAX/Web 2.0/Mobile Applications
Extremely Robust Tests Are Based on Structural Page Features

Register
Wednesday, 12 October 2011
2:00 PM Eastern Time / 11:00 AM Pacific Time

When web applications often change in subtle ways, and your functional/loading/monitoring tests may begin to fail if your test scripts are "brittle". eValid's advanced structural testing commands overcomes this problem to help you achieve tests that survive page changes -- but still validate performance realistically.

The eValid structural testing command set makes it possible organize tests entirely around structural properties of a page that don't change over time. A test done with structural testing methods can handle any AJAX/Web 2.0/Mobile application reliably and efficiently. Even when page structure and details (but not essential functional intent and effect) -- change substantially.

Learn how to achieve greater productivity with smaller budgets, maximize your IT investments, and get more work done in less time with less energy.

Build reliable, robust AJAX/Web 2.0/Mobile tests once -- and you won't have to worry about them again.

Webinar Outline
  • Introduction to eValid's Architecture.
  • Functional Test Creation: "What you see and do, is what eValid records, is what eValid reproduces".
  • Methodology Overview: Record From Life, Adapt From Page Facts
  • Index/Motion (Algorithmic/Structural) Command Summary
  • Typical Script Passages: "Recorded From Life" and Structural Versions
  • Script Enhancement for AJAX/Web 2.0: Bullet-Proofing Your Playback
  • Practical Experience & Recommendations
You are cordially invited to attend this free Webinar.
REGISTER NOW!

Friday, September 2, 2011

Can you tell me more about eValid's architecture?

An eValid user wrote:

Can you tell me more about eValid's architecture? Is it based on the Trident Rendering Engine?

Yes, the browsing part of eValid is based on use of the MSHTML (Trident Rendering Engine) libraries.

Although this makes eValid a complete browser (which emulates behavior of whatever version of IE you have installed on your machine), there are a few differences in the way eValid interacts with MSHTML. The main difference is that eValid has direct, immediate, "in-memory" access to the browser DOM and this unique capability makes much of what eValid does possible.

That architecture -- incorporating direct DOM access in a free-standing executable -- also is the reason why we can use eValid in server loading work by running multiple (100's or 1,000's of) instances to impose completely realistic load.

Also -- and this fact may be just as important -- the eValid engine does not make use of the JavaScript interpreter that is part of the browser. That is important because it means that applications that rely on JavaScript like modern RIA's that use AJAX do not experience any interference in their operation from the test engine itself. (You would not want a test engine to interfere with it is supposed to test, would you?)

Monday, August 29, 2011

How to record synchronization points from the GUI?

An eValid user wrote:

I need to make a good recording of an AJAX app, but I need to know how to record synchronization points from the GUI. I don't want to have to manipulate the script at all, please!

That's actually very easy.

The most common synchronization point is "Validate & Synchronize on Selected Text." This is 99.99% reliable even for AJAX applications (there are always 0.01% where you have to resort to "structural commands").

The protocol is simple to follow:

On each page, as you make your recording, select a piece of visible text with the left mouse button so that it is highlighed. Then click eValid: Record > Validate > & Synchronize > Text String, or simply press Ctrl-Y.

You'll see eValid record a command in the Script Window.

Now, knowing that the synchronization logic will wait for the highlighted text that you chose to show up on the screen at playback time, you can then take the next action. Click on a button, click on a link.

Then, wait for the application to settle down and repeat the sequence.

Simple enough. Just remember: Wait --> Sync --> Act, [Wait --> Sync --> Act, --> ...].

Thursday, August 25, 2011

Advanced Structural Testing Webinar Movie Available

The "movie" recording of the eValid Webinar, Advanced Structural Testing of Mobile/AJAX/Web 2.0 , that was given on 17 August 2011 by Dr. Edward Miller & Ms. Rita Bral, is now available. To view the movie simply click Request.

Wednesday, August 24, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Wednesday, August 17, 2011

How long do you think it will take me to learn to do a very complex AJAX application, starting from scratch with eValid?

An eValid user wrote:

How long do you think it will take me to learn to do a very complex AJAX application, starting from scratch with eValid?

The answer depends on what kind of web application you are testing.

(1) If you are driving a "conventional" (non-AJAX, see below) website, then eValid orginarily has sufficient internal automatic playback synchronizations built in so that you don't need any extra steps. Just type and click and eValid will record what you've done and will play it back, no problem.

Standard advisory note: If you record logging in to an application and then play back that script withOUT having logged out, then it's likely the playback will fail. You're still logged in! Of course it will fail. Good practice says, either record after having logged in and don't log out, or record the login and make sure you end with a logout.

(2) For AJAX applications the situation is more difficult. Because of AJAX activity in the browser, you may not get an accurate playback because the time that AJAX takes varies with web load and other factors. The "out of the box" recording with no special steps may or may not fully synchronize at playback time.

However, there is a very simple recording protocol that we recommend to use when you are dealing with an AJAX application. The basic idea is to use the eValid: Record > Validate > & Synchronize > Text String sequence from the eValid GUI to create synchronization logic as you make the recording. The sequence is simple: Act, Wait, Sync, [Act, Wait, Sync]...

The steps are simple enough: (a) navigate to the next page in the test plan, (b) wait until it is fully loaded, (c) highlight a piece of text on the page, then (d) execute the above command sequence (or use the Ctrl-Y shortcut). The resulting script then has a synchronization step that has to be satisfied before every action -- and this will assure fully synchronized playback.

Additional Note: In certain rare cases for AJAX applications you may need to resort to other, more powerful, DOM-based synchronizations if the recording protocol described above doesn't work. Just look up "Synchronization" in the eValid User Manual for complete details on this.

Wednesday, August 10, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.


Monday, August 8, 2011

What is the best way to record a test that you know will run when you play it back?

An eValid user wrote:
What is the best way to record a test that you know will run when you play it back?

The answer depends on what kind of web application you are testing.

(1) If you are driving a "conventional" (non-AJAX, see below) website, then eValid orginarily has sufficient internal automatic playback synchronizations built in so that you don't need any extra steps. Just type and click and eValid will record what you've done and will play it back, no problem.

Standard advisory note: If you record logging in to an application and then play back that script withOUT having logged out, then it's likely the playback will fail. You're still logged in! Of course it will fail. Good practice says, either record after having logged in and don't log out, or record the login and make sure you end with a logout.

(2) For AJAX applications the situation is more difficult. Because of AJAX activity in the browser, you may not get an accurate playback because the time that AJAX takes varies with web load and other factors. The "out of the box" recording with no special steps may or may not fully synchronize at playback time.

However, there is a very simple recording protocol that we recommend to use when you are dealing with an AJAX application. The basic idea is to use the eValid: Record > Validate > & Synchronize > Text String sequence from the eValid GUI to create synchronization logic as you make the recording. The sequence is simple: Act, Wait, Sync, [Act, Wait, Sync]...

The steps are simple enough: (a) navigate to the next page in the test plan, (b) wait until it is fully loaded, (c) highlight a piece of text on the page, then (d) execute the above command sequence (or use the Ctrl-Y shortcut). The resulting script then has a synchronization step that has to be satisfied before every action -- and this will assure fully synchronized playback.

Additional Note: In certain rare cases for AJAX applications you may need to resort to other, more powerful, DOM-based synchronizations if the recording protocol described above doesn't work. Just look up "Synchronization" in the eValid User Manual for complete details on this.




Wednesday, August 3, 2011

Webinar: Advanced Structural Testing for Mobile/AJAX/Web 2.0

Run Functional/Regression Tests on
Complex, Dynamic AJAX/Web 2.0/Mobile Applications
Extremely Robust Tests Are Based on Structural Page Features

Register
Wednesay, 17 August 2011
2:00 PM Eastern Time / 11:00 AM Pacific Time

When web applications change in subtle ways, your functional/loading/monitoring tests may begin to fail if your test scripts are "brittle" -- i.e. break easily. eValid's advanced structural testing commands overcomes the "brittle test" issue to help you achieve tests that survive page changes -- but still validate performance.

The eValid structural testing command set makes it possible organize tests entirely around structural properties of a page that don't change over time. A test done with structural testing methods can handle any AJAX/Web 2.0/Mobil application reliably and efficiently. Even when page structure and details (but not essential functional intent and effect) -- change substantially.

Learn how to achieve greater productivity with smaller budgets, maximize your IT investments, and get more work done in less time with less energy.

Build reliable, robust AJAX/Web 2.0/Mobile tests once -- and you won't have to worry about them again.

Webinar Outline
  • Introduction to eValid's Architecture.
  • Functional Test Creation: "What you see and do, is what eValid records, is what eValid reproduces".
  • Methodology Overview: Record From Life, Adapt From Page Facts
  • Index/Motion (Algorithmic/Structural) Command Summary
  • Typical Script Passages: "Recorded From Life" and Structural Versions
  • Script Enhancement for AJAX/Web 2.0: Bullet-Proofing Your Playback
  • Practical Experience & Recommendations

You are cordially invited to attend this free Webinar.
REGISTER NOW!

Tuesday, August 2, 2011

Page Performance Optimization Methods

There has been a great deal of interest in the web community recently about how to speed up web page delivery. At least some of this discussion is prompted by the increasing sizes of web pages, particularly for AJAX and Web 2.0 applications. For example, a few years ago a 100 KByte page would be considered "large," but now we see some pages that download 1 MByte, and these are considered "normal". Some website, e.g. the CNN site, regularly download 1.5-2.5 MBytes -- and that's not counting videos. In earlier times web page component counts could be in the low tens, now the component counts are 100+. On a recent day, CNN's page had 113 individual URLs involved.

To improve average download performance you have to buy your customers more bandwidth (this could be expensive!), or you need to figure out how to reduce the size of your pages (tedious, but very effective). But to fix something you have to understand it, and that's where a couple of eValid tricks come into play.

Page Metrics Popup

This is an eValid feature that runs along with your browsing activity.

As you navigate through a website, after each page is fully downloaded you see a simple popup like the one at the right (click on the image to see the full picture).

The data extracted by eValid includes the size of the base page, the total number of URLs involved, and all of the details about the internal structure of the page including the total size of the download.

Here are the details on eValid's Page Metrics Popup feature.

PageSpeed Process


The eValid PageSpeed Process uses the "detailed page timings" feature to collect page component byte-count and download times, in the order in which each component is recovered and rendered.

The resulting "stack chart" reveals detailed the download time and size of each page component, by simply hovering your mouse over the display bars. This way, you know which element is the bottleneck.

Bottom Line: eValid gives you all the details on what's what about your page. It's up to you to fix the problems eValid analytics reveals. That's a lot easier to do if you know what's wrong.

Monday, July 25, 2011

Drive tests using JavaScript?

An eValid user wrote:
Does evalid drive tests using JavaScript? If not, why not?

There are many reasons why evalid does NOT "drive tests using JavaScript" and some of them go back to the very beginnings of eValid.

A main goal of the eValid technology development was to provide a test bed or test driver that could work efficiently and easily with web browser enabled applications. In that beginning period -- going back to over 10 years ago -- we had completed internal "proof of concept" implementations of several kinds of testbeds. We tried out "wrappers," we tried out on-board programs using JavaScript passages, we tried out various "browser editors"...in short, we tried all of the combinations that we could think of.

What we discovered in our early engineering work was that there was a vast difference in the overall performance -- and a vast difference in how much each testbed trial solution interacted with the behavior of the web application. It was the potential for "bad interaction" which pointed the way for the team, because the underlying assumption was that, to be a good test driver, the test drive could not get in the way of the thing being tested.

Of all of the alternatives that were considered, we leaded strongly on the one prototype product that was built with an open-source browser. Having that kind of direct, immediate, "intimate" control of all of the signals and events and transfers and other activity while the browser gets the page components, assembles them into the internal document object model, and finally renders them to the user -- that level of interaction, we felt, was "perfect" for what we envisioned eValid to do.

We sill had to deal with the question of "overhead." No matter how efficiently you build a test driver, it is software so it takes some fraction of the CPU to execute. We settled on a target of not more than 0.1% interference with the application. And, the solution we ultimately chose, and which has become the eValid architecture, has met that goal in every regard.

So, the REAL reason that eValid does not use JavaScript to drive the test is that it is (a) too messy, (b) has too high an overhead, (c) imposes too large a footprint for the test engine, and (d) interfers with the normal operation of a web page. With the growing importance of AJAX this choice is more than justified -- eValid's architecture says "hands off" to the co-executing JavaScript passages that implement AJAX -- and this means that eValid tests are far more accurate and far more reliable than would have been any of the other architectures which we studied, and discarded as wanting.

__________________
eValid Tech Support

Friday, July 22, 2011

Do you have a standard pricing structure for building an eValid test? What are the limits on size and complexity?

An eValid user wrote:

Do you have a standard pricing structure for building an eValid test? What are the limits on size and complexity?
Yes, in addition to providing licenses to the eValid product so you can build your own tests, we also provide services that generate tests according to you own specification.

We have (as you might expect) a great deal of experience in building functional tests using eValid, and we generally are able to deliver test scripts to you that are 100% self-synchronizing and also 100% load-test safe.

Self-synchronizing means that you can make any adjustment to the Wait Time Multiplier you like -- including eliminating all delays, a Wait Time Multiplier of zero -- and the test will still run successfully. This is done with eValid structural commands and with eValid DOM-synchronization commands.

Load-test safe means that the tests can be run in multiple eValid instances on the same machine, without interfering with each other. That way, such a test can run 100's of browser users on one regular machine -- and 1,000's of browser users on a beefy, multi-user computer (like the ones we deploy when doing cloud-based loading work for customers).

We are so confident that we can complete such test script development projects on a tight budget -- and who isn't interested in having tight control of costs these days? -- that we offer such test creation mini-projects for a typical fixed-price fee $1,495 per script. And we take all of the engineering risks if it takes us longer than our nominal time budget. We have a 100% deliver success ratio on such mini-projects.

There are size constraints and limits of course, but for this very modest price we generally deliver a test script that has all of the above properties but in addition typically has coverage for up to 200 test steps (test plan imperatives like "click this..." or "select that..."), and can play back as long as about 5 minutes with no wait times.

You might think that 5 minutes is not a long time nor a very comlicated script, but when eValid scripts run with zero delay times, we find that the resulting test script, which may be upwards of 400 lines or more, will cover a very great deal of "functional ground."

All we need to get going on a mini-project like this is a step-by-step outline of your test, and appropriate access credentials for your application. If you don't want to write your test plan down, we can even include doing that step with a phone interview.

Thursday, July 21, 2011

Driving a complex AJAX APP

An eValid user wrote:

Driving a complex AJAX APP...Tell Me How

This is a good question and it raises an interesting point about how modern web browser enabled applications that involve large amounts of AJAX actually operate.

If you recall, when AJAX is used there are JavaScript programs that run in the JavaScript engine (inside the browser) that do all kinds of things, but mainly control communication and data transfers between the browser and the server, based (in part) of user inputs. Think in terms of what you see on your screen when you type strings into a search engine that has implemented some kind of "autocomplete" feature. In that case there is a LOT of back-and-forth to/from the server.

The amount of processing time for that used to be very small, almost "invisible" to you as a tester in the scale of time that relates to your test cases.

But, as the total volume of JavaScript has grown the total time that running those (admittedly, wonderful programs) also grows. Accordingly, the amount of time it takes for the browser to settle down and reliably accept an input from the test engine grows.

That's where the problem arises.

eValid's structural commands are done separately from that JavaScript (this is an important architectural feature of eValid's implementation -- the non-interference with JavaScript). Even so, we have seen cases in which the eValid structural commands are "too fast" for the browser...we have heard of cases when, due to rapid-fire issuance of structural commands that update the DOM, the browser actually aborts execution!

So, what to do?

What we recommend is to insert a Delay 10 command, or perhaps a Delay 100 command after major structural command sequences to give the browser time to stabilize after the changes. For some cases, we have even had to use Delay 1000 -- that is, delay an entire second -- to prevent failure.

Or, duh, you could get a faster client computer (but you didn't want to hear that, did you!).

_____________________
eValid Tech Support

Monday, July 18, 2011

Do you have any recommended maximum length of a test?

An eValid user wrote:

Do you have any recommended maximum length of a test?

Another way to ask this might be, beyond how many test steps is the state of the browser no longer going to be repeatable.

There's no imposed limit on the length of time an eValid script can play back, and we have seen some scripts that take 15+ minutes the execute.

One script we worked with recently had about 250 separate steps (about 500 commands overall) and took about 10 minutes to play. That's quite long!

That is quite long, and the elapsed playback time, even when accellerated by reducing waits to the minimum through synchronization, imposes delay when you are trying to modify or debug a script.

Obviously there is no general rule, but we would argue that a playback time above 5 minutes (300 seconds) is going to run into either state-loss or tester-patience-loss issues before long.

____________________
eValid Tech Support

Saturday, July 16, 2011

What happens to an evalid site analysis run if my website changes in the middle of the run?

An eValid user wrote:

What happens to an evalid site analysis run if my website changes in the middle of the run?

Here is the way the site analysis engine works.

It starts (at the page you specify) and makes a list of all of the links on that page and then, one by one, it attempts to visit every page on that list.

On each new page, it ADDs to the "work list" by enumerating all of the links on that page.

No page is visited a second time, and the scan stops when the "work list" is empty.

Now, if one of the pages changes during the scan, then the NEW information will be used as the basis for adding items to the "work list". If the new page has left out a link that was present at the time the scan began, then that page will not land in the "work list" and will never be visited.

So, bottom line, if the site changes there is a risk that some pages that were present at the time the scan started will not be visited, and there is a corresponding risk that some pages that were not present at the time the scan started will be visited.

Practically speaking, if you are running a scan regularly, ultimately all of the pages' actual [stable] content will be visited, so this effect may not be an issue for you. But a one-off scan may be in error.

It's best, of course, to run scans on stable sites that are not undergoing maintenance and/or upgrade and/or change.

_________________
eValid Tech Support

Tuesday, July 12, 2011

Testing With DOM Interactions -- Guide to Examples (Part 2)

This article presents eValid example scripts that illustrate use of the index/motion (structural testing) DOM manipulation commands. These scripts were developed using the available DOM Technology Resources to accomplish the results demonstrated in each "snippet".

In most cases the index/motion (structural testing) scripts are extremely robust in that these test script passages do not depend on specific page or application properties, but only on objects and effects that can change location and visual detail.

Tests built using these techniques survive the effect of dynamic page changes, including inconsequential changes that don't affect the underlying functionality. They also address basic test playback synchronization issues and can still provide fine-detail client-side performance data extraction suitable for large-scale loading experiments.

Link Short Example Explanation
Third Item in Dropdown List Find the third item in a dropdown list and click on it.
Nth Item in a Select Box Choose the Nth entry in a select box and click on it.
Select Two Elements in a CheckBox Select two elements of a checkbox.
Find and Follow a Specified Link Find a link based on knowing something about it and then follow it.
Find A Dynamic Tag And Click It Locate a dynamic element tag and then click on it.
Text Entry Into a JavaScript Editor Field Find a particular input field that is handled by JavaScript and type specific text into it.
Validate That One Item Matches Another Extract two values from different spots on a page and compare the extracted values.
Using Regular Expressions Using the IndexFindElementEX command to find using multiple "name=value" pairs.

Monday, July 11, 2011

Testing With DOM Interactions -- Guide to Examples (Part 1)

This article presents eValid example scripts that illustrate use of the index/motion (structural testing) DOM manipulation commands. These scripts were developed using the available DOM Technology Resources to accomplish the results demonstrated in each "snippet".

In most cases the index/motion (structural testing) scripts are extremely robust in that these test script passages do not depend on specific page or application properties, but only on objects and effects that can change location and visual detail.

Tests built using these techniques survive the effect of dynamic page changes, including inconsequential changes that don't affect the underlying functionality. They also address basic test playback synchronization issues and can still provide fine-detail client-side performance data extraction suitable for large-scale loading experiments.

Link Short Example Explanation
Navigation to URL Shows how to navigate to a particular URL.
HTML Push Button on a FORM Locate and click on a push button on a FORM.
Radio Button On A FORM Locate and push a radio button on a FORM.
Check Box On A FORMLocate and check a particular box on a FORM.
Single Form Text Input FieldFind a particular text field in a FORM and type something into it.
Multiple Form Text Input Fields Type in multiple files in a FORM.
First Item in Dropdown List Click on the first item in a dropdown list.

Friday, July 8, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Thursday, July 7, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Wednesday, July 6, 2011

Can eValid create a non-visible-text validation from the GUI?

An eValid user wrote:
Can eValid create a non-visible-text validation from the GUI?

Yes, there is a programmed-from-the-GUI optional sequence that will automatically construct a command to validate a selected object property. This command works from the PageMap and allows you to validate ANY property that is present in ANY object anywhere on the page.

A word of caution: this command, and the GUI-sequence that leads to it. is somewhat more technical that the vast majority of eValid validations. We put it in there because it was appropriate for completeness -- to have a least one command that digs into the DOM and constructs something in your recorded script for you.

As you can imagine, there are many ways that the GUI sequences can lead you to construction of a script -- "from the GUI" and thereby somewhat automated -- and you might ask, "Why doesn't eValid have a richer set of such GUI sequences?"

The answer lies in this observation: No matter how complex you create the from-the-GUI operations, there will always be some case that you haven't thought of, and then you're stuck. Instead, with eValid our idea was to provide the mimimum amount of GUI-based help needed, consistent with keeping the GUI simple and intuitive. (We have seen some other offerings that boggle the mind with the complexity of the GUI sequences involved!)

So, instead -- to give the user the power needed for the "outside the GUI" case -- we created a simple set of "structural testing commands" that are easy to learn, few in number, and ultimaly can do anything and everything that you need. Here is a link to the manual page for that:

Structural Testing Commands

The set of primitive operations you have with these commands -- get, set, put, find, move, etc. -- are able to handle ANY situation you can imagine.

In effect, rather than try to guess what you might need (and know that there will always be a case in which it "won't work"), we have provided a simple programming tool -- actually a kind of "program the browser" tool -- that is FAR more efficient in terms of your time and effort than an elaborate and ultimately ineffective GUI sequence.

We hope you agree with our simple is better approach to eValid design and operation.

_____________
eValid Support

Monday, June 20, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Wednesday, June 15, 2011

Selected User Forum Posts

Thursday, June 2, 2011

An Interesting Scalability Result

As our BLOG readers may know, we have been working recently with developing better understanding of the scalability of the eValid solution. "Scalability," simply put, describes the degree to which the solution can be ramped up to provide for large numbers of Browser Users (BUs) to drive load into a server stack.

Using a single user on a modest Windows machine, we regularly achieve 100 BUs in parallel. Using multiple users and a fairly large cloud-based machine image we have hit 10,000 BUs.

But a different way of doing things, which involves having one parent eValid BU launch multiple sub-windows, seems to be capable of besting even these very good scalability numbers. The advantage of using sub-windows is that each one takes far less memory footprint than a complete browser instance. But a disadvantage is that all of the sub-windows can't be active at the same time; so this solution only works when the tests you're running have a low-enough duty cycle (percentage of time active) so that cumulatively they don't exceed 100% of the main browser's time-line.

Within those constraints, however, this approach does appear to work quite well. Here is a screen shot of a typical Windows desktop with a total of 50 eValid browsers, each running 10 sub-windows, for a total of 500 + 50 separate activities: 550 Browser Screen Desktop Image. (Look closely at the bottom of the images and you'll see the 550 browser + window count.)

Isn't one picture worth at least 550 words?

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Wednesday, June 1, 2011

Update on Results From A Small Experiment

Previous BLOG items described a small experiment aimed at demonstrating how eValid can test the performance delivered to a particular smartphone. You can read about that experiment in detail in our Mobile Agent Loading Experiment #1 writeup.


To see if there had been any changes as the result of our experiment we reran the same test on the same application approximately 3 weeks after the first run. We're pleased report that improvements to that application's server stack has apparently resulted in a a 50% improvement in performance and capacity. You can see the relative improvement in the two charts shown in this Comparative Improvement of Performance.

Tuesday, May 31, 2011

How eValid Scales

There has been a lot of discussion in various forums -- including in our own eValid User Forum -- about how to scale tests up from singleton runs to large load tests. The goal seems in all cases to be to preserve the precision and accuracy of an eValid playback but still run enough evalid's in parallel to yield a realistic load.


The natural questions are, when you increase the number of eValid instances, what resources are used up first and what limits are hit along the way. Here are some of the main points that contribute to this discussion, in order of where they form limits:



  1. Initial RAM Usage
    When eValid finishes loading -- even when the initial page is about:blank the footprint is about 12 MBytes. That means that an initial load of 100 BUs will consume 1.2 GBytes of RAM. Which is certainly feasible with a 3 GByte machine.

  2. RAM Usage Growth
    As each browser continues working its footprint grows because the browser stores in its workspace all of the JavaScript files and a lot of other material that it picks up along the way. The longer the test the greater the growth. We have noted footprints for very long tests as much as 100+ MBytes per BU. (This behavior argues for smaller tests and/or for more-often restart of the BUs in your load test run.)

  3. Cache Space
    As your tests run on and on, with more and more pages, there are more pages stored in the cache. In LoadTest runs, though, this doesn't matter as much because you typically don't use cache at all. (Periodic DeleteCache instructions are a good idea.)

  4. Virtual Memory Size
    There are special instructions that come with eValid to make adjustments to the Virtual Memory size, etc. This is not a fixed number, but when you do the "machine adjustments" on most Windows systems you ask Windows to use the best size of the paging files to the maximum available.

  5. GDI Object Count
    You can't control the GDI object count, but we know (from our conversations with Microsoft technical support) that you may run past the built-in Windows limit of between 256 and 65,536 GDI objects per user.

  6. Input/Output [I/O] Bandwidth
    This depends a lot on the web application you are testing. Some are very economical of I/O capacity, and others are very hungry. The only way to make sure this is not a limit is to look at the PerfMon data in the Task Manage to monitor the networking activity.

There are some other tricks to maximize the number of BUs per run -- tricks that we use to get over 10,000 BUs off one machine. That'll be a subject for a subsequent BLOG post.

Wednesday, May 25, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Wednesday, May 18, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Friday, May 13, 2011

Results From A Small Experiment

Previous test reports pointed out how eValid pretends to be a particular smartphone, looks at how several different websites behaved in delivering material to that smartphone client browser, and studies the differences in the responses by the Amazon website to different smartphones.

Next, we tried a simple experiment with a smartphone application that uses AJAX. We wanted to see how the use of AJAX in an application affects smartphone behavior. For our test, we chose a beta-status application of a regional transportation system that offered real-time schedule information delivery to smartphones.

The experiment involved a simple test: On the mobile application, eValid pretending to be an IPhone 4 browser, request schedule data, synchronize final delivery, and measure the amount of time that delivery took. We found from static tests of that script that the data download on a per-test basis was about 330 KBytes.

The LoadTest script was set to start Browser Users (BUs) off at a constant rate until a total of 100 was reached. The repetition count for each BU was set high enough so that at the end of the test all 100 BUs were repeating the test -- all independently. The timing tests were very interesting. The LoadTest Data Report suggests that the response time for this application degrades by a factor of about 5:1 when the number of simultaneous requests grows above 75.

(Please note that this experiment was done to illustrate eValid capability; we're not making any recommendations to the agency actually responsible for the application implementation.)

You can read about our short experiment in detail at this page: Mobile Agent Test Page -- Loading Experiment #1.

Thursday, May 12, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Tuesday, May 10, 2011

More about Mobile Phone Response

A previous item pointed out how eValid could pretend to be a particular smartphone, and looked at how several different websites behaved in delivering material to that smartphone client browser.

A companion experiment that we did tried out five different smartphones on the Amazon website. (We chose Amazon because it seemed to be one that had very good smartphone options.) The results are shown in Mobile Agent Test Page -- Multiple Phones.

What is interesting about these data points is how much the size of the download varies from phone to phone: a ratio of 6.15+ from largest to smallest download volume.

If you are concerned with optimization of an application to a range of different smartphones this comparison method will be of great interest.

Monday, May 9, 2011

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

Thursday, May 5, 2011

eValid Applied To Mobile Devices

In response to some user's questions, we recently did some experimentation with evalid imitating different mobile devices. The question was, can eValid show the differences between server response on a variety of mobile devices?

We used the SetUserAgent command to set eValid to provide authentication as if from a different user agent. We chose to use the user agent string for an iPhone -- not for any particular reason and certainly not an endorsement -- just to see what would happen when imitating that popular device.

Next, we chose five popular sites to run a simple test on: Amazon, Meebo, Samsung, Sony, and Verizon. (Again, no endorsement implied).

The outcome of our experiment is shown in this simple summary: Mobile Agent Test Page

As you can see from this page, in most cases the servers responded differently -- as you would expect -- when told to feed data to a mobile device. The side-by-side comparisons of the single response page show how different things are. For three of the five applications the size of the delivered data was < 20% of the full-size file.

Note that the page rendering appeared to be quite normal (except for total screen area). We didn't note any essential differences.

But not in every case. The Sony and Verizon mobile downloads are around 90% of the full-size download. We checked the actual content and found for these it appears there were some Flash items and also some movie items in what is sent to the mobile device.

One obvious implication is that this technique may be very valuable in using eValid to drive substantial loads into a server that is serving mobile applications. eValid's inherent scalability is what does the trick.

Sunday, April 24, 2011

Webinar: The eValid Real Client Loading Solution

Functional Testing of AJAX/Web 2.0 Applications
Server Loading Scenario Development
Server Load Testing with eValid's Real "Browser Users"

Wednesday, 4 May 2011
2:00 PM Eastern Time / 11:00 AM Pacific Time


This webinar will focus on testing AJAX/Web 2.0 applications quickly and realistically. Whether you are focused on desktops, handhelds, or mobile applications, the number of different users makes predicting demand almost impossible. An incorrectly balanced server stack could create delivery contention and delays, and lead to customer click-away -- customers you can't afford to lose.

The eValid client-side testing approach is the original browser based test solution. eValid is a self-contained one-stop real client based solution for all of the most important quality and performance issues of AJAX/Web 2.0 applications. The eValid consolidated approach becomes a genuine force multiplier in your web application testing and loading efforts:

• Achieve effective functional testing of your AJAX/Web 2.0 applications.
• Create realistic loading scenarios with multiple functional behavio
• Impose very large real client application loads on your servers.

The eValid suite meets these requirements in a unified, easy-to-use, and easy-to-understand solution. eValid doesn't require programming skill, doesn't need special plugins or adapters. eValid runs quickly and efficiently. You'll achieve web quality solutions in days or weeks rather than weeks or months.

In this webinar you'll learn these important lessons:

  • AJAX/Web 2.0 Functional Testing: How to record perfectly reliable web application tests, out-of-the-box, including complex AJAX/Web 2.0 playback synchronization issues.

  • Handling Mobile Devices: How to use eValid features to model handheld and mobile devices.

  • Creating LoadTest Scenarios: How to organize multiple eValid functional tests into LoadTest scenarios that model your actual user's activity mix.

  • Running LoadTests: How to launch eValid load testing scenarios that can run 100's, 1,000's or even 10,000's of browser users (BUs).

  • Realistic Data: How to extract detailed performance data from each BU's activity.


  • Register

    Wednesday, April 20, 2011

    Selected User Forum Posts

    Monday, April 11, 2011

    Selected User Forum Posts

    Wednesday, April 6, 2011

    Selected User Forum Posts

    Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

    Here is an additional selection of some of the posts that we think would be of general interest.

    Monday, April 4, 2011

    Selected User Forum Posts

    Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

    Here is an additional selection of some of the posts that we think would be of general interest.

    Friday, March 25, 2011

    Webinar: All About AJAX Testing: Functional + Monitor + Load

    Functional Testing of AJAX Applications
    Provisioning AJAX Scripts for Monitoring
    AJAX Server Loading and Capacity Checking

    Wednesday, 30 March 2011
    2:00 PM Eastern Time / 11:00 AM Pacific Time

    This consolidated approach demonstrates how eValid becomes a genuine force multiplier in your AJAX web application testing, monitoring, and loading efforts. eValid is a self-contained one-stop solution for all three of the most important quality and performance issues of 2011 for AJAX web applications:

    • Achieving effective functional testing of an AJAX application.
    • Confirming continual correct AJAX application operation (monitoring).
    • Estimating required AJAX application server capacity needs.

    The eValid suite meets all of these requirements in a single easy-to-use and easy-to-understand solution. eValid doesn't require programming skill, doesn't need special plugins or adaptors. eValid runs quickly and efficiently, and you'll arrive at a web quality solution days or weeks earlier.

    In this webinar you'll learn these important lessons:
    • AJAX Functional Testing: How to record perfectly reliable AJAX tests, out-of-the-box, including complex AJAX playback synchronization issues.
    • Readying AJAX Tests for Monitoring: How to provision an eValid script for use in client-side monitoring, including interfacing the results into popular reporting engines.
    • Creating LoadTest Scenarios: How to insert functional tests into a server loading scenario that can run 100,s, 1,000's or even 10,000's of browser users (BUs).
    • Realistic Data: How to extract detailed performance data from each BU's activity.
    Register

    Friday, March 11, 2011

    Selected User Forum Posts

    Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

    Here is an additional selection of some of the posts that we think would be of general interest.