Thursday, November 4, 2010

Web Testing

Have had a bit of fun doing some web testing over the last week. Mostly I work on internal systems, so don't get to have fun with user interfaces.

I've been using Selenium RC, with the aid of Selenium IDE in Firefox to figure out some XPath details.

A couple of things that I've learn't over the last couple of weeks:

  • Using XPath to get elements in Internet Explorer is super slow.
  • Selenium RC is great, but it's great to have the IDE just to test out roadblocks
  • The .Click event mimicks a keypress on an element instead of a mouse click - I found some screen reader popups that only appear with keypress.
  • You can't interact with Print / Save dialogs directly (although there are other tools for testing these components)
My tests are mostly checking that elements exist and have the appropriate classes / id's, so I'm yet to see how it works with positioning and styles being applied to the page. 

I'm also keen to use the css element locator - it's supposed to loads faster than finding elements with XPath.

If you're interested in Selenium, check out the proposed Stack Exchange site and give it an up vote. 

Thursday, July 8, 2010

Where does your seat sit?

At work today, we had a bit of a chat about our physical work environment. Currently we've got an open plan setup happening, everyone faces into their corner of the workspace, and we've got space for a whiteboard. One of the issues with the current setup is that pair programming and code reviewing is a bit hard - trying to fit 2 people into a corner doesn't really work very well, and we want to start doing more code reviews to up the quality of our work.

I know that some people are big advocates of the 'everyone get's an office' idea, and have been reading Joel Spolsky's blog - particularly about office space. I think it'd be great to have my own office, but we don't really have the space, so we're trying to think about how we can work better in the space that we've got.

One idea is to have a large table that we all work at in the middle of the area, with whiteboards around the outside so we can draw and discuss ideas. Another possibility is to all work around the edge of the area, facing the wall, but not have anyone sitting in the corners - which will help with pairing and collaboration. A space would be reserved for a whiteboard, and we could wheel in another whiteboard in and out when we needed.

Anyway, hopefully over the next couple of months we can figure out a way to work better together, which may include a redesign of our physical work environment.

How do you work best with your team? Do you sit near each other? How does working remotely affect your collaboration?

Sunday, June 27, 2010

Short sighted learning


Focus
Originally uploaded by Dani Ihtatho
I've been enjoying learning about a number of aspects of the .net world over the last year or so. Recently, I've been creating WCF Services - being new to the service creation world, I had to start from scratch, which is always a good place to start.

My problem, however, is that I wanted to learn enough just to get something up and running. I find that the problem with learning by google (or Stack Overflow, MSDN, blogs) is that there's no one pushing you to get the complete view of a topic - not that people don't offer the information up, it just seems irrelevant at the time when you're working so hard on the basics.

My lack of understanding was highlighted when doing some performance testing. I thought the service would create threads per call, but there are limits to the number of threads (which, of course, makes sense) - but what happens with those that don't get through to the service? Do the requests time out? What happens when the requests are being pased through from a DMZ? A standard request that worked normally as a one off test starts failing under load. None of these issues are problems within themselves, but a lack of understanding about how services generally work, how to queue up requests, how to handle concurrent requests all come crashing back to bite when you get an unexpected problem.

Talking about a different project (one that I wasn't involved in), I was saying to my colleague that I think it's not wise to check something in if you don't understand what it's doing - which I still think is right - but I didn't even know that I didn't know what I was doing!

To help my shortsightedness, I think I need to define some kind of learning plan that outlines all the parts of a new topic that I'm working on, even if it's just a quick read over a msdn article to see what 'bits' are talked about so I'm aware of their existance. I've even been considering buying books! The more I look at it, the more I think a good book is a great basis for learning a new topic - they're usually comprehensive in covering a topic, even if they don't touch on the detail of all aspects - google can come into help then.

Tuesday, June 22, 2010

Planning to test


Traffic Lights
Originally uploaded by Roo Reynolds
When I code, I want to have confidence that my code does what I'm intending, and not being the most self confident coder in the world, writing tests boosts my confidence (except when they all break). Part of this is writing tests that are true to life examples of how the system will be used.

I'm not quite on the test driven development bandwagon yet - I would love to be, but I think I need to be more disciplined to make it work, and really need to learn more about mocking - and properly interfacing out my objects.

For my projects there are a few types of test that I'll write:
  • Integration tests that are testing a few components, for example creating a new object, validating the data and then saving to the database.
  • Story based integration tests - usually testing the API or services that are available, ensuring they correctly accept data, validate, save and return.
  • Simple database connectivity tests - to ensure my NHibernate mapping is correct.
  • Unit tests to test a single method.

There is probably a wide range of scenarios that I'm not checking, which is where working with a tester to manually write up the scenarios and work through them really helps. Over the last couple of weeks I've been working with a colleague, and have found this to be really useful.

Now we've got into our 4th round of testing, and testing is really starting to become labor intensive, which brings me to the question of how do I automate all these tests? To me, I would be confident building the tests in code, but how do you help others build confidence in your coded tests?

How does traditional test planning fit into an agile type development project? As I've written a large number of tests, where does the need to manually test come in?

For the continuing development, testing will obviously need to continue, and we'll need to keep automated tests up to date, which is a subject for another post.

Managing connectivity in a slow, slow world


Day 43
Originally uploaded by ClawzCTR
My last couple of weeks has been taken up with integrating an internal system to our CRM software, which is all hosted in a datacenter far far away. For each request that comes in, there can be up to 4 incidents created, all of which need to happen in real time so the request can be confirmed. The connection to the CRM is slow, both in the application and when developing against the software, but I didn't really give it much thought until I started running a few queries together.

My starting point was to use an external project with a utility to create a single incident with a number of settings. This worked fine until I needed to create 3 incidents, as each request was managing it's own connection, setup of fields, and submitting the new object to the server. At this stage my connection was timing out, there had to be a better way!

First thing to do was extract some of the common functionality - I wanted to create a base incident, which I could just tweak for each scenario. This was great, because most of the fields stayed the same (each field change required a query to get the database id based on the string I had). So the first incident takes a bit to setup, but each subsequent incident may not require any further database interaction until all process are ready to submit.

Initially, I had ruled out using threads, as there is one process that can break all other process, but I may be able to extract this out, and thread the remaining process - which could give a bit of a performance boost.

Another option to consider - should I hardcode all the Id's so I don't need to do so many queries - if so, how do I manage the config for different environments (part of a bigger question). This would save some time, but perhaps present some issues down the track when the system changes.

It's pretty interesting thinking about performance optimization, and this has got me thinking about where I could do things better in my own code, where the time taken may not be so noticeable, but all up could be better managed.

Do you develop against external systems that are a bit on the slow side? How do you manage multiple requests? How do you ensure you can provide a prompt response to your user, while ensuring all requests complete successfully?

Friday, June 11, 2010

Delivery is near!


"Tiny" Delivery Truck
Originally uploaded by El Struthio
The last 6 months or so has been rather hectic, and very unstructured, but the end is in sight!

This month I've committed to delivering 'complete' software by the end of the month, so the last week or so has been bug fixes and working with a colleague to do a variety of tests on the software I've written or integrated with.

Testing has been going pretty well overall, I've got a suite of unit / integration tests that I run myself, but just having someone else go over my project, confirming what I've tested and what's in my head has been great. It's enabled me to sit back a bit, release some of the unnecessary information from my head and prepare for handover.

There is still a lot of work to do (see my previous post about builds), integration that is yet to be fully tested, but it has been a great relief, and one of the reasons I'm keen on moving towards an agile work practice - handing over a tested and complete piece of software every cycle will hopefully allow me to leave work at work more effectively.

Thursday, June 10, 2010

Simple NHibernate mapping and the power of documentation


On the Road Manuscript, #1
Originally uploaded by Thomas Hawk
In an effort to clean up my code (long overdue), I've decided to change all my char types to bool's. At the moment I've got char's in my database, and was simply lazy to map directly to a char in my objects.

In an effort to fix my problems, I did some googling and unbelivebly came upon the NHibernate documentation that I obviously didn't read properly the first time. The section was 5.2.2 - Basic Value Types and the type was 'TrueFalse'.

Who would have thought that documentation could have been so useful - big thanks to those at NHibernate Forge for doing a great job on documentation.

Saturday, June 5, 2010

Work, life and distractions all about

I read a great blog the other day that my colleague sent to me - all about the reasons for working, particularly on a shared project - check it out at coding horror, but in particular the reasons that drive you to do good work, and keep on going at getting better.

Then, this morning I watched this video:

3 Barriers To Help Block Consumerism from Adam Baker on Vimeo.

Along with a pay review at work, it all got me thinking about why we go to work. Thankfully I live in a country where there's good employment, and I can choose what sort of work I do, but we have an endless array of stuff that we can keep searching for. I get paid fairly for the work I do, but there is always more to spend it on, which makes me think that I'm getting ripped off.

How hard it is to be content, and to be thankful for the many good things I've got at the moment! How do you go at being content with what you've got? What do you find satisfaction in?

Tuesday, June 1, 2010

Builds, dependencies and testing



Originally uploaded by +fatman+
Over the last few weeks I've been moving back and forth between testing on my computer and deploying to our test environment. I did another build this afternoon, thought everything was good, and deployed to the test server at about 430 for my colleague to test. Well, after he tried to run the test it turns out that I forgot to change a section of my config.

I watched an interesting video on infoq today about the deployment from dev to production, which has encouraged me to investigate the process a bit more. At the moment I've just got sections in my config for each environment, and I comment out sections when not needed.

So, there's much to do, including getting a build server up and running, so hopefully I'll be writing about that soon, and a whole lot of research about deployment. 

Friday, May 28, 2010

Disconnecting from work


Disconnected color
Originally uploaded by Leonid Mamchenkov
Over the last 6 months, I've been increasingly stressed at work and in life in general. Chatting to a number of people, I think one of the causes is my ability to disconnect from work when I go home. I've got a good job, and the expectations are that I won't take work home (not sure how I'd survive if I needed to do that), although the general work environment at the moment is pretty intense.

My task for the next couple of weeks is to figure out how I can better disconnect from work. Some thoughts that I'm thinking might help:
  • Walk to and / or from work - it's been raining for the last week, so this hasn't been possible, but I have found it just a good time to get a bit of space between work and home
  • Get into a regular routine of exercise at night - expending some energy is a good thing to do, and probably means that I sleep better 
  • Go on a holiday
As an information worker, I think it's hard to disconnect - if only I could leave my work brain at the door!

What techniques do you find help you to disconnect from work, and keep stress levels at a maintainable level?

Wednesday, May 26, 2010

Pair programming


Originally uploaded by ThaRainbow.
A while ago my colleague and I started work on a new project so we decided to do some pair programming, which was the first time I had worked like this. My colleague, having worked with pairing before at a previous job, took the lead. We'd been talking about using agile methodologies for a while, and thought it was a good opportunity to have a go.

At first, it was pretty awkward, as neither of us were overly good at communicating our coding plans, so we'd often wait till the other nutted out a bit of an idea, and then talked it over. We tried writing tests first, which was pretty successful, but once again, trying to figure where the other was going was pretty hard work.

We only worked together for a few days, and then got split to work on separate projects, but I would love to try  it again.

A couple of things that I found:

  • Pairing is humbling - if you don't know something, it becomes pretty obvious fast. 
  • Ideas are up for grabs - no one is going to be right all the time - you've gotta be prepared to put your ideas out there, and be prepared to talk them over and admit that you aren't always right
  • Great collaboration - although it's hard, it's a great way to learn and discuss ideas. It makes you work hard to communicate effectively - which is a great skill to generally have. 
  • Promotes openness - I find the way I like to work is on my own, but being pushed to work with others and be transparent is quite liberating, and it means you aren't the one source of all information.
How do you go working with others? If it's software, have you tried paring? If you're not a developer, what are some ways that you've been forced to work with others that have been surprisingly beneficial? 

Tuesday, May 25, 2010

Google Wave

We just used Google Wave at work today, tried to get a bit of collaboration going. It was my first time giving it a go, and I think the concept is pretty good. We've got a SharePoint site up for our project, but that doesn't really allow for real-time conversations. We're trying to get a feel the gaps in our project, so we can follow them up later.

I like the idea of post it notes and a whiteboard, but Wave keeps all the conversations in one spot, although I'm not sure if technology actually takes away from the collaboration process at this point - especially when we're all in a room together.

How do you collaborate? Have you given Wave a go?

What's it all about

Like most people, I've got a fantastic ability to forget everything that goes into my brain. This will be a way for me to jot down what I've been learning, and hopefully will be of some use to someone else, but if not, that's okay.

I'll probably write about technology, programming, family and christianity.