investigating software

Earlier this year Boeing 787 maintenance engineers were given some new instructions by the FAA (The US government's: Federal Aviation Authority). They were informed that if the airplane's electrical generators were left running for 248 days, they would enter the fail-safe mode.  In plain English: they will stop producing electrical power. This short video looks into why that might be and how this information can help us to test our software. The FAA directive is available on their website . A Guardian article: Boeing 787 bug could cause 'loss of control' on Dreamliner

In many of my clients, more effort is spent on 'test automation' than on other forms of testing or quality assurance. That can be the right choice, for example, I worked on a Data Warehousing project where we needed to write some test automation before we could test the data and its processing. Many other projects in different technology areas also spend a lot of time on their test automation. To be precise, they spend an increasing amount of time fixing & maintaining old 'tests' and 'frameworks'. There are great tools around to help us write these automated checks quickly. But as with many software systems: maintenance, in the long term, is where the time and money goes. That is why I'm surprised we don't use short term automation more. We have the skills. One good example of short term automation is Bug Automation . A simple script / executable that recreates or demonstrates a bug. This isn't a new idea, I've been doing it for year

I now cover this issue in more detail in my podcast ! The EPA (The US government's Environmental Protection Agency) recently issued Notice of Violations regarding the emissions from Volkswagen cars. Volkswagen is actually a group of brands, therefore the Notice affects other cars such as Audi, Porsche and Skoda. A lot of the focus has been on what was going on in Volkswagen, for example who knew what was being done? Did the VW testers know? Did they pass the details on etc. What interests me is the wider issue of how this could have been possible for so long?  ( Since 2009 )  If so many cars were affected and for so long, why didn’t we hear about this sooner? Why isn’t there a team of people assigned to finding this stuff out... Oh wait, there is... In the UK these emissions tests are governed by the Vehicle Certification Agency , answering to the Department of Transport. One might expect the manufacturer to be less inclined to investigate the cars emissions, after-all te

Many of my clients have a multi-national (and multi-lingual) user base, and their software receives input from a range of devices, not just those configured to UK or US locales. The sites may also need to process and publish content that is 'non-ASCII'. So when I'm quickly testing a website or web application, I need to investigate how they handle inputs from a multitude of locales, quickly. That's why I created the No More ASCII, a Firefox Add-on , it has a set of stock text strings from a range of languages and scripts. These have been chosen for their widespread use around the world, as well as their ability to highlight deficiencies in many web-sites. For example these features of the scripts can cause problems for ASCII/poor-Unicode implementations: Right To Left text  - Hebrew Diacritics - Swedish Non-Roman - Mandarin, Hindi etc. The text strings may not make 'sense' as some are partial sentences or Monty Python quotes. They are aimed to have

A while back I created a simple web based tool that helped you create text strings of a specified length. The text strings are created to make it easy to tell their length even if they are truncated. The tool was based on a similar tool by James Bach, called perlclip . I've now updated my Counting Strings script to be a free Firefox add-on . So you can now have it with you where ever you test online. You don't even need to restart your browser. Counting Strings opens right in your browser, without affecting your website.

Ever feel like your team is in a deadlock? The product owner wants Gizmo+ to be shipped, your senior engineers are split between grokking Gizmo+ and fixing Widget++ . Meanwhile the SDETs are franticly updating automated checks/BDD scripts and exploratory testers are uncovering that Widget+ and Gizmo+ should have been named ...+10 given the number of surprise bonus features they are finding. As a consequence feature delivery can start to slow and quality is inevitably hit as difficult decisions are made on what to fix. The typical reactions to such a situation can depend on your project's context, but to highlight a few common ones: Ramp up team size. Push back on deadlines. Push back on new features. Delay releases until 'it all gets sorted' ... I don't have to break it to you that these options are 'far from optimal'. In summary they all revolve around costing more and delivering less (from my time as a programme manager I can tell you - thats wha

I recently found a couple of security issues with the Telegraph.co.uk website. The site contained an Open redirect as well as an XSS vulnerability. These issues were in the authentication section of the website, https://auth.telegraph.co.uk/ . The flaws could provide an easy means to phish customer details and passwords from unsuspecting users. I informed the telegraph's technical management, as part of a responsible disclosure process. The telegraph management forwarded the issue report and thanked me the same day. (12th May 2014) The fix went live between the 11th and 14th of July, 2 months after the issue was reported. The details: The code served via auth.telegraph.co.uk appeared to have 2 vulnerabilities, an open redirect and a reflected Cross Site Scripting (XSS) vulnerability. Both types of vulnerabilty are in the OWASP Top 10 and can be used to manipulate and phish users of a website. As well has potentially hijack a user's session. Compromised URLs, that exp