145 lines
14 KiB
HTML
145 lines
14 KiB
HTML
|
<html>
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
|
|||
|
|
<style type="text/css">
|
|||
|
|
body { background: #F0F0F0; }
|
|||
|
|
#editor {
|
|||
|
|
width: 590px;
|
|||
|
|
margin: auto;
|
|||
|
|
margin-top: 60px;
|
|||
|
|
color: #333;
|
|||
|
|
background-color: #fff;
|
|||
|
|
font-size: 13px;
|
|||
|
|
line-height: 17px;
|
|||
|
|
font-family: 'Helvetica Neue';
|
|||
|
|
border: 1px solid #CCC;
|
|||
|
|
|
|||
|
|
padding-top: 1px; /* important for some reason? */
|
|||
|
|
padding-right: 10px;
|
|||
|
|
padding-bottom: 8px;
|
|||
|
|
padding-left: 0px /* prevents characters from looking chopped off in FF3 */;
|
|||
|
|
overflow: hidden;
|
|||
|
|
/* blank 1x1 gif, so that IE8 doesn't consider the body transparent */
|
|||
|
|
background-image: url(data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
#editor > div:first-child span {
|
|||
|
|
font-size: 140%;
|
|||
|
|
font-weight: bold;
|
|||
|
|
}
|
|||
|
|
#editor > div:first-child {
|
|||
|
|
margin-top:10px;
|
|||
|
|
margin-bottom:10px;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.gutter-noauthor {
|
|||
|
|
padding-left: 15px;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.inline-img {
|
|||
|
|
max-width:400px;
|
|||
|
|
max-height:300px;
|
|||
|
|
width: expression(this.width > 400 ? 400: true);
|
|||
|
|
height: expression(this.height > 300 ? 300: true);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.inline-tex{
|
|||
|
|
border: 1px solid transparent;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.inline-tex:hover {
|
|||
|
|
border: 1px dashed red;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
a.attrlink {
|
|||
|
|
/* font-weight: bold;
|
|||
|
|
text-decoration: none;*/
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.code {
|
|||
|
|
font-family: monospace;
|
|||
|
|
color: #777;
|
|||
|
|
white-space: pre-wrap;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.code span {
|
|||
|
|
padding-left: 32px;
|
|||
|
|
text-indent: -32px;
|
|||
|
|
display: inline-block;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
a.attrlink:hover {
|
|||
|
|
text-decoration: underline;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
.gutter-author-p-199106 { border-left: 5px solid #2996c3; padding-left: 10px; } .author-p-199106 { border-bottom: 2px dotted #2996c3; } .gutter-author-p-199053 { border-left: 5px solid #c66c78; padding-left: 10px; } .author-p-199053 { border-bottom: 2px dotted #c66c78; }
|
|||
|
|
</style>
|
|||
|
|
|
|||
|
|
</head>
|
|||
|
|
|
|||
|
|
<!-- todo: author colors, sidebar, embedly -->
|
|||
|
|
|
|||
|
|
<body>
|
|||
|
|
<div id="editor">
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106">Context-Driven Testing, Bonusbox Style</span></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 b"><b>Overview</b></span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106">For those unaware, "Context-Driven Testing" is a testing concept </span><span class="author-p-199106 attrlink url"><a class="attrlink" href="http://context-driven-testing.com/">conceived by James Bach and friends</a></span><span class="author-p-199106"> that essentially bundles basic common sense pragmatism into a set of seven general principles. This list of principles is more or less how we function at Bonusbox:</span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="1" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">The value of any practice depends on its context.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="2" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">There are good practices in context, but there are no best practices.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="3" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">People, working together, are the most important part of any project’s context.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="4" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">Projects unfold over time in ways that are often not predictable.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="5" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">The product is a solution. If the problem isn’t solved, the product doesn’t work.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="6" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">Good software testing is a challenging intellectual process.</span></li></ol></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-number emptyGutter"><ol start="7" class="listtype-number listindent1 list-number1"><li><span class="author-p-199106">Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.</span></li></ol></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106">How do we apply these principles at Bonusbox? For Bonusbox, the first two principles liberate us from the constraints and costs of a lot of traditional QA behaviors. But principles 3 and 7 force us to regularly re-evaluate our practices (or perhaps, "anti-practices"), as the company, and the product continues to grow and mature. Now, on to the specifics!</span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 b"><b>Breakin' The Law</b></span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106">There are a number of testing practices at Bonusbox, that at first glance, might make us appear to be what used to be called "cowboy coders". Nothing could be further from the truth. There is a method to this madness. However, it's quite true that this method runs directly counter to a number of ancient "industry standards" when it comes to QA as a role, and testing as a practice. Here are the 4 most obvious ones:</span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 i"><i>Think Outside The Black Box - </i></span><span class="author-p-199106">To test at Bonusbox, you need to understand Rails and object oriented concepts the way a dev understands them. You need to be able to do everything a dev can do, with the possible exception of actually writing his code. The days of requirements checklists, and hand-testing an opaque user interface are long gone. To add value to the team, you need to be able to identify the source of problems, including employing whatever technical tools are necessary to do that, even to the point of being able to fix them yourself.</span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 i"><i>Staging Is For Sissies - </i></span><span class="author-p-199106">The motto at Bonusbox is "break it fast, fix it fast". In order to execute successfully on continuous deployment, the tester does his work from the same basic environment the developer does: his desktop. Anything that requires external resources that cannot be duplicated or properly mocked, will get tested directly in production. For such cases, breaks will not be backed out unless they're completely irreparable. Instead, they are fixed immediately. </span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 i"><i>The Dog Ate My Test Plan</i></span><span class="author-p-199106"> - Test plans are traditionally drawn up at the time requirements are defined, during feature planning. This is simply untenable in an environment where features change shape and size almost hourly, as they make their way through the development process of a lean startup. Testers must be able to stay on top of this changing landscape, by staying connected to the code, and to design and development discussions in Trello.</span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 i"><i>Open Borders - </i></span><span class="author-p-199106">In legacy development environments, the tester's value was defined by how much he slowed the progress to production. Bug counts, feature rejections, and defects passed into production, were all metrics that gauged his competency. He was something of a gatekeeper, standing guard over the business owner's anxiety. Today, the situation is almost entirely the opposite. The QA is a free agent, a special forces commando. He is far less interested in completely sealing off borders, than he is in tracking down and pacifying threats on their own turf. He moves from team to team, working to help them get to deployment as quickly as possible, but also </span><span class="author-p-199106 i"><i>as cleanly as possible</i></span><span class="author-p-199106">. </span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 b"><b>Talk To Me</b></span></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106">As you've probably intuited already from the above, </span><span class="author-p-199106 i"><i>good communications</i></span><span class="author-p-199106"> and </span><span class="author-p-199106 i"><i>good relationships</i></span><span class="author-p-199106"> are key to the success of the modern QA Engineer. Though this is listed at the bottom, it is probably the most important feature of QA at Bonusbox. The QA must be capable of negotiating difficult conflicts and analyzing complex problems dispassionately, and he must be willing to communicate his findings with both developers and product managers, in their own language. </span></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199053 line-list-type-comment emptyGutter"><ul class="listtype-comment listindent1 list-comment1" ><li><span class="author-p-199053">and I"d stop here. And we'd have a bomb of a blog post...</span></li></ul></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-comment emptyGutter"><ul class="listtype-comment listindent1 list-comment1" ><li><span class="author-p-199106">Hey Vuk, I've made the suggested edits above (and a few others). Feel free to post it wherever you wish.</span></li></ul></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 emptyGutter"><span class="author-p-199106 b"><b>FAQ</b></span></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-bullet emptyGutter"><ul class="listtype-bullet listindent2 list-bullet2" ><li><span class="author-p-199106 b"><b>Should testers be involved in defining requirements?</b></span></li></ul></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-bullet emptyGutter"><ul class="listtype-bullet listindent2 list-bullet2" ><li><span class="author-p-199106 b"><b>Should testers fix bugs? </b></span></li></ul></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-indent emptyGutter"><ul class="listtype-indent listindent2 list-indent2" ><li><span class="author-p-199106">It depends on the role of QA on a particular project.</span></li></ul></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-indent emptyGutter"><ul class="listtype-indent listindent3 list-indent3" ><li><span class="author-p-199106">I tend to agree with </span><span class="author-p-199106 attrlink url"><a class="attrlink" href="http://sqa.stackexchange.com/questions/5194/should-tester-fix-bugs/5231#5231">this fellow</a></span><span class="author-p-199106">: </span></li></ul></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-indent emptyGutter"><ul class="listtype-indent listindent3 list-indent3" ><li><span class="author-p-199106 b"><b>" </b></span><span class="author-p-199106">If QA has been involved in the software development lifecycle, if QA has played a role in defining requirements from the start of a project, and if QA feels like they have the support of project management to take a proactive role, I'd say go for it. I've always welcomed testers and QA people with an engineering focus to take some time to understand the code that underlies the systems they are testing, and there's no better way to learn a system than to fix bugs in a project.</span></li></ul></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-indent emptyGutter"><ul class="listtype-indent listindent3 list-indent3" ><li><span class="author-p-199106">On the other hand, if QA isn't involved in the overall project, if QA doesn't have a seat at the table during the requirements phase and during the implementation of a project, then you are going to want to consider that QA may not have enough information to fix bugs without introducing more complexity (or even without understanding how the bug affects the overall development effort). Having QA fix bugs without the involvement of a developer or someone in project management could cause a range of problems. Maybe development has decided to delay the implementation of a feature because the business hasn't fully elaborated on a requirement? Maybe a particular bug is present because a developer is waiting for clarification? "</span></li></ul></div>
|
|||
|
|
<div class="ace-line gutter-author-p-199106 line-list-type-indent emptyGutter"><ul class="listtype-indent listindent2 list-indent2" ><li> </li></ul></div>
|
|||
|
|
<div class="ace-line longKeep gutter-noauthor"> </div>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<script type='text/javascript'>
|
|||
|
|
function goLive() {
|
|||
|
|
if (navigator.onLine) {
|
|||
|
|
document.location = 'https://bonusbox.hackpad.com/rElArs9Uhw9#Context-Driven%20Testing%2C%20Bonusbox%20Style';
|
|||
|
|
} else {
|
|||
|
|
setTimeout(goLive, 250);
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
goLive();
|
|||
|
|
</script>
|
|||
|
|
|
|||
|
|
</body>
|
|||
|
|
</html>
|
|||
|
|
|