Is testing last in line?

Testers always say testing is that last in line. It's always left to the end. Not enough consideration given, etc...

However, I've been reading Content Strategy for the Web and the author claims that content is always left till the end. That design is often created and then developed with little thought about content.

So, in your experience, who is last in line? Content or Testing? Neither? Something else? :)

I know I've tested websites with dummy content before and never seen them with the real words.

Tags: content, testing

▶ Reply to This

Replies to This Discussion

Permalink Reply by Joel Montvelisky on December 6, 2009 at 10:16am: Without having read the book my feeling is that the author placed "so much importance" to testing that he/she even forgot to take it into account and set content as the last stage when it should be the one before last (just before testing the content!)

Having said that, I am a true believer that we as testers have the power to push our involvement forward (earlier in the process) as much as we "want to", by showing value to the organization in the things we do.
For example, if we try contribute in the stages of design based on our knowledge of the system and our user-point-of-view then most times we will be called upon to do so.

In my experience most organizations will give us the chance to prove ourselves if we really want to.

My 2 cents.; ▶ Reply to This

Permalink Reply by Michel Kraaij on December 6, 2009 at 2:41pm: I agree with you, Joel. It's the mindset of the tester that matters. He/she has the power to be involved in an earlier stage. Before development and even before designing. Unfortunately, a lot of testers just wait until their timeslot in the project plan arrives... they forget they are able to influence the project plan.

About the content. Content shouldn't be addressed at the last stage. Neither should it be in the stage prior to that. Content is, with it's context, a representation of business information. Vital information for part of a process which is being automated through development. In my opinion the content should be addressed as one of the first aspects of a transition strategy (which includes a project). The complete business process relies on it.

(yay, my first message posted on this board ;)); ▶ Reply to This

Permalink Reply by Anna Baik on December 6, 2009 at 9:36pm: So what if marketing want to be able to change their minds on content right up until launch date? What if they feel that setting content in stone, 3-6 months before launch, is the kiss of death?

(Welcome to the board Michel!); ▶ Reply to This

Permalink Reply by Michel Kraaij on December 7, 2009 at 6:56am: Well, isn't that the case for every webshop around? The content changes on daily bases.

A while back i was involved in a project redesigning a large dutch webshop. Marketing was an important stakeholder for this project. The goal was to supply a flexible environment which was acceptable for marketing. At some point early in the project marketing had to determine the charasteristics of their content and agree upon the intended sollution for publishing this content.

(in the end the webshop was awarded for "Best (dutch) webshop 2009" and "Usability award 2009").

So in this case, the final content wasn't that important for the project itself, but the characteristics were.

Giving an answer to the original question. Is content last in line? Yes it probably is, but it's also one of the first topics in line.

(Thnx! :)); ▶ Reply to This

Permalink Reply by Amit V. Kulkarni on December 6, 2009 at 3:59pm: I'll second the opinion shared by fellow members. Its the testers' approach that matters a lot; however there are some companies/organizations where-in even if you show the interest, they will ask testers to WAIT.

I've always tried to be in touch with developers/designers in every project or work. Sometimes developers/designers used to get "irritated" with me - and times they used to like the suggestions/feedbacks. This used to take good efforts though!

Contents are vital information for any organization so if they can be provided from the client ASAP that would be great! But most of the time there is this other case that where-in we don't used to get contents and we've to test with "dummy" contents. At times client used to handle this from their hand after original contents were integrated; and there were sometimes when we used to get the task. However, most of the time problem happens in the first case and ultimately client used to hit back us for help!

Best Regards,

Amit

testing is my passion!!!
http://bugteaser.blogspot.com; ▶ Reply to This

Permalink Reply by Michel Kraaij on December 6, 2009 at 4:19pm: If they "ask" you to wait, you apperently have a choice... ;-)
If they "demand" you to wait, at least you could question their motives.

But i'm deviating from the topic. About content. To be honest, when i first replied an hour ago i didn't (bother to) click on the link Rosie supplied in her topicstart. My bad! But when writing this reply, i did. Now i'm wondering. Are we discussing the same type of content here? The book is talking about "the meaning of content and the value of usefull content". Not merely the representation of it.

Or was the topic about who was last in line? ;-); ▶ Reply to This

Permalink Reply by Enrique T. Campita II on December 7, 2009 at 5:09am: At the beginning of the project development I think it would be safe to test with dummy inputs like "Lorem ipsum". It would be a little incomplete to say though that we have considered every possible scenario in testing when we really didnt consider what data an object would hold. Imagine if a textbox was used when its supposed to hold a paragraph or blog. Or vise versa, The end effect on that specific page would push the rest of the objects away in unpredictable way, or even overlap the adjacent objects. And then the client would show you screenshots of their ugly-messy page. I think validating user input would be easy if you know first hand that its data is a date, note/paragraph, name, addresss, pictures and so on. That would be fine. IMHO; ▶ Reply to This

Permalink Reply by Rob Lambert on December 7, 2009 at 4:55pm: Good question Rosie.

I think this completely depends on the type of business working in. We have some products here where the content is defined at a high level so the formats, flows, UI etc can be built. The real content is then added at the end when the usability, accessibility and flow etc are complete(ish). This allows for more change to occur and saves people the time of defining all text before the UIs are done. We found UI changes meant the text needed to change and re-arrange.

Other products however, have all of the content defined up front and UI's and structure built around it.

I've worked in companies where the documentation/content/marketing team produce content each iteration and have input in the same way dev and test do.

I think there are pros and cons to each way and finding the right balance is part of our jobs.

As for who is last? Well, it's a little difficult to call really as each company works in a different way.

One question I would ask though would be:

"After adding in the content....do you think it would be prudent to let a tester explore around and check it's ok?"

Just a little thought. Every app/site/document I've ever been involved with has always had something wrong when the content is added to it. Appearance, layout, fonts, copy and paste errors, incorrect text, bad choice of words, meaning wrong, cross browser appearance etc etc.

Does this make testing the last line of defence? Maybe.

Rob..; ▶ Reply to This

Permalink Reply by Leslie Crandall on December 7, 2009 at 8:02pm: I think it depends on the organization. I've become accustomed to working with dummy text while testing simply because in many instances, the content is on a timer and is usually not posted until day of release (think things like press releases, study data, etc.) However, when testing 'time-released' content like this, it doesn't absolve the tester from confirming the timer is set to work correctly, or sanity checking once the timer has gone off to ensure the content is correct.

I think for many groups, PR professionals or copy writers manage the quality of content, so the belief is QA doesn't really need to see the 'real' thing. However, I've lost track of the number of times I've brought misspellings and egregreious grammatical errors to the reddened faces of editorial staff after the date of release.; ▶ Reply to This

Permalink Reply by Robert Healy on December 7, 2009 at 11:01pm: Hi Rosie,

I'm reading Geekonomics by David Rice at the minute. He makes a point relevant to this discussion. In the end, the users are the last testers, they will find the bugs that we unfortunately miss.
He makes it in a dramatic fashion claiming that we (users) are "6 billion crash test dummies". But what good is an economist that doesn't court controversy? :P

I think a level of pragmatism of content vs testing is called for; I'm not a website tester at the minute but used to develop one. From that perspective I agree with the Kristina Holvorson, designing the broad look and feel did used to take precedence and content went live around the framework, sometimes clunkily. I remember my boss (the CEO) at the time was the nearest thing I had to a tester. He was not technically proficient and a great person to learn from; I could spend days designing neat code and architecture but he would spot a typo, a grammatical mistake or a poor resolution image at 100 paces.

Thanks,

- Rob; ▶ Reply to This

Permalink Reply by Alex Sergeev on December 8, 2009 at 10:14pm: I think that time when tester can be involved into feature or application development depends on culture and feeling of testing in company or even in development group. When you have experience it maybe possible and correct to try to be involved from first stage (with help or opposition of biz and dev). But when you are junior... no, I think in this case too much reasons to be last in line: (maybe) not enough experience, too critical mind (no compromises!), not enough understanding of features importance and business needs, etc.

Back to your question. I've never read that book, so I can be wrong.

Before content will be applied to page - testers do tests on layout. They are checking that, in some limits, page markup will not be broken by content in future. From this point of view - content is last in line. When content is on the page - testing is like editing and less layout testing, in my opinion. And in this situation testing is final point.; ▶ Reply to This

Permalink Reply by Thomas Ponnet on December 9, 2009 at 5:10pm: I'll answer this one with a question myself (although I've been told not to do that), is it important who's last in line?
Does last in line automatically mean disregarded as not important? Some kind of test should be the last thing you want do before you release to the customer. This could be testing the CD that is shipped to the customer, the installation that has been implemented on the customers site, testing/reviewing the documentation, etc.
In my experience documentation people get information about the same time or even later than testers and have the same last minute scramble to make the necesary changed. Because if you change the content, not only will it need to be tested, the tech writers might need to take new screenshots, update steps, etc. That doesn't mean that's bad though, it's not something that in most cases in can't be done in another way.; ▶ Reply to This