Becoming a contract test consultant – part 1

Due to some changes in my personal circumstances, I have recently decided to move into contracting from being a permanent employee. My experience with working as a contractor is literally next to zero, this has certainly become a very significant transition stage in my professional career, and will undoubtedly influence my career choice in the next 5 to 10 years of my life.

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.

Apply UML in Softare Testing practice

UML – Unified Modeling Language has been around for years, since its inception, it has received mixed feedbacks from both industries and the software development community. It provides a simple, common and graphical representation of software design and implementation. By providing flexible ways to build abstractions across many levels, developers architects and experienced users are able to discuss the details of the softeware product.

Ad-hoc testing in a vendor environment

Ad-hoc testing in a vendor environment
I am sure we all get this, ad-hoc testing. The definition is simple, if the testing was not properly planned, scoped and resourced, and it just happened after a conversation from a meeting or over the phone, it’s mostly like an ad-hoc testing. Like it or not, this is often what tests will have to face in their daily practices, it is even more of a case when you working inside a vendor environment, where testing engadgements are likely to strike in small chunk and with very little or no early indication of its arrival.

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.

What is a good test case?

What is a good test case? I have asked the same question on a number of popular places where testing professional usually gather. The answer really seem to depend on the person’s background, industry, experience level and project’s nature. I summarised the main points in to the following points, hopefully it will be useful to others.

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.

Tester’s checklist for working on a new testing project – check 4

By now, you should have become somewhat familiar with the project. You understand the product and the solution at high level, you know all the business and function requirements, you follows the testing approach in designing your own tests. This section will look at other areas that also have strong influences.

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.