To mark such an occasion, I decided to dedicate some pages in my blog to help me as a reference when I need to access how successful this move actually was after some time, and hopefully, to provide some help and guidance to anyone out there who is in the similar situation as me and thinking about doing the similar thing.

As much as I like to write stuff, it is just way to long to put in a single article. I will divid into a series of short blogs, and post them here. Ok so here we go.

Just like everything else, whenever there is a need to change something, the first question is always related to – Why. Usually, when we make a career move, it’s because there is something we can’t get from our current position. Becoming a contractor is no different, you will need to ask yourself why, why do you want to become a contractor, I’d suggest you make a list of the things you want to achieve by working as a contractor, then find some contractor friends and ask them if your goals are realistic and achievable.

I have asked a lot contract test consultants, different people will have different opinions of course, but usually they are all related to and can be summarized as:

• Significantly higher pay.
• More work flexibility.
• More work variety.
• Less BS and political fights, if you like to concentrate on doing actual work.

Of course, the other side of coin:

• No job security guarantee.
• No benefits, such as industry certifications, training, seminar, etc.
• Much more other responsibilities that you will have to take care of, doing your own tax for example.
• No paid leave.
• Personal career development can be difficult to achieve.

Without too much detail, I will briefly going to some of the points above.

More pay. If you are in a short-term rolling contracts, in most cases, you will be paid by the hour. For a typical test analyst with around 5 years, the market usually pays between $45 and $60. Please be aware that the numbers are only for reference purpose, do not quote me on this. In a bad economy where market is too volatile, the rate will generally be lower. Depending on the actual company, project type, and market demand, the actual rates will vary. But one thing is for sure, a contractor will definitely be paid more than a permanent staff, usually it’s about twice as much. I did a simple calculation, if you are lucky get paid $65/hour, it is equivalent of $113,880 per year. I also took into account of 20 days of annual leave, 10 days sick leave, 11 days public holiday, and assuming you work 8 hours per day, 5 days a week. While this figure include personal income tax, but even after deduction, you still end up with lots money, not to mention you can have your business expense deducted and other many tax benefits too.

No job security. Generally, job security is mostly impacted by the big economic environment. This is especially true for New Zealand, as it is very dependent on export and import industry, any abnormal change in global economy will quickly impact the country. There were a lot contracts out of their jobs during the 2008 recession, but equally speaking, I have also seen many permanent staff been force to resign or made redundant as their roles were dis-established. I guess my point is when the global economy is turning into shit, everyone will be affected, regardless your job status. But I have to point out generally, contractors are the fist bunch to go as employer are still morally obliged to protect their staff, and if things don’t get back on track quickly, permanent staff will get similar treatment.

No paid training, seminar, etc. This is one of the most perks entitled to a permanent staff, being part of an organization, you will usually receive opportunities to go to seminars, conferences, and trainings, better yet, all of these will be paid for by the company. Often, these benefits are known as personal training and development. What one should know is that a company is not obliged to provide these, so say if your company is going through some finical hardship, your manager will have every right to turn down your training application and cancel that ones that already planned. Sometimes in less extreme situations, you can still have your training requests denied, because it doesn’t align well with the company’s long term strategy. So my point is, the paid trainings etc are not part of the company’s contractual responsibility, you as an employee won’t get it if the company you work for doesn’t want give it to you. Here is my way of solving it, by working as a contractor, you get more money, and if you want to get certified or attend a conference, just save the money and pay for it yourself, that way, you always get it and won’t have to be dependent on other things and you will always stay in sync with the new technology development of the industry.

If this is the 1st time you are into this uncharted water, I’d strongly recommended talking to your contracting friends, ask them about the pros and cons. The key here is about making a informed decision and not rush things through. Remember you are the one that is going to make the final decision, and accepting all the good and bad that follows. So please think it through, if still not sure after contemplating and scrutiny, park it and come back to it after some time.

While these are all good and happy news from purely software developing point of view, the software testing community has been largely left behind and been abscent as the modeling standard was developed. Accounting sometimes as much as 40% of the total development cost, software testing has became increasingly significant within the modern SDLC. It seems to me that the UML has been developed to mainly accommodate the requirements on the development side of software project. However, because the software testing has evolved into such an integral part of SDLC, it plays a vital role in the entire project delivery cycle, and the fact that UML was born to make building complex software easier, there is really no reason why the UML can’t be extend/used to assist with software testing practice.

For the majority, the benefits of the UML also applies to software testing:

• Standard approach documenting test artifacts.
• Test design can easily be understood.
• Allowing greater tracability.
• Enables ease of maintenance by providing more effective visual representation.
• Provids a vehicle for effective communication and reducing mis-understanding.

For example, a Use Case Diagram is the technique used by Business Analyst and Architects to capture the requirements of a system. Equally such technique can be used by testers to do functional test planning. Sequence and Collabration Diagram show a time-based flow of messages between objects. This technique is really useful in designing test scripts, where the sequence of event flow is very important, as well as the input and response.

Personally, I found ad-hoc testing can be a bit handful sometimes. More often than not, what the ad-hot testing achieved at the end didn’t really meet the basic objectives from testing point of view, in some circumstances, it could even ended up with lots test scripts produced, but adding very little or even no value to the business. I have to say, I always became frustrated when that happens.

Throughout the ad-hoc testing that I worked over the years, I found the following areas to be particularly challenging.

• Very limited budget. Budget is always limited, unfortunately, testing is probably the last thing that’s on PM’s mind, this inevitably leads to even more reduced budget. Limited budget always directly translates to poor testing quality.
• No visibility to the long-term plan. Because testers were rushed in at the last-minute, kind like fire fighters, they were only able to see what’s in front of them and get those done. This is useful in the short run as it directly saves the PM’s backend, however, in the long run, this approach is not going to be sustainable, and will fail to work when the testing effort became too large to handle in just a few days of effort.
• Unrealistically aggressive deadline. There is nothing wrong with aggressive deadline, but if it’s unrealistic, there is going to be problems. Trying to squeeze a 4 weeks testing job into 1.5 weeks is just not going to happen. It puts a lot pressure to the testing team to meet the deadline, there is only 1 thing testers can do when under deadline pressure, that’s to reduce the testing quality.

The unfortunate thing is that we can’t really avoid ad-hoc testing, as they generates revenue to the organisation, they brings possibilities of more big contracts in future and they fill those non-chargable work slots very nicely. So I personally found some ways to help me work easier with ad-hoc testing engagements.

• Act fast, as soon as you become assigned to a testing work that even vaguely looks like an ad-hoc testing, start auctioning on it.
• Be proactive, PMs, BAs, Solution Architects are always busy, especially when the project has reached a point where they need testers to be involved (a sure sign when project didn’t go as planned), be proactive, ask all the questions you need to, because if you don’t, it will become your fault.
• Have a plan, because you only have very limited time to work with, the key is to produce a plan and get everyone agreed on it. This essentially serve 2 purposes, to keep you focused on what needs to be done, and cover your backend if things went the wrong direction. So do your planning, and get key stakeholders agreed on it.
• Focus, it is important that you focus on what’s been agreed, don’t get distracted by other things you found in the project, if it’s something that you think should be covered, don’t do it without approval from the project.
• Communication, frequent updates are always welcome to keep everyone in the loop, and reduces the chances of you doing wrong things.
• Prioritise, you will not be able to test everything, so plan your test, assign a priority to each test scenario or test case if it’s possible, then start from the ones with the highest priority. This is a good technique the most in least time.

Please note this list only represents my view plus some input from others. It is by no means complete.

- Correctness. If a test case is not correct, it not only does nothing to adding value to the product, but also runs into the danger of missing genuine defects and wasting project resources. To certain extent, incorrect test is even worse than no test at all.

- Repeatability. If a test can’t be repeatable, it has very limited value in terms of help developer to isolate the defect and be re-usable in the future testing practice. There are certain tests that are not easily repeatable, in this instance the  detailed steps and enough description should be added to aid execution of the test case.

- Tractability. This attribute is important as it provides visibility to testers and managers, enable them to understand several key factor.

• Assessessing testing coverage.
• Monitoring testing progress in terms of requirements covered.
• Understanding business impact when setting priority

- Be SCC. SCC is short for Short Clear and Concise. Just like many other profession writing test case is a science at the same time an art. There is a delicate balance between enough detail and too much detail. The goal is to only write what the tester needs to know in order to execute, the amount of detail should be carefully controlled not to overwhelm.

- Up-to-date. If a test case was correct at the time of writing, it may not be correct after several release of the system, unless it’s been timely updated of course. It’s vitally important to keep all the testing artefacts up-to-date, among them test cases are the most important as they directly impact the testing practice and its outcome.

- Efficient. Efficiency can mean different things in different context. In this particular instance, efficiency is more to do with the time to execute a particular test vs number of defect found. It can be view as ROI. One thing to note though, do not ever sacrifice simplicity for efficiency. I have seen a number of test cases that are so efficient in terms of execution, but it’s a nightmare when checking the expected result, because it’s just too complex to do.

- Relevant. A test case need to have strong relevancy to a particular use case or requirement. In another word, it must have a clear objective about what it is trying to achieve/test.

Of course, you will have your view on what matters when it comes to being a good test case. Do let me know through the comment.

Check 4: Access

By Access, I didn’t mean the MS database software, but rather, the access to tools, environments, resources, etc. Every project has its own resource repository, which is often made up of tools, network shares, specific web servers, databases. All of these are there to serve the need to deliver the project. This means for every entrant to the project, that person must be setup so the access to these resources becomes possible. I specifically put this as a separate section, because getting access to a particular resource often causes significantly delays that the person unable to be productive and impacts the project progress.

As the saying goes, it’s better to be safe than sorry, I personally think it’s better to be early than sorry. So as early as possible, you should get a list of things that you must have access to in order to continue progressing the project. Often won’t know what you need until you start using it, therefore it’s a good idea to set up reverent applications on your workstation and start using them. On my work, I often check this list:

• Install defect tracking tool, if it’s web-based, asking for access to be granted.
• If applicable, install database tool, and trying to access relevant databases.
• If applicable, install the development tool, and access the relevant code repository.

Also, from time to time, a well organised project has its own document management system, like MS Sharepoint, or something that’s based on network share structure. You will also need access to these resources in order to view, and update them. So I would also check:

• If there is Sharepoint-like site used by the project, ask the site admin for access, make sure you ask for correct site privileges.
• If documents are stored on a network share, be sure to ask access to that location too.

Project manager is always the person to ask for access, even if project manager can’t do it, they can point you to the right person.

Last but not least, some large corporate organisation uses specific timesheeting code to track project budget and staff utilisation, this means the time that you spend on the project must be recorded against the project. You always ask project manager for this. If you are working inside small organisation, this doesn’t always apply to you.

Check 3: Understand Testing Requirements

This section is about trying to understand what the test requirements are. The task sounds simple, but it’s actually not all that easy as it may seems. Testing requirements often include several parts. There are business requirements, functional requirements and non-functional requirements. It is vitally important to understand each set of requirements in order to run effective testing against the targeted solution.

The step 1 is to get a full list of requirements that are within the test scope. It is important to note that not all requirements from requirements document will be included as part of testing exercise, this could be due to a number of reasons, e.g. budget constraints, priority considerations, etc. It’s always a good idea to start from a test plan or test strategy document, where it clearly identifies inclusion requirements for the project. Remember not to be distracted by requirements that’s outside the test scope despite the fact that they have been listed in requirement documents. The focus is the existing test plan or test strategy, if you are really in doubt about a particular requirement not included in scope, do take that to the testing manager.

The step 2 is to understand the relationship between the business/function requirements and testing requirements. Personally to me, business requirements are the requirements at the highest abstraction level, they defines what the business user wants the solution to do in order to fulfill the business needs, they are often vague and not detailed enough to enable testing. Functional requirements are 1 level down the abstraction chain, it outlines requirements from technical relisation point of view for the solution. Once business and function requirements have been identified as in scope for testing, they become testing requirement. Understanding how a testing requirement links back to its function requirement and business requirement is key to ensure good test coverage. I sometimes found it difficult to understand other’s test cases, I can always get pass this by trying to understand what the function and business the test covers, as these clues tell me what the test is trying to achieve.

The step 3 is to read through the testing approaches adopted by the project. This gives you an idea how to implement test cases, and making sure it fits with the overall SDLC of the project.

The goal of this exercise is to understand what the testing requirements are, how do they support the business and functoin requirements. Another thing is to get a feeling of how to design tests that fit with the standard testing approach to ensure consistency across all levels of SDLC while meeting the test requirement.

Check 2: Understand the Product and Solution
By solution, I really meant the item that is the target of this testing project, depending on the audience and the deliverable nature, Product and Solution is often used interchangeably. Personally, to me, a product is a system that has already in service in production environment whereas a solution is what the project is trying to achieve and will be delivered to production environment if the project completes successfully. In rare cases where you get lucky, which you often don’t, you get to work on a project that had no previous dependencies or history, it’s a brand new project. This is the best you could hope for, as it gives you the opportunity to get involved from the beginning, allowing  you to learn from the moment you start.

However, in the real world, you are more likely to be working on migration, updates or enhancements to existing product, in which case, you must learn what has already been built and the stuff that is going to be built as part of the solution. Quite often, the existing product is very complex, it could be a multi-tier application that spans across several data sources and several geo locations, it can be very daunting for new entrants.

When it comes to understanding it, there is no better place to start than the project manager. This role oversees the entire project life-cycle, from its inception phase right through to its closure. A project manager is very unlikely to give answer to a specific question, but they can always point you to the right people who is able to answer that question. Personally, whenever I start on a new project, I always ask the 1st question to project manager “I need to understand this product from high level, who do I ask?”.

More often than not, it is the solution architect that helping you understand the product. Try book a meeting room if possible just between you and the solution architect, take the opportunity to get introduced to the product. Don’t focus too much on the low-level detail as it is often irrelevant to what you will be doing, it is the big picture that you are interested. I found it is sometimes very helpful by answering questions like:

• What is the objective of this product, from functional point of view and from business point of view.
• What are the major components within the product scope, e.g. databases, middleware, main processing layer.
• What are the external applications that interface with the product.
• What about the previous testing history for the product.
• The good, the bad and the ugly.
• A walk-through of a typical processing flow, if it’s a transaction system, it could be a transaction processing, if it’s a web site, it could be a user registration process.

So the goal of this exercise is to understand the product as much as possible, the trick is not to be burdened by the details, concentrating on the big picture is the key. I personally found a useful exercise, is to try to describe the product, its brief history, its reason to exist, its imprefections, its beauty, etc etc, to another colleague and see if they can understand it, because if I can explain this to another person, that means I have understood it well.

Once you think you have understood the product, you need to think about doing the same thing solution. Remember a solution is what the project is trying to deliver, in other words, it is the target that you will be testing against. I personally would spend more time with the relevant people on understanding the solution. Similar to understand the product, I would ask these questions:

• What is the objective of this solution, from functional point of view and from business point of view. Note the solution is specific to the project, it is what the project will deliver at the end, whereas the product is what is already in production.
• External applications that interfacing with the solution.
• The good, the bad and the ugly.
• A walk-through of a typical processing flow, this time will be a demonstration of how the proposed solution functions.

As opposed to understand the product, you will need to go several layers down when it comes to understanding the solution, it is important that you keep a good balance between levels of detail and time spent. I personally found understand everything in the Solution Design document is often sufficient for what I need to do. If you have more time available, you could read Technical Design too.

The documents that read to understand the product and solution:

• Business Requirements
• Functional Requirements
• Solution Design
• Technical Design

Check 1: Know the important people and their role.
Depending on the nature and size of the project, there can be from 3 to 6 people working on the same project. It is important to know each of their roles, and their areas of expertise, so that when you are looking for help, you will know who to ask for. Personally, I would keep these people in mind and their contact details handy while working on the project.

Project Manager, this role looks after all aspects of the project and providing general guidance and governance to ensure the project progress as planned, more importantly meeting its deadline within budget.

Test Manager, you will directly interact with this role, seeking for help, advice, reporting progress, etc. You should pay extra attention to keep this person informed about  testing progress, updates, issues etc. In case of an unexpected event, this person should be the 1st one to contact.

Solution Architect, answers questions related to the solution under testing. If you have question related to how the solution works and its functional behaviour, solution architect would be the best bet. Solution Architect won’t necessarily know the implementation details as they are only focusing on the large picture, i.e. the solution and if any, its interactions with external applications.

Business Analysts, they are able to give you an overview of the solution from business point of view. They won’t be able to tell you how a particular business requirement is implemented within the solution, but they can tell you how the solution should behave to meet the business requirement.

Developers, they are the people realise the implementation, they know exactly what has been coded, if the questions is very detailed and specific, they are usually the person to ask. Be aware that there are often more than 1 developer working on the same project, it’s important to know where their respective focuses are.

Database Administrator, DBA role often is often the same person who takes the Developer role. As the name applies, they look solely look after database, so for anything database related, be it database setup, security, or schema related, DBA is the one to ask.

Support Team, this team is often found for large scale projects where the environment is too complex has too be looked after by a dedicated team due to its complexity and high business impact. They are people to go to when you need help with environment related problems, this could be for things like accessing to a particular application, needing help to setup integration between applications.

Business Representative, this role is rather inclusive, they can came from power-user of the targeted application, they can also be the subset of final business user. In nutshell, they are the group of people who will be the end user of the proposed solution. BRs are a very useful bunch of people as they can give great insight as to how a particular solution will be used when it is rolled out. Quite often, a functionally correct product is not necessary meeting all of its business requirements. BRs can give direct advice to help discover these potential defects that would be otherwise left unchecked.

It is a good idea to proactively communicating with the Project Manager and Testing Manager with testing updates, so that the managers stay in the loop and not be faced with any nasty surprises. There is the possibility that not all of these roles will be available, for example, you won’t find Support Team in small project. Also sometimes 1 person may take multiple roles, e.g. a Developer may be a DBA at the same time.

At the end , you must know who is involved in the same project as you, what they are doing, what their contact details are and what their office hours are. This ensures you to become part of the team, and not working as an one man band.