One of the values of automated testing is being able to run a set of tests as part of a suite or load. However, if you have sensibly built in some good protection using MVC anti-forgery or SAML tokens, then there is strong possibility tests can fail due to security functionality disallowing tests run too rapidly. Continue reading
The first lesson I had with Behaviour Driven Development (BDD), is that Kanban is ideal project management match. And particularly suitable for re-factoring projects, though prepare yourselves for more admin and management.
The remit was to implement a clearly defined set of new features, into an unknown arena. No developer likes picking up code in such advanced state as there are many possibilities as to what can go wrong. There were no registered open bugs of any note, as but development progressed, issues regularly surfaced at integration point. Here we hit what we realised was accidental Kanban. Because of the unpredictability of re-factoring projects, the development timeline became more fluid and subject to change. Although not generally done as default, I created new feature files in the Specflow BDD tool to cover the bugfix or where possible added or edited a scenario to an existing feature file (a feature file comprises of a user story and one or many scenarios). This meant that the developer fixing the bug could still follow the BDD process.
Exploratory Testing (ET) is much used (and abused) term, but is very valid description of testing done outside of BDD boundaries. However there is no reason that you can’t still keep to the feature file process when devising ET scope. No application is perfect, so the record of no outstanding issues looked likely to be a simple project closure exercise. So I used the ramp of issues closed near project end date as start point and sure enough, found many existing issues. Due to resources these issues were reviewed with harsh eye, only prioritising ones that could not be postponed. For example, one of the first issues found was that weekly newsletter emails were not being sent out, and had accumulated on mailbox server.
Security testing was not considered in the original project work, but with any website I believe is performing standard checks for security to highlight the more common XSS-scripting and SQL Injection vulnerabilities. It is surprisingly how many developers leave basic holes such a password field autocomplete set active. Security testing can go to real depths, but you can catch most hackers out with basic tests using specific lightweight tools. Remember, most hackers are amateurs.
Kanban provided a dynamic way to manage Work in Progress, which is at Kanban core. The idea is the keep your Kanban board well weighted, with work spread out to resources evenly and identifying the cross-functional elements of the team. Due to my overall experience I was able to offer consultancy on improvements from Kanban perspective. Scrum is iterative in approach, but Kanban is Iterative AND Incremental – managing the parts and the whole. More challenging from management perspective, but extremely effective at gelling a team.
BDD – Behaviour Driven Development is a set of practices which help software development teams to have conversations about the behaviour of their system and how it delivers value to the project stakeholders. BDD has changed from its early roots as a replacement to TDD and now works as a mini-methodology across the whole software lifecycle. Over the last few years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world. In this talk we look at the original reasons behind the creation of BDD, bringing the focus away from the tools and back to its purpose and the philosophies which support it, including Real Options, Deliberate Discovery and Feature Injection.
There are some good articles around at the moment about Agile and Business. The business approach to risk needs to change, avoiding Waterfall type check-points (milestones) to measure risk. An Agile project will stress under pressure of differing objectives between the Agile project and the business, if the old ways are not changed.
Agile provides a skeleton set of rules that you can apply to any other Agile-related methodology – apply them with iron fist, then allow projects to define their own variations, especially at development level. These rules are:-
- Full-Time ScrumMaster Identified and Team Members Available to Do Work
- Team Agrees to Demonstrate Working Software in No More Than 30 Days
- Stakeholders Invited to Demonstration
That is pretty loose, but get to grips with fundamentals of project team structure, and what is expected high-level, it’s a good start to developing your own Agile approach. Don’t forget, no methodology takes account of company culture, human resources or budget constrictions. Follow Agile to the letter, and it could prove very costly for you, without adding much comparative benefit.
The ScrumMaster role is a vital role, as it is he/she that keeps development on track with user stories, and is first point of contact for the business. This role is a common area of weakness – if you omit the role altogether, then you will simply have a Waterfall project (driven, as it would be, by the Product Owner). Product Owner thinks in terms of milestones, as they will have a stakeholder breathing down their neck. The Scrummaster brings some order to the input/output of requirements.
The team members include everyone that drives the daily SDLC, i.e. developers and testers. They may or may not be applying Agile software development method, but any Agile-friendly method is OK to use – best fit for the team and company. Length of Sprints is flexible and driven by realistic vision of what is possible given resources. 2 weeks is a common choice, which is sensible. A broad guide is to assume you need same amount of testing time and development time. 1 week Sprints can work, but difficult to sustain without sizeable team.
It is often stated that Agile is intended for smaller projects, and indeed SCRUM is very specific on this (ideal team size 7-12). This is a recognition that Agile was primarily for smaller projects. But if your project is large and complex, you can still apply the Agile skeleton rule, and choose a longer (and some would say more traditional) monthly release cycle. Corporation generally adopt this approach, largely because corporations are a slower machine. It doesn’t matter how dynamic or Agile your development team is. If stakeholders are rarely available, your project will slow up accordingly, as Agile assumes continual stakeholder contribution to the process.
Startup companies can adopt Agile more fully, as they have a lot more at stake for project delivery. No project, no funding, no company. So they can afford a more aggressive implementation of Agile, and SCRUM is ideal for an average startup structure. For s start everyone is usually in same building, if not on same floor. Interaction between employees is far more frequent, and feedback is very fast, up and down the chain. I have often thought the way corporations should be thinking is of each project as its own company, rather than attempting a corporation-wide strategy. While one project may suit Agile for software development method, another may be better using kanban (which is more developer-centric). Project methodology should be judged per project.
That’s not to say you cannot have an overall Agile strategy in a corporation – just adopt the Agile skeleton as the high-level framework. Then work out the development method to follow – taking parts of several methods, if appropriate.
I am a real collector of social networking sites, why, I do not know but I have ended up with a set of ones I use regularly, namely delicious, tumblr, stumbleupon, reddit (such horribly designed site – I love it!), vodpod, etc .. all used for different purposes.
Collecting audio has been more challenging as 95% of audio bookmarking sites are music-related, and I was more interested in other audio – presentations, comedy, lectures …. and due to another Apple smokescreen of “podcasting”, means most sites that offering these types of audio adopt the “podcasting” terminology, and either have such restrictive functionality makes it boring, or have the cheek to charge for basically being able to bookmark and upload your own “podcasts”. For podcast, read f*cking audio file!
The same way the iPod/iTunes turned a simple concept of hard drive, sound module and player software into a song and dance of epic callous sales and marketing – but at least they are generally only ripping off idiots. A fool and his money are indeed, soon parted.
However, my little rant over (the mere thought of Apple causes smoke to eject from my ears), I found a nice site, huffduffer, that did what I wanted. Still adopting the “podcast” terminology, but importantly on this site, it could juts as well be called a radio station. A simple service that allows you to bookmark mp3 files, and create essentially a playlist (or podcast if that pleases you) – whatever apple try and dominate in this area, this is still THE audio format and the most prevalent. Doubt I could describe it better than their short blurb:-
- Find links to audio files on the Web.
- Huffduff the links—add them to your podcast.
- Subscribe to podcasts of other found sounds
A well formatted RSS file, and very active community. Still very much web 2.0 user-generated content philosophy, which is generally now slated – but is a mutually beneficial free service such a bad thing? I could have actually created service myself, but I figure there is enough to be doing, and the web is a community after all, so support these web services. I think we take too much for free for granted.
During recent consultancy assignment, I have seen a dangerous misconception of a semantic web technology with taxonomy. Tags are a set of words that can be associated, in single or multiple assignments, to content. Although you can specify a set of tags before you even start generating content, generally tags ressult from evolution of a website, rather than be designed. It is not mandatory to organise tags in a hierarchial structure – that is more for ease for the human brain, which finds it easy to process procedural information. But in order to follow the semantic/microformat principles (data stored for ease of human and machine), it is better general practice to organise tags in groups and sub groups. These can be changed/repositioned at any time, with no impact on exisiting data. Unless ….
OK, so we have our nice taxonomy, and feel confident we are following new web development methodologies. Then we have the site application. One ridiculous peice of content management I have seen recently, is when content tagged with multiple tags, ends up published numerous times. Why? Because the way the site has been designed at folder level, was based on old-fashioned hierarchy. Each tag had it’s own folder, and as a tag could also be duplicated in many sub-folder names, the CMS created duplicates in all the same-named folders.
This is a problem when a CMS simply nod towards semantic web principles. The danger being, there is a part-implementation, and the classic mistake of trying to fit a square peg (outdated CMS) into round hole (semantic web). So we now have a massive inefficiency on the website itself – the web application portal on the www. All he careful tagging work done at content level is now effectively useless. Add a breadcrumb navigation, and be assured it will look nonsensical to the user. They will instinctively recognice the classic hierarchial menu, then get confused why when they click on “Fashion” -> “News”, then click on an article link to end up in “Retail” -> “News”. Modern CMS’s do (to varying degrees) seperate out the data from the design, but this is no good if they do not also understand why that is important.
There are very few corporate level CMS’s that are future-proofed, as they rely on constant support and upgrade contracts. But maybe now is the time to realise that maybe that is not what is needed – with a flexible, content could be provided in all sorts of way. Aggregation is increasing more and more, rss/opml have become standards for feeding news/articles, and other microformats have evolved to cater for other types of information. These can be managed very simply internally, as the UI’s for data entry are simple and structured. This is just the start – once these standards become more and more adopted, the semantic web will come ever closer. If you want to be seen, you have to do the work to get the user’s attention.
Now the web 2.0 buzz is settling down into business reality, further moves towards semantic web are crawling out of web 2.0 quagmire. It is easy to forget that web 2.0 was about a set of enabling technologies, and it is only now the hype has passed that these technologies are coming to the fore. Microformats – a term I had heard before, and is based on the sound principles of decentralising data control.
1. Markup should be as simple as possible.
2. Markup should be droppable into as many formats as possible.
3. Development should be decentralized.