‘Years ago (before online resume submission), the mailroom delivered a box to me. When I opened it, it was a large origami crane, with a note — ‘Unfold me.’ It was a resume.’
Debunking common job-search myths
Have we reached a stage already, where positions such as developer and tester are feeling like holding onto the past? Are they yet another role where the tasks to be either divided, combined or subsumed? The CV has be largely hailed as out of date, but nothing cohesive to replace it as yet. Perhaps we are in same state for how we think about people in the workplace, and we can’t yet exist without the pervasive labelling in company structures. We will be forced to change soon, however we personally feel.
Posted in exploratory testing, psychology
- Tagged common, date, Debunking, mailroom, myths, online resume submission, origami crane, past, stage, state, submission, tester, Unfold, workplace
There has been some interesting discussions around User Stories on linkedin recently – and have illicted some passionate opinions on why people think user stories are not enough for every requirement. Take performance or technical requirements. This is too simplistic a view on user stories – I would challeneg anyone to find a requirement that cannot be traced back to user/action(s)/results. It does require a different mindset, which I think is why there is resistance to change.
- Non-functional requirements are generally “hiding” in a User Story
- We have to learn how to include non-functional requirement as a User Story
- We have to learn how to create acceptance criteria to support a non-functional User Story
Seems straightforward, doesnt it? Well it isnt – but then requirements gathering shouldnt be – its a key stage in the beginnings of a project, and there should be a blood/sweat/tears element.
When a product owner says “this system must perform adequately with 100,000 concurrent users” the product owner is putting a constraint on the development team. The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 100,000 concurrent users.” Each constraint we put on a system narrows the design choices a bit; calling these “constraints” rather than “non-functional requirements” helps us remember this.
Non-functional Requirements as User Stories
Something simple to make your site font a little more modern and smooth. Google provide ability to add free embedded fonts – they can also be purchased at a charge you want to pay. You can pay nothing, but that would be mean spirited – people do a lot of work for free in web world, myself included. Payment isnt expected but believe me, it is hoped for 😉
How to do it
<link href=’http://fonts.googleapis.com/css?family=Ubuntu:regular,italic,bold,bolditalic’ rel=’stylesheet’ type=’text/css’>
Just place the above string in <HEAD> section of you header file (assuming you are still not madly using static web page). The next stage is to alter your stylesheet, for example:-
font: normal 12px/18px ‘Arial’, Helvetica, sans-serif;
font: normal 12px/18px ‘Ubuntu’, Helvetica, sans-serif;
Simple! (Ensure you change all CSS font definitions where you want this embedded font to appear)
Posted in css, testing
- Tagged Dress, file, Head, link, page, payment, something, stage, stylesheet, type
Behind every methodology is 1000’s of opinions of what the soundbites mean. Agile is self-explanatory to a degree – but only if taken in context. Product owners love it, as they can use those soundbites for easy justification of any requirements adding/amending. “Hey, its agile”. Changing or adding requirements at any stage of the lifecycle is part of agile ethos – but all is reviewed and sometimes, rightly, rejected. Its not a a demand-cycle, its a suggestion cycle. There is an inherent danger with the product manager role – especially if its the company owner takes it. I am not sure if this is blanket rule, but it does strike me as dangerous to hv such pivotal role in hands of someone who is thinking mainly about the next client demo
Another simple useful online tool I use regularly. It is often forgotten how machines/software process data. yes, most systems are very forgiving and understand what a space or quotemark is. But this all adds to overhead.
Machine-friendly data is what the semantic web is all about – how you enter data in a system backend is driving factor to the speed and quality of how data is delivered to frontend. Most systems will do this for you, but why not lend it a helping hand and observe some quality standards. We may be in advanced technological stage, but machines are still fundamentally basic entities that will only do what we tell them to do, and unlike humans, wont complain.
PC/Server architecture hasnt progressed that much, it’s the development languages and techniques that have – worth remembering! And this evolvement has simply been to add more layers shielding the fundamentals of machine program execution, binary, i.e. 1’s & 0’s.
I am not suggesting that all data entry should be this way! But when static data is embedded in code, then even more essential to use html encoding.