Friday, December 19, 2008

2008 Survey results - Software quality issues due to variable level of skills between locations

"...communication and collaboration was still the dominant challenge in distributed development with more than 85% respondents mentioning it, the surprise second, as per the survey, was software quality issues arising from too much variation in skill sets between sites" (see http://www.infoq.com/news/2008/12/distributed-development-quality for more information).
This was one of the conclusions from the survey (September 2008) described in the attached link, but the top identified issues are practically the same, even if some changes have occur in the hierarchy
- General communication and collaboration challenges
- Software quality issues due to variable level of skills between locations
- Political issues with the way organization is structured
- Quality concerns due to difference in processes/practices
- Project management issues caused by complexities of distributed development

Tuesday, December 2, 2008

Informal reviews - the inexpensive way to get benefits

An informal review is always the best solution when you want to avoid too many corrections from the formal reviewers or to decrease the number of obvious mistakes you've done. And it is quite easy: you have to go to one of your team colleagues and kindly ask him to review your work. The informal reviews are also very useful for the junior software testers since their confidence and experience is low, so they need help from the experienced colleagues (especially senior testers or programmers) to quickly review their work and to identify the aspects which don't make sense, which need to be improved or better described, etc. .
The informal review is not a formal process, it may be documented if the reviewers consider it necessary (the material may be as informal as a computer listing or hand-written documentation), is the most inexpensive way to get benefits and the date and the time of the agenda for it will not be addressed in the project plan.

Depending of the nature of the review, the tester can ask the informal review also from a programmer and not only from someone within the testing team ( senior testers or technical leads are
especially recommended for this, because they have the requisite technical or business expertise).
If you are a programmer you should be performing informal code reviews or having a colleague developer perform an informal code review to catch some of the smaller mistakes that are commonly made. A number of techniques are available for doing this, for example, use a parameter or constant in the code as a switch to display all parameters and/or print them to a log file. Become aware of what causes errors in program code and how errors can be detected and prevented. Also, learn to make the functionality understandable by using adequate comments.
One more important thing for the informal reviewer : critically reading the work of another software tester/programmer enables you to become more able to identify, diagnose, and solve some of your own issues.


Monday, December 1, 2008

Review process

"Review" is one of the key words when talking about the software testing. The reviews should not be necessarily carried out by the testers, but by the people to whom the project manager will assign this task (especially by the quality assurance department, if this exists within the company) .
We can review a lot of aspects during the software development life cycle: development and design documentation, test plans, test cases, test results, defects, tests and development metrics, etc.
Even if we are doing informal, walkthrough, technical or inspections reviews (I'll try to detail each of these types in the next posts) it is important to distinguish between the factors which make a review to be successfull or not.
We need to make sure the right people are involved for the review objectives, the review's objective is clear for all participants, each issue found is expressed objectively without affecting the author (it has to be a constructive action and not a "witch hunt"), we use checklists in order to be more effective in identifying the issues, adequate time for reviews are allocated in the project shedules, etc.
In case that the responsibilities are not taken seriously or understood, the allocated resources are insufficient or the processes to support reviews are insufficient (or don't exist) then we can talk about unsuccessfull reviews.
Only by reviews we can make sure that the system specifications/requirements are correct and important faults are found before coding has started.