Lets Talk About Tests, Baby: Recent Episodes
Lets Talk About Tests, Baby
Lets Talk About Tests, Baby is a fortnightly podcast covering Testing, QA, Scrum, and all other sorts of techy geeky goodness.
Lets talk about all the good things, and the bad things that may be, lets talk about tests
Shownotes: http://letstalkabouttests.xyz/index.php/2018/04/12/ep-100-part-two-the-openspace-edition/
Shownotes: http://letstalkabouttests.xyz/index.php/2018/02/15/ep-97-against-energy-and-the-caring-angry-friend/
Shownotes: http://letstalkabouttests.xyz/index.php/2018/02/08/ep-96-testers-are-the-canary-down-the-coalmine/
Shownotes: http://letstalkabouttests.xyz/index.php/2018/01/18/ep-95-you-dont-need-client-approval-you-just-need-self-approval/
Shownotes: http://letstalkabouttests.xyz/index.php/2018/01/04/ep-94-sound-effects-and-overdramatics-the-retrospective/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/12/07/ep-92-everybodys-a-critic/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/11/24/ep-91-stop-collaborate-and-listen/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/10/19/ep-89-tubular-bells-and-whistles/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/10/05/ep-88-theres-a-hack-for-that/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/09/21/ep-87-players-gonna-play-play-play-play-play/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/09/07/ep-86-dont-be-afraid-to-catch-feels/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/08/24/ep-85-sound-effects-and-overdramatics/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/08/10/ep-84-lets-get-clinical-clinical/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/06/01/ep-80-who-lives-who-dies-who-tells-your-story/
Original shownotes: http://letstalkabouttests.xyz/index.php/2016/10/06/ep-61-takes-two/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/05/04/ep-78-may-the-testbash-be-with-you/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/04/20/ep-77-sonic-screwdriver-wont/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/03/09/ep-74-around-the-world-in-80-tests/
Shownotes: http://letstalkabouttests.xyz/index.php/2017/01/12/ep-69-talking-bout-generation/
News: I have a Patreon! https://www.patreon.com/GemHill If you do want to Patreon the show specifically you can choose the LTATB tier, and then the money will go firstly to hosting costs, then for equipment for me and Matt, travel, etc.
I also have launched a new podcast this month: http://innerpod.co.uk/ it's about Mental Health and storytelling and I'm very excited about it!
Shownotes: http://letstalkabouttests.xyz/index.php/2016/12/15/ep-67-diving-deep-domains/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/11/17/ep-65-gordian-knot-numbers/
That's right, a bonus episode all about Testbash! Shownotes: http://letstalkabouttests.xyz/index.php/2016/10/31/ep-63-testbash-bonus/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/10/20/ep-62-banishing-…exhausted-pigeon/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/09/01/ep-58-hot-tub-time-machine/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/08/25/ep-57-dont-go-chasing-waterfalls/
shownotes: http://letstalkabouttests.xyz/index.php/2016/04/14/ep-47-beyond-unreasonable-doubt/
Yes we can! (Maybe?)
Want to come work with me? We're hiring a junior tester!
Leading on from the Science! bit, I want to talk about testability.
So testability is how testable a product or system is by a given person, in a given context. Having software that’s testable makes testing quicker, because not only can we test quicker, we can also be confident that our testing has been effective.
Testability requires certain things:
We need to have a definition of right or correct behaviour, so we can form a test plan or strategy. If we don’t know how the system is meant to work, we can’t ensure it’s working as expected.
We need to put some work into defining features separately, so each can be discussed in isolation (or as much as is possible). This iterative process means testing can happen as early as possible, otherwise we’re in a position when all we can test is all of it in one go, which makes it harder to test.
There are some things that are only really testable in certain circumstances - whether that be a quirk of the system that means we can only monitor the results when live, or features that have an effect over a long period of time. I recently had a feature that tracked results over 7 days, and it wouldn’t be feasible for us to leave off deploying to the test environment for 7 days to see if that works, so there was some hackery involved so I can ensure that it removed data from older than 7 days as expected, things like that. It wasn’t ideal, but it was good enough.
And this is an issue that I run into occasionally. Where possible we try to figure out a way to test it as close to reality as possible, and put those frameworks or systems in place.
Linked to this is being taught how a feature works. Sometimes devs will put notes on a ticket to point me in the right direction, and then will provide release notes for the client. One lead dev recently asked whether we would be worth putting the notes they’d pass onto the client on the ticket when passing the story for testing, so I can both test the feature and the release notes. Now, this is an idea I want to implement, because again, the devs know how to use the feature, so the instructions may be either too broad, or use terminology that’s not well known to the client (referencing entities, MIME types, etc).
I prefer just having an idea of what the feature should do or should allow me to do, so I can see how intuitive the feature is, and make sure I’m not following the smooth path and looking for edge cases. If it’s a complex piece of back end functionality that we would provide instructions for, then I’ll use those to see if they work as expected.
This way, I’m testing both the instructions and the feature at the same time.
There’s more to testability than usability though. The definition is testing by a given person in a given context. Everyone tests differently, and everyone uses different tools to do so. Testability in this sense can be raised by someone helping out with testing, or by a test strategy, product, system, or domain knowledge; anything that means the tester can test more, or feel more comfortable and confident testing increases testability. And gaining knowledge of the product and the client will give greater understanding of risk, both to the specific product and to the system you use more broadly.
For example, I generally speaking, test Drupal sites. Drupal does categorisation in the form of taxonomies and vocabularies out of the box. Specific categories have to be set up, but the framework is there. That takes roughly two minutes for me to look over while I’m testing something else because I know that it doesn’t need testing, really. I feel comfortable taking that risk.
And managing risk, and reducing the distance between what we currently know and what we need to know is really the cornerstone of testing.
Footnotes http://www.infoq.com/news/2016/02/testability-teams-faster https://www.testingcircus.com/lessons-usability/ http://www.satisfice.com/tools/testable.pdf
Yes we can! (Maybe?)
Want to come work with me? We're hiring a junior tester!
Leading on from the Science! bit, I want to talk about testability.
So testability is how testable a product or system is by a given person, in a given context. Having software that’s testable makes testing quicker, because not only can we test quicker, we can also be confident that our testing has been effective.
Testability requires certain things:
We need to have a definition of right or correct behaviour, so we can form a test plan or strategy. If we don’t know how the system is meant to work, we can’t ensure it’s working as expected.
We need to put some work into defining features separately, so each can be discussed in isolation (or as much as is possible). This iterative process means testing can happen as early as possible, otherwise we’re in a position when all we can test is all of it in one go, which makes it harder to test.
There are some things that are only really testable in certain circumstances - whether that be a quirk of the system that means we can only monitor the results when live, or features that have an effect over a long period of time. I recently had a feature that tracked results over 7 days, and it wouldn’t be feasible for us to leave off deploying to the test environment for 7 days to see if that works, so there was some hackery involved so I can ensure that it removed data from older than 7 days as expected, things like that. It wasn’t ideal, but it was good enough.
And this is an issue that I run into occasionally. Where possible we try to figure out a way to test it as close to reality as possible, and put those frameworks or systems in place.
Linked to this is being taught how a feature works. Sometimes devs will put notes on a ticket to point me in the right direction, and then will provide release notes for the client. One lead dev recently asked whether we would be worth putting the notes they’d pass onto the client on the ticket when passing the story for testing, so I can both test the feature and the release notes. Now, this is an idea I want to implement, because again, the devs know how to use the feature, so the instructions may be either too broad, or use terminology that’s not well known to the client (referencing entities, MIME types, etc).
I prefer just having an idea of what the feature should do or should allow me to do, so I can see how intuitive the feature is, and make sure I’m not following the smooth path and looking for edge cases. If it’s a complex piece of back end functionality that we would provide instructions for, then I’ll use those to see if they work as expected.
This way, I’m testing both the instructions and the feature at the same time.
There’s more to testability than usability though. The definition is testing by a given person in a given context. Everyone tests differently, and everyone uses different tools to do so. Testability in this sense can be raised by someone helping out with testing, or by a test strategy, product, system, or domain knowledge; anything that means the tester can test more, or feel more comfortable and confident testing increases testability. And gaining knowledge of the product and the client will give greater understanding of risk, both to the specific product and to the system you use more broadly.
For example, I generally speaking, test Drupal sites. Drupal does categorisation in the form of taxonomies and vocabularies out of the box. Specific categories have to be set up, but the framework is there. That takes roughly two minutes for me to look over while I’m testing something else because I know that it doesn’t need testing, really. I feel comfortable taking that risk.
And managing risk, and reducing the distance between what we currently know and what we need to know is really the cornerstone of testing.
Footnotes http://www.infoq.com/news/2016/02/testability-teams-faster https://www.testingcircus.com/lessons-usability/ http://www.satisfice.com/tools/testable.pdf
Yes we can! (Maybe?) Want to come work with me? We're hiring a junior tester! Leading on from the Science! bit, I want to talk about testability. So testability is how testable a product or system is by a given person, in a given context. Having software that’s testable makes testing quicker, because not only can we test quicker, we can also be confident that our testing has been effective. Testability requires certain things: We need to have a definition of right or correct behaviour, so we can form a test plan or strategy. If we don’t know how the system is meant to work, we can’t ensure it’s working as expected. We need to put some work into defining features separately, so each can be discussed in isolation (or as much as is possible). This iterative process means testing can happen as early as possible, otherwise we’re in a position when all we can test is all of it in one go, which makes it harder to test. There are some things that are only really testable in certain circumstances - whether that be a quirk of the system that means we can only monitor the results when live, or features that have an effect over a long period of time. I recently had a feature that tracked results over 7 days, and it wouldn’t be feasible for us to leave off deploying to the test environment for 7 days to see if that works, so there was some hackery involved so I can ensure that it removed data from older than 7 days as expected, things like that. It wasn’t ideal, but it was good enough. And this is an issue that I run into occasionally. Where possible we try to figure out a way to test it as close to reality as possible, and put those frameworks or systems in place. Linked to this is being taught how a feature works. Sometimes devs will put notes on a ticket to point me in the right direction, and then will provide release notes for the client. One lead dev recently asked whether we would be worth putting the notes they’d pass onto the client on the ticket when passing the story for testing, so I can both test the feature and the release notes. Now, this is an idea I want to implement, because again, the devs know how to use the feature, so the instructions may be either too broad, or use terminology that’s not well known to the client (referencing entities, MIME types, etc). I prefer just having an idea of what the feature should do or should allow me to do, so I can see how intuitive the feature is, and make sure I’m not following the smooth path and looking for edge cases. If it’s a complex piece of back end functionality that we would provide instructions for, then I’ll use those to see if they work as expected. This way, I’m testing both the instructions and the feature at the same time. There’s more to testability than usability though. The definition is testing by a given person in a given context. Everyone tests differently, and everyone uses different tools to do so. Testability in this sense can be raised by someone helping out with testing, or by a test strategy, product, system, or domain knowledge; anything that means the tester can test more, or feel more comfortable and confident testing increases testability. And gaining knowledge of the product and the client will give greater understanding of risk, both to the specific product and to the system you use more broadly. For example, I generally speaking, test Drupal sites. Drupal does categorisation in the form of taxonomies and vocabularies out of the box. Specific categories have to be set up, but the framework is there. That takes roughly two minutes for me to look over while I’m testing something else because I know that it doesn’t need testing, really. I feel comfortable taking that risk. And managing risk, and reducing the distance between what we currently know and what we need to know is really the cornerstone of testing.
Footnotes http://www.infoq.com/news/2016/02/testability-teams-faster https://www.testingcircus.com/lessons-usability/ http://www.satisfice.com/tools/testable.pdf
Yes we can! (Maybe?)
Want to come work with me? We're hiring a junior tester!
Leading on from the Science! bit, I want to talk about testability.
So testability is how testable a product or system is by a given person, in a given context. Having software that’s testable makes testing quicker, because not only can we test quicker, we can also be confident that our testing has been effective.
Testability requires certain things:
We need to have a definition of right or correct behaviour, so we can form a test plan or strategy. If we don’t know how the system is meant to work, we can’t ensure it’s working as expected.
We need to put some work into defining features separately, so each can be discussed in isolation (or as much as is possible). This iterative process means testing can happen as early as possible, otherwise we’re in a position when all we can test is all of it in one go, which makes it harder to test.
There are some things that are only really testable in certain circumstances - whether that be a quirk of the system that means we can only monitor the results when live, or features that have an effect over a long period of time. I recently had a feature that tracked results over 7 days, and it wouldn’t be feasible for us to leave off deploying to the test environment for 7 days to see if that works, so there was some hackery involved so I can ensure that it removed data from older than 7 days as expected, things like that. It wasn’t ideal, but it was good enough.
And this is an issue that I run into occasionally. Where possible we try to figure out a way to test it as close to reality as possible, and put those frameworks or systems in place.
Linked to this is being taught how a feature works. Sometimes devs will put notes on a ticket to point me in the right direction, and then will provide release notes for the client. One lead dev recently asked whether we would be worth putting the notes they’d pass onto the client on the ticket when passing the story for testing, so I can both test the feature and the release notes. Now, this is an idea I want to implement, because again, the devs know how to use the feature, so the instructions may be either too broad, or use terminology that’s not well known to the client (referencing entities, MIME types, etc).
I prefer just having an idea of what the feature should do or should allow me to do, so I can see how intuitive the feature is, and make sure I’m not following the smooth path and looking for edge cases. If it’s a complex piece of back end functionality that we would provide instructions for, then I’ll use those to see if they work as expected.
This way, I’m testing both the instructions and the feature at the same time.
There’s more to testability than usability though. The definition is testing by a given person in a given context. Everyone tests differently, and everyone uses different tools to do so. Testability in this sense can be raised by someone helping out with testing, or by a test strategy, product, system, or domain knowledge; anything that means the tester can test more, or feel more comfortable and confident testing increases testability. And gaining knowledge of the product and the client will give greater understanding of risk, both to the specific product and to the system you use more broadly.
For example, I generally speaking, test Drupal sites. Drupal does categorisation in the form of taxonomies and vocabularies out of the box. Specific categories have to be set up, but the framework is there. That takes roughly two minutes for me to look over while I’m testing something else because I know that it doesn’t need testing, really. I feel comfortable taking that risk.
And managing risk, and reducing the distance between what we currently know and what we need to know is really the cornerstone of testing.
Footnotes http://www.infoq.com/news/2016/02/testability-teams-faster https://www.testingcircus.com/lessons-usability/ http://www.satisfice.com/tools/testable.pdf
Yes we can! (Maybe?)
Want to come work with me? We're hiring a junior tester!
Leading on from the Science! bit, I want to talk about testability.
So testability is how testable a product or system is by a given person, in a given context. Having software that’s testable makes testing quicker, because not only can we test quicker, we can also be confident that our testing has been effective.
Testability requires certain things:
We need to have a definition of right or correct behaviour, so we can form a test plan or strategy. If we don’t know how the system is meant to work, we can’t ensure it’s working as expected.
We need to put some work into defining features separately, so each can be discussed in isolation (or as much as is possible). This iterative process means testing can happen as early as possible, otherwise we’re in a position when all we can test is all of it in one go, which makes it harder to test.
There are some things that are only really testable in certain circumstances - whether that be a quirk of the system that means we can only monitor the results when live, or features that have an effect over a long period of time. I recently had a feature that tracked results over 7 days, and it wouldn’t be feasible for us to leave off deploying to the test environment for 7 days to see if that works, so there was some hackery involved so I can ensure that it removed data from older than 7 days as expected, things like that. It wasn’t ideal, but it was good enough.
And this is an issue that I run into occasionally. Where possible we try to figure out a way to test it as close to reality as possible, and put those frameworks or systems in place.
Linked to this is being taught how a feature works. Sometimes devs will put notes on a ticket to point me in the right direction, and then will provide release notes for the client. One lead dev recently asked whether we would be worth putting the notes they’d pass onto the client on the ticket when passing the story for testing, so I can both test the feature and the release notes. Now, this is an idea I want to implement, because again, the devs know how to use the feature, so the instructions may be either too broad, or use terminology that’s not well known to the client (referencing entities, MIME types, etc).
I prefer just having an idea of what the feature should do or should allow me to do, so I can see how intuitive the feature is, and make sure I’m not following the smooth path and looking for edge cases. If it’s a complex piece of back end functionality that we would provide instructions for, then I’ll use those to see if they work as expected.
This way, I’m testing both the instructions and the feature at the same time.
There’s more to testability than usability though. The definition is testing by a given person in a given context. Everyone tests differently, and everyone uses different tools to do so. Testability in this sense can be raised by someone helping out with testing, or by a test strategy, product, system, or domain knowledge; anything that means the tester can test more, or feel more comfortable and confident testing increases testability. And gaining knowledge of the product and the client will give greater understanding of risk, both to the specific product and to the system you use more broadly.
For example, I generally speaking, test Drupal sites. Drupal does categorisation in the form of taxonomies and vocabularies out of the box. Specific categories have to be set up, but the framework is there. That takes roughly two minutes for me to look over while I’m testing something else because I know that it doesn’t need testing, really. I feel comfortable taking that risk.
And managing risk, and reducing the distance between what we currently know and what we need to know is really the cornerstone of testing.
Footnotes http://www.infoq.com/news/2016/02/testability-teams-faster https://www.testingcircus.com/lessons-usability/ http://www.satisfice.com/tools/testable.pdf
Shownotes: http://letstalkabouttests.xyz/index.php/2016/03/10/ep-42-always-look-bright-side-life/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/03/02/ep-41-friends-dont-let-friends-use-ie6-ep-40-revisited/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/02/18/ep-39-i-can-teach-you-but-id-have-to-charge/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/01/28/ep-36-life-is-a-lemon-and-i-want-my-money-back/
Shownotes: http://letstalkabouttests.xyz/index.php/2016/01/07/ep-33-these-are-the-testers-youre-looking-for/
Show notes: http://letstalkabouttests.xyz/index.php/2015/12/31/ep-32-totally-addicted-to-stats/
Show notes: http://letstalkabouttests.xyz/index.php/2015/12/17/ep-31-tales-of-derring-do-bad-and-good-luck-tales/
Shownotes: http://letstalkabouttests.xyz/index.php/2015/11/26/
ep-28-youre-like-me-im-never-satisfied
Shownotes: http://letstalkabouttests.xyz/index.php/2015/11/05/ep-25-a-year-in-the-life-of
Show notes: http://letstalkabouttests.xyz/index.php/2015/10/22/ep-24-i-am-jacks-medulla-oblongata
Shownotes: http://letstalkabouttests.xyz/index.php/2015/10/15/
ep-23-you-cant-teach-a-fish-to-climb-a-tree
Show notes: http://letstalkabouttests.xyz/index.php/2015/10/08/ep-22-stranger-in-a-strange-land
Show notes: http://letstalkabouttests.xyz/index.php/2015/08/27/ep-16-creativity-in-time-and-space
Shownotes:
http://letstalkabouttests.xyz/index.php/2015/08/20/ep-15-so-cunning-you-could-pin-a-tail-on-it-and-call-it-a-fox
Show notes: http://letstalkabouttests.xyz/index.php/2015/08/06/ep-13-i-love-docs-ive-always-loved-docs
Show notes: http://letstalkabouttests.xyz/index.php/2015/07/23/ep-11-theres-no-i-in-team
Show notes:
http://letstalkabouttests.xyz/index.php/2015/07/16/ep-10-crouch-touch-pause-engage
This week I talk to Mike Bell, Drupal Dev, friend, and colleague about the relationship between QA, Dev, and Client.
Shownotes: http://letstalkabouttests.xyz/index.php/2015/06/28/ep-8-rage-against-the-qa