System is soon to be opened for the world, yet quality still is poor.
There is no one part of the system we could say "it works".
As a tester, I feel it's my duty to improve overall quality.
Overloaded team
The team seems to overloaded with jira tasks. There are three kinds of them:* totally new features (agreed upon with our client, and paid for)
* bug fixes
* improvements to existing features
Current development mode could be summarised by: "develop new features, and we'll get back to bugs later".
My first approach (after high eyebrow rise and some breathing exersises to calm myself) was: "Let's not break the system - please let's have overall quality as a first goal". This was rejected by the team.
Mainly because the project would be a political failure, should we fail to deliver 100% of requested functionality. I asked several times whether 100% functionality must work, and it seemed that "it should" :-)
Getting parts of the system done
Today I proposed another approach. When developer changes part of the system (a screen, or a process), he/she should:* read the specification (official document detailing the way system works, the design) and make sure that particular system feature works exactly as describet
* look at jira issues, find and resolve all of task that are related to given feature/screen/process
After that, no improvements or changes are allowed. That particular feature is finished. Sure, there might be bugs, but no changes are allowed.
This way, we could get small, but importand quality improvements with each new system version (every 2 days). This way, the system would finally work properly someday.
This is only a change of view
Developers still have the same amount of work to be done. But my approach fixed the "context switch" problem and, even more importantly, leaves a feeling of job being done. Some parts of the system may now be ticked as done.The team gets visibly closer and closer to the final goal.
My hope is that this method gets accepted...
No comments:
Post a Comment