Author:David Greenless
In the ever changing world of IT it's extremely important to stay on top of things. To be successful at almost everything these days you need to 'hit the ground running'.
It's fair to say that the above is common understanding. But what tasks do you undertake to achieve it?
It is especially important in the world of consulting… multiple projects, multiple clients, and an even greater need to avoid failure!
I think it's even more important in the world of software testing consulting. By nature we (software testing consultants) are called in towards the end of the project…
It may be behind schedule, or perhaps testing was an after thought (shock, horror… but it still happens). Whatever the reason may be, it tends to happen quite frequently. This leaves us very little time to gain the amount of knowledge required to introduce a successful quality control such as testing. All of this and I haven't even begun to think about entering an agile environment.
Does this make it even more important again? By nature, true agile environments are fast paced so I would think it does.
Below is a small sample of the things I like to do which assist me to 'get up to speed' in a timeframe that suits the context and level of my engagement (in no particular order):
- Exploration – I find this is key, especially when engaged at the analyst level. I find it very handy to request access to the applications/s under test (even if read only to begin with) and just get in there and dig around. Take a tour of the application/s and note key areas/function points as you go and try some of the more common scenarios or use cases. This will give you a great understanding even if only visual. There will be many occasions when you attend meetings, etc. where the participants are talking about the application/s and you'd be surprised how much easier it will be to follow the discussion if you can visualise the areas they are talking about. Michael Bolton wrote a cracker of a blog here, (http://www.developsense.com/blog/2009/04/of-testing-tours-and-dashboards/) and also take a look at the comments, specifically Cem Kaner's.
- Meetings – Schedule new ones, attend existing ones. When you're new to an organisation or a project you'll normally find that introductory meetings are booked, however if not then book away! Putting a face to a name is vital and will help you understand where you can go if you need a question answered (we can't know it all unfortunately). I also find it useful to attend existing meetings that would not normally be attended by your role. Even if it is simply a one off in the first week or so, it will give you a greater level of understanding and a better appreciation of what others are facing. This is often met with confusion by the meeting chair when requested, but nine times out of ten they will actually be all for it once explained.
- Interviews – This does depend greatly on the level of your engagement, however one on one interviews are a great way of getting individual perspectives on project progress, team morale, etc. Ask each of the Test Analysts how they feel about the application or what they think the biggest benefit will be from the new system, etc, etc. You'll discover many differing opinions which will assist in guiding your approach.
- Reading – This one goes without saying. On most occasions there will be hundreds of pages of reading… project documentation, organisational procedures, training, etc, etc. Fitting all of this in is a big task. Instead of simply reading everything I'll usually ask the right person (whomever that may be) what I need to concentrate on, and what I can skim over. Take a risk based approach like you would for testing. We've all heard of exhaustive testing and how in real world contexts it's not possible? Well exhaustive reading isn't either, not when the deadline is knocking on your door!
- Build Relationships – I cannot stress enough how important this is! Everyone does this differently, and your focus needs to be different depending on the type of relationship you're trying to build. Maybe you need to get on the developers side because you can see straight away there are going to be a large amount of bugs, or you're going to need their help in developing stubs… maybe the architect because they know the business and technology layout like the back of their hands and will be able to answer any question you may have. Whatever the need, get in early and build! If you can identify with the 'go to' person in the initial few weeks, then things will be much easier for you.
As mentioned above, this is only a small sample. I'd be keen to get some responses with things that may have worked for you in the past, maybe even some horror stories of things not to do.
Also, do you think this really can be achieved in an agile environment where new stories are created on a weekly basis (example only)? Sure it can… just use your 'agility'!
One more important note – Be honest! If you don't know something please don't attempt a bluff. Be honest and make it a priority to gain that particular knowledge.
People appreciate that more than finding out later that you didn't actually know and have now done the wrong thing, or similar.
The reason for the title of this blog? As technology moves so do the ways in which we control its quality… you need to be quick on the draw, or guess what?
