• 25 Apr 2012

    Test Studio for iOS

    iphone and ipad appsYesterday afternoon Telerik held a webinar for one of their products soon to hit the market. Test Studio for iOS is an automation tool that allows you to actually create automated tests for iOS applications on the device itself using manual touch input. There is a definite gap in the market for such a product given the growth in the mobile applications market (especially that of iPhone). In my experience there aren’t many companies out there that offer a similar solution to this and certainly not one that is not as easy to deploy as this.

    Some of the features that really stood out to me were:

    1. The tests are not co-ordinate based – because all the steps are based on Element Locators this means that the same tests can be used to test the application on iPhone and iPad. The use of Element Locators also means that ongoing maintenance to keep these tests working is kept to a minimum.
    2. You can add to an existing recording – the fact that you can just add on steps to the end of a test instead of having to re-record the whole thing from scratch is going to be a great time saver.
    3. The Ad-hoc Testing looks great – if during your exploratory testing you stumble across a bug there is a really nice feedback system that lets you take a screenshot, highlight the affected area, add feedback/bug details and then export on mass via email. Given time I would love to see this with the ability to publish straight to TFS as a bug report.
    4. Can record swipe and pinch – These features are unique to touch screen devices and as a result aren’t usually catered for in such tools. It’s refreshing to see this included.
    5. Disconnected – You can continue to author and edit your tests even without an active internet connection.

    All in all this looks to be shaping up very nicely and should be a handy tool for anyone who finds themselves testing mobile applications for iOS. I look forward to getting my hands on the beta and giving this a go.

    Head on over to the Telerik website now and have a play with the beta.

    Photo credit Lukewhitt

    Read More

  • 26 Mar 2012

    Simple Fix != Simple Retesting

    Spend a couple of days around a developer while they are working and I’m sure the phrase “That will just be a quick fix” will come out (or words to that effect).

    As the project starts developers will be putting in considerable hours to implement functionality, typically the amount of time allocated for testing will not be close to this figure (at this point). However later on in the project comes a point where people are likely to ask for a ‘Small Fix’. This could be something as simple as how the password validation works. I’m sure developers love these because after 5/10 minutes work they can tick something off their to-do list (which can usually be quite extensive).

    However as a Tester this might mean having to go through multiple test cases again, each with various parameters. This includes but is not limited to:

    • Min / Max accepted length Boundaries
    • Ensure all validation criteria is fulfilled (Uppercase, Numerical, Special Character)
    • If only some of the validation criteria are required test all possible combinations
    • Incorrect password handling
    • Ensure correct password is actually accepted
    • Ensure correct password is being securely stored in the database
    • Ensure passwords expire if they are single use

    As I said this list isn’t even extensive; there are further tests that will need to be re-run to ensure that no features have been regressed, and that no new bugs has been introduced as a result of the changes made.

    Given this knowledge next time you ask for a quick fix be assured that, yes, it can be fixed relatively quickly but to have it ‘fully’ tested in the grand scheme of the application might take considerably longer. This is true no matter where you work; web development in London will go through the same process as those in smaller more remote locations.

    Read More

  • 22 Feb 2012

    Testing in the Real World: Tesco Credit Card Edition

    I recently found myself applying for my first ever credit card and following a poor offer from my own bank I turned to the internet to look around for a better deal. I decided to go with the Tesco Credit Card; I jumped on their website and worked my way through the online application process. My application was successful and just as I was being walked through the closing stages of the application I had to click the back button to confirm something I entered on the previous screen.

    This is where my problems started. As soon as I attempted to continue with the application I was presented with a warning message saying that because I clicked the ‘Back’ button in my browser my session had been timed out for security purposes. I can appreciate this from a security perspective given the ease of Form Tampering so started the application from the beginning again.

    However this time (using the exact same details) I was denied at the credit check stage and because of the way the credit check system works it couldn't tell me the reason why (again for security reasons). Knowing how unreliable these sorts of systems can be I tried a few more times but again had no success. I then left it a couple of days and tried again thinking they might have a time limit between applications but to no avail.

    Finally just as I had succumbed to having to call their customer service a letter appeared through my door confirming that my application had been successful even though I had not completed the entire online process. The kicker was that the following day I received another 5 letters telling me that my application was unsuccessful (clearly one for each of the additional times that I applied).

    From an end users perspective these problems made a simple process into something incredible difficult and stressful. These are all problems that should have probably been picked up in the Testing stage of development. Perhaps if their Use Case examples were more detailed as per the Agile Software Development process this could have been avoided.

    Read More

  • 22 Dec 2011

    The Dangers of Social Engineering

    Asset Allocation by its nature is a risky business attempting to make money through investments such as shares, equities and funds. With this in mind it makes sense to ensure every other aspect of the company is as safe as possible to prevent further risks and dangers.With this in mind let me set the following scene:

    'Imagine you arrive at work in morning and are just about to enter the building when you see a delivery person struggling with the door'

    It’s human nature to try and be helpful (at least for most of us); in this situation it would mean holding the door open so they can get through easier. Of course in a perfect world this is fine but what if that delivery guy you let into the building was in fact a ‘Hacker’, you would have just given them access to the building and potentially the network of your business.

    This type of attack is known as ‘Social Engineering’ and it preys on people’s good will. These sorts of attack go beyond the ‘Tail Gating’ example mentioned above and can actually become quite smart in the way they work. Someone confident in the art of Social Engineering might even attempt to directly contact a member of staff pretending to be in a position of authority to gain information on their target (an act known as ‘Reverse Social Engineering’). Obviously this works better in larger organisations where there is less personal contact between the lower and higher levels of the workforce.

    As soon your network is compromised internally it no longer matters how much your company has spent on fancy Firewalls and advanced Intrusion Detection Systems because the damage is probably already done. Trojans might have been put in place to allow the hacker a Backdoor for easy access to the network again, Key loggers could have been installed on a target system or personal details might have already been taken from the database. These are things that you really don’t want to have to worry about when you are trying to focus on complex Asset Allocation procedures.

    There’s nothing that can really stop these types of attacks from happening but you can do your best to prevent them. This amounts to one thing really; Training and knowledge sharing. You need to set out clearly in the operational procedure of the business the sort of things to be aware for; i.e. Do not let unauthorised personnel into the building, always lock your computer (with password protect) whenever you leave it for a prolonged period of time and never ever give your password out to anyone.

    Read More

  • 20 Dec 2011

    Fund Administration and the Security Triangle

    Fund Administration is defined as “the set of activities that are carried out in support of the actual process of running a collective investment scheme”. If you strip this down to its most basic elements it basically leaves you managing someone else’s money for them. As soon as you start looking after someone else’s money priorities drastically change.

    When you consider security with regards to development for Fund Admin applications it is difficult to not consider the ‘Security Triangle’ (shown below):

    Picture of the Security Triangle

    In an ideal world your project would sit dead in the middle of this triangle representing a perfect harmony of the 3 aspects; however this is rare because the sections do not always complement each other that well. When considering fund admin theme this becomes clear; obviously you want to protect the data as best you can from unauthorised access by malicious users and the best way of doing this would be to implement a strict multifactor login process. However by increasing security it means you are decreasing ease of use because the user has to go through all of this before they can even access to application.

    There is always going to be a compromise between these factors and it’s down to the nature of the project you are working on that will determine how this is decided.  For more information on fund administration click here

    Read More

  • 13 Dec 2011

    Top 5 Security Tips

    Having recently attended a course in Ethical Hacking it has made me dangerously aware of just how flawed some security systems can be. More specifically if you have ever found yourself working on a  project developing financial software it is guaranteed that you will have to deal with (and in turn protect) delicate personal information. This said I thought I would try to compile a top 5 security checks you should keep in mind while developing such projects:

    1. SQL Injection / Cross Site Scripting – this is the biggest problem that catches most people out. In all places where a user can input data it’s important to sanitise the inputs to ensure SQL strings cannot be generated due to a rouge quotation mark.
    2. Passwords – one of the easiest parts to not enforce in the security process is that of a strong password. Dictionary words should really be avoided seeing as they can be brute forced in a matter of minutes (this includes words with letters replaced with similar symbols i.e. ‘a’ and ‘@’). Complex passwords should be enforced by default and then particularly sensitive applications (i.e. Financial Software) should implement a multifactor log in procedure using methods such as RDA.
    3. Employee Education – you can set guidelines in official company documents but chances are that they will get glanced over whenever an employee is asked to go though the document. Hands on education is the key to avoiding attacks based on Social Engineering techniques (more about this in a separate blog).
    4. URL – If you are passing sensitive data or anything that can help an attacker figure out details about the file structure of your website it is important to obfuscate this part of the URL to prevent file directory manipulation based foot printing.
    5. Windows Update – there are tools out there that can determine your OS in a matter of seconds and then compare its results against a database of known vulnerabilities. These can then be used to compromise the system in a multitude of different ways at the click of a button. In two mouse clicks you can potentially have access to someone else’s system; this can be avoided by simply keeping Windows patched and up to date.

    Read More

Get a feed of Craig Pilgrim's blog posts