HCI and Web Design

One of my favourite modules at University was Human Computer Interaction 1 & 2. It was taught very well by Dr. Russel Beale and was fun and interesting. I learnt a lot from that module especially in terms of the human aspect of designing a system and web sites. However, one thing I have found is that in the business I work in, HCI tends to be put on the back burner. It’s usually not seen to be as important as the core functionality of the system and seen as ‘cosmetic’. I find it quite frustrating that basic concepts such as good colour schemes, affordances and metaphors are not taken into consideration when designing systems. Usually decisions for look and feel are made by the client, but there tends not to be a usability expert on either side to say ‘hold on a second, we shouldn’t do it like this because that page will look noisy’ or ‘the buttons shouldn’t be arranged as ‘Cancel’ ‘OK’ as when people hit enter on most systems they are expecting it to click ‘OK’ and not ‘Cancel’. Other things we tend to lack is that (apart from UAT) we don’t have end users directly involved with using the system iteratively as it is progressing. Techniques like Cognitive Walkthroughs would provide us with a fantastic insight into how we can make systems more user friendly. Usability studies are usually based around human psychology and human perception and if the system layout doesn’t meet the user’s expectation then they will be reluctant to use it or they will not use the functionality to it’s fullest....

Automated UI Testing using Ruby and Watir

Just before Christmas our Scrum Master was asked to come up with a way of automating UI testing using open source software. He came across Watir (Web Automated Testing in Ruby). Creating scripts in Watir is very easy to do. Our Scrum master (using the watir API) has written some classes including domain specific ones (relating to our project) thus making it very easy for anyone to be able to write scripts. The point of this was to help with regression testing so that it is almost push a button and the scripts will do all the work for UI testing. Obviously there are limitations (such as automating email activation) but it is devised in such a way that writing a script has a natural language feel to it. We have been incorporating the writing of these scripts as screens are developed in our sprints, this allows us to provide better test coverage. The scripts have mostly been written by the developers and a tester, we were hoping that the testers would be more enthusiastic in getting involved, however this has not been the case. I think they are a bit hesitant and would rather go through every single screen than to trust the automated process, which is a shame really as it works so well. For further details on the technical aspect of Watir, please visit the link...

Demo & Retrospective

Demo Even though it was a late night on Wednesday, we managed to get all our stories ‘done’ ready for the demo the next day. I was told by the scrum masters that the demo with the client went very well. The only disappointing thing is that apart from the Scrum masters and the BAs and other management types outside of the sprint teams. I raised this during the last retrospective and an item was actioned for this. However, nothing came about of this. The scrum masters decided that the team members should go to the dry run prior to the sprint demo. I was one of those who went along, it was nice to see our work up there and as one of the client is a part of our sprint team, it was re-assuring to see him presenting and selling the end product so well. The only issue is that the sprint teams should have the option of going to a client demo whether they choose to or not is up to them. Ultimately it is the sprint team who have produced the work and the client should have exposure to this, it feels a bit like they’re being shielded from the sprint team. I know that management have their reasons and that ‘rooms are too small’ etc, even if the sprint team were there as observers it would be a good learning experience for the team too, especially those that have not been involved in agile development before. Lastly, it is one of the practices of Agile, that team members should be present at demos! I...

Multi-Functional Teams

As mentioned in one of my previous posts, sprint teams are meant to consist of team members who are multi functional. Although, we tend to have defined roles (i.e I’m a developer and person x is a tester, person y a business analyst etc) the whole multi-functional teams has been put to the test this week. In the past BAs have taken on testing roles especially towards the end of a sprint, however this time round we’ve managed to finish all the development and the bottle neck is at the testing end. So myself, and the rest of the developers have put on our testing hats and started testing (obviously not code that we have written and the test conditions have been written by the testers). It’s not so bad as long as the test conditions are written well and it’s a case of executing them and raising any defects. At the end of the day, the ultimate goal is to get the stories into ‘done’ and points on the board, so it’s much more beneficial to help out in this way then to sit there twiddling our...