My take on future of testing has always been – in fact I think it is the current state now, that:

1. Testing is not just functional GUI testing
2. Desktop apps are a thing of past
3. With the advent of Web 2, SOA, Cloud, etc. it is getting more and more technical
4. Performance
5. Security
6. Usability
7. Integration
8. Automation
9. …are the areas where the testers of today need to develop skills in

I have interacted with all kinds of testers, testers from different schools, contexts, methodologies, level of experiences, and most of them specialise in functional testing. But if you would really like to be future-proof – then I think Technical Testing is the way forward.

To add fuel to the topic Goranka Bjedov did a great presentation recently at a conference in Wellington: STANZ

In the presentation she shares her past experiences in software testing, especially last couple of years of her life when she comes across some hard reality of life/software quality. And she ends her presentation with the following summary:

1. We can reduce dev time (and costs) by writing productivity tests
2. We can bring in quality by adding smart system tests in right places
3. Think performance, scalability
4. Think usability
5. We can reduce number of machines needed in dat centers
6. We must start calculating and communicating the value of our work (dollar amounts)
7. We must stop being the cost center

I was testing the ‘churn’ sample from the book. The actual issue was I had one ruby file which contained the code base called ‘churn.rb’ and then there was another file to unit-test the code called ‘churn-tests.rb’. Both these files were under a custom folder under ‘D:\blah\blah\code\’

‘Churn-tests.rb’ includes ‘churn.rb’ file to be able to test it. The command used to include is: “require ‘churn’”.
Initially in previous versions, since both files were in the same folder, Ruby would simply load the code file – ‘churn’. But as of Ruby v1.9.2, as part of the default installation, the code directory: “.” has been removed from the $LOAD_PATH.

As a result my code (unit-test) just wouldn’t work. I tried various options but no luck.

Finally, I came across few ways of fixing it, and those are:

1 – Provide the relative path:

require ‘./churn’

2 – Get current file’s path and reuse it:

require File.expand_path(File.join(File.dirname(__FILE__), ‘filename‘))

3 – Same as above but bit more readable:

require Pathname.new(__FILE__).dirname + ‘filename’

4 – Spell out the complete path, but obviously that’s not ideal

Hope that comes handy to someone.

Happy Coding… oops… Testing!

The original list is not available any more. Dazzlepod has though made the list available without the passwords so people could check if any of their email addresses have been compromised. The list is available here: http://dazzlepod.com/lulzsec/?page=1

Requirement:
There are almost 62,000 email addresses and Dazzlepod has divided the list in to 120 pages.
I would like to go through the list and check if any of mine or my family member’s email has been compromised. Going through 120 pages and searching for almost 10 aliases on each page is a daunting task.

Solution:
So I went ahead and automated the process, that is scripted a spider (kind of). The spider goes though all 120 pages and reports if any of the aliases I know of have been compromised.

This script is created using iMacros plug-in for Firefox.

Instructions:

• Download and install Firefox (if you don’t have it already).
• Download and install iMacros for Firefox
• Click here to download my iMacros script and copy it to iMacros folder. It is mostly (C:\Users\<username>\Documents\iMacros\Macros) in Windows-7 environment.
• Open the script in editor and update the values in var mynames = new Array(“alias1“,”alias2“) with your aliases. Do not include domain name and suffix.
• Now run the script and you should get the response in 5-10 minutes. Depending on number of aliases and website speed.

If your browser blocks the download of a ‘javascript’ file then here is the script for your reference:


var i, j, retcode;
var report;
var ret;
var macro;
var jsLF = "\n";
var iPages = 120;
/*NOTE: Change the list in next line to include all the email aliases you'd like to check.
E.g.: ("alias1","alias2","alias3","alias4")
*/
var mynames = new Array("alias1","alias2")

alert ( report );


UPDATE:
1 - There is a longer list now on Dazzlepod with almost 260,000 emails: http://dazzlepod.com/lulzsec/final/
2 - They now also have a search box, so that makes this script redundant

Image Source

Matthew in his post on software testing – How do we see ourselves? has reflected on a new tester requesting for some guidance around learning QuickTest Pro.

Hi
I am new to software testing and want help with learning QTP. I am based in (city) and looking for mentor.

Thanks
(name)

Now, I’m not trying to insult anyone. But imagine, for a moment, this appeared on a Carpentry forum:

Hi
I am new to carpentry and want help with learning The Hammer. I am based in Detroit and looking for mentor.

Thanks
Bob The Builder

I would like to make two comments here:

1 – I think he has got the analogy wrong here. If we are comparing testers to carpenters, then the comparison should be as follows:
Tester – to – Carpenter
Tester’s ability of critical thinking and finding bugs – to – Carpenter’s ability of being creative and fixing things in a clean and efficient way
Basic tools: PC, MS-Word, JIRA, other defect logging tools – to – Basic tools: Hammer, Saw, Screwdriver, etc
Specialised tools: QTP, Jmeter – to – Specialised tools: Miter tool, or other such power tools

2 – Therefore, a relatively new tester cannot be expected to always know specialised tools; specially automation tools like QTP. I don’t know the tester in question here, but if he is already into tester (which he seems to be) and is keen to learn automation, then where else is he expected to go for help other than approach some experienced testers around?