A discussion has just come up today on the testers.chat slack channel about using planning poker to estimate for stories.
It started with “In planning poker, do we estimate our own work or everybody else’s work?”
I’ve written about this with @melthetester in our games in testing article series. I personally feel that there should be a shared understanding of the task to be undertaken so that there is an idea across the board of the amount of dev & test effort that will go in to a story.
I thi…

@techgirl1908 recently spoke at TestBash Philly about “How to Get Automation Included in Your Definition of Done”.
@satya followed up with a blog post about the talk
I stuck on this paragraph:
Coming up a commonly agreed up on definition of done is quite hard and each stakeholder has different perspective. At the outset it seems quite obvious and achievable but software development is complex and there are many exceptions and context of each story matters.
In my own context I’ve had 2 …

If we didn’t get to your questions tonight or you’d like to continue the conversation, why not ask them here?

out of curiosity @heather_reid what about my post did the class remind you of?

As far as the agile way, most companies forget that agile is a set of tools that can be used as templates and that those agile templates should be honed to work for the organizations purpose. Often times agile to a company from the top down means doing more with less, and for a testers from the bottom up it means doing more with even less. Its a shifting of the expectations on QA and what they should be handling. That is why we see such a wide variety of titles for QA engineers. its a facility of agile methodologies and where the buck once passed lay.

Preventing this is a difficult thing and what is possible is based on how QA is seen in an org and their power to affect change. Often times QA even with power can only suggest changes. But i feel like data driven insights helps a lot fo companies understand the pain points as seen through QA’s and ultimately the end users eyes. We can test immediately, we can shift our focus from intense up front planning to more targeted feature I/O testing modified by swarm testing if a general user base is available internally to help, but often times the company then starts to wonder where documentation went, why high profile hotfix bugs are found in the wild. I find doing reporting on how many bugs are found during development and on production and severity as a rubric against time QA had to test the software as a helpful indicator of how quality is being formed implicitly by the actions of an agile happy culture. This takes the burden of wrongdoing off anyone person or group and allows it to be shifted towards the processes employed.

For instance if agile forces QA people to end load their testing instead of beign able to test up front or throughout the lifecycle of the development, then the code in a completed state will have less time to be put through its paces. this speed of rapid development and subsequent production bugs should not reflect badly on QA but rather be seen as a cost of the speed and added into any risk assessments QA makes during planning. Often times the best way to make a change is to suggest in planning meetings that QA timelines will be impacted which affects overall risk of release. Getting a sign off on that reality and making a plan that maximizes the time and quantifies risks that can be known. that coupled with the tear down of the sprint and bugs found helps to adjust agile behavior and thinking to become something truely agile.