Challenges of a tester in software product development
Sowmya Sridharamurthy
Enabling engineering teams deliver value at scale |??International keynote speaker |?? writer | ? Accessibility Advocate |
An obvious fact known that testing plays a vital role ensuring a quality product is released out of software development process. A theoretical survey would have the highest votes agreeing this, however in all its genuineness, its considered the least prominent activity or rather considered one of the easiest and less stressful activity.
Having said that we cannot hypothesize the scenario is same everywhere. By and large majority of testing/quality colleagues would agree with the below points.
1) Dead specification document -Oh! yes, we are talking about that bible of software development process. This tops the chart, I am sure majority of test colleagues out there would agree that having a dead specification document would have led them to many chaos during test phase/s. They would trust on every word mentioned in this document during development and testing. The beauty of agile methodologies is flexibility that it provides towards requirement changes during development (percentage of change depends on company and project) however the same boon can transform into a bane when the traceability of changes is not updated in the document. Usually these specification documents lie in project folders (or configuration management tools) without its recent updates for long.
Not so seldom a product owner/functional expert would discuss with developers offline for any changes during coffee corners / water cooler chats or at their respective workstation. It would have happened completely unintentional (many times in a view of improvement) and unaware of further impacts. Things will still go smooth, provided respective test team is updated about the changes. Often these changes may go missing and when the product lands to test phase there is a lot of chaos, as most times, the actual will never be in line to the expected planned results.
2) System availability: System/ environments play a major role specially in test phase. The product just cannot be installed and tested in any environment. It needs to be seasoned with necessary data. When the test timelines are declared its necessary that testing team is equipped with all required tools for testing. Thick and fast the system set up should be done before the actual functionality is tested. But test colleagues would just lose their time in waiting for an appropriate environment to be ready, the result; testing is just a pell-mell.
3) Belongingness: It’s not an exaggeration if I say testers are a neglected lot and least counted in any development team. The significance and importance that a developer gets in a team is paramount. Yes !! testers do feel betrayed when they are not involved in important discussions, gatherings or in meetings, after all everyone is working for the product success and the ones who ensure the best product is released.
4) “It’s more technical” – wondering why this would come as a standard answer? When there is a “why” from any tester there comes a standard answer “it’s more technical may not be relevant for you”, “it’s on technical side probably it may not be of your interest”. Why is any technical answer may be of any interest to a tester? Yes, test colleagues may not be as technically sound as developer and need not be but any technically rich talk would eventually make testers much more zealous in their task.