You have the power to implement one thing across your team, what is it?
I will kick things off. I would consign Test Cases/Test Scripts to the bin. They are antiquated, they offer only a snapshot of someone else experience of the software and they go out of date. Focus more on Exploratory methods, that encourage, support the tester in their testing. These methods allow the tester to tell the story for the software in a more of the moment, rather basing it some past biases.
I would shift the responsibility of creating the test strategy from our Product Owner to the QA department. I think it was only constructed that way because one of our PO’s was previously in QA and has more experience creating test strategies, but I think this is a big miss in the growth opportunity and overall quality of our QA department.
We have been wrestling with this concept recently too. It’s a tough nut to crack! On the one hand, we hope to have the ability of handing off test cases either to developers or other QA staff to be able to guide others in testing, or provide a way for secondary/new staff to able to aid in testing without needing to completely ramp up on the context for a project. We are also looking to provide tests/test cases a deliverable to our clients for some confidence/transparency into the quality of the product. I have mixed feelings on this by itself, but can understand the greater good.
On the other hand, I agree that it’s cumbersome to write out test cases and they evolve/expand pretty frequently, making them a burden to maintain. While I am all for some level of documentation for what is being tested and how, I am struggle to follow a strict construct most of the time.
Do you think test cases vs no test cases is somewhat subject to your individual preferences as a tester?
I am moving towards championing Test Charters and from them you can derive the results of your exploratory testing. This would give you the transparency as you would share these with not just the dev’s but with the Stakeholders.
The newly elected Test Dictator stepped up to the microphone. She gazed across the sea of faces and smiled. Finally, business and IT were represented by not only project team members on both sides but their stakeholders and the stakeholder’s managers. The Testing Dictator, herself once a Tester in the trenches, campaigned on unity and purpose. Her leadership demonstrated over many projects and recognized by many project managers, this day validated her energy, tenacity, technical prowess, and collaborative mindset.
She refused to stay on one side of any wall by openly, politely, and respectfully questioning assumptions and biases at the start of a project. Her peers were both concerned and hopeful. They remember “The Experiment” she defined. “Give me one small project and one month,” she requested. While that experiment required two months, the people in The Experiment were happy. The product was solid.
“Give me a medium project and three months,” she requested. Her peers and others in the department thought it a brazen stunt. While that experiment required four months, the number of people who experienced the methods of getting stuff done grew as did her influence. With attention on her, others asked how could one person move these projects through successfully? We must stop experimenting and give her a real test. She liked that; she did testing best.
A large re-architecture of the four most used workflows on the company website was scheduled. “Give me one month to train and four months to complete the project.” When the project elevated six months later, she rode on its coattails to the position of Test Dictator.
“Greetings everyone! Thank you for this position!” she started. “I speak to you today in this position because you believed in an idea. You believed we could deliver better products, believed we could collaborate, and believed testing could lead a large project to a successful conclusion.” The crowd cheered.
“We have entered a new phase of product delivery. We have unleashed methods, ideas, and mindsets to make possible a shining future for our company.” The crowd cheered.
“Today, I have made two requests.” The crowd laughed knowingly. “First, new projects starting over the next four years will be defined so they complete in less than four months. We will embrace the feedback from our customers and from you to make every project better.” The crowd cheered.
“Second,” she said as the crowd hushed, “I refuse the title of Test Dictator and refuse to lead you alone.” There was a noise of hushed confusion.
“Rather, I will be known as the High Sovereign of Test and have chosen others to help guide us. As a group, we will rotate others into positions of this leadership to provide a diversity of new thinking. Together, we will use testing for the good of the company, to overcome our challenges, and to be proud of our accomplishments!”
The crowd cheered. With the final word of her speech, fireworks started, and champagne was served to everyone.
I would make the product owner responsible for chairing the defect triage meetings.
(hush falls over the room)
Some of the product owners I have worked with have been fantastic in bug meetings. They can spot what is real and what is waste of time.