tag:blogger.com,1999:blog-9421494.comments2023-12-06T03:17:00.670-05:00Lessons Learned by a Software TesterPaulhttp://www.blogger.com/profile/16826575269870573990noreply@blogger.comBlogger171125tag:blogger.com,1999:blog-9421494.post-29814022895193077662016-03-04T23:41:06.308-05:002016-03-04T23:41:06.308-05:00Perhaps. I believe that people and their mindset m...Perhaps. I believe that people and their mindset matter more than processes and tools. We can come up with the right processes and tools we need if we have the right people collaborating with the right mindset. You can build high quality things without a single documented process. And I'm not talking about a Cowboy/Hero culture either.<br /><br />The vast majority of current IT/Development cultures are broken. Test processes exist as a kludge/band-aid solution to the broken relationships and culture. If we fix the culture we shouldn't need those processes anymore and our tools will be different.Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-53326876271027567802016-01-25T09:36:37.701-05:002016-01-25T09:36:37.701-05:00I totally agree, I write python test frameworks th...I totally agree, I write python test frameworks that can be executed on Linux small computers (Raspberry Pi) The company I am contracting to just decided to shift the test cases to QC.... I read that ALM 11+ supports REST interface so I had no objection.... NO it does not it supports a tiny subset of its features. Why does any modern test tool not use open standards? and dont get me started on the actual interface oh my good god.. really.. define a test as Automated... that's it now you cant change it back... one of the features in any project I design is the ability to pass a test between Manual Automated and Augmented.. Most tests start out as Manual tests, and evolve to Automation... Now not possible! you must duplicate the test mark it Automated and block the Manual test?? duplication is the enemy! Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-72461063458129107032016-01-12T00:31:44.769-05:002016-01-12T00:31:44.769-05:00Hi Jessica, thanks for your question. When you per...Hi Jessica, thanks for your question. When you perform the kinds of tests that are more Business Facing (i.e. at the top of the chart), your team members/testers are dipping more into the psychology and personas of your end users. This adds complexity that is very difficult to automate and is rather fun for the creative mind.<br /><br />The human mind is the most efficient and effective tool for quickly learning and exploring systems from different users' perspectives. When that learning has happened, we can select certain touchpoints along the user journey and choose to automate those checks for future reference (i.e. regression testing). The kind of UI-level test you describe is definitely Q2 and is what I would happily place in the automation part of Q2.<br /><br />Q3 is more of an exploration of solution fit so it requires real user/expert/specialist feedback, and the effect of this feedback is usually a design change somewhere in the developed product/software/system. This kind of feedback cannot be automated.<br /><br />Q2: Business Facing + Verification = some test/check automation possible.<br /><br />Q3: Business Facing + Validation = no test/check automation possible as computers require predetermined expected results. (Computer-assisted data gathering highly encouraged when possible.)<br /><br />It's a tricky line. Once you've understood & agreed upon a design requirement (i.e. from Q3 exploration), future checking of that requirement places the [automated] check in Q2.Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-88479932841832743512016-01-07T10:46:02.652-05:002016-01-07T10:46:02.652-05:00Very good article and I also like the describing p...Very good article and I also like the describing pictures :-).<br /><br />I have a question about Q3.<br />When you write <br />"The next important observation is in Q2, the place where Testers typically self-identify themselves. The key here is that NOT EVERYTHING CAN OR SHOULD BE AUTOMATED HERE! The closer you get to business-facing tests, the more you require human intelligence to interpret results in real-time."<br />Are you then talking more about the tests in Q3, where you as a tester do more alternative tests to try to criticize the product (not the base flows)?<br />I agree that not everything is worth automating in Q2, but we find (in our company) that our regression test suit (on UI-level) is quite good to have and is relatively stable.<br /><br />//JessicaJessica Ahttps://www.blogger.com/profile/01091364715767260644noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-75611243513770984512015-11-02T08:59:25.520-05:002015-11-02T08:59:25.520-05:00Thanks for your response Paul, greatly appreciated...Thanks for your response Paul, greatly appreciated.<br /><br />I'll take from your answer the rough idea of how the models can be overlayed & try not to sweat the details too much :-)<br /><br />DuncsAnonymoushttps://www.blogger.com/profile/13734686574367515881noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-11893844288904781932015-10-28T01:08:45.987-04:002015-10-28T01:08:45.987-04:00I'm sorry, Any, I did not intend to confuse an...I'm sorry, Any, I did not intend to confuse anyone. Yes, automation is a programming activity, though sometimes testers may automate in a language that is more natural. It's about the interfaces.<br /><br />For example, Fitnesse uses tables to capture/communicate the testing conditions in a structured format that clarifies the business rules and testing techniques. Cucumber + Ruby is a good tool that testers may use to create Executable Specifications. You are testing using the business language with automation in the background. Depending how the team works, a tester may never see/maintain the back-end automation. Is that what you mean?Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-22294874438760783322015-10-28T00:58:42.747-04:002015-10-28T00:58:42.747-04:00Good question, Duncan. I have thought about that t...Good question, Duncan. I have thought about that too. Sometimes I treat the quadrants/matrix as a closed set of 4 boxes for categorizing things, and sometimes I look at it as an x-y graph with an outside boundary drawn for convenience.<br /><br />If you think of the former, a closed set of categorization boxes, then anything outside the boxes doesn't make sense (to me, at least). If you think of the latter, an x-y graph, then that left corner sticking out is just a part of what's in that quadrant. When I look at that bottom left corner, I usually take the x-y graph view, so no, it doesn't have any significance (to me, right now).<br /><br />Cheers!Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-75146701006651257572015-10-27T17:41:09.083-04:002015-10-27T17:41:09.083-04:00Interesting post Paul, I like how you've overl...Interesting post Paul, I like how you've overlayed the models to give a different perspective.<br /><br />1 question - what about the bottom left hand corner of the pyramid? How does that fit into the overlayed model please?<br /><br />It seems the bottom right corner does have significance, does the left corner have any?<br /><br />DuncsAnonymoushttps://www.blogger.com/profile/13734686574367515881noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-73730684925326628452015-10-24T13:10:38.588-04:002015-10-24T13:10:38.588-04:00Do not confuse people. A tester that automates dev...Do not confuse people. A tester that automates develops in the language of the automation tool; s/he doesn't develop in the language of the application being tested. So QA doesn't end.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-53762835028812952732015-09-28T02:23:56.427-04:002015-09-28T02:23:56.427-04:00Your article about software testing is awesome. It...Your article about software testing is awesome. It helped me to understand the career prospects in software testing industry. Software Testing Traininghttp://www.fita.in/software-testing-training-in-chennai/noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-42829300562164883962015-09-17T12:26:45.772-04:002015-09-17T12:26:45.772-04:00Hello Zaed, thank you for taking the time to share...Hello Zaed, thank you for taking the time to share your thoughts and experiences. I am always happy to learn of more places that are practicing collaborative ET. It sounds like you are beginning to straddle the fuzzy line between Waterfall and Agile development.<br /><br />Here's the point: Agile Testing doesn't really exist. It's not really a thing. The point of Agile software development is to deliver things of value to your customers, and to do so in a way that expects things to change over time. We are not talking about made up silos like: Agile Technical Writing, Agile Programming, Agile Design, Agile Testing, and so on. That is a Waterfall-view of Agile. *Agile Development is the whole picture and it is a team sport - one in which your customers are part of the team.*<br /><br />There is a mindset change.<br /><br />*** If you are thinking to yourself "How can I be a better Agile Tester?" you are doing it wrong! ***<br /><br />So, why do I talk about Agile Testing here? Because I want to reach an audience that might otherwise ignore the message here. That is, if I wrote about ET vs Agile Development, I would hear the complaints that I'm not talking about the same thing.. apples and oranges. Yes. That is in fact what we are talking about here.<br /><br />A better analogy might be: testing in an agile context is like the human circulatory system. It is an integrated part of the whole system.<br /><br />Above, you mention "an agile team has a required social aspect that is difficult to be part of when you float in and out of the team on a regular basis." That's really a key difference.<br /><br />Regarding your last question, the length of the feedback loop may be interpreted in different ways. In *Lean* terms, we are talking about "waste" in the system. For example, if you are using a Bug Tracking system, then you have wasted time/effort in your system. That is also inherently non-Agile.<br /><br />If you want to talk about short feedback loops, I would ask "of what? for what purpose?" For example, a short feedback loop to validate that the software is "fit for use" -- have the customer/user sit at the programmer's/team's computer. A short feedback loop that the software builds correctly -- have a Continuous Integration server in place. A short feedback loop that no past bugs have reappeared -- automate the checking of these bugs. A short feedback loop on a potentially infinite space of possible (mis)interpretations of the software/system -- hire some good exploratory testers.<br /><br />"Testing" is a dirty word that hides many meanings, so our discussion here may never end. This (blog) is not the best/ideal medium to maximise clarity on the distinctions between and within the different practices. I hope this has helped spark some new ideas or connections.<br />Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-7118835866991287822015-09-17T09:23:50.086-04:002015-09-17T09:23:50.086-04:00Interesting discussion between you and Huib, Paul....Interesting discussion between you and Huib, Paul. We all benefit when two mindful testers discuss the philosophy/theory behind what we do. I wish I had found your site sooner. Thanks!<br /><br />You mentioned wanting more empirical evidence to support Huib's comments, as any good CDT tester would. So I thought I'd offer mine. I can't name the Fortune 500 company I work for, but I've built up over the past few years (with help from some other key individuals) what I would consider to be an ET team that practices collaboratively, as you mentioned not seeing in the wild. <br /><br />We learn together, we test together, we review/introspect together. I would not hesitate to say that we are agile in that respect. But I believe it's because we practice Context-Driven Testing, specifically that 7th principle Huib mentioned in his post: "judgement and skill ... exercised cooperatively." So I think anyone successfully embracing the context-driven testing principles accomplishes that piece you feel is missing to make them agile.<br /><br />For me, it seems the biggest difference between agile testing and ET testing in a CDT context is the feedback loop. I agree with you that agile testers should be embedded with the development team. ET testers are typically on their own team, or they are "teamless" floaters. I say "teamless" because working in an agile team has a required social aspect that is difficult to be part of when you float in and out of the team on a regular basis.<br /><br />CDT ET testers (I'll try to think of some more acronyms to throw in front of that) are always trying to shorten that feedback loop with development and you can't get any shorter then being directly on the development team. I would even go so far as to say that the next evolution of our team would be to start embedding them with various development teams throughout our company.<br /><br />I hope that info is useful. I'd be interested to hear what your take is on the feedback loop.<br /><br />Thanks!<br /><br />Zaedzaedhttps://www.blogger.com/profile/08749113030648329933noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-36968252582254377912015-09-09T04:19:53.642-04:002015-09-09T04:19:53.642-04:00Good article and agree 101%. I like this paragraph...Good article and agree 101%. I like this paragraph<br />"We succeed as a team, so never go it alone in an automation effort. Remember that test automation is a development task -- i.e. programming is involved and all the supporting activities that go with it (like maintenance, version control, coding standards, and so on). Always be sure to include and involve your developers in any automated testing evaluations and efforts"<br />The success of an agile team is collaboration and lot's of communication. The separation of devs and QA's must come to an end and start working together to release an awesome product while enjoying working with your team mates!Happy_smilehttps://www.blogger.com/profile/09457534841441119826noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-2719814971040813762015-01-05T08:26:20.062-05:002015-01-05T08:26:20.062-05:00Thanks for sharing!keep it the sameThanks for sharing!keep it the sameAnonymoushttps://www.blogger.com/profile/17292875450208421060noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-24437412064629862102014-12-07T03:29:01.728-05:002014-12-07T03:29:01.728-05:00TNX!TNX!http://www.sacredhypnogoddess.com/40-days-of-inner-power/https://www.blogger.com/profile/14496654331352618082noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-24868734206222947632014-08-25T05:11:46.393-04:002014-08-25T05:11:46.393-04:00Agile testing tends to have all-automated tests wi...Agile testing tends to have all-automated tests with short feedback between test execution and test result and it is a software testing practice that follows the principles of agile software development. Informative and helpful post!!!agile testinghttp://bizsense.innoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-47311017942879093992014-07-23T04:32:29.903-04:002014-07-23T04:32:29.903-04:00Nice post. This blog is very helpful for beginners...Nice post. This blog is very helpful for beginners and professionals. I like it very much.Unicode Technologieshttp://www.unicodetechnologies.innoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-14609437624992480752014-03-14T02:01:59.855-04:002014-03-14T02:01:59.855-04:00My name is Jerry, and have been doing consulting n...My name is Jerry, and have been doing consulting now for over 18 years - in the testing arena - across many states (CA, TX, Northeast, and global): kudos to you Paul.....for having the self-confidence to express your personal adverse experience with HP products. Reading carefully your piece, and the replies from what obviously seem like HP salespeople or company folks on the thread (defending HP), I totally understood the essence of your blog title, and what you really meant by it. Actually, the bias was obvious to me from those who were too quick to basically categorize you as almost "loony" and "emotionally in distress". Well, fact is that I go back way back....since Y2K testing and have used QC, QTP....and I can submit with confidence 5 points: 1) HP has spent millions on advertisement and promotions...and that accounts more for the popularity of their tools...then the quality of them, 2) in recent years, HP has changed their business model from, direct distribution, support, and sales of their products, to now having vendor (contracting companies) do the selling and distribution for them...this is proving to be a nightmare...from a communications and support angle...and is leading to a lot of frustrations, 3) years ago, you could go on the HP site and clearly view their license and price options....now, they force you to sign up with a vendor rep., allow them to give sales presentations, and more pitches before you can get price info...and this is proving to be a time killer and frustration for companies that are already informed about the products and simply want to move ahead with assessing purchasing decisions...so you have to wonder why has HP moved to such a "unfriendly" and "time consuming" model?, and 4) absolutely.....over the years, HP has clutter their software with so much coding that it has put a strain on their performance....so I', hearing across many blogs how QC adds more and more clutter to your machine's memory as you use it, that performance is being compromised. And #5) the biggest hurdle of all....HP has found itself in a battle with its' own business model by having to charge astronomical license prices (compared to other tools), in order to offset the $millions being spent in marketing and the $commission they now pay vendors (their new sales force). From a business angle, I think HP is slowly killing itself through these very bad marketing decisions. Regarding product knowledge...hate to burst the bubble for those defending HP in this blog, but your experience with that trainer is more the case today then the exception with HP. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-20368602392037922352014-03-10T11:19:17.914-04:002014-03-10T11:19:17.914-04:00It's been a few years since I had to use QC (2...It's been a few years since I had to use QC (2010 was the last time, I think) so I'm not sure if it has changed, but this post brought all the bad memories rushing back :)<br /><br />Essentially, and in common with *many* test management tools, it isn't designed for testers to use in their day to day work, it is for management to get information on what testers are doing, or more generally in the overall status of the test phase of a waterfall project. <br /><br />In addition to the needlessly complicated setup work required before anything can start to happen, the bits that used to drive me crazy were the way that all test cases were sorted alphabetically within a folder, and modal dialogue boxes so you can't refer to your previous work when e.g. writing a new test case.Fionnahttps://www.blogger.com/profile/13482711994985922118noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-69725771924511778172014-03-01T02:51:33.337-05:002014-03-01T02:51:33.337-05:00Thanks for this posting. This blog provides best m...Thanks for this posting. This blog provides best method of software testing. It is very informative tips for software testingyogesh jihttps://www.blogger.com/profile/14923283980898059434noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-43052363582410488902014-02-21T00:55:44.194-05:002014-02-21T00:55:44.194-05:00Hi Paul,
I finally found a moment for a short rep...Hi Paul,<br /><br />I finally found a moment for a short reply.<br /><br />You mentioned: "For a start, I learned and practiced ET long before the Agile Manifesto was written. That tells me that I am not necessarily doing AT any time I am doing ET."<br /><br />Surely agile software development existed before the Agile Manifesto was written? For example Jerry Weinberg wrote on Agile Impressions how they were doing incremental development already on 1957 at IBM and how this was, as far as he could tell, indistinguishable from XP. Or how they formed, most probably, first testing group on Project Mercury early 1960's. The testing group on Project Mercury was composed of skillful programmers and worked rest of the development team along the project, from day one. Depending on your definition of Agile Testing, I think glimpses of that was seen 50 years ago.<br /><br />If we dismiss the historical references, the latter sentence on your quotation is hard to tackle unless I understand better how you define Agile Testing. How do you define it by the way? (In a sentence or two) Or Exploratory Testing? I for example define Exploratory Testing as "Approach to testing that emphasizes testers ability and responsibility to explore an unknown object or space through concurrent test design and test execution."<br /><br />Perhaps even more important is WHY do you think it's useful to have separate definition for Agile Testing?<br /><br />I personally think exploratory testing is part of basically all software development projects. It varies a lot though how consciously it is used. I've been participating to workshops in my current project, where we're discussing with business, what features should be implemented and if the suggested piece of software is even giving business value. Next week I'm participating technical documentation reviewing meetings and later sprint planning. In all of these I do exploratory testing. I listen and observe the information. I come up with questions "What if we add this 30 character long email address to this field in this system X?" or "In what kind of physical environments users are using this product?" Then I evaluate the answer and modify my next question based on the answer I've received. Or ask later when I have thought about it for a while. Responsibility steps in when I try to optimize my ability to ask those questions and having perhaps better base knowledge about the subject before attending to meetings. I do think that's exploratory testing and it is part of working with a team. When those questions get asked when we're having face-to-face meetings, others hear them and often have to react to them, if they're inclined to answer. That makes it more team's story than individual's story.<br /><br />You also mentioned: "Yes, I believe that knowing ET will help make a better Agile Tester. You need to know more than just ET though. You can also learn to be a great Agile Tester without formally learning ET. A good agile team will provide you with the feedback you need to help you grow."<br /><br />Needing to know more than just ET depends on how we restrict our understanding of ET. For me part of ET is collaborating with the team through those conversations I mentioned earlier and providing as much visibility as possible to my process of learning. <br /><br />What do you mean by "without formally learning ET"? If you're learning to be a great Agile Tester without formally learning ET --> What are you actually learning then? <br /><br />I'm glad you wrote this post as it reminded me of skimming that Agile Testing book of Crispin & Gregory.<br /><br />-AleksisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-16704015712478985662014-02-19T11:14:40.461-05:002014-02-19T11:14:40.461-05:00Hi Huib, thanks for the comment and the link to yo...Hi Huib, thanks for the comment and the link to your post on agile testing. I like the post.<br /><br />I agree that "agile testing is testing in an agile context" and that's how I usually describe it when coaching (and in my "Pitfalls" workshop). I also agree that the activities you listed may be performed in an agile context, and more. The Agile Testing Quadrants provides a nice way to think of many different testing/checking activities that may be performed on a given project. Individually, the testing activities themselves don't make you agile.<br /><br />When I say that "SBE is an exemplar of Agile Testing" I am referring to the Specification Workshop in particular, not the test case-like scenarios that are often automated for checking purposes. The Specification Workshop brings together the "three amigos" (Product Owner, Dev & Tester) to come up with examples that provide a shared understanding of the system. The gherkin notation scenarios (or Fitness tables, or whatever) are a happy by-product of the meeting.<br /><br />To me, the Spec workshop is the epitome of efficiency in Testing. You have the key team members together designing and testing the system in real-time before any code is written! I have often heard testers lament "testers should be involved sooner in the project, like when the requirements are discussed." Well, this is it. The Spec workshop puts Testing in the forefront of the requirements discussion. Every good tester should learn how to facilitate one of these meetings.<br /><br />I grant you that ET _<i>may</i>_ be done as a group, however, I have never seen it done that way (so far). I'd like to see at least two data points (i.e. companies/teams where this is practiced) before I change my language to say it is more common practice. I usually do paired ET as a form of coaching, to help testers learn how to do it. I encourage tester pairing (and know at least one other person who has advocated it in a past company I worked at) but it rarely sticks. Testers tend to work alone.<br /><br />I agree with how you describe how ET may be done with dashboards and daily touch-points, however, information radiators aren't a part of ET. I can't imagine doing ET without one, but they are mutually exclusive. That's one of the primary weaknesses of ET - it takes place in your head. An information radiator (like a testing dashboard) is one way to try and summarise the key points worth sharing with your team or other stakeholders. Info radiators _<i>complement</i>_ ET but aren't required.<br /><br />When programmers create code on their own without XP, pairing or TDD, yes, they are being non-agile (I reference Agile Principles #3 and #7-10). When designers design in isolation without external feedback, yes, they are being non-agile. Ditto for tech writers. I generally find that designers and tech writers are the most agile in how they work though. They have generally matured as a profession more quickly than programming or testing... although it is possible to irrationally work in a vacuum and I have seen that happen.<br /><br />So, is it possible to do ET in a way that aligns with AT? Yes! Does that always happen? No! Unfortunately.<br /><br />I like how you think about this topic, Huib. I believe we are on the same page. Based on what I have seen most companies doing, I can't take the one [agile] scenario you described of how it's possible to do ET as the one true way that it is always done. That doesn't match the reality I see today. There is a bit of overlap between ET and AT in the Venn circles, but not much.<br /><br />Cheers.Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-56720398128842103292014-02-19T03:37:15.422-05:002014-02-19T03:37:15.422-05:00Hi Paul,
Interesting blog post. But it confuses m...Hi Paul,<br /><br />Interesting blog post. But it confuses me...<br /><br />To me agile testing is testing in an agile context. Exploratory testing is a style that can be done in an agile context but also can be done in ANY other context.<br /><br />Testing in an agile context can include many things: scripted testing, automated checking, bug hunts, exploratory testing, Specification by example (or ATDD or BDD), TDD, etc.<br /><br />I am not sure what you mean by "Specification By Example (what I consider to be the exemplar of Agile Testing)". To me SBE is "just" a technique. I happen to like the technique very much, but testing in an agile context is way more than SBE.<br /><br />You seem to try to make the point that agile testing is team work and exploratory testing (or at least the learning) is done individual. And I do not agree at all. Learning can be a group thing. Exploratory testing can be a group thing: using an dashboard with the charters on it, discussing what testing should be done next, fits perfectly in an agile context and is team work. Paired exploratory testing is an excellent example of team work. It is all about sharing knowledge and learning together.<br /><br />Programmers can create code on their own. When they do, they learn during this process but work individually on the code. Does this make it non-agile?<br /><br />More about how I think about agile testing be can found in my blog post: What makes agile testing different? (http://www.huibschoots.nl/wordpress/?p=1072)Huib Schootshttps://www.blogger.com/profile/00870619240033128666noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-43491978795990334282014-02-17T14:33:56.191-05:002014-02-17T14:33:56.191-05:00We have done similar thing last year in Poland - T...We have done similar thing last year in Poland - TestingCup, and we are doing in again 2,3 june 2014. http://testingcup.com/<br /><a href="http://testingcup.com/" rel="nofollow">TestingCup.com</a><br />We hope to have 200 testers testing same time!TestingCuphttp://testingcup.comnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-18271648349822284382014-02-10T00:11:51.796-05:002014-02-10T00:11:51.796-05:00A very interesting article on testing management. ...A very interesting article on testing management. Thank you for posting. Zora Ferrelhttp://www.cloudstaff.com/noreply@blogger.com