Kiichigo

While I write it from consultant perspective, I guess it’s quite good practice for any semi-executive position in research and development department in software company. The idea is – your client have to know what you doing. That’s good ethics and actually quite useful for self management.

General Rules

Company might use internal jabber service or even some exotic IM protocol, voip, bug tracker or any other means of talking to each other. That’s all good, and consultant should use them. But never forget about good old E-Mail. Try to send anything important to your-self for future reference. And copy status updates and white papers to the clients mail box.

There is multiple reasons for that, one of them, starting from: you might have dozen of clients, and everybody use different protocol, it’s nice to know that you won’t accidentally forget to send somebody a note or update.

Status Updates

Make this regular, I would not recommend sending them more than once a day. But daily is good. If you lazy you can try bi-daily or weekly, consider weekly status updates to be an absolute limit. Daily is actually not that bad, and will take only 5-10 minutes or your (paid by a client) time.

Always [blind] carbon copy yourself (cc/bcc), and it’s nice to have an imap mail server, where you can have different folders per status updates for each client. If you are not a modest type like me – you might consider compiling huge update in a PDF from all those small emails you were writing for weeks or months to a client – to remind him of enormous work you’ve done wink.

White Papers

It’s nice to write a white paper for libraries, frameworks and utilities you develop. While documentation in code will be most likely seen and understood only by programmers in your current department. Whitepapers should be a good reference point for people from any other department: UI, GUI, Back-end, Front-End, QA and such. If you are involved in Rich Internet Application / Web 2.0 development it’s really useful to supply Web Designers, UI, GUI and Web Security people with some reference on code, so that they know what to expect.

If a library or framework you’ve developed is particularly huge (150 or more classes for Flex Project for example) – it’s nice to provide your fellow developers with some kind of reference on Facade points of your library too, while they can get documentation, it’s not always clear where to start reading documentation.

And don’t forget to include whitepaper writing to the status updates wink.

Client Specific

As I stated before – each company might have some specific ways of communication. While some of them are exotic and hard to guess. JIRA, Redmine, Mantis, Confluence, SIP and BaseCamp. While it’s quite useless to guess what client’s company might use – it’s nice to install bunch of different IMs from old ICQ to new Skype and open source Jabber, and learn some wikisyntax. Also If you are going to work for scientific/research companies and there is lot’s of interesting job in that sector – LaTEX is quite useful.

That’s not professional QA technic, but in my experience it’s a best one for team that does not have dedicated QA engineer for some reason.

If you working in young Start Up company, or huge company in pre-Christmas season, you might experience lack of QA engineers. Personally I consider QA-people to be second most important engineers in Software Development. While programmers can find critical bugs and develop software on their on. It’s quite hard to find all those small glitches, and small bugs. But it’s very easy to miss them, and build rather smelly foundations.

Usually this bugs are quite easy to fix, but occasionally you can accidentally base important bits of architecture on buggy library. So, I want to share a simple QA technic that can be exploited in almost any company/group. I will use Twitter and WordPress as a simple enough examples.

I want to make a point here: all this sounds very-very easy. But you should not rely on your memory. Tests should be done step by step, and it’s good to have a actual document, and not just oral contract with other people.

Brainstorm use-cases

Get all possible use-cases that matter at this point. It might be good idea to write use-cases that does not matter too, for future. Use cases can be devided by “start position” In case of twitter we might have 3 start position:

• Full Stop: Logout, Quit Browser, Clear Cache and open Twitter site
• Main: Simply go to main page, without relogging.
• Refresh: Simply refresh current page.
• Continue: Just continue from any position.

It’s important to note, that some operations might and have to work only once per session (like popups, announcements, settings storing and such), while other features should work from any point.

Outline each use-case

Each use case should be outlined, with every action that user should do. Then list expected behaviour under each action, in case of a WordPress blog commenting it might look like this:

• [Full Stop]
  
• Open main page – http://kiichigo.eu
• • Page loads
  • Posts rendered, and sorted by date.
  • Sidebar displayed.
• Click on any post title.
• • Individual Post loaded.
  • Comment text-field is available
• Write some text.
• • Spell check is engaged.
  • Post button becomes active
• Post Comment
• • …and so on.

Yes it looks excessive, but it’s not. Trust me if you are in Agile or Game Development environment, and this days it seems like it’s either one or the other – you will be testing same application and same use cases over and over again. If R’n'D is fast – even multiple times a day. Unless you some kind of Savant – you will most probably forget small details here and there.

Print it

My last advice – is to print it, many copies of it actually, and then tick off each step as you go. That’s faster than command-tab/alt-tab every time you want to check next step, and easier to compare.

Conclusion

In my experience, QA is responsible for Deadlines. Good team of programmers can write code pretty fast. But QA can specify functional (requested by client) and non-funcitonal (security and such) features that should be implemented. If QA is unavailable it’s nice to know that software will be stable anyways.