Last week, I’ve attended a good, interesting conference – Agile Practitioners 2012. One of the sessions was held by Orit Hazzan (An associate professor and head of the Technion’s department of education in technology and science).
I thought to summarize her lecture here for your benefit, adding some notes of myself, as its probably relevant for you, your team and touches an important aspect of software testing.
So, why is it that so many don’t like testing?
There are several reasons for the resentment testing might cause. These reasons can be explained in a few ways, some work-related, some human-behaviour-related.
- Time pressure – Work in general, and projects specifically, usually run under strict time constraints and time pressure. Perhaps they shouldn’t but facts are that they do. Testing, as a seen by many in the organization, slows down the project, holding it from moving forward. Not only that, even those who test, the testers, don’t like being those who prevent us from reaching our milestones/schedules.
- Negative feedback – when working the traditional way, first developing then testing, the process starts with something you build then ends with something negative, need to break the code and re-write it. Testers are bound to give negative feedback to the written code, to developers. Again, no one like to hear and get such bad feedback, and most don’t like being those who deliver it.
- Responsibility – with the develop-then-test methodology, still widely used, those who create the application (developers) are not responsible for checking it works… it is up to others (testers) to do it. This responsibility transfer is unlikely in most other jobs, or even at home :-)
You do it, make sure you do it right.
- Classes at work – developers are a higher class, testers the lower. This simple – sad – truth, should be said loud and clear. Unfortunately, both groups still share this belief in many groups. And who wants to belong to the lower classes? exactly.
- Conflicts – the individual tester is experiencing a conflict doing their work. This is a conflict between the group’s goals and his goals. The group has a project to complete, schedule to meet, budget to stay in. The tester is all about finding problems, issues, where does the project fail and should be stopped until fixed.
- Managing testing is difficult – working the traditional way, with testing located at the end of the line, raises challenges for the QA manager. What to test, when to test, how much time is required and how much time to allocate for each test or group of tests, understanding the requirements and the new developed application/features/code.
Breaking the circle
What can we do to improve the process and find solutions for all these problems? How can we make software testing be more attractive, more accepted?
The answer is found in the description of most of the issues. In most you can see that the separation between the groups of the project – developers, testers (even business people can be counted here) – is a main source for them.
So, let’s get everyone on the same team.
The business people, the analysts, developers and testers. All of them should be in a team, working on a project, or part of it. They should be working together from the beginning, when requirements are discussed, explained and written, through the design, then development and testing.
A collaborative relationship rather than a competitive relationship with a software team will drive better results for all, for the project first.
Call it development driven testing, or any other way you wish, as long as you can see the benefits of such practice and how it can solve the problems in discussion. let’s go back to them and review the new process and how it helps:
- No time pressure – Testing is done continuously, from the first phase, never postponed to the end of a development stretch. It’s done in smaller units, with visible immediate results. Development and testing move forward simultaneously.
- Positive feedback – This is a nice one. In the first case the process always ends with a negative feedback, but with testing done while developing (and fixing) the end result is always success.
Think of code that is written according to an already written test – it is bound to work, and the test will pass. It just can’t otherwise.
- Responsibility – all of the team is now involved in the testing process, writing tests, understanding the tests, and developers are practically executing tests as part of what they do.
- No classes – since not only the testers are testing, the importance of the testing is now higher, developers are part of it, accepting it completely different than before. Working all on the same team, brings more equality, better communication, better understanding of the qualities and challenges of each team member.
- Less conflicts – the individual tester is now part of a group, which is not a testers group only, but a group/team which works to complete a goal of creating a new working code.
- Easier testing management – the QA manager has now more information, from day 1, can better plan the resources, the tests, what’s need to be tested and how.
Miracles happen only in fairy tales, and development projects are defiantly aren’t such…. to accomplish a better project, and with in it, better software testing, managers need to work, and find the best solution which will fit their vision, their organization and their specific project.
Changing the way of work, to the described suggested way above, cannot be lightly done. It takes time, people need to understand it and how it works, and how it will help them.
This involves a new culture in an organization. New procedures and work flows. Some will find it hard to accept maybe, as is with new things brought to an existing environment. Since a basic part of this methodology is based on cooperation managers must find the right way to convince people it’s a good thing. Forcing it will fail the idea itself.
We believe it’s worth the effort.