Ideally, testers would be involved with the system under development as soon as it reaches the team. Information about what/how to test would be communicated openly within the team, allowing for both the sharing and reviewing of plans, ideas and insights. The manner in which test results should be documented (or not) and shared would also be a priority before any programming takes place. This should then be communicated with other stakeholders. This would create clear expectations and responsibilities and avoid future troubles.
At the company I used to work for, this was sort-of the case. At the very least, this was what was strived for.
This would allow the same amount of work (from a tester) to have more impact and more business value, as it would not only point to possible implementation defects, but help shape both what and how a system was developed.
Halfway through the year, however, I changed jobs. I went from a company with a flagship product to a web agency.
This meant moving from an environment with (somewhat) clearly outlined processes to an environment that leaned mostly on heroic effort.
One of the first things I encountered was a strong division between various disciplines (Front-end, back-end, testing, project-management, sales, etc.) This had the effect that there was a lot of “chucking things over the fence”, instead of actual collaboration. As an effect, testers were usually not involved until the final phase of projects. This in turn lead to a situation where it wasn’t always clear wether or not particular behavior of the system under test was “a feature or a bug”.
It was also very much unclear whom was responsible for what. Especially when obvious defects were uncovered.
These questions usually remained unanswered as effort was only directed at fixing defects.
As testers could not gain a deeper understanding of the system under test, not much remained for them to do but superficially test a system’s UI and logic.
During the months that followed, through a lot of effort, this pattern seemed to gradually change. One of the major changes within the company was that teams were created. As there were not enough proficient testers available to have “a tester per team”, the testers were still somewhat left out of the feedback loop. Communication between the various different “layers” did, however, become slightly more fluent.
This meant that testers became aware of projects that were inbound at a time before they had to start testing. There’s wasn’t much change in the way responsibilities were defined. Test result were mostly communicated through issues and programmers still seemed more irked than thankful for bug reports.
The final state of affairs, sadly, is that testing is still more of an afterthought than integrated part of our development process. There isn’t much space for idea’s surrounding testing as this is mostly deemed something “the customer hasn’t paid for”. The fallacy that programmers are competent enough to test their own (or eachothers) work still prevails. There is intermittent talk of test automation but even something as simple as programmers properly “unit-test” their code is actively avoided. No clear path or plan has been formulated by non-testers as how to create better tested products. The voice of testers within the company is mostly undervalued or ignored.
Murky waters indeed.
Luckily, all is not lost.
Although there is no clear plan amongst “the other disciplines”, there is a plan amongst the testers. Steps are being discussed on how to make sure each team has access to a tester, as early as possible. Part of this plan is to move communication from “formal channels” (like bug-trackers) to low-tech solutions (like post-its). We’re also looking at getting testers involved with sprint demo’s to get an earlier view of what is being developed.
The only real hurdle that we (as a company) have yet to take, is gaining a broader understanding as to why testing adds more business value the products we create.