Concatenating cells with a delimiter

Earlier today, I was looking for an excel function somewhat similar to ruby’s join function for arrays. Given a range of cells and a character to use as a delimiter, I wanted the function’s output to be a concatenation of the cell values alternating with the delimiter. I googled and was easily able to find a solution that suited my needs well enough.

Usage:
=MConcate(B6:AX6,"|") – Concatenates B6 to AX6 with “|” as delimiter

VBA code:

Public Function MConcate(Data As Variant, delimiter As Variant) As Variant

    Dim vntBuild As Variant
    Dim vntItem As Variant

    For Each vntItem In Data
        vntBuild = vntBuild & vntItem & delimiter
    Next
    If Len(vntBuild) > 0 Then
        MConcate = Left(vntBuild, Len(vntBuild) - Len(delimiter))
    End If

End Function

Reference: http://www.ozgrid.com/forum/showthread.php?t=86223

A first-timer at WTANZ

I’ve been hearing about Weekend Testing for quite some time now. From what I’ve heard, the WT sessions usually last for two hours. Participants are given their mission and they conduct their testing on the first hour, after which they have a discussion for the second hour covering stuff like bugs found and lessons learned. WT initially started out in India, and has quickly gotten the attention of testers from all over the globe. I’ve heard of Cem Kaner and James Bach joining in on these sessions. Soon enough, a European chapter of WT was formed. And just recently, the ANZ chapter was formed and they had their first session this Sunday.

I didn’t exactly had my mind set on joining today’s session. My Sundays are usually reserved for visiting my parents’ home and for errands. But since I didn’t go home to my folks’ place today, I had the afternoon free and so I gave it a shot.

For today’s session, we tried out a mortgage calculator. The primary mission was to verify the functional correctness of the calculator. Other missions were to check on usability and browser compatibility. What follows is a hodgepodge of some of the stuff that was tried, bugs found and tools.

• (tool) http://bugrepository.com for logging bugs
• (tool) I used an excel spreadsheet to plot my inputs, expected and actual outputs
• (tool) Some compared the outputs to the outputs of other online mortgage calculators
• (bug) Interesting finds were the lack of data validation e.g., negative loan amounts, negative interest rates, no maximum limit for the number of digits, etc.
• (bug) Something I wasn’t able to explore further was a weird behavior wherein my input for the interest field “10000000000000000000000000″ became “10,000,000,000,000,000,905,969,664.00″
• (bug) I triggered a division by zero error by setting the start and end dates as the same date
• (usability / accessibility) Lack of color contrast of the calculate button
• (bug) $100, 10%, 10999 years as input gives “$inf” for the Total interest you will pay in today’s dollars
• (bug) Loan period lasts for 10998 years by entering -999 and 9999 in the year fields
• (tool) http://browsershots.org for multiple browser testing
• (tool) I tried out http://ipadpeek.com which distracted me a bit from the mission :p
• (usability) The “nominal dollars” and “today’s dollars” links didn’t seem to do anything. I had a tendency on clicking on the “today’s dollars” link instead of the provided check box.
• (usability) This is out of scope but I think the links at the side look too much like plain text.
• (tool) Suggested tool: VirtualBox.org for testing multiple browsers
• (tool) Suggested tool: AllPairs tool at James Bach’s website for combinations to test
• (oracle) Some used personal data — “data that is very familiar to you so errors would be easily spotted.”
• (tool) Suggested tools: HTML Validators — http://validator.w3.org/ or HttpLiveHeaders plug-in for Firefox
• (tool) Suggested tool: Windows Live Writer, a note-taking tool used by Ram who was able to post a blog write-up within the WT session
• (bug in test tool) When logging an issue in bugrepository, the only option for the mandatory Category field combo box is “(select)”.

A testing exercise: ParkCalc

Early the other day, I noticed some of the tweets of testers I followed had a #parkcalc hashtag. At first, I couldn’t exactly get what they were saying, but I guessed that they must have been testing something collaboratively. At the time, I couldn’t stay online long enough to find out more about parkcalc. Luckily, when I got home that evening, I found a blog post on the topic. The author of the post suggested to click the link to the parking calculator before reading any further, and so I did.

The first thing I tried to do was to click the Calculate button without changing any of the default values. A page with error messages (e.g., Warning: mktime() expects parameter 4 to be long, string given in /home/grrorg5/public_html/Includes/Calculator.inc on line 72) got displayed before the page refreshed to show a more user-friendly error message.

The next thing I noticed was the layout seemed a bit off. I thought maybe it was just a Chrome thing. I tried loading the page and the pop-up calendar in Firefox, and I was able to confirm my hunch.

Next thing I did was to play around with the inputs for the entry date and time, and exit date and time. I tried the usual stuff — entering no values, entering invalid values, non-existent values (e.g., 13 for month, non-existent dates like Feb 29 on a non-leap year), cases wherein exit date/time came before entry date/time, etc. Most interesting finds I think were triggering the “Not Acceptable” page and managing to get an estimated cost of $3,946,162,582,627,248.00 for 1.64423440943E+14 Days, 15 Hours, 21.6 Minutes of “Short-Term Parking”.

I then checked out what the rest of the blog had to say as well as the recent tweets tagged with #parkcalc. And apparently, I’m not the only one who enjoyed tinkering with parkcalc. Finding the bugs on my own is in itself a good exercise, but more than that, it was pretty interesting to read about how other testers attacked the app and to read about their finds even if they make mine look lame. For instance, someone used exponential notation for the inputs, someone managed to trigger a cost value of $5,124,095,576,028,720.00, and my fave so far is this link that I got from one of the tweets: http://is.gd/bknIb

—-

[Edit] Additional links:

• EWT: Please park my bug – This has a chat transcript of their weekend testing session with ParkCalc.
• ParkCalc — Review and Discussion – Matt Heusser’s wrap-up for the testing exercise

Inside-out risk analysis… by chance

A couple or so days ago, I came across a tweet by @dailytestingtip.

Risk is a problem that might happen. James Bach http://ow.ly/1s4j1 #softwaretesting

The link lead to a pdf file on Heuristic Risk-Based Testing by James Bach. One of the things discussed in the paper was the two approaches to analysis.

• Inside-Out – wherein you chop things up to smaller components, look into each one of them and ask What can go wrong here?
• Outside-In – wherein you’ve got a list of known or possible risks, look at each one of them and ask Does and will this risk apply?

As I read the description for the first approach, I recognized it as the approach I had taken for planning for my testing of a particular function in a recent project. I find it cool when what I’m doing turns out to have some official/legit-sounding name. Hey, I wasn’t just planning… I was doing inside-out risk analysis!

What I basically did was I diagrammed my understanding of the functional specs in an excel file capturing actions that the user could do (e.g., Click button A, Click button B) and the corresponding program behavior for the action. For the program behavior, I tried breaking it down into the steps that would need to be performed (e.g., for Click button A, the program will have to do Actions 1, 2 and 3). Then for each step, I tried to think of what if’s to ask which in a way was asking what can go wrong for the particular step.

My resulting informal test plan looked like something like the table depicted below. Since I used excel, I used another column to track whether I’ve gone through the cases or if there were some problems encountered.

One of the lessons I learned (as far as inside-out risk analysis is concerned) from reading the article is that the approach I took could have been done together with the developer. Two heads would have been better than one. Another thing is the use of more elaborate guide questions compared to my very generic “think of what if’s or things that could go wrong”. James Bach gave three questions we can ask for each part of the product:

• Vulnerabilities: What weaknesses or possible failures are there in this component? [my take: what weaknesses are there at this point?]
• Threats: What inputs or situations could there be that might exploit a vulnerability and trigger a failure in this component? [my take: how could we attack these weaknesses to trigger the things that could go wrong?]
• Victims: Who or what would be impacted by potential failures and how bad would that be? [my take: what happens when things have gone wrong, consider error handling, recoverability]