Many testers feel underrated; they don’t think they get the respect they deserve.
There are more reasons for this than suggested solutions.
One proposed solution is to define the profession more thoroughly, to get standards and certifications that can guarantee more than the bare minimum of test quality.
I am confident this isn’t the “good” path.

Main reason is that the role is so dynamic, it depends so much on the environment that standard processes or certifications often won’t be good practices. This is true for many professions, but some things are special for testing:

Expectations – there’s a huge difference between testing of a pacemaker, and testing of a personal blog. For some software the importance lies in reliability and security, and for others attractiveness is all that matters. Sometimes testing has traceability requirements, sometimes there just ain’t no time for planning.

Responsibility – even if the goals are clear, you have to figure out what is covered by other roles. If developers have good unit tests, you might not have to bother so much with regression testing.
There might, or might not, be usability, security or performance experts whose work you don’t want to overlap too much. Customer testing might cover requirement holes, and limiting contracts or “physical” access might set the scope. Regardless of your title you
might also deal with customer support, quality assurance or configuration management.

The solution for our status is small-scaled: do a darn good job by doing the testing that the product needs, and isn’t covered by others.
This will be valuable, and you will get respect, and higher status eventually.

This might mean creating automated regression tests, or very thorough testing of some details, or manual, lightweight testing beyond the requirements, or all of these and a lot outside and in between.
Your test team needs to figure out where and how you provide most value, other people can only guess (and help with expectations, responsibiities, goals.)

Long-term, we should promote testing so we get more talents, more diversity, more ideas; more, merrier and better.
University degrees might be nice, but our reputation will come with the products we help deliver.

Recently had some issues with the method assertNotNull(object) because it doesn't help with any of the 4 principles of TDD.

1. Specifications
2. Feedback
3. Regression
4. Granularity

 I vloged my thoughts here.



Finally, here's the code I was looking at.
and check out www.approvaltests.com

I’ve been having a lot of rants about Cucumber of late, as it’s the new shiny thing for agile teams.  Does anyone else have issues with it?  I’ve asked all of my programmer friends to convince me of its worth, and they’ve all failed so far.  I’ve not seen it adding any value above building a good API (and I see it bringing a lot of negatives relative to other possible approaches).

In my experience, I’m seeing -

- Customers/non-programmers never write the tests (because they have very little interest in specifying everything in given-when-then.  They just want to tell us what they want.  And it doesn’t make much sense to specify everything in that format anyway).
- Customers/non-programmers write the tests but it focuses the test effort on writing those kinds of tests, rather than other testing that seems to add more value.
- The tests are written in English, but what the test actually does depends on how the developers convert the english phrases into code (so there’s no guarantee it tests what the customer intended anyway).
- Avoidance of conversation (ie. tests as contracts).
- Cucumber and the related tools (through the toy examples they provide) encourage developers to put lots of implementation detail into the tests (and sometimes to do a lot more testing through the GUI/http layer rather than pushing some of that testing down).
- Refactoring sucks as we lose IDE support.
- Much heavier test artefacts (when a lot of the teams I work with are already struggling with the weight of their agile test automation).
- A continued focus of tests on what the system does and not why it does it and the business outcome.
- Anecdotally, I’m not seeing better outcomes than people were getting with other approaches.  I realise it may be leading to better designs, but then I’d expect to see improvements somewhere in the process.  That looks like it would require better modelling skills than I’m seeing in most of the cucumber tests on my projects.

Most of the examples that I’ve seen where people are claiming success are fairly small applications.  I’m not seeing the approach scale that well.  Yes, most teams could do write their cucumber tests better, but even then, in my experience, other approaches would be more effective and more efficient.

Any thoughts?  If there’s interest, I’ll try and post some examples of what I think those tests might look like if we pushed them into other forms.

Speaking to a customer recently, I was told:

"Honestly, our favorite thing about moving to AnthillPro is that we've moved beyond 'Plug-n-Pray' deployments. You know, many of our deployments were so scary we'd have a bunch of people in the office or on a call all weekend to execute and debug the deployment and then have all hands on deck Monday morning to deal with the inevitable problems. We were all so stressed and tired that we were pretty much useless for a few days after the deployment.

That's all gone now that we've automated. Most of those deployments are a 30 minute effort Friday night, and we don't do anything special on Mondays."

It always feels great to hear that your product isn't just good for productivity, traceability, etc but that you're also making people's lives better by giving them their weekends back. But I think it's important to call out that changes in process for this customer and others like them that are equally important.

• No more Word documents containing the deployment plan They're hard to follow, and get out of date.
• No fixing application server configuration in Test environments by hand: Instead of fixing a broken configuration of the test environment by hand (which often results in the same breakage in Prod), the teams fix the automation to set to the configuration properly in all environments and redeploy to Test.
• Repeatable Deployments: An automation system can only deploy that which is automateable.  This rules out funky processes that rely on guess work and gut checks. The process of figuring out the deployment process well enough to automate it makes the process better. (see our WebCast on using automation to shine a light on your process.

It comes down to making sure your process can be automated. Automating that process. And not circumventing the automation - even in test environments. Each of those three elements delivers some unique gains.

This weekend I realized my last post was almost 2 months ago, on July 4th.

This break from writing was not intentional and it was not really a break since I was really busy with tons of PractiTest work and some additional heavy-duty chores related to caring for 2 small children during their summer vacations.   But there was also a positive side to this pause since it gave me a chance to reflect on what I’ve written on the blog so far, the subjects I’ve covered and those I haven’t gotten to yet.

I did something interesting, using “wordle” (a very cool app!) I generated a word map of the blog’s content:

Word Cloud for the QABlog

It was no surprise that the word TESTING came so strong and central, but there were also some other words that took an important place and I want to take this chance to review them.


SHARE – Sharing is (almost) always positive, but in Software Development and specially in Agile Teams it becomes one of the biggest success or failure factors.
I am currently reading “Agile Testing” by Lisa Crispin and Janet Gregory and it covers this point broadly with many reasons why sharing and collaboration are two of the most important factors for succeeding in agile processes.  By the way, the book is a great read and I recommend it even to testers who are not part of Agile Teams.


TIME – If I had 3 wishes they would be happiness for my kids, world peace, and a 32 hour day!  Time is one of our most valuable assets and so we need to learn to manage it correctly.
But managing time is not enough, we also need to learn to respect it, both our time and that of our colleagues.  For me personally the biggest time waster is context switching. When I stop what I’m doing to read mails, answer IM’s or phone calls, or even when someone walks up to me to ask “just one small question” it takes me between 5 to 10 minutes to reach the level of concentration I was before the interrupt.  If you do this 2 or 3 times an hour you end up spending half the time just getting to restart your work.  Can you relate to this?


THINK – this is a big one!
Most of us don’t really think as much as we’d like to accept, we are mostly busy reacting to what is going on around us.
To really think we need to take a time-out, breath deeply for a couple of minutes and clear our heads from all the urgent things in order to focus on the important ones (notice that most times the urgent things are not necessarily the most important ones!).  When was the last time you did this??
Whenever we take the time to THINK we use our resources better by investing them on the tasks that are really needed.  It’s a shame we don’t get to do this more often…


DEVELOPERS – these guys and galls are our biggest allies, and yet they’re also the ones with whom we tend to be most in-conflict during our projects.
Our relationship with developers makes me think about the classic book “Men are from Mars & Women are from Venus” by John Grey.  In fact we need to understand that the issues between developers and testers are mainly linked to the fact that we are 2 different species (or at the least belong to 2 different cultures) and in order to communicate and work together we need to understand and respect the principles of the other side, what’s important for each of us, and how each one approaches problems and challenges in his own way.
The key lies in understanding & communicating with your colleagues- just like in all types of relationships.


PERSPECTIVE – one of my personal favorites and closely related to thinking.
When you are in the middle of the forest it becomes too hard to look at the trees.  Perspective allows us to take a new look at the issues we are working on and check for new and interesting stuff even in the places we’ve already visited multiple times before.
Gaining perspective is relatively easy, you just need to fully focus your attention on another subject for some time and then revisit your previous task.  Just by switching context you will be able to see things under a different light.
I use this all the time: when testing to make sure I really covered all the important scenarios; when trying to solve problems by looking for different approaches that may give a better result; and even when in I find myself arguing with a colleague when I take time-off to cool down and think about the stuff that is really important.  Give it a try, and tell me if it worked for you!


Lastly an interesting pairing of words that came out of the random image:
GOOD SCENARIOS – something I have not talked about much in the blog but a subject I think I will write about in the near future


I am hoping that now that summer vacations are reaching their end, and after having released some pretty amazing stuff in PractiTest that we were working on for a number of weeks, I will have some more time in my hands to continue posting more regularly…

• This domain is forbidden!+" rel="" title="Tweet This!">Tweet This!
• Share this on del.icio.us
• Digg this!
• Share this on Reddit
• Stumble upon something good? Share it on StumbleUpon
• Share this on Facebook
• Share this on Technorati
• Add this to Google Bookmarks

Related posts:

1. When you think you’ve done enough, go for a walk and then think again
2. Testing the image in the mirror
   - or -
   Why a good tester needs to be Self-Critical?

I'm excited to announce we're holding the Practical Software Test Automation workshop in Oklahoma City on Tuesday, Sept. 14 and Wednesday, September 15, 2010.

The workshop will be held at the Hampton Inn, Airport location at:

1905 South Meridian Avenue
Oklahoma City, Oklahoma,
USA, 73108-1719
1-405-682-2080

You can see the details (outline, pricing, etc.) and register at:

http://www.mysoftwaretesting.com/product_p/okcauto.htm

GSA discounts are available for this workshop. Just contact me for details.

I hope to see you there!

A couple weeks ago, we rolled out v3.0.4 of our platform. And now, after a little extra time in the oven, we’ve launched another feature designed to make it quicker & easier to access your uTest account.

Social Sign-In
Let’s say you’re like millions of other people around the world and you have an account on Facebook, Twitter, or LinkedIn. And let’s also say you’re tired of keeping track of passwords, remembering to sign-in everyday to all the websites you like, and are yearning for something simpler. Starting today, we have a solution for you, at least when it comes to your uTest account (we can’t speak for anyone else). Now you can log in to the uTest platform using the credentials from your Facebook, Twitter or LinkedIn accounts.

Setting up this linkage is simple:

1. Get started by visiting our platform and clicking the button for your favorite social network(s).
2. Then sign in to your social network and confirm the connection.
3. And that’s pretty much it. The next time you visit the uTest platform, just click that same button and you’re in.

Enjoy!

Cloud computing is an emerging phenomenon that offers enormous advantages, such as shorter time to market, flexible computing capabilities and limitless power, but the cloud market, still in a very early stage, continues to grow and evolve.
As cloud computing evolves, it creates a global infrastructure for new possibilities used in software quality assurance and testing. Businesses can share public or hybrid clouds with each other or create private clouds to be shared within the whole company, instead of using separate options for different enterprise departments. However the cloud is also threatened by some risks. These risks should be addressed to create the highest result in implementing the cloud and avoid threats on the other hand.

In the last few posts I have discussed some of, what I consider to be, the most valuable Agile methods for development.  The list is pretty long, so breaking the list up allows me to define each practice and include the individual benefit of each Agile method.  This post defines some hot terms right now- continuous integration, multistage continuous integration, and story points.  Enjoy!

Agile Method: Continuous Integration

How frequently have you merged your code with changes from the mainline, only to find that the result doesn’t build, or it builds but it doesn’t work? Monthly? Weekly? Daily? Hourly? Or worse, how often have you made changes that broke the build, requiring you to quickly correct the problem while getting flames from your team members?

A practice that has emerged to address the problems of integration is called Continuous Integration. The basic idea is that if integrating changes together and getting build and test results on a regular basis is a good idea, integrating and getting build and test results on every change is even better.

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

Agile Method: Multi-stage Continuous Integration

Integration is tough enough when you are just integrating your work with the work of other folks in your small team, or the whole effort is being done by a small team, but when you are part of a large team there is also something called “Big-Bang” integration. That’s the integration of the work that multiple teams have been working on for long periods of time. In a typical project, this integration is done in a phase toward the end of the project. During integration, many problems are discovered for the first time which leads to delays and/or changes in scope.

The real question is, what is a good way to structure this integration so that it will scale smoothly as you add more people to the equation? A good starting place is to look around for a pattern to follow. What are some similar situations? I have found that everything your organization needs to do in order to produce the best possible development organization can be entirely derived from the patterns and practices at the individual level. This approach makes it much easier to understand and much more likely that it will be successfully followed.

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure. MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day

Agile Method: Using Story Points For Estimation, Instead of Units of Time

In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of release by calculating a velocity.

Next up: Backlog, velocity, planning poker and burnup charts.

For a few years now I've been listening and reading to the work Mary Poppendeick has produced with increasing appreciation. Then last year I had the opportunity to interview Mary and Tom for InformIT, as part of InformIT's coverage of the Agile 2009, where Mary was giving a keynote speech.

(Mary and Tom) and I have very different backgrounds. We worked in different kinds of organizations and our careers and interests took us in very different directions.

Yet here was this other person that had both studied the history of the philosophy of management -- and studied the actual effects of those ideas in practice -- and come to the same conclusions as I had.

For that matter, the way that the Poppendeick's approach the subject is different than my stuff, and I think worth studying. So when I found out that they had a google tech talk, I just had to link to it here:



I've spent tens, if not hundreds of thousands of words trying to explain the ideology of "process improvement" and some of my concerns about it. For a quick summary introduction, I gotta say, this video by Mary is shockingly good. Throw in a copy of The Management Myth by Matthew Stewart and you end up with a very good survey of the literature in two source documents.

sigh.

If you need me, I'll be in the corner, licking my wounded pride, trying hard not to cry.

:-)

Seriously, this is a good stuff, and I am pleased to recommend it.

UPDATE: A cursory glance at Poppendeick LLC website finds several 'sound byte' level things that you might take issue with in regards to /testing/. My advice: Ignore the sound bytes that are so easy to misconstrue; watch the video instead. Check out what she actually /says/ about software development, management, and leadership. I expect it will resonate with you. It did with me.

We’re fortunate to be having John Seddon keynote at our internal conference in a few weeks so I wanted to read some of his material in advance. I bought the Freedom From Command and Control book out of interest to see how he applied systems thinking to the service industry.

Depending on what your background reading has been, it may or may not be heavy going. I really appreciated the background I’d done in reading about lean thinking, systems thinking and other respects so I found most of my interest seeing how he viewed the application of these tools, rather than the description of the tools themselves.

Despite some warnings from a number of people, I found the book easy to digest – made all the more entertaining by the repetitive (in a good way) and controversial statements thrown in the book. I figure Seddon wrote them in to intentionally jar your traditional manager into thinking differently.

My biggest takeaways follow:

Stop creating failure demand – Lean thinking looks towards the end-to-end flow of value – starting from customer demand. Seddon articulates on focusing on the idea of shaping the demand and service organisations often get to choose what sort of demand they have (to a degree). More often than not, organisations instead flex their capacity to meet all demand – not really spending the time to think about whether or the demand they have is what they want or not.

For me, this links into another view such that organisations need to address bigger root causes, improving quality and experience for customers to stop generating failure demand. I see these ideas equally apply in a software context – many of the practices we adopt is intended to build quality in from the start so the development effort can be focused on helping the flow of business ideas, rather than spending time on fixing “defects” for customers that should not have reached them in the first place. Similarly, properly addressing user experience early enough will help to prevent failure demand.

Reaffirmation that arbitrary targets are bad – Seddon isn’t fearful to state his view around the idea that setting targets are bad – in that, you get what you measure and the targets are often not really related to the purpose of the system. This seems to sit well with the discoveries of the Beyond Budgeting Movement who’ve realised you cannot use the same instruments for measurement, planning and setting goals (decouple them!)

I found interestingly Seddon still explain to people the importance of measurement, just not arbitrary ones that managemet set and then create systems around.

Using Capability Charts to map demands – Seddon describes the capability chart as a way to visualise the way demand is being generated. Its focus on visualisation is a way of helping people to see natural fluctuations in a system and a way of identified trends not easily seen when boiled down to a matrix of numbers.

As we near autumn up here in the Northern Hemisphere, the wind is starting to blow a bit chillier and here in the Bay Area that can only mean one thing: Oracle is suing everybody! it's time for JavaOne!

A whole lot has changed since last year, Sun Microsystems was acquired by Oracle, Kohsuke left Snoracle to found InfraDNA and Hudson has continued to power on as the single best continuous integration server on the planet.

While the tickets for Oracle OpenWorld/JavaOne are just as outrageously expensive as they were last year, we are hosting a meetup/hackathon/continuous-drinking-contest at Digg the Sunday prior. We have not yet set any kind of agenda, but some core Hudson hackers and plenty of plugin developers should be in town so it should be a great time hacking on and/or with Hudson.

RSVP Here! * When: September 19th, 1:00 p.m. * Location: Digg's Office: 1040 Mariposa St - Suite 100, San Francisco, CA 94107

View Larger Map

Note: Unlike last year, we're trying to organize this with Meetup.com, if you experience any difficulties RSVPing let us know

In my previous post, I made it sound like the Rails installation was painless, and it was apart from one point. When starting ‘rails server’, it complained that it couldn’t find sqlite3-ruby. I would have expected this to be installed as part of the rails gem, but it’s a simple installation anyway:

gem install sqlite3-ruby

However, when attempting to start the server again, I received the following message dialog.

---------------------------
ruby.exe - System Error
---------------------------
The program can't start because sqlite3.dll is missing from your computer. Try reinstalling the program to fix this problem.
---------------------------
OK  
---------------------------

With the stacktrace of:

C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:6:in `require': no such file to load -
- sqlite3/sqlite3_native (LoadError)
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:6:in `rescue in <top (req
uired)>'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:2:in `<top (required)>'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.0/lib/bundler/runtime.rb:64:in `require'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.0/lib/bundler/runtime.rb:64:in `block (2 levels) in require
'

To solve the problem (and considering this is only my local dev machine) I downloaded sqlite3.dll from http://www.sqlite.org/sqlitedll-3_7_2.zip. I then copied the two files into C:\Windows\System32. 

I could then happily execute rails server. Admitted, not the best way but it was the quickest :)

As you may have heard, Rails 3.0 final and Ruby 1.9.2 have been released. These have got a large number of features, with both representing the next stage of Ruby development.

While Rails 3.0 won’t cause too many problems, it does require Ruby 1.8.7 or higher. As Ruby has grown, multiple versions have been released which can live happily side-by-side. Sadly, command lines don’t make it easy to specify which version you want to execute.

For example, I have two versions of MSBuild on my machine with my command prompt being aware of both:

>where msbuild
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe

However, by default, it will execute the one it finds first when scanning the directories set in the PATH:

>msbuild
Microsoft (R) Build Engine Version 4.0.30319.1

The same is true with Ruby. Yet, this is complicated by the fact that there are multiple different executables (gem, rake, cucumber, spec, rails etc) together with different gems depending on the core Ruby version - 1.8 and 1.9 will have different gems installed even on the same machine. 

To help manage this, the Ruby Version Manager (RVM) was created. “RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems”

Sadly, RVM doesn’t work on Windows. Thankfully, Pik does - “Pik is a tool to manage multiple versions of ruby on Windows”.

This means we can do the following:

>ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

>pik switch 192

>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

Below is how I installed Pik, along with Ruby 1.9.2 and Rails 3.0 to start the next part of my Ruby development journey.

Installing Pik

My machine already has Ruby 1.8.6 (ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]) installed which means I can install pik via RubyGems. If you don’t already have Ruby, the README file on GitHub has a section called “Install pik using the installer“ which I recommend you follow.

gem install pik

After downloading the gem, you need to install pik into a directory on your machine. This can be anywhere, apart from where you already have Ruby installed (C:\ruby\bin).

>mkdir C:\pik

You need to include the directory used above in your %PATH% environment variable before the location of any existing Ruby installation. I put it at the start.

When installing, simply specify the directory you picked.

>pik_install C:\pik
Thank you for using pik.

After which, you will have three files in the folder. This is everything required for pik.

29/08/2010  17:08               119 pik.bat
29/08/2010  17:08               145 pik.ps1
29/08/2010  17:08           694,272 pik_runner.exe Using Pik

I can now start working with Pik. Executing the pik command will locate all existing Ruby installations and configure itself.

>pik
** Adding:  186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
Located at:  C:\Ruby\bin
Usage: pik command [options]

Executing pik list outputs all the ruby installations it knows about. 

>pik list
* 186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

As Rails 3.0 requires 1.8.7 or higher, let’s install the latest version of Ruby.

>pik install ruby
** Downloading:  http://rubyforge.org/frs/download.php/71175/ruby-1.9.2dev-preview3-i386-mingw32-1.7z
   to:  C:\Users\Ben Hall\.pik\downloads\ruby-1.9.2dev-preview3-i386-mingw32-1.7z

Sadly, this still tried to install a dev preview, even with the latest version released. Luckily, it can be installed manually. Manually installing Ruby 1.9.2

By default, installing Ruby on Windows can be somewhat difficult. Thankfully, a 1.9.2 one click installer has been released which you can download here - rubyinstaller-1.9.2-p0.exe

After clicking next a few times, I installed Ruby into C:\Ruby192.

I then need to tell pik about my installation by pointing it at the bin directory. That’s it.

>pik add C:\Ruby192\bin
** Adding:  192: ruby 1.9.2p0 (2010-08-18) [i386-mingw32]
Located at:  C:\Ruby192\bin

If you list pik, then you can see all the different versions installed:

>pik list
* 186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
  192: ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

You can then switch to the particular version you want, for example originally I was running 1.8.6.

>ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

But I can then switch to 1.9.2 with a simple command.

>pik switch 192

>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

Installing Rails 3.0

That’s the hard bit done. I didn’t have install pik but during the transition between 1.8.6 and 1.9.2 I *think* this will be invaluable. With 1.9.2 now configured and set as my current pik environment I can just install rails.

>gem install rails

Yep, that’s it.  Rails 3.0 Hello World!!

To create a new rails app, let’s just execute the command:

>rails new HelloWorld3 

Followed by:

>rails server
=> Booting WEBrick
=> Rails 3.0.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-08-29 18:01:27] INFO  WEBrick 1.3.1
[2010-08-29 18:01:27] INFO  ruby 1.9.2 (2010-08-18) [i386-mingw32]
[2010-08-29 18:01:27] INFO  WEBrick::HTTPServer#start: pid=7472 port=3000

I now have our Rails 3.0 application running on top of Ruby 1.9.2 on Windows.

If I ever need to go back to Rails 2.3.5, I just type the following:

>pik default

>rails -v
Rails 2.3.5

If you’re in the market for a new mobile device (and these days, who isn’t?) one of the most important decisions you’ll have to make is whether to choose the physical keypad or the touchscreen.

As we learned from our most recent What Do uThink poll, most mobile users actually want both of them. In fact, 70% of respondents said they would prefer a device like the Motorola Droid or the Blackberry Torch, as opposed to the 20% who said they preferred the physical keypad only (e.g. Blackberry Curve, Blackberry Bold) and 10% for the virtual touchscreen (e.g. the iPad, iPhone, etc).

So, 70% of mobile users can”t be wrong, can they? Let’s take a look a few of the arguments (from the uTest Forums thread) in favor of each, then decide for yourself.

Physical Keypad
“I go with Physical keypad. The reason is I have experienced problems while using touchscreen keys. I love Physical keypad which allows me to type the message fast and call the number much quicker than a touchscreen. Also, my LG Android had gone for service because the touch screen was malfunctioning. For instance, when I pressed 3, it used to display 6.”

Hybrid
“I prefer a hybrid model as it gives me independence to use the phone as per my convenience. Also, it makes things much easier for me. If I have to chat or SMS I can use the keyboard feature, but if I have to punch in a phone number or username/password I can do it from touchscreen. Plus, different situations demand things differently so a hybrid model is a perfect one for me.”

Virtual Touchscreen:
Pros:

1. Does not take physical dimensions & weight, thus devices can be lighter & thiner, or can be larger with larger screens & additional physical buttons in return to that acclaimed space & weight.
2. Some physical keyboards can be used only on one orientation. Virtual keyboard will mostly work on both.
3. Easy keyboard layout navigation & usage – E.g. Input switch, Special chars (rather than hitting an Alt/Shift/Sym+Char), Smileys and other special inputs.
4. Languages support – As opposed to physical keyboard which can support 2 languages max, TouchScreen keyboards can support and unlimited amount of languages, so everyone can enjoy the languages keyboard of their choice.
5. Used device’s brightness setting thus can be visible at dimmed or low-light environments with no problems, as opposed to physical keyboards’ limited lighting.
6. Clarity & efficiency – Most touch keys use all sorts of key highlighting pressed button such as – Coloring, Magnify glass (e.g. iPhone), Vibration (E.g. Android)

So where you come down on this debate? Which type of device will you be leaning towards for your next purchase. In other words, What Do uThink? The comment section is all yours.

We all know that UI test automation for any complex, rapidly changing web application can be daunting. Authoring effective tests is often painstaking, and the maintenance burden of keeping them kicking is generally hefty. In order to stay on top and keep our QA team in good mental health here at LinkedIn, we’ve adopted the [...]

How to stress load your application and set up web tests or win form tests with Visual Studio Team System.

This tutorial shows how BDD can be done from early requirement collection stage to late integration tests. It explains breaking user stories into behaviors, and then developers and test engineers taking the behavior specs and writing a WCF service and unit test for it, in parallel, and then eventually integrating the WCF service and doing [...]

If you were unable to attend Sonatype’s last webinar on Build Promotion with Nexus Professional, you can view the presentation recording here. This webinar is an introduction to the Build Promotion capabilities of Nexus Professional, the industry leading repository manager to help companies acquire, manage, and report on open source software artifacts in their software development projects.

The Build Promotion feature in Nexus Professional allows an organization to create a temporary staging repository and to manage the promotion of artifacts from a staging repository to a release repository. This ability to create an isolated, release candidate repository that can be discarded or promoted makes it possible to support the decisions that go into certifying a release.

Upcoming Webinars:

Build Promotion with Nexus Professional

When: Thursday September 9th, 2010 at 10:30 am PDT, 1:30pm EST

Who: Blaine Mincey, Senior Systems Engineer, Sonatype

Register for this webinar

 

I'll be in Copenhagen from 9/5-9/7 and in Oslo 9/8-9/9 to present in JavaZone. I'd like to take advantage of the opportunities and have user meet-up events in those cities. Depending on the number of participants, it could be just a drink in a bar, or a talk in a meeting room.

So if you are:

1. in those cities,
2. available in the evening of 9/6, 9/8, or 9/9, and
3. willing to attend such an event,

... then please let me know.

Also, if you have an office in those cities and willing to provide a space for an event, that would be extra appreciated!