tag:blogger.com,1999:blog-83512792208924495862024-03-05T13:14:05.489-06:00Prairie TesterThe trials and tribulations of a software tester on the Prairies.
I'm a Software tester who is passionate about my craft and career. Software testing is both, it's a highly skilled, thought provoking, challenge and joy.
Join me in my journey to become a better tester as I implement the ideas of those smarter than I. I'll talk about what worked, what didn't and why I think it didn't.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.comBlogger27125tag:blogger.com,1999:blog-8351279220892449586.post-5579172367329002052016-06-15T14:15:00.001-06:002016-06-15T14:15:19.968-06:00Saskatoon Testing Discussion Group: End of Season 4It's been 4 amazing years since I started the Saskatoon Testing Discussion Group. I'd tried to start a local interest group a few times before, but didn't have the reach or support needed to be successful. I'd like to thank <a href="http://www.vendasta.com/">Vendasta</a> for being a amazing sponsor for the group. They have provided food, drink and space for the meeting for the past four years.<br />
<br />
The group has changed a bit over the four years, and some of the sessions were better than others. I think that this latest season has been the best so far. To that end I need to thank the members of the management team that stepped up this year to help me plan and arrange the events. It has made the topics more widely applicable to more of the people in Saskatoon doing test (even on testers doing the role).<br />
<br />
We've tried to record and live stream most of our events so that people that can't attend have a way of catching up or attending remotely. We've struggled with the technology for this over the four seasons but it seems to be coming together better lately.<br />
<br />
With the end of our latest season drawing near, I wanted to take the time to say thank you to those that come out, those that help and those that have bitten the bullet and spoken at the gatherings. The other thing that I want to do is promote our last session of the season. We have <a href="http://satisfice.com/aboutjames.shtml">James Bach</a> of <a href="http://satisfice.com/">Satisfice Inc</a> giving a remote presentation to the group about the layers of testing and how they are all involved in every test. I'm very excited have have James speak to the group. I've heard him talk at more than a few conferences, and he is an excellent presenter that always challenges me to be better at my job. If you want to check him out before the talk, many of talks are on <a href="https://www.youtube.com/results?search_query=james+bach">youtube</a>, and is blog can be found <a href="http://www.satisfice.com/blog/">here</a>.<br />
<br />
Come on out to hear him speak on June 29th at 12:15 (lunch) in the <a href="https://www.google.ca/maps/dir//Vendasta,+220+3+Ave+S+%23405,+Saskatoon,+SK+S7K+1M1/@52.126521,-106.665033,17z/data=!4m16!1m7!3m6!1s0x5304f6e7cc477065:0x1ff248f9ca8335bc!2sVendasta!3b1!8m2!3d52.126521!4d-106.662839!4m7!1m0!1m5!1m1!1s0x5304f6e7cc477065:0x1ff248f9ca8335bc!2m2!1d-106.662839!2d52.126521?hl=en">Vendasta</a> Atrium. Pizza and pop provided, Please RSVP at <a href="http://www.meetup.com/Saskatoon-Testing-Discussion-Group/events/231594349/">Meetup.com</a><br />
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-3001717653690177422014-10-12T22:12:00.001-06:002014-10-12T22:12:45.746-06:00New Season of Discussions at the Saskatoon Software Testing Discussion GroupThe new season of discussions is starting this week. The gatherings have moved to Wednesdays from Tuesdays this year. Hopefully this won't be a problem for anyone and actually makes it easier for a few of you to attend. I plan to record the sessions and post them the same as in earlier seasons. They will be available on the you tube channel. In other news, there is now a Facebook group as well as the Google+ and Meetup pages. <div>
<br /></div>
<div>
The first discussion will be on "Estimating testing effort". I hope all of you locals can make it out. </div>
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-29540491933173584412014-09-17T08:25:00.000-06:002014-09-17T08:25:54.851-06:00Passion in testingI've thought a lot about passion and passion in testing lately. I was asked to speak to the september meeting of KWSQA about creating passionate testers. I've found this model for thinking about the training, mentoring and long term careers of testers as a refreshing thought pattern. Passion has some excellent imagery that can relate to careers and to testing.<br />
<br />
And so a question for you all.... Think about the things that you are passionate about. Have they changed over the years? Was is sudden? Or a slow change? Were you able to reignite the passion at a later time?<br />
<br />
I'm looking forward to talking to many of you about this topic over the next few weeks and months, and I'll let you know how the presentation goes once I'm done.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com1tag:blogger.com,1999:blog-8351279220892449586.post-12004224624355567572014-08-13T22:13:00.002-06:002014-08-13T22:13:38.706-06:00CAST 2014 - DAY 2There were a lot of great talks today. I was really impressed with all of the <a href="http://perscholas.org/experience/software-testing-education-program-step-new-york/" target="_blank">Per Scholas</a> graduates that I met today. If you work in testing in the New York Tri-State area and need testers, these men and ladies are top notch. I could talk about the talks that I saw today, and I will. I've decided to do a blog post about each one and have an actionable from each talk that I'll blog about later, but today I just want to talk about the final Keynote.<br />
<br />
The Final keynote was by Matt Heusser, and it was about the state of testing. While I don't agree with every thing he said, his desire to inspire us to go out and address the challenges of spreading the work of good testing was evident. There was an important conversation that happened during open season. The audience started to talk about where people in testing were going, and why they were leaving the profession. I understand that this is their experience, but it's not mine.<br />
<br />
My experience is that passion is infects. If you haven't met me in person yet, I tend to be very passionate about testing and it comes out when I talk about it. Software Testing is my passion, and my carer. I will talk to anyone about it, and every one. I introduce my self as a Professional Software Tester, and I extol the virtues of software being developed with Professional Software Testers involved from design through to delivery.<br />
<br />
I've been a Software Tester and a Test Lead for just over 8 years now. This started after I did two degrees, in Software Engineering and Computer Science, and I found that while I could design and develop, I was much better at Testing. Since that time, I have trained many people to be testers and inspired a few to become testers from other roles. All most all of the people that I have worked with in eight years as testers are still in testing. So I ask myself, why? Why when other are seeing attrition have I seen soo little.<br />
<br />
I think it boils down to passion. I work hard, I learn hard and I encourage others to do so. I do it with people at work, I do it with members of my testing community. It's why I lead the Saskatoon Testing Discussion Group. I ensure that testers that work with me have mentors and access to opportunities to learn. If all employees had this let alone testers, there would be happier workplaces.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com1tag:blogger.com,1999:blog-8351279220892449586.post-50084825360908942772014-08-13T07:11:00.001-06:002014-08-13T07:11:41.443-06:00CAST 2014 - Day 1What an amazing first day. <div><br></div><div>It started with a great talk by James Bach about how testing is not Test Cases. Test cases are just an artifact of testing, and much of our work doesn't invlove test cases. This got me to thinking about how what we do is all testing, but very little is test cases, and those test cases are more of a group of ideas for the next tester to think about when they go to test. Even if a tester was to use a test case with detailed steps, the a good professional tester would still go "off script" to better understand what the test case was trying to illumunate. </div><div><br></div><div>It was a very full day of learning and talking with other testers. It's been a full day, I'll write more about what I learned later. </div><div><br></div>Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-66374483075066554322014-08-11T20:36:00.001-06:002014-08-11T20:36:13.849-06:00CAST 2014 - Day 0 (Tutorial Day)<a href="http://www.associationforsoftwaretesting.org/conference/cast-2014/" target="_blank">CAST </a>(Conference for the Association for Software Testing) this year is in New York at NYU. I've just spent my first day at the pre-conference tutorials. I spent a really fun day hanging out with other professional testers and learning about how we as people discover things. IE, how do we as people examine things, make guesses as to what they do and refine or refute those guesses until we understand something. It was a really good tutorial session lead by <a href="http://mavericktester.com/" target="_blank">Anne-Marie Charrett</a>. We were looking at research from the social sciences by <a href="http://en.wikipedia.org/wiki/David_Klahr#Bibliography" target="_blank">David Klah</a>r and learning from it so that we could use it to inform how we as testers could improve how we discover.<div>
<br /></div>
<div>
As testers we discover things all the time. We discover the quality of the item we are testing, we might discover good or bad quality, but the path to discovery is the same. Learning to examine the steps that we are unconsciously taking to make those discoveries allows to to take conscious control over those steps so that they can be refined and improved. </div>
<div>
<br /></div>
<div>
It's been a few full days here in New York, I hope I'll write more later. </div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-79915829166360688742014-08-10T15:00:00.001-06:002014-08-10T15:00:55.407-06:00It's CAST time againIt's that time of year again, and I'm off gallivanting and visiting my favorite testing community at CAST. This year it is in New York at NYU and while the actual conference hasn't started yet, hanging around with this many other professional testers and people that like to think about test is inspiring, motivating and generally a great experience.<br />
<br />
I came out early to attend TestRetreatNYC, a open space for test interested people to gather and talk out their testing questions and ideas in wonderful environment. Thanks to LiquidNet and Anna Royzman for letting us use their space, the amazing space certainly helped the discussions. Also thanks to Matt Heusser for organizing it, and Matt Barcomb to helping us run an open space.<br />
<br />
I was involved in great discussions on how to grow small testing teams, and testers communities. There were also discussions about the trends in Automated Checking (some call it testing...) but I was at a session about the trials and tribulations of being a lone tester on an agile team. My favorites sessions were about test leadership and the parallels between attending an experiential drama performance and testing.<br />
<br />
Like many of these event some of the best discussions happen not in the formal sessions but in the hallways, bars and hotel lobbys where we just throw around ideas and riff off each other. I have some new things to try out, and as before, good or bad, I'll share them here once I've tried.<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-R_WX2oaWyj8uXAErsiSdRmWA5DyPqjDd8owFj7ygXB_7_VQe3fV0Es-CiNZarqGKshsSr6wXqUo0ykCYuH958mW8ylMf4yHitCX9bo3GQcdAF1OfOQKwlcsZg5Y9TuFik0eUCcXaDhQ/s1600/20140809_201513.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-R_WX2oaWyj8uXAErsiSdRmWA5DyPqjDd8owFj7ygXB_7_VQe3fV0Es-CiNZarqGKshsSr6wXqUo0ykCYuH958mW8ylMf4yHitCX9bo3GQcdAF1OfOQKwlcsZg5Y9TuFik0eUCcXaDhQ/s1600/20140809_201513.jpg" height="240" width="320" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-69213946511126216382013-10-08T08:41:00.001-06:002013-10-08T08:41:10.311-06:00Off WeekI was planning to blog about API testing this week, but I seem to have a really busy week this week. The local testing user group is meeting on tuesday and the Saskatoon's First Lean Coffee is this thursday. Currently I lead both groups. So I'll be back next week with API testing. If you have any heuristics or tools that you use for API testing, Please feel free to put them in the comments on this post and I'll include them in next week's series. Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-32548689617154260752013-10-06T15:07:00.001-06:002013-10-06T15:07:24.081-06:00MindMaps In Testing: Wrap upSo I spent a week without using a notebook, a testing management tool or any notes except for mindmaps. It was an interesting week, I think I actually took better notes, missed fewer dark corners of the applications that I tested and was able to share my work with others easier. Alot if this was made easier by the use of colors on the nodes in my mind maps. I used bold colors for things that I needed to come back to later, and light variants once I had come back and done what ever action was needed. <br />
<br />
<br />
Lets take a look at what my process looked like. Every Day I reviewed my Maps from earlier in the week to see if there was anything I needed to pull into todays map as a item I planned to do. So before my day even started I had a map with a center node that was the days date, surrounded by any tasks that carried over from the previous days and the items I planned to do that day. If there was a task that carried over the the previous day, I would copy the node over with every thing that was under it so that I had my notes from the earlier work to guide my continuing work. I found that my exploratory testing was very much assisted by this exposure to my previous results. I was able to make links across sessions and generate new charters with better insight than I had when I used a notebook for this same process.<br />
<br />
As the day progressed, the first level nodes that I was working on would progress through several states denoted by color. White for upcoming tasks, yellow for the currently active task, Red/Purple for tasks that needed to be revisited, and Green for completed Tasks. If that was all that I had done, this would not be as great a tool as it ended up being. Also made notes on the tasks, and did my test planning under the testing tasks. Since I used an electronic MindMap tool this allowed my test plans to be fluid and dynamic based my results. Results from the tests were also recorded in the MindMap as were all of the defects and other issue I noted. Again these were color coded to allow me to make notes about them and not get distracted by opening my bug reporting tool and spending time then reporting, but rather making enough notes that I could come back later to do a RIMGEA analysis and better report. <br />
<br />
<br />
I found this technique very useful. My entire day was in one place, I could break pieces out to share and collaborate with others, and I missed less. I will continue to use MindMaps in this way, and will continue to look for new ways to use MindMaps in my work.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com1tag:blogger.com,1999:blog-8351279220892449586.post-70683926358993672212013-10-04T10:30:00.003-06:002013-10-04T10:30:57.773-06:00Schedule ChangeI've realized that my blog schedule isn't working very well. Writing Monday morning seems ok, but I really seem to be writing this post Sunday Night, So I' going to try and Release the Monday post either Sunday Night or Early Monday. The wednesday post doesn't seem to have enough exposure to the tool or technique to have a lot of insight, So I'm going to move this post to Wednesday Night. Same goes for the wrap up post, by writing to for Friday Morning, I'm losing a day of exposure to the topic before I write, so this will be Friday Night/Saturday Morning depending on my availability.<br />
<br />
Tune in tomorrow for my MindMaps Wrap-up.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-41179750120277212712013-10-02T08:26:00.000-06:002013-10-02T08:26:31.186-06:00SFDIPOT.... Huh?<span style="font-family: inherit;">One thing last weeks </span><span style="font-family: inherit;">exercise</span><span style="font-family: inherit;"> showed me was that while I'm familiar with SFDIPOT, I haven't used it enough to be comfortable with it. So let dive in, I'll explain what I know (or think I know) about using it and how I plan to use it this week. If I make mistakes, I fully expect the community to help out and show me where I'm using SFDIPOT wrong, and I'll pass that on to you. The original blog post about this by James Bach on his blog </span><a href="http://www.satisfice.com/articles/sfdpo.shtml" style="font-family: inherit;" target="_blank">here</a><span style="font-family: inherit;">. He's mentioned that developed this heuristic from surveying six or seven computer science </span>textbooks<span style="font-family: inherit;"> to lay the framework for his thoughts on application modeling. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">As I understand it SFDIPOT is a heuristic to use while doing a software tour to ensure that you have a complete understanding of the application. This is sort of how I use it. I actually do several tours of the application/feature in questions, all very quick and high level while thinking about each of these. I don't do them in the order of the Heuristic simply because I don't really think that way. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">So what does it mean? </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><b>S:</b> <b>Structure</b>, how is the application put together/wired up. These are things like: Uses Mysql as a server, Has a separate authentication server, Uses memcache and Uses Ajax. Things that can lead you down other vectors that you might not have thought of while doing a simple product tour. You might need to get help/information from the developers and or Documentation for this piece, as such I recommend doing near the end of the heuristic. </span><br />
<span style="font-family: inherit;"><br /></span>
<b style="font-family: inherit;">F: </b><span style="font-family: inherit;"> </span><b>Function<span style="font-family: inherit;">, </span></b><span style="font-family: inherit;">what are the functions of the feature/application. What are the individual things that it does. This can be a (organized) listing of all of that actions that can be done using the application. These are smaller than the user stories, these are things like "Mark favorite" and "Join mailing list". Stories will come later and will invoke many of these functions. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><b>D: Data</b>, what are the data types involved in the application. Data types can lead to interesting test cases. Have a look at Elisabeth Hendrickson's <a href="http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/" target="_blank">cheat sheet</a> for some great ideas on how to test your data types once you have identified them. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><b>I: Interfaces</b>, one of the newer letters in this heuristics (and thus harder to get information on), these are the interfaces that the application interacts with the outside world on. Does it have a file based interface anywhere (import/export functions?) Does it store intermediate files to a local storage anywhere? Is an api provided? Does one exists that isn't provided? And yes, the GUI is an interface, does it interact in the ways that a user will expect that kind of interface to interact.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><b>P: Platforms</b>, What are the platforms does this application run on? Is it a java app? Does the version of Java matter? Is it a Web app? Does the browser version or vendor chance the performance or interactions?</span><br />
<span style="font-family: inherit;"><br /></span>
<b style="font-family: inherit;">O: Operations</b><span style="font-family: inherit;">, What are the operations that the application is trying to accomplish? What is the purpose of this application? What are the mistakes can can happen when trying to do this operation? I've been asked if these are your User Stories and Test Cases, and the answer for me is kind of. User stories are </span>definitely<span style="font-family: inherit;"> things that are thought of here, but not just the stories, how those stories can go wrong and or get </span>interrupted<span style="font-family: inherit;">. Test Cases however are part of your test coverage. I'm using this heuristic to create a PCO which will in turn inform the creation of my test coverage.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><b>T: Timings</b>, Another recent addition to the Heuristic, Timings are what are the time based things you will have to think about with this application? Does your application have to run a specific time? What will happen if it runs on Feb 9th? Or runs over new years Eve? in 1999? What happens when two actions are done too quickly? Too slowly? A recent conversation with also pointed out to me that these can be environmental. Where is the application? What is happening at the same time? Is it rush hour at that time at that location? </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">As you can see, if you run through all of these, you will have a very extensive list of things to think about while designing your test coverage. As I said in the beginning, this heuristic while seemingly simple does take some practice to use, and that is my goal for the week. To use this heuristic and get better with it. </span><span style="font-family: inherit;">My plan is to use this in my everyday testing, for every feature and bug report from the field that is passed on to me. I realize that this might not align with the it's best uses, but I'm game to try, maybe I'll figure out something new about the heuristic, or about myself. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">I'll let you know how it's going on Wednesday!</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">If I have anything wrong or </span>misinterpreted<span style="font-family: inherit;"> in this, please let me know in the comments below.</span>Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com2tag:blogger.com,1999:blog-8351279220892449586.post-59680186280107862932013-10-02T08:20:00.002-06:002013-10-02T13:09:19.383-06:00MindMaps in Testing: Mid-weekA few days in of increased use of MindMaps in my daily routine and I have seen some interesting results. Like any technique that is new, the novelty of doing something a new way can drive higher short term adoption, and I have been able to consistently use my day notes mind map to track my day. I would normally try to write this in a log book, but I tend to forget. The ability to color code the nodes however has made this more likely to continue after the "New way" interest has worn off.<br />
<br />
So what have I done with mind maps so far? Two of my common tasks have been moved over to mind maps. Test planning for newly completed features, and my daily activity log. I have in fact combined these two into a single map, one for each day, where testing won't span more than a day. Where testing will be a multi-day or multi tester effort, I've split it out into a separate map. The daily activity map has helped me track my day and make notes on the activities that I do. I've marked with color finished tasks, blocked task, bugs found, future investigations and test results. The color enables me to quickly look and see what I need to remember. I used to do this with my notebook, but it's been hard to find the tasks and future investigations easily later when I go looking.<br />
<br />
The tool that I've been using has a mode where it will auto color the nodes for you based on a color change at the leaf level to indicate that you have completed a task or been blocked if you are using your MindMap as a plan/to-do. I don't usually write detailed plans, I write down a list of areas I want to test, and some notes under each of those about why or how of that testing area. This feature the MindMap software that I'm using allows me to quickly look back and see what area's I have left to cover in upcoming charters, and update based on the charters that I've completed.<br />
<br />
<br />
All in all, MindMaps have been a good addition to my work. I haven't had to share the information in them with others yet, but I expect that to be helpful also.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com2tag:blogger.com,1999:blog-8351279220892449586.post-84916513558388908252013-09-30T16:28:00.004-06:002013-09-30T16:28:35.220-06:00Mind Maps as a Tool for TestingA lot of people have written about mind map and testing recently because the tools for working with and sharing them have gotten so much better. There are really smart excellent testers out there that use mind maps in their daily work flow, and I've been trying to add them to mine since I got back from CAST 2013. This week I'll use them any time I would have written anything down. <br />
<br />
For example:<br />
<br />
<ul>
<li>My activity log for the day complete with bug and investigations will be a mind map.</li>
<li>Testing Plans</li>
<li>Exploratory Charters and the notes/results from them</li>
<li>Feature/Bug/Product outlines will also be done up this way. </li>
</ul>
<div>
I hope to create 4 or more Mind maps a day for the next 5 days. It should be an interesting experience. </div>
<div>
<br /></div>
<div>
<br /></div>
<div>
Read on for some dryer text on what mind maps are and how I will be doing them. </div>
<div>
<br /></div>
<div>
<a name='more'></a>Mind maps are a recording technique that for most people allows them to organize their thoughts in a manner that more closely reflects how they are thinking about them and see patterns that are forming. I've done mind maps with my daughters to help them organize their thoughts on an assignment they were working on. Mind Maps can be done on paper or with a application. The central idea is that idea and thoughts are connected to the ideas and thoughts they are related to and located near other items that they are related to. </div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl-fJ4AtMdewnQlXzY18vJkJkBJsToymUKrRbYoGqUL3VedQZQXoj4UXrDjzmiZRphcsJdmUsjvrRoE9Apvst5tccUmit72WejLk75YupQGrPFfP2dE_l5vKXr_QqPVboxF5eEJuJkRww/s1600/Kijenga.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhl-fJ4AtMdewnQlXzY18vJkJkBJsToymUKrRbYoGqUL3VedQZQXoj4UXrDjzmiZRphcsJdmUsjvrRoE9Apvst5tccUmit72WejLk75YupQGrPFfP2dE_l5vKXr_QqPVboxF5eEJuJkRww/s640/Kijenga.png" width="640" /></a></div>
<div>
<br /></div>
<div>
The important thing to remember is that the relationship are as you think of them, it's your mind map. There can be as many nodes connected to a node as you want. Like color, use it!. Something related in two places, put it in one and draw the link to the other. With practice you will be able to create mind maps that reflect your thought process.</div>
<div>
<br /></div>
<div>
One stranger way that I'm using them this week is my daily work/activity log. My central node is the date, and all of the first level nodes are the major activities of the day, bug or features that I'm testing. Under these I have notes that occurred to me while I was doing it. Bugs that I will need to come back to file (so that I can do RIMGEA). I'm using color to tell me how important the items are, if I need to come back to them and what was injected into my day. </div>
<div>
<br /></div>
<div>
There are many applications out there for working with them. The two that I'm using these days are <a href="http://www.xmind.net/" target="_blank">Xmind</a> and <a href="http://www.mindmup.com/" target="_blank">MindMup</a>. </div>
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-33219060898210945972013-09-27T10:16:00.001-06:002013-09-27T10:16:09.205-06:00Random Data Tool: Wrap upA week of using a random data tool has not shown the amazing benefit I hoped it would. This might have to do with the tool that I choose to use, and might have been that I wasn't really using the tool the way it was designed.<br />
<br />
I prefer to use self-validating data as often as I can, and thus random data isn't always useful. When it was useful, I used it, but ran into a few blocks. The service that I was using didn't provide all the types that I was wanting (valid US phone numbers, multiple formats), or didn't provide enough variation to suit me for the data types it did have (Like name, only used normal english names) I was hoping that this tool would help drive me into some of the corners of the data set, but all it really did was keep me in the center of the path with different values that didn't diverge far from the norm.<br />
<br />Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-41347356733274799932013-09-24T08:03:00.003-06:002013-09-24T08:03:54.239-06:00Random Data toolI was originally going to write about a API testing heuristic that I stumbled upon recently for this weeks blog series, but I'm not planning on doing any APi testing this week. So instead I'm going to write about a new tool/website that I recently discovered for generating random data of various types. <a href="http://testspicer.com/" target="_blank">TestSpicer</a> provides a set of post/get api calls that will generate "Random" data for you. Need users name for a test account? Call the name endpoint. Need an image? There's a call for that. In Fact there are currently 19 different end points, many I won't use, but this week, I'll try a few and see if it helps me find some a bug by creating an account that I wouldn't.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com1tag:blogger.com,1999:blog-8351279220892449586.post-46767203077696574712013-09-23T11:36:00.001-06:002013-09-23T11:36:07.388-06:00RIMGEA: Wrap-upUsing RIMGEA for the past week has been a great exercise. It certainly improved my bug reports. I didn't get to the point of all my bug reports being fully RIMGEA or the bugs fixes that I reviewed being fully explored using RIMGEA, but I did see a improvement in my bug reports and bug exploration.<br />
<br />
Lets look at these two sides of how I used RIMGEA and the challenges that caused me to shortcut using it fully.<br />
<br />
RIMGEA as a bug reporting Heuristic:<br />
This is the intended use for this Heuristic, and it works well here. If you are rushed for time, or have a large number of bugs to report, it's unlikely that you will use all of it. For some bugs I didn't get past the R(eplicate). Once I got my replication steps, I could write a convincing bug report. However, this past week I tried to get further with every bug. My reports were definitely better. Reducing all the possible variables out for the I(solate) was hard, and often I overlooked some, but looking for them certainly helped my testing in other areas. I think I'll do this exercise every few weeks until I can consistently get into the last few letters of the Heuristic. <br />
<br />
RIMGEA as a bug verification Heuristic:<br />
This was a bit of an off-label use, but I thought that if the bug hadn't had this done to it when it was written, the fix might not cover all of the incarnations of the bug either. It worked for me. Often replicating the bug in the pre-patched system showed the the bug had been fixed earlier and the new patch wasn't actually needed, or that there were other paths into the bug that had not been examined and fixed.<br />
<br />
<br />
All in all, this was a productive exercise. I'll do this one again, and share it with my team.<br />
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-55096970954024616002013-09-18T14:48:00.004-06:002013-09-18T14:48:51.934-06:00RIMGEA: Mid weekThis one has been a little easier to do. I'm not trying to use it outside of its scope, and that has helped. Additionally, I know that a well written bug report helps the developers find and fix the bug, but sometimes I really don't need as much information on a bug as RIMGEA would have me provide. Nor I do not have the time to do all of RIMGEA for the six bugs that I need to file before I leave work for the day. That said, having a note on my desk reminding me to use it has increased the quality of the bug report, just not all the way.<br />
<br />
One change that I didn't expect was the change in how I've been verifying bug fixes. Many of these bugs come on from external sources or non testers. Many get to the developers before a testers has had a look at them. Thus when they do get to me, they rarely have replication steps let alone any of the other items outlined by RIMGEA. Filling in a very quick RIMGEA has increased the depth at which I verify these bug fixes to almost a full exploratory testing session. Making the bug fix verifications more through. It's caught a minor issue that I might not have caught otherwise.<br />
<br />
<br />
So Far So Good with this Heuristic. More on Friday!<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-91522295841379980032013-09-16T21:30:00.002-06:002013-09-16T21:30:23.080-06:00RIMGEA: A Bug reporting HeuristicLast week I looked at a heuristic that helped me with testing, and planning my testing. It even helped me with isolating a bug and replicating it. If that was all that I did, it might be the only heuristic that I need in my daily work. (Un?)Fortunately I also find bugs, and bug reports are one of the main forms of written communication that exists for me or my team. Thus, a well written bug report that has all of the elements can be important, or at least as important as the bug we are reporting.<br />
<br />
This week I'm going to concentrate on writing better bug reports by using the <a href="http://searchsoftwarequality.techtarget.com/tip/Software-testing-is-improved-by-good-bug-reporting" target="_blank">RIMGEA heuristic</a>. This heuristic developed by Cem Kaner and gives the user a series of steps to go through to ensure that a bug report has enough information that others can correctly evaluate and prioritize the bug you are reporting.<br />
<br />
<b>R, Replicate</b>: Ideally all bugs that we report are replicable, we might not understand all the variables involved in the bug yet, but in order to move on in this heuristic the bug needs to have a series of steps that will replicate the bug. If it doesn't we need to spend some time coming up with some steps. If these steps only sometimes replicate the bug, try to refine them so that it can consistently replicate the bug or at least describe how often these steps can replicate the bug. Sometimes how often a bug can be replicated using the same steps is an important piece of information.<br />
<br />
<b>I, Isolate</b>: Any given set of replication steps will have any number of things that just happen to be that way, but the bug doesn't need them. Identify these elements so that we know what is really involved in the bug. This step will help with the next two.<br />
<br />
<b>M, Maximize</b>: This is to find out just how bad this could be if everything went exactly wrong. The version of the bug that you have discovered or have been asked to improve the report for is not likely the worst case version. Since you have isolated the bug you should be able to determine how to make the effect greater.<br />
<br />
<b>G, Generalize</b>: This goes part and parcel with Maximize and Isolate. Since we know what the isolation is and how to maximize it, the other side of this coin is what is the easiest version of the steps, or what is the most common path a user could follow to trigger this bug.<br />
<br />
<b>E, Externalize</b>: This one is important, not to the bug, but to your ability to inform others of the effect of the bug. To externalize, you describe the impact of the bug to the users, their data and their ability to complete the task that they are trying to complete with this application.<br />
<br />
<b>And blandize</b>: Ok, they stretched it on this one to make it an A, but it is an important aspect of any bug report. To find a way to report your bug without making it personal. They could have used O for objective there also and it might have made it clearer to the users<br />
<br />
Interestingly, I filed a bug report for work while writing this blog post. My bug reports will have to change a lot to this week. It's not that my bug reports are incomplete, I feel that I write them to the appropriate level of detail for who will need to read them. However, I didn't do some of these steps. It should be interesting. Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-68176501027885632912013-09-13T06:44:00.002-06:002013-09-13T06:44:47.315-06:00SFDIPOT: end of week ReviewWell it's been a week of concentrating on using SFDIPOT in my testing activities. So did it make me a superstar tester? Did it show me every bug? Was my team amazed at the testing plans I wrote? Could it cure cancer and bring about world peace? These are all (well mostly) important questions that I have to answer when I ask myself the most important questions: Will I keep using it? Will I encourage others to use it?<br />
<br />
Did it make me a superstar tester? No, but it did have some excellent benefits. It reduced my testing time be giving me better direction when I setup my testing plans. It gave me better insight into bug investigations. It gave me new ideas of areas to test to add to my list already too long list of areas to investigate. I wasn't really looking for a single item to change and I'd become a superstar, I was looking to improve, and learn. That part of my mission was a success.<br />
<br />
Did it show me every bug? No, but I was able to find some sooner than I would have otherwise. I don't think there is any tool or technique out there that will find every bug, the search space to find every bug is impossibly large. So a better metric might be did it help me find more bugs, or find the bugs faster? In my experience from this past week, yes it did.<br />
<br />
Was my team amazed with my new testing plans? Not really, for me, it didn't change much. I can see it creating better testing plans for some, but in my environment, working in a agile development team, I don't often share my testing plans. My testing plans are usually something I write for myself so that I don't forget anything. Being a single tester on a team has lead to some bad habits, but I'll deal with those another week.<br />
<br />
In all it's been a good week. I enjoyed this emphasis on SFDIPOT, and the extra thought it helped me do in my testing activities. I didn't really use it as much as I meant to, I'll keep using and teaching it to the team of testers where I work, and I'll keep you updated if I learn anything new about it in that journey.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-60048961309407276862013-09-11T10:14:00.003-06:002013-09-11T10:14:40.000-06:00Mid-Week with SFDIPOTIts been two days of my renewed attempt of learning SFDIPOT by using it for all of my testing activities. So far I have used it in conjunction with a product tour, a bug verification/investigation, and a the test coverage planning for a single feature. I've been surprised to find that it helped for all three. The bug investigation was the one that surprised me. I thought I might have to heavily modify SFDIPOT to use it, but it has started to flow nicely and more comfortably. Here's some quick thoughts. from the early week.<br />
<br />
<br />
Understanding a technique takes time, and often trying to explain it to others. I think I learned the most from about SFDIPOT writing monday's blog post. Michael Bolton and James Bach were both generous with their time and knowledge and review my post before it went live and discussed with me some the place where I wasn't truly relaying what they meant. There are still a few places in my post they are not completely what they mean, but they are in areas where I'm still not sure what they mean. <br />
<br />
There's never too small a item to use this technique if it is stumping you. Yesterday I had a bug report come in from the field. The replication steps were simple, except they didn't expose the bug except at the customer site. After spending some time trying to figure out what the difference was I pulled out SFDIPOT and took the time to do a structured approach to my thinking about my investigation. Very quickly I identified the missing variable and was able to get refined replication steps that reliably reproduced the bug.<br />
<br />
The last thing this exercise has shown me is the the structured approach helps me even when I'm working with a old existing feature that I've tested many times. Today I was able to quickly identify a place where testability could be improved while i was doing a code review and using SFDIPOT to guide my thoughts. I haven't even thought of the test coverage yet, but I already know it will be easier to test because I was able to fully think about the feature.<br />
<br />
It's going well so far, I've even had some developers asking about it! I'll be back on friday with the round up!Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com1tag:blogger.com,1999:blog-8351279220892449586.post-15097241175954200382013-09-07T23:02:00.000-06:002013-09-08T15:43:56.604-06:00San Francisco DepotOne of the things that I identified last week in my excursion into PCOs, was that while I'm familiar with SFDIPOT, I haven't used it enough for it to come naturally. Thus my plan for this week will be to use it in every testing situation I can. Even some where it doesn't make sense at the outset. In order to really know the ins and outs of a technique, using it improperly can show you what and why the limitations are so that you can get the most of that technique when you use it.<br />
<br />
Reading list:<br />
<br />
<br />
<ul>
<li><a href="http://www.satisfice.com/articles/sfdpo.shtml" target="_blank">SFDPO</a> - The I and T were added later</li>
<li><a href="https://twitter.com/huibschoots/statuses/306908462179311616" target="_blank">T added</a></li>
<li><br /></li>
</ul>
Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-77648296357612778222013-09-06T05:42:00.001-06:002013-09-06T05:42:13.180-06:00Change of Plans, PCOs and Lean CoffeeI was going to blog today about my week of using PCOs, but it turns out that a 4 day week is not enough time to really get a feel for this technique. I did share it with my agile team, they were confused. I shared it with my testing team and they were very excited. I'll come back and write the third part of the PCO experience next week at some point.<br />
<br />
However, that doesn't mean I don't have something to talk about today! Today, lets talk Lean Coffee. I first experienced Lean Coffee at CAST 2013. It was a great experience there and I've been looking for ways to bring it back to Saskatoon ever since. Yesterday I did that in a small way. <br />
<br />
The test team that I lead has a weekly meeting where we get together to discuss various testing related topics that have come up in the past week. This has taken a few different forms, from learning sessions where we have a specific topic that someone teaches about to Highs and Lows sessions where we talk about the best and worst of the past week. While these meeting were achieving my goal of getting the team together and helping solve their problems, I didn't feel the team was engaged. One member has been consistently asking to skip, and if I was away the meeting didn't happen. I might have a solution, for my team at least.<br />
<br />
Yesterday, instead of starting the meeting as I usually would by polling the room for impediments from the past week, I introduced Lean Coffee. When I was done and they set to it, every person had put forward at least two topic ideas. While we didn't have a lot of time, the dot voting did direct us to the important items quickly. The few topic cards that were left when we finished were either filed as: 1) lets do this as a one on one later, 2) This can wait until next week, or 3) that other topic card covered what I wanted from this card. It was a great experience and I felt my team more engaged in the meeting than I have in months. <br />
<br />
If you haven't been to a lean coffee, you should try it. It will change the way you think about small meetings. It works really well for short meetings of people with a related interest to spur on great conversations that might not happen because you don't know that others are thinking the same things. I'm hoping to spread lean coffee further at my workplace and even around saskatoon. <br />
<br />
For more reading about lean coffee see <a href="http://seattle.leancoffee.org/resources/" target="_blank">here</a> and <a href="http://leancoffee.org/" target="_blank">here</a>Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-62074796807613087422013-09-04T06:43:00.000-06:002013-09-04T06:43:08.313-06:00PCOs, two days in.....Well not really two days in. It's a short week here in Canada with Monday being a holiday, but I did review some of the reading that I said I would read before starting on this weeks subject. It gave me good insights into what I would be trying to add to my existing processes.<br />
<br />
So far the exercise has lead to some interesting insights into the product that I work with, and it certainly will inform my testing and test planning. I have noted however that as I usually work mostly on features and feature integration, a lot of this <b>felt </b> like extra effort. I'm sure it's not, but time will inform that.<br />
<br />
Additionally, as I don't often use the SFDIPOT heuristic, it felt clumsy. I can see that with practice it will become a very useful tool to help my thought process, but I spent too much time trying to figure out what went under each of the headings.<br />
<br />
Come on by again on friday for my summary of using PCOs for an entire week.Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-89878824625164090122013-09-02T06:00:00.000-06:002013-09-02T06:00:05.827-06:00Monday: Product Coverage OutlinesA product coverage outline is not my invention, or my term. I picked up the term from <a href="http://testingthoughts.com/">Paul Holland</a> at <a href="http://www.associationforsoftwaretesting.org/conference/cast-2013/">CAST 2013</a>, but the concept is something that most of us are already doing. However without formalizing the activity we might not be doing it as well as we could be. I currently do something like this as a mental exercise, but I don't think I do it very well that way. I think I miss things because I don't write it down or review it. This week I'll be trying out a more formal written Product Coverage Outline.<br />
<br />
A Product Coverage Outline (PCO) is a document (doesn't matter what kind) that you develop to assist you in thinking about the product that that you will test. It is important to note at this point that this document is about the product, not the testing and it is not the documentation. Paul even suggested that you do not read the documentation until late in the process of creating this document so that it doesn't limit your thinking. There are many ways of doing creating this document and all of them are ok, as long as it is something you and/or your team developed to help illuminate the product. I've seen great mind maps that expressed a product coverage outline, excel documents and word docs. Some of these are easier to read and work with than other, but all did the job. This is because the job is not just the document, it's the process of creating the document the stirs our thought process and helps us ensure that we have thought about as much as possible. That way when we go to create our testing plan, we can consciously choose what's being covered and not instead of some areas not being covered because we didn't think of them.<br />
<br />
That's a lot of talking about a PCOs without saying much. What is the goal? The goal is to create a document that you could give to any tester on your team to give them a concise overview of the product that will help them decide how and what to test in the time that they have. Combined with a heuristic approach to exploring the product you should be able to quickly create a document that achieves these goals.<br />
<br />
For this week I'll be using the SFDPOIT heuristic to help me ensure that my PCO's are complete. If you've never heard of SFDPOIT check <a href="http://www.satisfice.com/articles/sfdpo.shtml">this</a> out. My PCO will be done with a Mind Map and have first level nodes for each of the terms of SPDPOIT, but that isn't required for a PCO, but I think it will help.<br />
<div>
<br /></div>
OK, how about an example? Since I obviously can't show anything from my job, lets take the classic triangle problem. I looked around and found a triangle calculator <a href="http://ostermiller.org/calc/triangle.html" target="_blank">here</a>. If I use the SFDPIOT heuristic and a mind map I can quickly create this PCO:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYZYXFDnHmq1MPSgrmPymfyEmqVwtqAsUZq9F_4VrWcdFULTf-RRPISP9M4rP6sjLYD0OQCwElTXJt4M4VXzcmmkAF3P6Tz6A-HdimMsRVU9v1wJMYmfm7RUo6l1VQqyXq9Et55GhDkrc/s1600/triangle_pco.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYZYXFDnHmq1MPSgrmPymfyEmqVwtqAsUZq9F_4VrWcdFULTf-RRPISP9M4rP6sjLYD0OQCwElTXJt4M4VXzcmmkAF3P6Tz6A-HdimMsRVU9v1wJMYmfm7RUo6l1VQqyXq9Et55GhDkrc/s640/triangle_pco.png" width="640" /></a></div>
<br />
I spent maybe 15 minutes doing this PCO, from it I should be able to come up with a reasonable Testing plan.<br />
<br />
See ya on Wednesday!Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com0tag:blogger.com,1999:blog-8351279220892449586.post-40418050136207191132013-09-01T11:28:00.000-06:002013-09-01T11:28:20.054-06:00My PlanOk, I've heard the biggest problem people have with writing and blogging is not finding a topic to write about but more precisely they run out of things to write about because they their topic is either too broad and they hit writers block or their topic is too narrow and they exhaust it. I've heard that the best solution to this is to find a topic to write about that you are passionate about and to have a plan.<br />
<br />
Well since you are reading this, you can tell my subject matter. I'm obviously here to talk about software testing, but it's more than that. I'm going to do a three part explore of my subject matter. My regular blog pattern will be a Monday/Wednesday/Friday pattern of experience reports. On mondays I'll lay out the new technique that I'm going to be exploring that week. On Wednesdays the blog will be shorter, as it will be a progress report on how it's going so far. Fridays will recap the week and explore what I liked about the new technique, what problems I had and solutions if I found them.<br />
<br />
If you'd like to join me on my journey, I'll try to announce the topic for the next week on the Saturday or Sunday so that you have time to do some reading. This weeks topic will be Product Coverage Outlines. <br />
<br />
Reading List:<br />
<br />
<ul>
<li><a href="http://www.satisfice.com/tools/htsm.pdf">Heuristic Test Strategy Model</a> (pdf) - I'll do an entire week on this later</li>
<li><a href="http://www.developsense.com/articles/2008-10-GotYouCovered.pdf">Got you covered</a> (pdf)</li>
<li><a href="http://www.developsense.com/articles/2008-11-CoverOrDiscover.pdf">Cover or Discover</a> (pdf)</li>
<li><a href="http://www.developsense.com/articles/2008-11-AMapByAnyOtherName.pdf">A Map by any other name</a> (pdf)</li>
</ul>
<br />
<br />Anonymoushttp://www.blogger.com/profile/16141468737761368754noreply@blogger.com4Saskatoon, SK, Canada52.1343699 -106.6476559999999851.9784439 -106.97037949999998 52.290295900000004 -106.32493249999999