What to do if the team has no processes at all?
In this article, we look at what to do if the team has no processes at all?
In big organizations, a formal visible process is followed. In smaller teams and organizations, an informal process might exist. People may work with some understanding between themselves of how various activities flow into each other.
A project is a series of activities that will achieve a definite goal. A process is how this is achieved. An optimized process is one that reduces or removes re-work. Getting it right the first time is the aim! When a set of activities are repeated time and again, one begins to understand what went wrong in the previous projects and how this can be remedied in the next project. Mastery/expertise over coding and testing, understanding industry best practices, learning from previous mistakes and common sense lead to a clear process over time.
What we say as process, therefore, comes down to a series of checks to reduce rework, ambiguity, confusion and hence the bottom line. It ultimately translates to $$$!
For a tester to do his or her work optimally, a few musts are:
1. A properly version-ed build – without a proper build, defects cannot be tied down. They cannot be reproduced and hence fixed.
2. A clean, reproducible test bed or environment which is as close to the Production environment as can be.
3. A build is accepted for testing only after the agreed upon ‘Sanity Tests’ have passed.
4. A clear definition of the scope of testing for every cycle – both the breadth and depth
5. A Clear defect cycle
6. Review of test plan and test cases and prioritization of tests based on complexity and risks – agreed with BA and Development team
7. A clear start and end of test cycles
8. Checking the back end database during System testing
9. Some amount of Performance and Load included during System Testing
10. Highlighting the defects and work-around in case the product needs to go out during the test phase
11. Insisting developers do Unit, Module and Integration testing before QA drop off and reading the Test reports from Development to prioritize testing.
12. Buy-in from stakeholders- BA, Development Team
13. Reviews of the various Project artifacts for missing, ambiguous requirements.
