I read. A lot. And I share the 5 best things I read every week. This week features an interesting take on a failure model, a Andreesen Horowitz presentation, crash test dummies, a thought provoking talk on the role luck plays and yet another org chart cartoon.<\/p>\n
1. Crash only thinking<\/a> 1. Crash only thinking<\/a>
\n2. Mobile is eating the world<\/a>
\n3. Overweight crash test dummies<\/a>
\n4. The lottery analogy to software development<\/a>
\n5. Yet another org chart cartoon<\/a><\/p>\n
\nMy notes:<\/h3>\n
\nA very interesting write up. I have often wondered if catching all kind of bugs is correct for a testing team. Business impact bugs cause the organization to learn faster, grow up quicker, improve safety culture, plug processes and better risks. With that in mind, I’m pretty sure the healthy\/optimal number of business impact bugs in any software should probably be a number greater than zero. This concept is super hard for a tester to admit and very hard for me verbalize here. I should just devote another blog post to clarify what I mean. For software engineers, interesting related articles include: The rise of Worse is better<\/a> and The challenge of “good enough” software<\/a>.
\n
\n2. Mobile is eating the world<\/a>
\nMobile is eating the world. Nice deck created by Benedict Evans of Andreesen Horowitz. The longer I stay in India, the more I am aware of how mobile devices (even the no-smart variety) are changing the world. I liked this deck primarily because mobile testing is my new hobby. If you are starting out your testing career now, I would strongly encourage you to focus on testing mobile devices.
\n
\n3. Overweight crash test dummies<\/a>
\nGood test setups mimic a range of users. Apparently car companies are using overweight crash test dummies to model the growing obesity problem. I’m actually surprised that this change is happening only now.
\n
\n4. The lottery analogy to software development<\/a><\/p>\n
![Yet another org chart cartoon<\/a><\/p>\n\nMy notes:<\/h3>\n1. Crash only thinking<\/a>\nA very interesting write up. I have often wondered if catching all kind of bugs is correct for a testing team. Business impact bugs cause the organization to learn faster, grow up quicker, improve safety culture, plug processes and better risks. With that in mind, I’m pretty sure the healthy\/optimal number of business impact bugs in any software should probably be a number greater than zero. This concept is super hard for a tester to admit and very hard for me verbalize here. I should just devote another blog post to clarify what I mean. For software engineers, interesting related articles include: The rise of Worse is better<\/a> and The challenge of “good enough” software<\/a>.\n\n2. Mobile is eating the world<\/a>\nMobile is eating the world. Nice deck created by Benedict Evans of Andreesen Horowitz. The longer I stay in India, the more I am aware of how mobile devices (even the no-smart variety) are changing the world. I liked this deck primarily because mobile testing is my new hobby. If you are starting out your testing career now, I would strongly encourage you to focus on testing mobile devices.\n\n3. Overweight crash test dummies<\/a>\nGood test setups mimic a range of users. Apparently car companies are using overweight crash test dummies to model the growing obesity problem. I’m actually surprised that this change is happening only now.\n\n4. The lottery analogy to software development<\/a><\/p>\n](\"https:\/\/pbs.twimg.com\/media\/B1VSkk9IgAE9ftM.jpg\"){kind=link}