tag:blogger.com,1999:blog-9421494.post4080285425302157729..comments2024-03-27T06:18:38.214-04:00Comments on Lessons Learned by a Software Tester: The Testing ParadoxPaulhttp://www.blogger.com/profile/16826575269870573990noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-9421494.post-47167093734540078882009-06-24T05:11:43.383-04:002009-06-24T05:11:43.383-04:00Very good article, It's really useful for me. ...Very good article, It's really useful for me. I am doing a bit on research about "Software testing" and i found also macrotesting www.macrotesting.com to be very good source for software testing.<br /><br />Thanks for your article<br />Regards,<br />PremMacroTestinghttps://www.blogger.com/profile/10082007205388765725noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-91896077249417274192009-06-03T23:33:58.257-04:002009-06-03T23:33:58.257-04:00Hello Loron,
You asked "how do you make test ...Hello Loron,<br />You asked "how do you make test plans when there are no specs?"<br /><br />It's a good question, but in the words of Fermat, "this margin is too narrow to contain" a proper answer. ;-)<br /><br />First, I'd need to understand what *you* call a Test Plan, because it may not be what *I* call one. So, for instance, are you referring to the overall Testing Strategy for a feature/product/system/component/release? Are you referring to the collection of test cases for a common feature/product/component/area? Or do you mean something other?<br /><br />The short answer is that in the absence of written specs, I'd go and ask all the people I can ask who are related to the project as to what's important to them and how they think it should work. (Make notes.) Work from there. A little song.. a little dance.. and voilà! Testing done. ;-)<br /><br />The reality (for me) is that written reference material only represents about a third of the input source that I'd usually use to test something. More importantly is that I don't perceive myself as a "tester" in a traditional sense anyway.<br /><br />As a good exploratory tester, I see myself more as a "doubt management specialist". But that's a different discussion..<br /><br />Cheers! =)Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-20376999083119974842009-05-13T07:35:00.000-04:002009-05-13T07:35:00.000-04:00how do you make test plans when there are no specs...how do you make test plans when there are no specs?Loronhttp://testing-blog.byethost31.comnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-70486002407846517682009-05-10T20:42:00.000-04:002009-05-10T20:42:00.000-04:00I like to think of it as differences in the level ...I like to think of it as differences in the level of detail. We have a test idea, it could become a charter for an ET session, or it could become a description of a scripted test. And while scripts I see tend typically to focus on functionality, they come in many flavors often allowing choice of data, browser, etc. When tests were first written, you needed a lot more detail because the mainframe didn't know what the printer was or where the input stream was or where something was saved too, but now a lot of this happens by default so it remains as unscripted details in a scripted test.....!<br />Erik PetersenErik Petersenhttps://www.blogger.com/profile/15533063091357812675noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-13484995384238305552009-05-08T00:07:00.000-04:002009-05-08T00:07:00.000-04:00Hi Michael, I believe there is a clear distinction...Hi Michael, I believe there <I>is</I> a clear distinction between ET and Scripted Testing. It's like the difference between the goal posts on either end of a football field. Most of the action happens in the field between, and so it is with Testing too.<br /><br />However, just because most of the game is played somewhere in the field, moving back and forth as required, it doesn't mean that you should ignore the posts and boundaries at either end.<br /><br />There <I>are</I> clear distinctions between these two approaches. One requires thinking and learning, while another does not. Whether or not Scripted Testing is done [by humans] in true scripted style doesn't change the nature of it. It just reflects the inability of the tester to completely disengage his/her brain while testing.<br /><br />The two lines of my blog that you quote are not contradictory - they are complementary. The <I>question</I> is meant to identify the boundaries, while the <I>continuum</I> comment reflects the reality of the practice.<br /><br />There are strengths and weaknesses at both ends of the spectrum. You ignore the boundaries at your peril - but you don't stay there either. In teaching testers the complete picture of the opposing approaches, we can prepare them to make better decisions on how to make adjustments to their processes based on the needs of their situations.Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-24068105989661331492009-05-07T03:02:00.000-04:002009-05-07T03:02:00.000-04:00Hi, Paul...
I don't agree when you suggest that t...Hi, Paul...<br /><br />I don't agree when you suggest that there's a clear distinction:<br /><br /><I>"When you sit down to test, are the tests already written or are you going to figure it out as you go along?"</I>I'm much closer to agreeing with you when you suggest that<br /><br /><I>a testing approach falls somewhere in the continuum between pure scripted and pure exploratory methods.</I>It's important to think of the exploratory and scripted continuum as one of approach and mindset. Very generally, we assess something as a scripted approach to the degree that the focus is on confirmation, verification, and validation; to the degree that a tester (or a programmer, for that matter) requires explicit instruction; to the degree it fosters separation the processes of test design, test execution, result interpretation, and learning from each other over time and space. A machine can perform purely scripted test execution (but can't design or interpret it); a human whose brain cells are still working can't help but behaving in a somewhat exploratory way no matter how rigourous the script's instructions.<br /><br />http://www.developsense.com/2008/09/evolving-understanding-about.html<br /><br />---Michael B.Michael Bolton http://www.developsense.comhttps://www.blogger.com/profile/09027725699187903416noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-87976508903104661272009-05-06T23:21:00.000-04:002009-05-06T23:21:00.000-04:00Hi Corey, thanks for your note.
From one perspect...Hi Corey, thanks for your note.<br /><br />From one perspective, the difference between Exploratory and Scripted Testing can simply be defined by the answer to the following question: "When you sit down to test, are the tests already written or are you going to figure it out as you go along?"<br /><br />You can use programs, automated scripts, and tools with either approach, so I can understand your confusion. "Programmatic testing" is not a term that I am familiar with, so I can't comment on it.<br /><br />I suppose an equivalent practice for programmers would be to compare "Scripted Testing" to Test-Driven Development. In TDD, the tests are written *before* the code is written. When the code is done, you run the tests.. you don't have to think about them. No exploration there - just run the scripts. (Literally and figuratively.)<br /><br />In general I agree with you that a testing approach falls somewhere in the continuum between pure scripted and pure exploratory methods.<br /><br />Why is that? Is it to leverage the benefits of both approaches, or because the testers do both rather poorly, so they combine the approaches to hide the fact that they can't do either really well?Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-65099558052242267482009-05-06T10:15:00.000-04:002009-05-06T10:15:00.000-04:00Great post.
The problem I have is mostly in termi...Great post.<br /><br />The problem I have is mostly in terminology. <br /><br />I refer to "scripted testing" as programmatic testing. You can use programs and scripts to explore a system if you want. You can do exploratory testing with scripts/programs/tools.<br /><br />The debate seems to overlook that definition and define "scripted" as just following a number of predefined steps.<br /><br />I don't see it as a boolean argument. I think of it terms of a spectrum and somewhere along that programmatic/manual continuum is where you work.. exploratory testing can fall in many areas of the spectrum.<br /><br />That is where the argument breaks down (IMO).Corey Goldberghttps://www.blogger.com/profile/06219872951977664560noreply@blogger.com