For our sixteenth session of TestBash Home 2021, @testervenkat takes to the stage to talk about how to provide leadership while participating in team discussions.
Weâll use this Club thread to share resources mentioned during the session and answer any questions we donât get to during the live session.
Code Complete by Steve McConnell:
1. Do you have any tips where management flat out refuse to include test leaders in requirement gatherings?
Quite possible that this could happen, and letâs acknowledge that. Itâs in the best interest of the product quality that we ask the management to include test leaders in the requirements gatherings. So, test can try to convince the management regarding the same using rationale, data, and common sense. But if the management still does not listen, there are other avenues - when the development bring the requirements for internal review, or when the requirements get quoted in the functional specifications to initiate product development, etc., at which time test can raise the issues in the requirements.
The earlier the best, to find issues through the eyes of a test leader, in order to save time and effort.
** 2. Do you see the future of testing being a move more towards a BA kind of sphere?**
Future of testing wonât be just in the BA sphere, but in all stages of software production, and it should be. Depending on the development model being used, it may or may not be called as âtestingâ, but sure, testers and test leaders would be involved in all stages. This has been the case even many years back, but not sure when the disconnect happened and testers are boxed out just to handle âmanualâ/âexploratoryâ testing, and automation.
** 3. How many test leads would you have in a project/team to be able to get through all these activities?**
It depends on the amount of work load each test lead has taken up, and the capabilities of that test lead.
If thereâs a position called âTest Architectâ or a âTest Technologistâ, who focuses on business and technology aspects, that would bring down the work load of âtest leadsâ who can focus on project management and operations aspects of day-to-day testing.
** 4. In an agile development process, are requirement errors unavoidable and not too bad because of the iterative process?**
Iterative process is good in order to support customer and business needs, but the customer has to be sensitized on the consequences of changes. There wonât be any âAgile Leadershipâ, if the product is being pushed and pulled in many directions due to volatile requirements. A test leader (as mentioned in my talk) should make the product owner and the business aware of the time, resources, budget consequences of every change in requirements, and push back the change when it is not justified for the sake of good business.
Requirement âerrorsâ is a completely different matter, which should be prevented totally, agile or not.
** 5. How to avoid of miscommunication?**
In my experience while talking to business leaders, I use a standard template or a system to collect facts and figures. This is based on the âfocus areasâ that I talked about, and before any meeting with stakeholders, I keep the template ready on what questions to ask and what data to collect. Recording, making and sharing meeting minutes, etc., will make sure that there is no errors because of miscommunication. If thereâs any discrepancy, we can always go back to the business and ask for clarification.
** 6. How do you get a business to buy into the need for traceability of requirements when they want everything done at speed?**
I donât understand how traceability would reduce speed. Traceability is an internal process of the product team to make sure that all requirements are met end-to-end. Why would business have any objections to that. In fact, they have to celebrate the fact that we are trying to build quality using traceability. If they donât get it, we should explain the benefits to them.
** 7. How can you promote better engagement of team members in requirements meetings?**
The best way I have seen this to be done is to bring a strong sense of ownership of the product to all team members. All team members should feel included and valued. If this is ensured, participation and engagement automatically follows.
** 8. How much time should you spend in the requirements stage?**
Itâs unfortunate that requirements analysis is branded as just âtime waste review meetingsâ. Given the volume of defects that we find earliest (âMost Left Shiftâ) and issues that we can avoid, I think we should spend considerable time before we even get to action on design and code. If 50-65% of defects are found in requirements stage, how much do you think we should spend on requirements stage?
9. Can all requirements be made explicit?
We should try to make them explicit because all team members need to know the facts and figures, and there should be no misunderstandings and assumptions while designing and coding. Keep in mind that team members come and leave, and if something is not specified and documented, it is left to anyoneâs imagination or assumption. If there are things that are âimplicitâ, make them explicit by clearly stating them in the requirements document.
Just want to answer point of number 1. â 1. Do you have any tips where management flat out refuse to include test leaders in requirement gatherings?â
We can propose a metrics driven approach to compare and show the benefit/value add of involving test leaders in requirement gathering. To elaborate, if we maintain metrics such as design defect density, code defect density, schedule variance, TDCE etc and compare with releases where testing team wasnât involved during requirement gathering. Now the question is how do the above parameters improve. Test leaders are equipped with previous release defect RCAs, conflicts that occurred during test execution where business was involved and change requests were triggered. Knowledge sharing from learnings, best practice, pareto analysis from previous release and conducting testability would definitely improve the above mentioned metrics. And once the numbers/metrics shows the benefit, involving test leaders in requirement gathering will become a mandate 