Lessons Learned in Very-small-scale Agile Development And Testing Of A Wiki Agile Testing

What Worked Well

With the project complete, the Wiki delivered and working, and having had the time to review what I did(is this what they call an agile retrospective?), I would like to report the following positive aspects of the development process:

  • Pair programming and pair testing worked very well. I estimate that working alongside another member of the team in developing and testing the Wiki was more than twice as effective as working on my own(in terms of timescales and lack of reworking). The obvious and tangible benefits included:
  • Being able to keep each other focused on the task at hand (made it harder for me to keep checking out my auctions on eBay or my mates on Facebook and Second Life).
  • Filling in for each other’s knowledge gaps –There was often something I couldn’t do that my esteemed colleague did know about, and vice versa–this meant together we had a more complete coverage of the knowledge of the development environment capabilities.
  • Providing a testing dummy –I have often experienced the situation where you have observed a bug, spend ages trying to understand what is going wrong, but don’t seem to be able to make any progress. Then a mate comes past who you grab and ask for their help, and even though they don’t really say a word, the act of explaining what is going on actually gives you the eureka moment where you spot the problem. At this point they usually stand up and wander off, feeling smug about having done so much to help you! This experience is just part of the pair development and test paradigm, and happened to us several times each session.
  • Solving that developer testing thing –I find it hard to test my own work. I seem to focus on showing that the code works the way I expect it to work, rather than focussing on showing that the code doesn’t work. This is a subtle difference between a developer’s approach to testing compared with a tester’s approach, but in practice it seems to make a big difference (more on this later). With a pair testing approach, I found that together we would come up with more test scenarios and more thorough scenarios(maybe finding more error conditions to test against, for example). The other person also keeps your testing “honest”–no cutting corners or making rash assumptions about how good your code is. Where I had tested on my own, there were always lots of issues reported by the team when they made their weekly review of the system. On those weeks where I had been able to work with a colleague on pair programming and testing, we calculated that there were only about 50% of the bugs reported.
  • The weekly iteration cycle –While I don’t believe this will work for large projects where they have large tasks to complete, I found this to be a highly effective technique to adopt on my project. Because we were running to a weekly cycle, everyone seemed to get into a rhythm in terms of their responsibilities and tasks:
    1. I knew I had to review the requirements(existing and new requirements)every Monday morning and ensure the requirements tool was kept up-todate.
    2. The team knew that they would get the latest version of the system to review each Thursday afternoon, and also that they had to have their comments ready for the teleconference on the Friday afternoon.
    3. Similarly, I had access to the project manager(my boss)on the Friday conference call, as well as the customers/users(the rest of our team),and could take direction from them on priorities and goals for the next week, as well as, where appropriate, to make requests for additional resources(such as a pair developer and tester).
    4. Monday afternoon to Wednesday was development and testing time.
    5. That left Thursday morning to do some formal testing to ensure I had met the requirements for the week, and to regression-test the Wiki to make sure I hadn’t introduced any deleterious changes;I had to be thorough and I had to make good progress to hit the Thursday lunchtime “code drop” deadline to deliver to the users.
  • Lack of co-location with users –The fact was, that although we weren’t physically co-located, the company we worked for provided extensive team working support facilities. I could always ping one of the team using our company instant messaging system and could always publish the latest version of the Wiki for anyone to take a look at some aspect of the functionality I was working on. I don’t believe I could have developed the system as quickly, with as high a level of quality, or with as close a match to the users’ needs working on my own in isolation and only having contact with the users once a week.
  • Lack of co-location with the project manager – Again, although not physically co-located, I was able to quickly and easily ping my project manager using instant messaging. My feeling is that the project timescales, quality, and match to the users’ requirements did not suffer through lack of face-to-face contact with my project manager.
  • Tool Support –I found that having access to a requirements tool was very useful:
    • It provided me with a simple and effective solution to documenting requirements.
    • I could use the tool to publish the requirements to my project manager and the users so that they could review them and provide me with their comments.
    • Keeping the requirements up-to-date was straightforward, and I had a built-in trace of how the requirement had changed and who had requested the change. This proved to be invaluable several times, as guilty parties in the team denied having suggested a particular change–the tool never lies.;-)
    • I would have liked to have had access to testing tools as well–such as the sort that can automatically scan a web application to identify problems(such as missing links, widows and orphans,2 security issues). The reality was that this project was too small and had no funds to allow us to use such tools. However, having seen such tools demonstrated, I would certainly investigate their use on other projects that I may get involved in.(I am selfish, and anything that saved me time and effort on testing would be something I would be very interested in using!)
    • And last but definitely not least–rapid prototyping. I found this to be a really useful means of increasing my efficiency and keeping to my timescales. Rather than just assume I knew best and spend ages developing a complete solution that it turned out nobody wanted, very quickly producing a simple, navigation-only model and running it past the team meant that if I had gotten it wrong, I had only spent a couple of hours of time on the task(and had gained the big bonus that I now understood better what was actually needed). So, prototypes are a quick, simple, and easy way to check you are developing the right thing and if not, to not waste too much time and effort, with the bonus of getting a clearer insight into what the users actually want.

What Would I Change in the Future?

Although the project completed successfully(admittedly, with a deliberate fifth iteration overrun), with the benefit of 20–20 hindsight, the one area I might change, if I was still working in the team and there was a requirement to run a similar project, would be in the area of continuous integration and refactoring.

What I would have liked to have been able to do was to undo changes I had made in a formal, safe(i.e., allowing me to restore a change), and repeatable manner. For example, if a particular request for a change had resulted in a catastrophic problem in the system, it would have been nice to have easily restored the system to its prechange working state. Also, it would have been nice to have been able to retain those successful changes that might have been made in parallel with the problem change while undoing that change.

Given the relatively low size and complexity of this project, this was in practice a relatively small problem(although I did spend several frustrated sessions in the evening, and on one occasion across a weekend, fixing such issues). However, I can see where this would be an extremely serious issue with larger and more complex applications and larger teams.

This seems to me to be largely a configuration management problem, and my solution to this issue on future projects would be to employ tool support, using either a shareware tool off the Internet for the sort of small project described in this case study or a more capable and robust proprietary product for larger, industrial-strength projects.

Perhaps the most innovative thing I might try in the future, if I was involvedin a similar project, would be to use some of the new hi-tech means of online collaboration, such as team meetings in Second Life. For example, I have heard of Second Life design review meetings where the team could actually walk through a 3D representation of the design diagrams and provide instant online feedback on the information displayed. While Second Life might not be a perfect solution to the problem of not being able to get together for face-to-face meetings, I really believe it is an option well worth exploring(assuming my older colleagues actually have accounts on Second Life)!

Finally, my only other wish–and again while this was not really an issue on this small project(I can see benefits for larger and more complex projects)–would be to consider automated software testing. In the case of this project, a web testing tool(to check navigation, usability, and security)might have been very useful and, for larger projects, some form of record and playback tool to regression-test later builds and releases could save huge amounts of valuable tester time and effort(avoiding the unwelcome prospect of spending too much time manually testing the software in the evenings and at weekends, when I could have been out partying instead)!

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics