Have you worked in organisations where new projects are formed by having a week or two long set of meetings to hash out the basics including roles like architects, UX, BAs, PMs but somehow the role of a QA is conveniently not present?
It seems more and more companies are doing this and to top it all off sometimes testers are also unsure what they will do during these phases.
I need a way to convince QAs and possibly other roles that there is value in getting a Quality strategy bang from the start. Have you participated in such inceptions and what value were you able to provide?
2 Likes
Not having QA representation early on is risk to the project. An experienced tester can identify missing requirements, requirements that cannot be verified, and features that present test issues. Consideration of these topics at the start can help avoid disruptive surprises later in the process. Also, in my experience the ownership and commitment of the larger team is improved when the essential roles are represented in planning.
1 Like
Hello @praqriti!
Testing representation at these early meetings can help clarify requirements and review designs for testability. Even after the project is executing, it can benefit from testing representation at requirements reviews (clarity), design reviews (testability), and code reviews (function discovery, testability, unit test coverage).
As a community, we should be responding the question “Why should I have testing representation at this meeting?” with “That is not the question. What you to be thinking is ‘I can’t start this meeting until the testers arrive.’” In my opinion, the way we do that is be demonstrating value in those meetings using some of the ideas above. If you, as a tester, are not part of those meetings, ask the PM to do an experiment and invite you to one or two of those meetings.
Joe
4 Likes
I can’t see any decent reason why there wouldn’t be a QA present. The cost defects theoretically rises at each stage of the process. It will also help you better understand the process within your business. You might be able to mention a defect that you’ve experienced in the past. You might be able to identify a potential risk. You might overhear something that will help inform your testing. As @devtotest says, ask your PM for an invite.
On a slight tangent, we now ask a member of our support team to be present at initial kick off meetings. They are the ones that are at the coal face, and they have a wealth of knowledge and a strong and direct relationship with the customer.
2 Likes
Rather than focus on your reasons for wanting the change, since we should be mostly in agreement anyway, I will focus on the following:
“I need a way to convince…”
My source, in this case, is a study from 1992 by Gary Yukl and Bruce Tracey called “Consequences of Influence Tactics Used With Subordinates, Peers, and the Boss”.
According to the study, in order to influence people, you could use a some of these tactics:
1. Inspirational appeals - “WOW! This is so great!” aka Evangelizing, talking (passionately) about how good something is.
2. Consultation - Asking your team mates for help in convincing the rest of the team. “In your opinion, how could the test team help with the design?”
3. Exchange - The Quid Pro Quo. You scratch my back, I scratch yours.
4. Personal appeals - “Can I ask you a favor?”
5. Rational persuasion - Saying flat out what the benifits are and the cost of not doing it.
6. Coalition - Using allies to help convince someone of your point. “Jan and I both think that…”
7. Legitimating - Using rules and regulations to help with your point.
8. Requesting - Just asking for what you want.
Yukl also adds “pressure” as a motivating tactic, which nobody really recommends because it isn’t very effective, and you need to be coming from a position of power to even attempt it.
Everyone reacts to these influencing tactics differently, so one tactic may not be very effective. The trick is to find out which tactics, in your group, are best (coming from you). Usually, it will be a combination of tactics.
For the question of “how do I get the test team involved in specification and design,” the most effective for me was a combination of consultation, coalition and rational persuasion. (Note: I’m just NOT GOOD at inspirational appeals, every time I try, it turns rational) That is, I let the team know my intent. “I want us to build testability into the product.” I ask team members for their support. I lay out what we might do and how we might accomplish it. In that way, I get the most support from the team, I get good feedback about why it might not work in our context, and the team feels like they are part of the process.
2 Likes
Look at it from the other person’s point of view. A lot of QA feel they should be involved in an inception and they might even argue the point from their perspective. However, the best way to get invited is to sell why you should be invited.
I’d make a list of all the things we expect to come out of an inception. Once you have a good list of outcomes from the inception, think about how you can contribute in ways the other participants cannot.
One example might be:
I expect all stories to be t-shirt size
What is t-shirt sizing? It is one way to estimate effort needed. Often times people are thinking about how to make sure the application does what it is supposed to do. They aren’t accounting for making sure the application doesn’t do what it is not supposed to do. Essentially, things can and do go wrong. You need to factor in handling that.
When I am involved in sizing stories there will be a fair number of times when others might say it is a small or extra small. I’m claim that it is a medium or occasionally a large. I present my reasoning. We throw again and frequently, the average goes up. Or in other words, I have found that I think of things the others don’t typically think of.
Another example, might be that in order for the QA to be effective they will need to understand what they are testing. Being involved in the inception provides the opportunity for the QA to clarify things and have a better understanding. Without having a QA present during inception then there might be assumptions made or questions not asked because QA thing differently than the others on the team.
Now for me, my company puts together different teams for different projects based on who is available. In some cases the BA might have worked as a QA on a previous project. Or the senior developers have worked with enough QA to actually have a good mindset for thinking like a QA and a developer. In those cases, I’m actually not needed in the inception as much as other times. Since the client is paying for the number of people present (we are billable by the hour typically) then they might want to save a little money by not having a QA join the project until after inception.
Bottom line, what do we expect to come out of an inception? Taking the business people who really know what is needed out of production for a week or more is expensive. Someone has already figured out why inceptions are important. You just need to figure out what they believe that outcome is and show how you will contribute significantly.
2 Likes