About Software Testing

Starting a new contract

As a contractor I got the chance to work on many projects – small, medium, or large. This is what I like the most of being a contractor, I never get bored of an application, of the people I work with and if I start to get bored it means that it’s time to move on.

I always liked testing. For me testing is not just a job. You could find me on a Saturday night reading a book about testing and I have to say that I really enjoy finding out stuff that I can apply in my job. I’m always trying to improve and see how other people do it, get new ideas.

After six years of contracting I got to a point where I can teach others about testing.
Starting a new contract can be daunting and highly emotional for many people, they don’t know where to start or how it’s going to be. Contracting is like lottery: you win if you get to a place where people know what they’re talking about when it comes to testing, or you lose if you end up in a lousy place where people do sloppy testing.

Every time I start a new contract I have a few things that I first look at:

If I join the project in the beginning of the life cycle I first look at requirements and functional specs. That tells me how well the company understands testing. Any good project manager or good test lead knows that testing starts with good requirements and they’re going to push for it.

If I join the project in the testing phase I tend to look first to the test cases written by other peers. This gives me an idea about the seniority and skills of my colleagues. I can also identify gaps in tested functionality based on what those test cases validate.

Then I look at the defects that are logged, either in a previous testing release or in the current release. This gives me a very good idea about the functionality of the application and also how good of a job people in the team do to log defects properly – with a detailed description and screenshots of the problem described. I think this is one of the best ways to quickly learn an application.

Defects should have all this info: when was the defect logged, who logged it, what’s the history of the defect, who was assigned to, who fixed it, who re-tested it, what was the result. If they don’t, people need to learn on how to log, track, and report defects.

Three things that are super important from a QA perspective are:
Keep track of test execution – writing test cases is not enough, you have to track them when you execute them. “Tracking” means marking each one of them with passed or failed, and also writing the corresponding defect number if the test case failed.
Keep an up-to-date defect log – if it’s not up-to-date there is no point in even having it. People tend to “forget” about defects towards the end of the testing cycle.
Report on your test execution in very detail – what functionality you’ve tested, how many defects were logged, how many were fixed, how many test cases you’ve run, how many passed, and so on. You always need these statistics; it’s good to have something to refer back to or to start preparing testing for next phase.

…A quote from an article I just read: “It’s important what you test, not how much you test”. Test intelligently, don’t just test.