PabloTesterBar

In this blog post/tutorial I will describe how to write a simple automated test for an android device and get it running on your machine. I will start with a quick crash course explaining the android emulator, how to get it up and running and how to install a native application (in this example instagram). Once the emulator is up and running, we will move onto 'calabash-android', how to install, configure, write and run a simple login test. Installing and running the Android emulator First thing is we need to download and extract the latest Android SDK, get it from here and unzip it into your area of choice, I would recommend putting it in your $HOME directory for now. After you have downloaded and unzipped the SDK, you will need to create an AVD (Android Virtual Device). Do this by changing into the tools directory in the SDK root and running the android create command: $ cd android-sdk-linux/tools $ ./android create avd -n android4.0 -t 20 -c 256M If you want an ex

I have been working with a number of client web applications, and it surprised me how many of them are/have been open to XSS to the point I'm actually worried. My guess is that testers don't really understand what XSS is, how to exploit it and what risk it poses to the business, so I will try and give you a working example using the ft.com. They are not a client of mine but I did find their search was open to the XSS exploit. Don't worry I have contacted and reported the issue to them, so by the time you read this the site will be patched and immune to any sort of XSS bug. Lets get started: 1. First lets find an input into the webserver, ft.com has a search form field we may be able to exploit. 2. We want to enter some malicious text into the search field, for example script tags to see if they break the page. First lets do a normal search and analyse how the page is returned, type 'Lenovo' into the search field and click search, after a short wait the re

Testers should break the rules.... I come across a lot of Developer In Test roles these days, its a new trend that a large number of companies are adopting as they fully embrace Agile and BDD practices, or at least try. I think its good and productive to embrace Agile, its something that works and as a tester far better than waterfall era of giving everything to test in a short space of time at the end of a project.  I am concerned however in the trend of the DIT role and what its doing to the test horizon, what worries me is this now huge lean on automation, and companies losing sight of what testing is really about, now it seems automating your Cucumber feature files are more important than actually finding bugs, and in some companies I have come across, leaving functional testing to the BA's whilst your DIT's just write automation code or even worse, making the developers that actually wrote the code now functionally test it (recipe of an  apocalyptic ELE for you

SQLite Manager and testing data files. I recently was given a task to test some data files, created by one system, processed by another then sent back to the system of origin in a transformed state (data munged with a few extra columns and data, standard ETL stuff). In my experience, when data leaves its system of origin it pretty much goes into the unknown, it passes a boundary into a foreign system, and sometimes a foreign culture. It may come from a company culture where testing is of the utmost importance and enter into a culture where testing in itself is a foreign concept, needless to say it will not get treated in the manner in which it is accustom too. We must be careful of making too many assumptions, a 'csv' file that contains data means different things to different people and more importantly different systems.For example files created on a Windows server may not be encoded correctly for a UNIX machine, some developers insist that csv values are contained in

Training is the key.... I consider myself a man of habit, somewhat stubborn and stuck in my ways especially when I was younger. In my first few jobs mainly working in data warehouses, I refused to work with graphical SQL clients, it was all sqlplus, db2, isql for example, and up until a few years ago I would not go near an IDE, I was tied In holy matrimony to vim. I have chilled out a lot since then and have become more open minded, and would not develop anything without my trusty intelliJ IDE, in addition I wish I had embraced these more modern tools sooner in my career, but why didn’t I?. I always felt there was something pure about working with the command line, seeing lines of green output on a black screen always made me feel more technical, and indeed it made me more technical. I had to think about ORACLE environment variables, about where the database lived and what files I had to configure to connect to it, I forced myself to do it the hard way which in turn helpe