Possible Exciting Things (or I'm hoping to attend or speak at)
Agile and Beyond March 10 Dearborn, MI
Agile 2012 August 13–17, 2012 Dallas Fort Worth
World Class Quality
We have no idea what quality is
We are even willing to lower quality, as long as it is cheap and we can outsource it or simplify it
| ...<< MORE >>
I have a new perspective on what is possible with automating acceptance tests for Agile stories because I've seen it working better than I believed teams could achieve! I'm inspired.
Seeing some very good testers finding some new bugs and becoming even better at working with their developers is the most rewarding part of coaching so far.
One bug was found that went undetected for a decade because of a tester learning new exploratory testing techniques! It's talent she had all along, but now it is set free!
Got to work with a developer that I admire to troubleshoot an issue that was important to a client, and made a major breakthrough on it in just a few hours.
I had no idea how friendly, open, and kind people were in the middle of the country. It sounds odd to say, but in Seattle, people don't often invite me over, or offer to have lunch, or greet a new person and go out of their way to show them around. The fact that it isn't just one or two people, but most of the people I've had the honor of working with makes me want to do my best work for them even more than I already did.
Working in an open space, I've learned that I need to be a bit more careful. I'm loud, enthusiastic, and I have distracted people on accident, slowing their progress at times. Enthusiasm can be good, but breaking someone elses flow or distracting them unintentionally isn't.
There is an unfounded fear that some testers are dealing with that I'd like to see wiped away. Code should not be used to confuse, belittle, or intimidate anyone. I assume (sometimes wrongly), that testers have understanding of programming concepts, when in reality, our experience and comfort level varies. I'm proud to say that I'm working on material for a quick class on Object Oriented Programming Basics for Testers. One of the testers on my team is going to collaborate with me make it stronger and present it with me for any testers who want to come learn or review.
I've learned that I'm limited. I tend to get excited and think that because I want to do something, that I can go on forever without free time, sleep, or time to care for myself. As a result, I've been in worse health the last month. I've literally fell asleep onto my laptop twice. I'm growing, but I know it is possible to learn and grow without self-abuse. I just haven't found that balance yet. I suppose I had to test myself to know what the limit was. ...<< MORE >>
I believe that boundary testing is in the calculator exercise in Testing Computer Software, which is also known as "The Bible" among software testers. Despite the fact that most professional testers know that we should be testing for boundaries, I'm finding that often, these tests aren't well performed, and even when we do perform the tests, the bugs aren't fixed! Here is a true story about several different bugs found in one day, just by testing ONE boundary.
A bug was found that when a certain number or more characters were entered, truncation did not happen. This error was handled, and an error dialog was brought up, alerting the user. Unfortunately, this application is expected to be run without a person watching (without a UI, or also known as headless in some circles). This meant that for all practical purposes, the application was frozen. A fix was put in place, but I was curious to test all of the boundaries. The team created an exploratory testing charter.
When the charter was run, we found MANY diverse behaviors depending on where we exceeded the expected characters.
1. In some cases, the application would crash. We wrote a bug on this straightforward issue with ease.
2. In other places, truncation happened, leaving unusable and incorrect email addresses and ages. These are easy to report, but difficult to know what is "expected" or what would be desirable in that case.
3. The most interesting issue we found was a silent failure. The entire entry would be skipped, and the log would report for example--Success! 10 entries imported. 9 Correct 0 Skipped 0 Errors. Subtle silent failure is the riskiest issue we found in my opinion, because if you are dealing with many enterprise solutions, you might have millions of imported pieces of data per day, and nothing to check that any are ignored, truncated, or missed.
A few things to think about in terms of boundaries. It isn't just how many characters, or what characters, or is "replace with nothing" or "null" allowed, or can you delete nothing that concerns me. The better question is, on what scale are these issues fixed? Will the headless system ever be fixed so that NO error dialogs will put it into a useless state again? It is easy to test for the error conditions that we handle. It is the error conditions that we don't handle and don't expect that we need to test for. This is why unless we have tested the boundaries and error handling ourselves, we should not assume that because it is basic that it is covered, or that because in one part of the application it is handled, that it is handled everywhere.
...<< MORE >>
If you haven't checked it out, I am proud to be in such great company with the other authors in the April edition of Teatime for Testers.
Read online at http://issuu.com/teatimewithtesters/docs/tea-time_with_testers_april_2011__year_1__issue_ii
Or download the PDF at www.teatimewithtesters.com/#!downloads and click on the icon of the April issue. I recommend getting all of the issues if you haven't. They are fantastic reading.
...<< MORE >>
I got into an interesting chat on twitter about "Happy Path Testing". You see, in the experience of one guy, exploratory testers just don't have the patience to test requirements. They get bored and stop seeing problems when they become familiar with a UI. Well, it seems to me he is blaming several different issues on "Exploratory testers", when really they are issues with some people, and all humans. Let me break it down for you.
Issue 1: Functional Testing is part of the job.
By this, I mean testing the requirements and verifying correct behavior (I.e. "The Happy Path") is part of every testers job. There is NO exception for Exploratory testers. The difference is, with Exploratory testers this is where you start (your acceptance criteria), not where you finish. In many modern software testing groups, there is some automation in place to make sure that the happy path stays happy. This may be in FitNesse, Selenium, Unit tests, TDD, and it may be created and/or maintained by Developers, and/or testers. Usually the basic happy path is best covered by developers, and more complex combinations are covered by testers using some sort of scripts or tools, but the point isn't to automate all testing. It is simply to automate the boring testing so that humans can do what they are better at rather than running the same test the same way time after time. Also, just because the test is automated doesn't mean you never need to test it manually. It is good to test the user experience from time to time. Automation has a narrow validation scope in most cases. A human can generally detect more variance than automation can.
Today I spent several hours validating 117 XML files and out of those I had a list of 2 separate issues. It turns out there was a valid explanation of both problems. So. Did I waste my time? Am I doing a poor job? I say no. No, because this was new functionality that needed thorough testing. Even a slight problem would be quite expensive in this area, and this data change involves some math. I had to validate beyond the smallest scope to make sure that the changes didn't impact more than intended. The FitNesse tests and unit tests not only passed, but were reviewed by another developer, and a tester. Also, this was a new area for me, so I learned more by going through these files difference by difference to understand why. However, why did I stop short of validating all 580 of the files? For a great reason. After testing over 20% of the files, I didn't find even one unexpected difference, yet, I'd validated every expected change over 100 times total. It is possible that I missed a bug, however, the likelihood was low. I conferred with my fellow testers. We all found the same results with different tests. The fixes were good. Did we feel bummed out by learning ...<< MORE >>
When in a small web company, Agile releases are real. By real, I mean they SHIP, and then you get feedback. In situations where you don't actually release the software at iteration end, done means different things, but until it is released and people are USING it, it isn't done. Even then, it isn't truly "done", but that isn't my point. My point is, we set up these arbitrary iterations to help us meet our goals, yet it is just a structure if we aren't actually releasing at the end of a sprint. There are many business reasons why it isn't always possible to release that often, as well as testing considerations! It isn't always best for the customer to get the latest code every few weeks even if we like the short feedback cycle. My point is, when you aren't really releasing, there is an awareness that the iterations are a fake framework slapped on top of a real release schedule. This has some pros and cons. Also, I've learned in the last month that business size has little correlation to agility. I'm working with a very agile team at a large company, and a team which isn't following any process I've experienced before at a very tiny company. Overall, I'm glad to be experiencing both!
-Ability to work in testing that spans features. There is a huge gap in the general "Agile Testing" strategy used right now. That is the basic fact that many teams using Agile aren't on the first release anymore. There is a huge debt swamp of regression, building changes, and outside risk to be slogged through, sifted, and planned for. If we prioritize these, they can be great to automate, manually test, as exploratory charters, or even as end to end collaborative test exercises.
-Flexibility in validating bug fixes. We aren't REALLY releasing. This means even if others try to impose an emergency, we testers can be wise and stay calm. Emotions can be useful in testing, but they are deadly and dangerous to making good decisions. We can keep things in perspective.
-Partial stories don't have to make sense to the user. We just have to demonstrate them internally.
-Retrospective, burndown, & backlog all regularly get done, so we can incrementally improve.
-No feedback from users!
-Not really getting the full advantages including actual practice of a full release every iteration.
-Testing is still going to be different before a real release than it is for iteration end.
-Little to no incremental insight into how to adjust our testing to improve it.
Personal Life Stuff
Much of my daily life has changed! Long time no post, and mostly that is because of all that has been happening behind the scenes. First, I've gone independent! Yep. I am now the sole owner of Spark Quality, LLC. In a few months a business website with all sorts of info should be ...<< MORE >>
Sorry I'm so tired and congested in this video. You can tell I'm not feeling 100%. I did want to remember to come back to talking about this idea of improving speed & accuracy though. Please share if you have your own ideas on making exploratory testing faster & better. Also, how do you judge what is most important? Faster? Is there ever a point at which we are happy? Can we ever say that our testing is "fast enough" or "good enough" for now? Will we always be shaving off any second we can in order to be faster than the next team? ...<< MORE >>
One of the important testing questions that I don't see asked often enough are performance related design questions.
1. How long do we keep trying for?
2. What do we do while we are trying?
3. When we fail, how long does that take?
4. How do we define fail?
5. How many ways can we fail?
6. What if we fail in another way?
7. Can we clearly and correctly define success and failure?
8. How does failure impact the user?
I have an example here of what I love to see and one that really bothers me, and the difference is really subtle.
In free Hotmail, which is supported by ads, when faced with a connection issue, I'm shown my email and an ad error. Good choice, Microsoft! The ads will give up and live to fight another day. They will accept failure to the ad server this once, still give me my email, and the next time I click, they get another chance.
Also, while I'm pretty happy with this fail, it could be better. How else could it fail? When should they require success to show me my email?
...<< MORE >>
What is the important part of a test?
Why do so many companies track them step by step? Is it the charts? Business people LOVE the chart, the number, show me how you saved money/earned money. What is the bottom line? Why do I pay for this? They want to know.
Here is my ranking system in the last 10 project I've worked on:
1. The Question the Test Idea is Trying to Answer
10. The Test Idea
15. The Test Data
100. The Topic
1001. The Title
1002. The Expected Result
Either 2 or 2002 depending on how you are using it. The Actual Result (at that time)
When judging the priority of a test, how important is the question that the test will answer? This helps me prioritize better.
...<< MORE >>
Today I tested a feature which supposedly allows a user to upload a training video. I reported a bug that I was unable to load any of our small files, even the smallest video we had. I got an appropriate error which informed me of the upload failure due to exceeding the file size. The maximum file size?
Well, that doesn't look so bad, does it? If you gave me that many dollars, I'd be pretty rich! So, that leaves me trying to explain a few things.
1. People don't speak in bytes. I mean, not since the early 1990's. Not anyone I like to talk to, unless they are talking about converting FROM bytes to something more useful in the UI or using byte comparison to detect changes for automated checks, but I digress here. The point is, bytes do amazing things, but video takes more than that. If we are attaching a .txt file, I'm happy with this limit.
2. Before they followed gmail in offering ever growing free space, I believe Hotmail allowed 20GB space for users for free! Don't quote me on that one, because it's been so long since I had to much about with deleting my photos and excel spreadsheets that I've forgotten. The client I'm testing for is paying money. YouTube lets any video jockey who wants to upload a cute kitten riding a roomba have bandwidth at 5GB a pop and that's while compressing the daylights out of it for you so it will fit in the 5GB beach bucket. We aren't talking cinema quality here. Yet we can't allow these paid users upload more than .001 GB of video? Feel free to point me to .001GB worth of video to show me what kind of video training I can upload. I'm sure it will be very informative. Rated G or PG only please. I keep content to PG13 or below. It's me, so I have to allow for an occasional "d" or "s" word, but I try to avoid dropping any "f" bombs on my kindly readership.
3. Why? Why bother to support a format without supporting the ability to upload files IN that format? It's like the gift of the Magi, but less sweet. However, I had fun giggling about this defect. The funniest thing about this defect? It isn't considered a bug.
What? How can this not be a bug? We're talking about 0.001GB allocation. Several years ago, before they moved to mostly unlimited, free Hotmail allowed users 20GB. YouTube is giving us 5GB per video. Has been for ages. Cloud space is going for $.03 per hour (after a setup free, some contracts that said something about rumplestilskin, and a few cloudy things). By calling this NOT A BUG do you realize what you've done? You've made me do it. Yes, I researched the average hourly wage of EACH user by area and job title in the US who we intend ...<< MORE >>
My current project is quite busy right now for me. I'm on my forth week of overtime, and despite being prepared for the crunch, I'm becoming a bit weary. Therefore, I'm taking a break to share with you a few things I've learned recently about testing as a consultant. I've heard many testers explain what is and is not in the scope of their "job" as a tester. Strict statements, such as "It is my job to provide information, but I don't assure quality." or "I make recommendations, not decisions." One of my favorites, heard recently, was "You are a consultant. You provide suggestions. It could harm your longevity with the client if you forget that!" Wow. There are some strong feelings out there about what boundaries we testers must stay within. Being a tester, exploring boundaries is quite natural for me. In fact, if I never check them, I could be guilty of self-limiting behavior, which is worse than testing boundaries to me.
I see my role as a consultant to provide what is needed for the project to succeed. Sometimes that is testing information. It certainly includes a solid testing strategy that adapts as the context changes, and it does include testing that is improving over time. On this project, I've created a new section to test plans that my boss plans to use for future test plans, I've started creating draft read-mes and delivering those along with some documents to help users to the tech support team which supports our product (along with dozens of other products), I'm doing the planning and documentation for UAT, and have done research to inform the deployment plan for the project. None of these things are traditionally testing tasks. I feel fantastic about this! Teams are smaller. The teams I want to be on should hire a flexible person who will grow over time. I want to keep learning skills. I also want to work with Developers who do what is needed. You need a diagram on how X works with Y? They will draw one on the white board to use for now, and possibly revise it later, but they don't wait for the planets all to align and a new analyst to be trained just to stay within their job description. This is part of the freedom of being a team member, and not just a role or list of skills. While not all of the tasks we do fit into "testing" strictly, I'm a consultant. That frees me up to do what is needed, which is not always testing.
...<< MORE >>
Deck the halls with specifications
Water folly lolly la, la la la la
Wad up the changed versions for decorations
Water folly la, la la la la
Don we now our passing deadlines
Waterfall folly la, la la la
Tripping bugs like aging landmines
Wateryfolly la, la la la la
Ok, I kid. In all seriousness, I've learned some great things going from Agile to Waterfall that I'd like to share. Scrum has a few problems that I'd like to see addressed. One is that the PO job is too hard! On the project I'm working on, we have a great team of Business and Functional Analysts. They are working with end users to design something that works overall WITH agreement and flexibility for change in the future. Because they demo the creation in Proof of Concept, and because there is User Acceptance Testing, there is more customer interaction than the Agile team I worked on. Also, instead of the product owner being the one who understands, we are all responsible for understanding and building/testing/designing what suits the business need. The part where someone communicates well with the users is deemphasized in the way Agile is often implemented, especially with Scrum.
So far the best part of working on this team is my stress level. I'm not working every weekend and until 1am. I don't feel on the verge of tears or like I'm working with an axe over my head. I have a reasonable amount of time to do things. The schedule is MORE agile than my agile project was. I do not miss the daily Scrum meetings at all. I meet up with the analysts when I have questions, and in this way communication is better than it was on my agile team.
If I could change one thing, it would be the specs. Rather than endless pages of documentation, we'd do quick presentations, diagrams, and demos. The recordings in video would be the working spec. It is getting the walk through and agreement that matters, not the format. I also notice that business people read even less than we do. No one making business decisions want to read a 150 page technical spec. I like the agile approach better.
I've realized I want to work on a team with great communication, a flatish org structure, and to have trust. I'd prefer a place who doesn't do "initiatives" and instead is focused on building great software (what works over what the process is). I don't think scrum or waterfall are good answers. In fact, I think scrum as practiced has little to do with the agile manifesto.
...<< MORE >>
Firstly, I must now approve all comments as spam has run rampant. This is an attempt to manage it. Once I approve you to comment, you can always comment, so please be patient as I try to make my comments worth reading in this blog. Rather than posting this on Wednesday as I'd hoped, I found and reported a bug to GoDaddy.com. Using a workaround, I now present to you the video blog I'd planned to share 2 days ago.
In case you don't have 5 minutes, let me summarize.
I did a webinar today on 9 Tips to Encourage Collaboration hosted by Frank Cohen from PushToTest.com. I'll share the link once it is posted next week! Everyone can watch it for free and send me comments/questions/throw rotten tomatoes! Today's webinar was the first time I presented with a cat on my lap the entire time. It was quite calming, although I blame her for me going over time as I normally leave 10 minutes at least for discussion and stories. Kind of weak to give a talk on collaboration and then not take any input? Yeah--Well, give me some input.
I'm reading Weinberg on Writing right now. I like it, but as I lazily skimmed the exercises I've decided to go back and do them all instead of being that "instructions are for wussies" arrogant girl that I can be sometimes. Rules? What rules? I break them or make them, don't abide by them.
Also, THANK YOU. To the people who read my blog. To the many people who've helped me get started and grow as a speaker and writer this year. To the people who believed in me when I got laid off. To those who recommended me and showed up! Happy Thanksgiving.
...<< MORE >>
There has been plenty to read lately about the Future of Testing. Some of it from testers who I greatly respect, and up until now I've held my tongue and instead rambled on about topics I know more about, such as the real experience of using a schedule to keep me sane on my current project. Paying attention to the context of my assignment and changing my test strategy to be more waterfall (gasp) because that is what the client is asking for. So, considering that my current testing for the most part in much like testing I did in 2003, who am I to talk about the future of testing? I'm Lanette. Also known as Testy Redhead by some. I'm not here to predict the future of testing. I'm here to ask what people are smoking that makes them think that because they are great testers or that because Agile is really popular right now that they suddenly are psychic friends and can accurately predict the future. I must call some shenanigans on method used to predict the future here. I do so with all respect for the TESTING expertise of people involved, as they are talented at testing and have great ideas. Predicting the future didn't make the cut for me in terms of their great ideas though.
First, what I'm talking about is this summary blog from Sauce Labs which isn't the main culprit, but merely the straw of pseudo science that broke the camel's back. A few weeks ago, Elisabeth Hendrickson ASKED (note: She did not state a proven fact, she wrote a question) in her blog if Agile development had changed the skills employers hiring testers are asking for. She did some investigation, and found that among employers running want ads for testers, a certain percentage were asking for coding skills. She speculated that this meant that in the future testing will look like this set of skills employers are asking for now.
Chris McMahon took this a different direction in his blog, but then again, he doesn't talk about what it means or does not mean when some employers who post ads ask for certain things. Furthermore, he goes on to talk about "New Frontiers". Agile is the mainstream way to develop and test now. It isn't a bleeding edge anymore. It IS the mainstream. Doing automation isn't new. Asking for programmers isn't new. Microsoft laid off everyone who wasn't years and years ago. Has it already been 5 years? Yes I believe we are coming up on it. Testing the emotional response of Badgers with various mobile ringtones to determine human response would be new and possible blazing quite a frontier of testing. Not sure if Chris would listen to me speak on it, but it would be new. When I think of frontiers in software, I think of people with the guts to work for free. Open ...<< MORE >>
You Want it When?
Doing test planning for my current project phase has been a challenge because we have so many things to complete in a short period of time. I was totally overwhelmed looking at the total number of things we had to test with two people. It seemed impossible for awhile even though I know it is possible to deliver helpful test data in ANY context being from the context driven school of testing. There is one simple thing that was a huge breakthrough and it is totally simple.
We have a testing schedule for the rest of the project. A what? Yes. A simple list of what happens when so I know if we are behind or not. This isn't for the project. It is just for us. Because if we do things to plan we WILL deliver great testing. A simple weekly schedule for us to follow is the simplest thing in the world. So why? As an agilist what in the living daylights am I thinking?
1. This isn't an agile project.
2. It isn't in my control.
3. This isn't one project. We have about 8 mini-projects to manage instead.
4. A test plan ain't gonna cover this situation unless it helps us DO the testing.
Break it Down
What buckets of testing do we need to complete? I don't mean test cases, I mean huge buckets/topics of testing. This is just the headlines.
What is due when?
What can we start?
What do we need first?
When do we have to start what we need first to be finished with that when we can start?
Line it Up
For us, lining up what to start each week helped. Could be different in other situations.
One Day, One Tester, One Deliverable, One Completion at a Time
No longer stressed. If (and this is a BIG if) we get what we need to start on time, I am CONFIDENT we will rock this project on the testing side. This is well within our capability. It can be 20% messy and we'll still pull it out. Haven't figured out how to express that risk in the plan other than show days slippage on dependencies. Examples are welcome.
...<< MORE >>
Collaboration << MORE >>
On time and under budget do not matter to end users, yet it still is rewarded and desired at most businesses, even those who claim to be "Agile". It doesn't matter if the team "does agile" if the corporation does the standard individual financial compensation. They only can do a limited version of agile and it will be corrupted from within the team. The true motives aren't guided by the agile manifesto when each person is out for themselves. If you have that sick feeling that something is wrong with Agile in practice and you don't know how to put it in words, consider this blog. Consider that it may not be an Agile problem at all. What if the reward infrastructure is causing some perversion instead? The misunderstanding and twisting of Agile from what is defined in the manifesto.
How would you feel if you knew that your team mate made 10% more than you simply because of his height, or because at the time he was hired the company was really desperate to get someone in? What if your co-worker is simply prettier, younger, and thinner, with better dental work, and for that reason seen as having greater future potential. That is worth say 25% more than you make. What if you all worked very hard to meet the project goals, but because you were a week later than estimated, even though time to market wasn't critical to the sales of the project, your team lost out on a bonus? What is the bonus rewarding? Does it include something for the long term well being of the company? Or is the software being treated as a hot potato to get off of your plate and dump it on someone else? What about sustainability?
Signs of Perversion/Moral Ambiguity
When I first heard about Test Driven Development, I think my bias for testing blinded me. I was only thinking about the first part! Test Driven. That is when the fantasy began. What would Development be like if it was driven by testers? Testers of power? Like capes and spandex? I wonder if I'd get a tiara, or at least a lunch invite if my tests were really great? Would Developers really care about testing if we used this magic bullet? All I'd heard was the title. In the 1 day between hearing the title and my first research, I'd built up this idea of what this exciting new thing was going to do! Every possible misconception was there. Some of the false things I believed were:
1. It is for testers.
2. Testers do this!
3. The testers start FIRST, and THEN, well, the coding happens.
4. The testers DRIVE the development, so they have the ULTIMATE POWAAAAH!
5. No testers, no code.
6. No testers, no project.
7. Developers really are going to be thinking about testing and learning the practice because they are interested.
8. We are going to pair with these Developers and put in tests right as they code! This is going to be so cool.
9. Integration testing WILL be a part of the definition of done (of course).
10. Tests will have to pass, including error scenarios, complex end-to-end tests, and usability for this code to be considered done.
11. If the tests break, the code moves out of done and is now "undone".
Let's just say that Test Drive Development isn't that. I don't know why I thought it might be. Not that my idea is so great, but I'd be interested to know which parts of it would be good if it were tried for releasing software.
So, what IS Test Driven Development from what I've seen? Well, it is this practice where almost always, when coding, the developer thinks of a test and makes it fail. Then the dev will write code to make it pass! Quite simply, it is a discipline. I think many devs at first would find it torture. It is test hindered development when you first do it, but long term it can save lots of time. But what is it really? It is a way to build in your own unit testing. Now, it could be MORE than that. You could work with a tester and after your basic functionality is completed, you could add some more tests to it, but that isn't what the practice is right now. Now, at best, you get code with related tests that work completed in the code. In a way, that is some ...<< MORE >>
Opinions are worth less than a test result.
A long hypothesis about what WILL happen is not worth much. Go test and find out what does happen. The best part about being in test? It is a verb. Go test. All of that "not testing" stuff you have to do during the day? It is stealing time. If you have to choose between teaching someone else the basics of their job, of doing work that the team needs and was offloaded on to you, or you've been assigned doing tech support for the product or you've been loaned out to 3 other projects? You are NOT testing. That means the people you are working may not understand why testing is important.
It is very difficult to appreciate the absence of a pain you've never felt. I've heard testing described by many as an information service we provide a business. It is up to the business to decide what to do with that information. But how far does that go? Is it up to those who know little to nothing about testing to determine HOW the testing should be done, or what is and is not important to test? How much responsibility to we have to educate our stakeholders about testing? What if they have little interest? Is testing still just a service if you come up with a list of areas of risk and the business person in charge of the project tells you that they don't care about that? What if the area is security and all of their customers will be at risk? What if it is part of a life sustaining medical device? Is there any pointwhere you draw the line and testing becomes more than just a service to a business person? There is the classic excuse I hear that it is "just software" and that it can't kill anyone. I've worked on software that could kill a business or harm someone's reputation if it failed.
I expect to be testing. If things are ready for testing, I expect to be involved in making things testable and strategizing and learning to make testing more effecient when it can be performed. To be designing tests as the software is created. I expect the same of my fellow testers. Testing should be their default state. If that isn't possible, anything needed to prepare for testing, and if that isn't possible, anything of interest to that tester to sharpen and grow their testing skills should be the default. Yet even though "Agile" is now the default development methodology, I still see these lengthy test projects where months are spent before a single test is run, and this is by the "Testing" team! Rather than run one small test and fix it, this lengthy upfront test design procress starts and for months all testing is ignored completely, because eventually the test framewok will be ...<< MORE >>
"That is the only way we can know for certain," insisted a wise co-worker after he requested detailed analysis on how the application handled a missing reference.
Do we have to know for sure? What will we know for sure? If we ask the developer, we may know for sure their opinion and intent in creating the code. Not what will actually happen, but what they anticipate will happen.
I explained that what I like to do is perform a test. To force the missing reference, and test what will happen. This way what we know for certain is the behavior of the application under test in this environment, which means we know something more important than what the developer intended. We know the impact and the result of what actually happens.
I'm not discounting the importance of understanding the code, but I am saying that asking other people is of far less value than performing a test. If you aren't sure HOW to test or force that condition, by all means, ask. But an answer is not the same as a test. A test result is something that may be influenced by fewer assumptions than the opinion of a developer on how their code works. ...<< MORE >>
If all you knew about testing you learned from the interview, what would you assume after watching interviews for testers at the top 10 software companies?
The above process might make some sense if it wasn't paired with the http://agilemanifesto.org/. How are you possibly putting individuals over tools if you are ignoring every aspect of what makes an individual a good long term investment or a tragic one?
These interviewing ...<< MORE >>
Many months ago at the Writing about Testing conference I did a short point/counterpoint with Jon Bach about certification. I explained why I don't care about the topic. The reason I gave was that certification is annoying, like a small ankle biting yippie dog latched onto the ankle of testing. I didn't want to spend time on it when there is a giant pitbull attached to the jugular of testing as a craft & profession. Jon felt that anyone profiting from harming the profession of testing and preying on the ignorance of the uniformed should be called out and held responsible for their behavior, but at the end it turned out not to be a point counterpoint afterall. He has also seen the damaged caused by the ferral pitbull. In his talented thinking testers and the requests from his clients time after time.
For months now I've been thinking about how I can express what I see as the biggest threat to testing, and still I've not thought of safer words or a better way to express it, so I'm going to just get started.
Without much detail, the biggest issue facing testing as a profession is the perversion of Agile. ...<< MORE >>
On his first day at the new job Phil was really excited to be working again. With the economy struggling, he was thrilled to be working in testing once more and was determined to be the best tester he possibly can be. He immediately started asking questions and contributing ideas from the very start. He was seated in a cube next to another tester, Bill, who was working on a different project. Phil greets him excitedly, explaining how great it is that they are both working for SynergyLeveragers, Inc.
Bill, uncertain of the amenities at his new job had brought a sack lunch, music with headphones, and some bottled drinks with him. It was also his first day. Although friendly enough, Bill was taking more of a "wait and see" approach. He'd been in many jobs the past few years, and in his opinion a job had better earn his trust and loyalty. He's no eager newbie who just fell off the turnip truck.
Both Bill and Phil get their test strategy together and with their teams ramp up on the technology. Soon they are both creating test cases and getting plans finalized. Phil has some great days, some terrible days as his lack of knowledge leads to some difficulties. He smiles at people as he walks by, leading some people to believe he's up to something. Phil mainly keeps to himself, but gets to know a few members of his team.
Soon Phil notices a problem with the schedule. Basically it is very compressed! In his worry, he asks Bill what he should do about it. Bill suggest he do his best, realize that this is pretty typical of schedules for projects, and to let his team know what his priorities and assumptions are and to accept feedback. Well, Phil is a bit excitable and just feels it would be better to be upfront. He tells his team, Bill, and just about anyone who will listen that the schedule is unreasonable and so fraught with peril that he can't test it responsibly.
Bill casually shares his priorities with his team, and tests what he can, leaving some lower priority test cases totally unfinished. Bill does his work, but at the end of the work day, heads home to his real life. In fact, he makes sure when the team happy hour happens that he is there on time and enjoys a few drinks. While out he kids a bit about Phil, sitting in the room beeping and flapping unable to chill out. What is the point of life if you can't enjoy it a bit too? Balance is normal, but hey, if Phil is willing to burn himself out, that's his choice.
Phil stays late and gets his documentation finished and approved. He also finishes all of his test cases, ...<< MORE >>
I recently had an online chat with a friend going through some unexpected relationship changes. He talked about his past and it struck me how he said, "Once I stopped simply chasing tail,..."
There is a quote from the CEO of one of my favorite companies, Zappos CEO Tony Hsieh, who mentions in his new book, Delivering Happiness: A Path to Profits, Passion, and Purpose, Zappos became successful once he turned his attention away from chasing profits and toward the satisfaction and mentorship of his staff.
Since one lead to long term success, and one lead to failure long term, could you argue that my friend should have never stopped chasing tail? I wouldn't. He had the chance to be something better.
So, what does this have to do with software? Absolutely everything. The companies who are trying agile who don't understand why it is failing are failing to understand that it is a change of focus and mindset. You aren't going to do agile right if you are still chasing profits as your first priority. It isn't even possible. The founders and manifesto don't say anything about that, because the cost of entry seems low if you don't talk about the important stuff. The reason to use the agile manifesto as a guide when developing software is that you get the chance to be something better and more human, no matter the result. If you turn a profit or not, you'll still be improving incrementally.
So, why take the chance? Have you seen the end point of the other path? Really? Take a hard look at it. Is THAT where you want to go? Chasing profits leads to an unsatisfying end that is nearly always unsustainable. Stressed out employees in charge of huge chaotic outsourced operations. Cutting quality wherever possible. Cutting customer service. We see it all over the place at this point. It isn't idealistic to suggest there is another way. Companies are doing so right now, and they are improving their reputation with their customers and employees for taking the chance to try something better.
That brings me to process. A "maturity model" process "improvement" has a goal of making you more efficient in chasing tail. It says, "We'll come down to the gutter where you are and help you chase tail as efficiently as you possibly can!" There are many mercenaries who currently will sell you agile in the gutter. They say, "We'll come use agile to help you chase tail. Yes you can stay in the gutter there and we'll do some agile process." How about that agile manifesto though? It requires you to put people before process to follow it. It is really offering you a chance to focus on something else. It is a chance to be better. It ...<< MORE >>
Last week I learned that only employees get to whine. Consultants get to bring solutions. Immediately. Without whining.
Chris--Stop reading--metaphors beyond this point will drive you crazy.
I met a developer consultant yesterday at work. We talked agile stuff. I haven't been working on any agile projects. It is so strange to go from software development to working in corporate IT. We think the blazing edge of technology is home, where everyone is doing tons of automation, and how you code on a whiteboard is what gets you the job, and everyone has hardware and software purchased THIS year and is using the newest Agile methodologies at least that the last 5 years has to offer. That is not true. Do you realize most of the corporate world is STILL using old operating systems? We are talking Windows XP with IE6.0 is the setup I'm testing for. That is the current use. Why? Because I'm not working at a technology company. They have real products that need selling! They aren't selling the bleeding edge. In fact, the bleeding edge could slice of a huge chunk of their business. The bleeding edge is a risk they don't need.
New things, such as planning training. Seeing just how willing to work around bad design they are if it helps the business. This isn't about doing what is ideal. It is about something that will work for their needs right now. I'm working on a product that was selected because it covered more of the features. There wasn't much talk about how it covered the features, just that it was already working in practice for other large business, and that it met more of the features for the price. This is how companies win projects. Because on time and on budget are what makes you "reliable" in business. Not just what you deliver.
As a consultant, I'm working safely on the handle of technology. It isn't the battering edge. It isn't any edge. It is the safe handle of the knife where the technology is second. It needs to deliver safely, without drama. No diva applications allowed. Here is where I'd break into the song, "A Whole New World" from the Disney Film Aladdin, but being that this isn't video, I'll refrain.
I am learning 2 scoops worth of new knowledge each day I'm at work. It is sort of like visiting another country for me, where I'm not sure I can live there, but I'm glad I came anyways, and I'd like to see all I can of real life while I'm there. Yep. Consulting. It is like taking a cruise (this ain't no backpacking tour), and trying to help as much as you can at each port, and leave it in happier shape than when you arrived. Now THAT would be ...<< MORE >>
While adjusting to the early hour, the new commuting plan, and the woefully allergenic office mate had me concerned for a day last week, Friday things started to click for me on my new project assignment. I'm ready for Monday! I'm perfume free (hoping to help out the poor .net programmer who's allergies have been winning the war), have opted for comfort over fashion with the shoes, and I did studying this weekend on my application.
This testing assignment is TRUE acceptance testing. What I mean by that is the application is developed somewhere else, in fact, all of the code has already been deployed to production somewhere else. The configuration, suitability in this context, and integration are what I am testing! Having figured out the scope of my assignment, I'm realizing this testing task is different from testing for the software development team. In the past, my job has been to make the developers look fantastic and genius, because the software has high quality when released to the public. Now, that isn't my assignment. My assignment is to make the deployment of this software in this setting and configuration go so smoothly that internally it makes jobs easier, happier, and relieves stress and frustration for those doing the work. Being a big picture thinker, I have to figure out the overall goal before I can effectively plan my test strategy.
Even more exciting to me is knowing that I'll be helping with a round of user acceptance testing! Collaborative group test exercises and dry runs are my specialty. If I had to pick one area where I have the most experience, the most unique ideas that I've put into practice, and the most to offer software testing, I'd say without a doubt it is in collaboration. I'll have a chance to work with about a dozen users, and subject matter experts, including a lead who is going to coordinate and help the acceptance go well! I don't think I explained my experience in this area in much depth to my new boss, but he assigned me to the right project. I'm thrilled with what a good fit this is as I learn more. ...<< MORE >>
So far I'm really liking my new job. The challenges are different than what I thought or what I am used to. I'm not sure I thought about what it meant to be part of a consultancy group. Basically, I thought my job would be to do a great job testing for Starbucks, and as a QE Lead it would be like being a QE Lead for Adobe, where the lead part was going to be taking responsibility for the test strategy and taking more initiative to understand everything needed to deliver a quality product. That is not the case when you work for a consultancy. That is one portion of your job as a QE Lead, but it isn't all of it. Your job is also to provide test leadership to your consultancy. That includes helping testers grow, creating a more solid group of testers, thought leadership, helping test documentation, and helping to improve the test services offered by your consultancy. When I read it on paper, it makes sense. It is a learning curve for sure, and my first week at Starbucks is an adjustment! Here are some firsts that I'm adjusting to.
1. Earliest start on a job in the last 10 years.
2. Attire is business, with casual fridays being business casual. That means not a suit, but people dress like they are headed to a fancy dinner. However, today is Wednesday and after walking in heels too far yesterday I don't think I can wear heels again today. Ouch.
3. Very fun and active culture at Starbucks! This includes stairs in the middle of the building and everyone is caffeinated and walks faster than in New York! This combined with the nerve damage and heels means I'm in WHOA for the pain level.
4. Free coffee and tea drinks is fun! I made a chai latte yesterday. However, I do miss free soda. Going to bring my own Diet Cokes soon.
5. Both companies got me a laptop! Awesome. However, I now have 3 laptops total and I can't carry them all. I locked them all up and will have to figure out which I use where.
6. Thursday is our "unit meeting" in the evening for Sogeti, which for me means a day from 6am-9pm. Friday may be casual indeed.
7. After 9.5 years of having my own large office with a door I kind of enjoy sharing a room with 3 other people. I mean, I am social and extroverted. It is an adjustment though and I'm always afraid I'm making too much noise. I likely am, but I'll adjust. I guess I'm just used to not impacting anyone around me if I rifle through a bag, or check a text message, ...<< MORE >>
Checking out the comments on the Baby Cry Interpreter Challenge, the thing that had the most value to me was when one tester would point out the flaw in another tester's plan.
James Bach had a test idea:
"One test would be to play the same recording 100 times and see if the system consistently responded in the same way."
Curtis Stuehrenberg responded with a technical consideration: "Even analog recordings chop off the upper and lower ranges of sound, so recordings are not a true record of the sound generated in life. Digital recordings turn smooth sine waves into a sawtooth pattern unknown in nature."
So, we don't know if this is a test that will help us or not, but it is suggested again later by another tester.
Then Amanda Shankle Knowlton brings up something that I love. She suggests that parental satisfaction in actual use is a more important goal than technical accuracy! WOW! She shares the same ethical concerns as others do, but for this reason of considering the customer satisfaction as key, I am awarding a clear win to Amanda on this challenge. The win is because she is prioritizing our testing, a VITAL key to good test strategy. If Quality is value to some person(s) at a some point in time,** kudos to Amanda for clearly pointing out the users of this product and planning to use their feedback. So, what does she win? Sadly, just my admiration and the declaration that she is the winner of this challenge to me.
I am not dismissing the ethical concerns because I agree that it very important. I'm also not dismissing the value of determining accuracy of the product functionality, especially some of the tribal knowledge shared about similar hardware and defects to look for.
I have a new job! Starting tomorrow, I am a Senior Consultant (Full Time/Permanent) for Sogeti. My first assignment will be as a QE Lead on a project at Starbucks Headquarters. As a consultant I'll be working as a CW (contingent worker) at Starbucks through this project, and then rolled on to other projects as needed. This is a huge learning opportunity for me, as all of my experience for the last 10 years has been at Adobe. I feel thankful to my Adobe colleagues for all that I've learned as well as feeling excited for the new challenge to adapt and ramp up quickly to work with an amazing client team at Starbucks for my first consultant assignment with so much support from the other Sogeti Testing Services consultants.
...<< MORE >>
Now on sale for $39.99 from thinkgeek.com is the Why Baby Cry Analyzer which tells you why an infant is crying.
How would you ethically test this device? Would you change the strategy to test the iPhone app ? If so, how? Should there be a disclaimer? If so, what should it be?
What impresses me about these products is that they were developed and they exist. Most testers I know would be so concerned about the liability and ethics of diagnosing why a human baby is crying that they may not be comfortable shipping such an application, yet here they are, available as low as $4.99.
...<< MORE >>
For Mac users, or iTunes, here's the podcast format
This is a 7 minute video podcast (~20mb) where I explain why I didn't take offense when James Bach asked me what I thought a test case was and if I really agreed with the IEEE definition, which he felt was a poor definition.
For those who prefer to watch online-the YouTube version
This is my first podcast. Feedback is welcome on all aspects. ...<< MORE >>
This week I've been reading about software process. Agile, Performance, Waterfall, Lean, Six Sigma. It is assumed that testing is a part of these software development approaches, models, or paradigms. Is it? We hear "Test Methodology" or the "Software Testing Process". Is it really a process?
I don't know of thinking of it as a process helps. I'd like to think of it instead as an action, a goal, and important thing "to do". What is the "to do" of testing? Well, mainly to gather relevant information, with the goal of improving the overall quality. I am not one of those testers who believes the limit SHOULD be that testers provide information. Sometimes that is the limit of our power, but I believe testers can and often do coach and pair with developers to contribute to quality of the product up front. Even just by asking questions early on, even just by listening and adding in tests, even just by quickly providing feedback that developers can count on every build. If they know each day they are going to hear sanity pass/fail and benchmarks faster/slower that is feedback they can rely on. It is a reason to be careful, it is a reason to finish up so that the tests won't fail. It isn't about being tricky or "getting those developers", anymore than it is about them sneaking a bug past us. Giving reliable quality feedback to the team often can build trust. In the same manner, when developers who have a tricky fix to check in are willing to walk me through it, give me their opinion on what to look out for, and show me that they CARE about the testing, they build trust with me. They have a bank account of credibility with me as a tester. If they did this on every little tool tip spelling change I'd be annoyed and wonder if they were paranoid or what, but if on a complex or late change they take time to do this I think it is very cool. In the same way, in a situation where we need to do less testing than is ideal, I'll write a brief test strategy email and send it just to the few devs involved. Then I'll meet with them in person if I can, or just on IM or phone to see if they have suggestions. Ok, not JUST to see if they have suggestions, but also to see if it triggers any warnings in their mind when they think about that fix. If I did this for every single fix it would be a total waste of time, but I think it builds trust if they know I'm really serious about getting good coverage in high risk situations.
I bring this up because this pairing is inefficient. If process and savings are your top goal at every point in the project, our team should have been penalized ...<< MORE >>
I had such a good time and learned more about teaching, presenting, process, and agile in Las Vegas this week.
Thank you to all who attended my session: Testing for Quality Beyond the Code and Requirements.
I'm posting the final sides along with my notes from the slides where are in comment form on the PDF.
BeyondCodeandReqs.pdf ...<< MORE >>
My collegue Jon Bach pointed me to a project funded by the Agile Alliance to highlight some successful women in Agile today! See http://sites.google.com/site/diversityinagile/project-definition for details. The first thing that surprised me was the title. Why isn't it titled "Women in Agile?" I found it odd that it didn't mention any other diversity besides gender diversity. Let's face it, it isn't just women that are missing in most technology teams. Hispanic and black people of either gender are few. Also, let's not forget that the GLBT (not sure what order they go in but I'm talking about sexual orientation and transgender) are still underrepresented. However, this is one part of diversity, and they are DOING something. So many people just nod, complain, or use it as an excuse for why they can't go further. Not these people. They volunteer time to make a positive change.
There are many things I love about this project. First, it is volunteers who care doing this on their own time, and kudos to the Agile Alliance for funding a project that highlights the success of women in Agile! I'm proud of Lisa Crispin , and the longer I know her the more amazed I am at all she volunteers for. She inspires me. I enjoy the positive attitude that agile takes. It doesn't claim that this will solve the problem of diversity in software, but it shows a scope and something they WILL do and I think it will get people thinking. I love that. Rather than being petty or giving up because the problem is too large, or refusing to do anything until they can do everything, they pick something they can agree on and get to work.
If that isn't the spirit of agile , I don't know what is.
...<< MORE >>
I wanted to share with you my thoughts on the last blog post teleporter exercise, specifically what approaches I noticed.
Gauge the confidence of the engineer who developed the prototype
At first it may seem like a joke to the casual onlooker, but this is a critical step many testers do to assess the risk of the project. Part of asking the engineer to go first might be viewed in the Scrum world as separating the chickens from the pigs , or who has skin in the game. It was interesting to me how many people were interested in getting good data from the programmer now versus the past when Agile wasn't well known and wasn't often practiced. I thought this was an exciting change.
Cartoon from www.implementingscrum.com
Understand the Context (Situational Awareness)
Did you notice some of the distinct points of view that came out early on? Some people wanted to know as much as they possibly could before running even one test. Others were ready to jump in and get their information FROM the tests. I have a few theories on why this is, and I think it depends on the project which approach is better suited for adding value to the project. This is where the People before Process part of the Agile Manifesto is powerful. Ideally, to me, a tester is able to adjust based on what they find out. They will do what they can to advocate for good coding practice and coverage on the code, but will not be stopped by the lack of it if it is a situation where it doesn't exist. I think it is good to have a preference, but adaptability is a skill I admire in a tester. Opinions will vary, and that is just my preference.
You'll notice a few different ways this is done. Some people asked me more about the people who were involved, the client, the head honcho, and the engineer. Others asked me about the design for the machine itself. Some asked about the budget and timeframe. Others asked about hiring experts to help them collect more info.
Far fewer testers went this route, but I did notice those who did were people I know have lots of industry experience. This is something I try to do for every project.
Far fewer testers did this. I think that one reason is I framed this exercise as something in fantasy and most people were playing along. I don't think the testers would risk a human life in real life if they didn't ask, but there is something interesting about those who did.
...<< MORE >>
The most amazing thing has happened! The Star Trek teleporter has been created in a super secret prototype and YOU get to test it. Our head honcho wants to impress the client by having it ready for a demo where he will beam himself in from outside the demostration area and back out again in 3 months time. Nothing has been tested yet, but our engineer believes the prototype is complete and ready for testing.
How do you proceed? ...<< MORE >>
Selena Delesie recorded my short lightning talk among friends in the evening after StarEast sessions.
Because of the angles you can't see the cat photos that well in the video, so here are a few you can see more clearly.
This is Stardust, who is 2 years old and 17lbs and gaining. She's friendly and insane. She will eat all of the food in the house.
This is Tizzy. She is 6 years old and very shy. She burrows under blankets and often hides.
This is Ashley. She is 17 and would like to be an only cat.
A wonderful day! Seeing these two cuddle up together.
Ashley is still not impressed, but she'll let them live (for now). ...<< MORE >>
What is isolation? In testing we find a bug and we think first about isolating it. We want to break it down into the fewest steps possible to recreate the issue. The exact scope required to make the bug happen. If we can find out exactly what is causing the problem, all the better. It is much easier to route the problem to the correct programmer for a fix and have the bug evaluated by the right "bug deciding group".
Isolation also means you are testing one component at a time. Maybe instead of testing a core technology integrated into a product, you have a custom interface that allows you to test it by itself. This way you can tell if the application integration is the problem, or the code of the component itself. Perfect.
Unit tests are my example of isolation. A clean machine is another example of isolation. You don't want other software interfering. One application at a time. Perfect isolation. One tester working alone in an office with the door shut. Or one tester total for the entire team and consider your team lucky to have one at all. The lone ranger. The tester in complete isolation. Or you don't test with any deviation at all. Test driven development meaning pre-defined tests that we code TO pass. A great way to start and when they pass it is wonderful to know you can START testing (although I'd run a manual sanity test first as well, but I digress).
So what is up with this trend of tester isolation? I see these conferences and there is no one else from my company there. Not ONE soul. They are busy writing more tests and taking classes to test in more advanced "isolated" ways.
In object oriented programming, it is ideal to create things in a modular, or isolated fashion. It really helps to keep the code clean, logical, and maintainable. I believe that testers who have had this rammed into their brain for years as developers first assume that it must be that testing is this way as well. The more logical, clean, and modular our tests, the better. For unit tests and the basic code coverage automation this is absolutely true. This is NOT enough. Testing in isolation is a huge problem because users do not work in isolation with one application at a time running on their hardware.
Testing in isolation is like eating a meal where you don't let any of your food items touch. You eat all of one food until it is gone, drink some water, wash all your utensils, then eat another item. It is unnatural, unenjoyable, and not a very good replica of what users will do. If our tests are designed to avoid potential problems, they are designed to avoid finding ...<< MORE >>
Last week I attended StarEast in Orlando Florida. From start to finish it was quite a ground breaking series of moments for me.
1. Elisabeth Hendrickson gave a keynote that gave me goosebumps. I heard her give a great keynote at PNSQC, but what I loved about this was it was even more test focused. It inspired me to hear her say in no uncertain terms that Exploratory Testing is not optional. YES! I am so thankful that in public in a main stream setting people are brave enough to say this. I hope that people who have some power to make changes at companies are listening and will try it. I don't ask anyone to agree. I just ask that they try it and compare results.
Elisabeth answers questions after her keynote.
(Left to Right) Selena, Me, Matt, and Dan discuss after the Keynote.
2. This may be the most self-centered thing, but James Bach gave a keynote about earning your reputation as a tester. He gave me a head's up that he was going to mention me, but I had no idea it would be with a slide and details! I was there, of course. I've never missed a chance to see James speak given any possible way to go. I started writing my blog because I took a tutorial at CAST 2007 about self-education for testers from James, where I finally gained enough confidence to share my ideas despite the criticism that might result. More on that in my first blog ever if you are interested. I wasn't just that he mentioned me that was such an honor, but more that he believes in my potential as a tester. I have so much to say about this that I'm going to do my first video blog on this topic when my laptop arrives. Look for it in a week! Anyhow, until then, if you were at the keynote and wonder what it was about, check out what I said a test case was in a technical paper, which James rightly questioned. You can read my response which is a blog called."What is a Test?". The keynote itself was important and not just because James is a great speaker (which he is), but because you will hear many ideas at conferences. There is one key reason that James is different and it has nothing to do with his style and everything to do with the content. His ideas work. Not just for a manager. They work in practice as a tester. They empower each tester to do better work rather than belittling them.
3. Overheard at the conference, "The context driven kids are running the ...<< MORE >>
Today in preparing to head to StarEast I was gathering my ticket, directions, and other official info. One of the websites I'd just ordered from sent me details in my hotmail inbox. I'd asked for this email, so I was fairly certain it was safe, but check out the warning I got:
As I see this I know that hotmail would see this "as designed" since they are protecting me from what could surely bring peril and also have provided me a workaround. What about the well known company who sent the email? This doesn't happen with non-hotmail accounts, so clearly they have no responsibility to make this experience better.
So, what if I was an average user? Would I be worried that I had an email virus? Would I become so desensitized to seeing these errors that I always open them anyways?
I say that this is a user experience issue. It is an issue for the product formerly known as hotmail, a.k.a. Microsoft Betty, Windows Live The New Busy Bees Knees Email system. Why? Because it is annoying to get false security messages and each false warning you give a user makes it less likely they are going to heed any warnings.
It is also an issue for the sender of this email. It is harder to conduct business with the company who sent the email if I am not sure I can trust them. This email warning message gives me the message that there is something wrong. Rather than the confirmation raising confidence, it has lowered my confidence.
How many issues that impact customers daily are closed as "not this product", "not a bug", or "as designed". If it hurts the customer experience, it still is an issue. What do you do when an issue isn't a bug, but still impacts the user experience?
...<< MORE >>
What Matters Most to ME?
For me it is all about Photoshop Content Aware (everything) and Puppet Warp.
Gossip 1: Johnny L=Hot
First, the gossip. If you've seen the launch, at http://cs5launch.adobe.com/?trackingid=FDXXQ you'll notice Johnny L is up after Shantanu the CEO. One of my friends at work has a total work crush on Johnny L. When he speaks just to the employees he's usually really funny, and I think that is why he's so well liked. In this video though he seems more formal than what we see inside at the smaller internal meetings. Anyhow, I'm glad they picked him to do the introducing.
Gossip 2: Adobe Employee Wolverine?
So yes, the employees here giggled when the customers started commenting that we hired Wolverine. I haven't heard if Jason has the sideburns still, but his energy is legendary. He won the demo contest at our last internal tech summit. I know lots of people were giving him a hard time about his chops, but man, I think he should grow a handlebar mustache for the next CS release to silence any critics.
Content Aware Fill
Gossip 3: The response to Content Aware fill was high drama!
Some people are accusing Adobe of making it easy to steal photos on purpose. Others are saying Photoshop is trying to replace the need for good photographers? Well, they've been saying that forever, but there is no way to replace art. It's just a tool for the artists. It still needs to be used well. Anyhow, I think once people start to use it they will be amazed, but realize that you still have to start with a quality photo taken with talent and edited with skill.
This cracked me up! I like the humorous response to some people's fear over advances in Photoshop CS5.
I'm just starting to imagine what is possible with this feature, but I'm pretty excited to see it.
Anyhow, I'm blown away by CS5 and super proud to have worked on it. My name does appear in CS5 suites, but as I worked on the quality of the suites themselves and not a product. You can find me in the credits if you look hard enough. Pretty exciting stuff. I'm very proud to have worked on CS5 and I hope that my designer friends out there love it! The content aware feature in the Photoshop CS5 healing brush alone is addictive.
Oh, and one tester tip? Get more ram. ...<< MORE >>
We are working very hard to complete shipping CS5. As a result one of my developers who I worked with on the agile project, the one I paired with the most this cycle, who lives on an Island in the Puget Sound missed the last shuttle and needed a ride home. I dropped him off at the ferry dock and despite being swamped I was finally able to ask him what he found most useful about pairing. I was thrilled to hear that we both agreed on what it was.
From his perspective, the test scenarios I would bring up during the code walk throughs would help prevent bugs. This meant that since he was heads down in the code, when he was showing it to me I could ask questions before the tests were run or written. I know that many agile teams are using TDD, but you can use direct pairing in some cases as an intermediate step! It is pretty exciting to figure out that this is most of what we were doing that we both valued.
The other main advantage was finding problems in the code. When he would explain what the code was doing, it meant he was reviewing his own code later. He found mistakes almost every time we paired. This made his code better by the time it was ever reviewed by a non-tester. We only paired a few hours a week usually, so not a huge amount of time.
If you want to start pairing, ask your developer to walk you through their latest code. Just explain it to you. You might be surprised how useful it is. Then again, if you have been doing TDD all along, perhaps this is useless, but it was pretty great for us. It also helped me to come up with tests on the whiteboard. Oh, and I learned new things that helped my Python scripting as well. I've reviewed some bug fixes in Java and also in Action Script 3.0 (using Flex). I don't write code in either, but if you start looking at it, you can add some scenarios to your testing.
This does not replace other testing, but is great to add to what you are already doing. ...<< MORE >>
As part of my QE Lead job for the last few years published a quarterly newsletter for PDF, print, and in a flash pod using our products every quarter. I didn't start the quality newsletter and it started as a group testing effort. The team I joined in 2006 published it for many years. For now, finally it is not published in 2010(yet). I passed it on to someone internally in hopes that they will revive it one day. We'll see. In my dreams these things would go on forever regardless of who works at the company. When one person moves on, the bench is ready and someone is willing to step in and continue the work.
I've also worked on getting discussions going about quality topics with the format of a short presentation with an active discussion. As the quality team became more dispersed and the time zones varied more, it evolved. It turned into guest speakers more than internal speakers as time went on.
Based on a series of pods created by one of the product teams, I worked on a project to create a portal, consolidating all of our quality info into a single portal to make things easy to find. The team made examples so that people could create and add custom pods! We shared info between teams. I spent a great deal of time hunting down contacts and websites, both wiki and intranet pages as well as a contact for every team we had, and there were hundreds. However, it was very hard to get participation. Not one person made a pod. Each time a change happened on the forum I'd spend time fixing our broken pod. It wasn't very resilient as things changed. I learned that even a great idea is difficult and self-updating information is more useful than counting on people to update their own information. The portal will live on, but just like test automation, community code doesn't do well without someone having dedicated paid time to work on it. An actual gardener to keep it from becoming a useless mess. When the teams change so fast, it is hard for community to flourish. How does a culture thrive when it is changing so quickly no one knows what it is?
Then there was working with a wonderful small group to arrange a quality summit.That was awesome! I would do that again in a second. The reason that one was cool was we had people from all over the world. We did a smaller one locally and it wasn't nearly as helpful because it consisted of people who already knew each other, so the excitement was a bit less than when people travel and are meeting new people for the first time.
...<< MORE >>
It would be too simplistic to say that the software testing profession is changing. It HAS changed and is changing even more at a blazing pace. Some of what was foretold and we were warned of has started to happen. Companies like Toyota have seen quality slip due to software errors. Software companies like Adobe face huge threats to the PDF format because of security issues. Even President Obama had his twitter account hacked using password retrieval guessing and research to break in. What is the cause? Are things getting worse out there?
In a few ways they are. As we rely more and more on automation, some risks come up time and time again. The weaknesses in automation are more likely to become the weaknesses in shipped software. However, because automation has weaknesses does not mean that it is all snake oil. Some of it is snake oil and some of it is needed and valued medication, a cure for a specific ailment PROVEN to work. Some of it is instead just a cooking oil. When applied by a skilled cook it makes tests faster, better, more powerful, and adds to the cooking that was already happening. It doesn't select ingredients for you or teach you to cook, but it can enhance what you are already doing.
I've been practicing my scripting both at work and in my spare time because many of the jobs will require me to script on paper in an interview. I've NEVER scripted that way. It is an entirely new skill for me to learn.
This week on twitter, Shrini said something that shocked me. Part of what he said I disagreed with. He said, "Demonstration of coding - even for testers? As primary mode of evaluation? I wonder why your focus is "code" or "coding" ? how about testing without coding? Let me put it this way. Unless scripting is 100% of my job as tester, I will learn what is required minimum in 2-3 weeks. To me a tester is required to "test" that involves a varying degree of scripting effort. It can vary between 10% - 60%. Once I know the basics of a scripting language, I will develop skills as I go on, that is a secondary skill for tester, anyway. Unless you are an SDET (in Microsoft lingo) a tool developer for testers - you need to focus on doing testing not scripting." I understand and agree with some of this. Testing methodology is vital! I feel like I am very solid in my testing ability. I feel confident. I count myself among the many skilled, informed, and passionate software testers in the community who continue to learn and practice the craft of our profession. I am not the best tester in the entire world, but there is no one out there I'd be afraid to test with ...<< MORE >>
What I'm Not Doing
Looking for a job.
Taking on more projects.
Going to small claims court. I've settled with the towing company which is great for us both!
Asking anyone else to solve my problems for me.
Backing away from any of the commitments and obligations I've already taken on.
What I am Doing
Trying to become more and be able to offer more variety in testing capability while still being myself.
Moving to a new office at work, starting Monday, for the rest of my time at Adobe, ending May 31st.
Finishing my current job to the best of my ability and transitioning well.
Trying very hard and improve my health to get the most out of the upcoming conferences and presentations through June.
Spending time in an attempt to improve my relationship at home rather than spend all of my time working on work. Finding balance is difficult for most of us, and I've been especially off balance. Finding a balance I can sustain is vital to my long term health and happiness.
Learning about Agile Testing both by experience and with research and practice.
Doing some SQL Injection reading along with some other web security testing stuff. http://bit.ly/90CPuT, http://bit.ly/c1FHOT, http://projects.webappsec.org/SQL-Injection, http://is.gd/anFGz, http://bit.ly/dlG7XG, http://3.ly/K5SC, http://ha.ckers.org/xss.html, http://unixwiz.net/techtips/sql-injection.html, http://tinyurl.com/mnsocw
Putting together slides for Better Software 2010.
Practicing presenting! I've been loving presenting more and more. Many thanks to those who've given me the chance as well as feedback.
More python scripts for my learning and to help my current project.
Submitting an abstract for PNSQC 2010.
Preparing to moderate for StarEAST and finalizing schedule.
Signing up for WAT conference and finalizing travel plans.
Contacting some friends in writing to possibly start on a few new projects in June.
Finishing my taxes.
MS Walk 2010-Seattle.
Updating this blog with a new format! Hopefully in June.
Updating my resume.
Practicing testing exercises.
Buying a few outfits to present in.
Learning more about stock so that I know what to do for my 401k and stock on or before May 31st.
Learning about companies and jobs which might be a good fit in the future. ...<< MORE >>
Last night I presented for QASIG. It was a wonderful group, a good sized crowd, and I got the best introduction I've ever had.
Next month I'll be heading to StarEast where I'll be a moderator. It was awesome to get an introduction from Jon Bach because I now have an example of what sort of introduction I'd like to give the speakers. One that lets people know who the speaker is, what they are about, and one that gives them a confidence boost to start out the talk. I feel like people were more engaged and had more questions because of how he introduced me. It set the tone for what we were going to talk about as a group, not just a "sit back and hear the blabber" type of thing.
Doing this topic again gave the the chance to totally revise my slides. I took out most of the text and put in pictures that made me smile and reminded me of what I wanted to say about bloat without words. This was good for the talk. I think that the talk I did last night was some better than the one I did for PNSQC, mostly because the slides were better, and I'm learning and improving as I get experience speaking. If I could go back and remove some "Umms" I would. Also, I'd have slowed down my pace in the middle some. I was going a bit fast on some of the most important points. What else? Well, there may be video to share!! It is going to take a few weeks to get here, if I can post it at all, but I'll put it here on the blog if it arrives.
Slides - I added clip art to slide 2 for extra irony since my font dropped out in the PDF.These slides are far different from the First Version and I think sort of shows how I am evolving as a presenter. I'm becoming more me. Less serious. I'm having more fun! It's quite awesome! I'm so thankful for all of the people who've been helping and giving me feedback and opportunities to practice.
One other thing. After presenting I had a wonderful time! I do wish that I'd had a seat sooner though. I have nerve damage in my leg, so I can't stand up for 3 hours and expect to be ok. I was in a crazy amount of pain last night and this morning, so if you see me out presenting please come chat me up, but let's have a chat sitting down! I get so excited about talking about testing I forget about important things, like that I need to sit down so I won't be in too much pain the next day. I'll put that on my "to improve" list for next time to work on too.
Those of you who were there, please feel free to ...<< MORE >>
"I can't do this. I'm too afraid and I'm going to have to go back downt he ladder," I whined to Skinnyman. I was standing on a wooden platform with my harness latched to a zip line in the Yucatan jungle in Mexico.A 300 foot ladder decent seemed a better option than sitting back and trusting the harness and hand grips to hold. "Look at my eyes. I know I'm not handsome, but I want to look at your eyes." I stared for no more than 10 seconds at his confident and amused expression. "There.Better?" he asked. I lifted my legs, Skinnyman gave a gentle shove, and I was flying. It was so fast, so fun, and nothing about it was scary as the canopy blurred beneath my Tevas. The jungle rushed by and I laughed hysterically the rest of the ride. When I came back the next time I didn't need any help, and Skinnyman wasn't surprised.
I'm freaking out! I'm so nervous I'm hyperventilating!" It was the morning of PNSQC and the first time I'd presented outside of my company. I'd rehearsed and revised over and over. incorporating feedback each time. The technical paper had drafts 1-28 already tossed out and this was draft FinalFinal. "You are going to be fabulous! I just know it," Gretchen replied, "Not to mention, I'll be there. No matter what." Scenarios from not even one person coming to see the presentation to a full blabbering meltdown or a freeze up ran through my mind. What if there was a heckler? There were some pretty blunt criticisms of the paper. What if they could tell it was my first time presenting? I told myself, "Whatever happens, be you. Everyone else is taken." The introduction was made, and off I went.
On presentation day I wake up nervous even knowing I'm as prepared as I can be. When I get ready I will have tried on my outfit and gone through the revision to my slides I just updated. Usually the change is one photo or one quote that I've put in and taken out over and over. I look at my makeup sideways hoping I don't have a mask line or any streaking and clip my hair so it won't fall into my eyes. I give myself a critical look and even say, "Whatever happens, it will be ok. You know this stuff. You've lived this stuff. Just tell the story."
When the Q & A starts I always feel relieved and satisfied, but I'm afraid that no one will ask a question. I hate it when no one has a question. Really? I spent hours at night trying to share something that mattered to me and no one cared? It is the most personal thing even though we are told it isn't personal, it's just business. No way. It couldn't possibly be more personal. These are MY stories. My test ideas. I wouldn't share them and go through the nerves if it wasn't ...<< MORE >>
Our cat Midnight who passed away last March was a delight to live with. He had a love of licking walls and sometimes electric outlets! His tail even looked like a question mark and he defined curiosity. We hypothesized that his head was full of fur and that's why he acted so insane.
This weekend our friends came to visit including their toddler who is soon to be 3 years old. He is adorable and has completed his teething. He has boundless energy, curiosity and enthusiasm! He is new to owning teeth and randomly bites stuff. His father's head. His own tongue to the point it was bleeding badly. His Mom even when sitting on her lap. He is unable to resist touching and licking anything dangerous at all and in bizarre and creative ways seems to seek his own demise. He is relentless in his pursuit of strange plots that no one could predict. At one point he chewed up some carrots and dropped them into the cat water. Not on purpose, just playing around. He's relentlessly exploring the limits of what he can do, what he can learn, and the world around him. He's also inexplicably drawn towards the dangerous and forbidden. His Mom told me that she needs to start him skydiving early because he's either going to be an extreme sportsman or a sociopath. He might make a great security tester as well! I got wondering if we could somehow capture the spirit of exploration and relentless curiosity and sheer unpredictability of a toddler during the exploration part of testing sometimes what we might learn.
What if we could tap into this power of exuberant peril and enthusiastic discovery to improve software? We build up this idea of rules and safety, but really, despite behavior that seems crazy to us on the surface, toddlers are learning so much! I'm not suggesting we have a meltdown of tears or lose our strategic thinking, but there is something about that curiosity that I think could be usefully applied to software testing.
...<< MORE >>
Are you turning into a developer?
A colleague I respect asked me if I was learning to code because of fear/money/jobs. That is a very valid question. I'm working on a project that I'm more effective at testing with more scripts. I am a tester. This means I do my best to use all of the skills and tools that apply to do the best testing I possibly can. I also continue to grow as a tester. I am not a naturally talented coder, and as a creative person at times I've wanted to give up. Luckily, I've had some patient mentors willing to talk me down from the ledge at those moments. I'm proud of the work I'm doing because it is right for this project and also because I feel like what I am learning is making me a better tester. It is not making me a developer.
Since I've been working more with Python I can now understand Java better! I can read other people's code and follow it more often. I'm pleased that I can get test ideas from what I think is missing in the code, not just what I see that is there. I see why peer reviews work because when I code my focus is on making it work. Being good at testing does not mean you automatically test your own code. It is hard to learn good practices even when writing small test scripts. The good news is a CAN test my code, I just need to set aside a different time to do it and focus all of my energy on that. The trick to wearing multiple hats is to not try to wear them all at once. It makes your head overheat and looks silly.
In the past month I've gone from putting together scripts other people wrote and making a few edits to making some of my own scripts and pairing with other people so that I can collaborate on scripts. I'm at the point where I can make a function, then write a small test that uses that function. Later I can hook them all together without getting lost as easily as I was before. I am not making custom classes yet, but I can follow scripts that do without much trouble. Lists and arrays are making more sense to me. I am understanding appending lists and I can handle some strings now. I also am doing a bit of using numbers as strings and I can keep track of them now without a headache. I am at the point where I giggle at jokes from Pycon about lingerie because I remember typing Pythong at the command line on accident. I'm still early on in my script writing, but it has been an intense and productive month for me.
Math in Python is easy to read, easy to do, and generally has been a joy!
if len(completed) > ...<< MORE >>
In my talk on March 10th at QASIG I'm going to go into this new area I'm exploring. Are some tests toxic? Why do we cling to them when they are harmful? When they become to harmful and toxic to us, why do we try to push them off onto other people?
There are some tests that we put into a category of "boring" or "less important" or "not worth human time", yet in many cases companies are taking these tests, packing them up, and paying a contractor, a counterpart in another country, or even a new tester or an INTERN to do these tests. Why?
One reason why is punishment. Some testers are so pissed about the changes in software testing that they want to demoralize and punish those who are "taking over their jobs" as they see it. They think if they set them up with unimportant tests they will fail.
Another reason is fear. We've become used to having these tests run and it is much easier to come up with an alternative so we can still run them than do the hard work and work through the fear and risk of NOT running them.
I have a news flash for you. Do not ever suggest to me that I get an intern when I'm frustrated at reading my log files. If I get an intern it is MY duty to make them a great tester. Not to waste their time and talent on a menial task. I may ask them how they would solve the problem and see what they come up with for me, but do not assume the people you train are not as intelligent and driven as you are. It is unfair and it is untrue. You aren't given an intern, a trainee, or a contractor to haze or initiate. You are given their time to build a great base of knowledge and get them off to a great start. When you abuse that trust by passing off toxic tests onto them you are doing a disservice to testing and a disservice to yourself.
More on this topic in the future.
...<< MORE >>
I read a post about the line stop at Toyota that was so complimentary. I just don't get it! They have cut so far they aren't even number 1 in quality anymore yet it seems everyone in testing is a panting fanboy for Toyota. Look at the product? Just not exciting and now not even slipping in overall quality for multiple years yet most people in quality want to be them?
Why? How about the fact that software isn't a car. It has a far shorter shelf life in most cases and it isn't a tangible item. Also, how about the fact that the actual quality is SLIPPING not improving over time?
Also, I'm sick to death of the process fanatics. I don't mean those who want to improve things, but I'm talking about this HUGE reality gap between what they say and what actually happens. Let's talk about Lean, Agile, Flavor of the Sell Me Process of the month. Some of it works really well. I like some of it. However, just the people who have these unrealistic ideals and are too far from the work to know that there is a major reality gap that exists. Sometimes I do read about the perfect land of unicorns and fairies and how that now that we're agile all of our problems are better. It's like a death march. All of our problems aren't over. We just make the same mistakes faster now and sometimes it helps and sometimes it just sucks. I don't know if it saves money or not. Why are we blindly following a car company with quality and reputation that is on the decline instead of trying new innovative ideas that actually APPLY to the kind of products we make?
On my team we just really hose stuff up faster, and sometimes that's good! Sometimes I get so flustered I wonder if this pace is sustainable. Why do our sprints feel like a death march? Isn't this supposed to help? We're still doing the trail of tears, just with a few more checkpoints on the way. Bleh. Anyhow, yes, lots of room between what the sales brochure of process improvement says and what really happens and although I think it is unfair to just pick on Agile, Lean, or XP as the problem as there are many good goals, I do think talking about problems in QUALITY needs to happen more. This "minimum viable product" idea is demoralizing. I'm against it. Really? How much less aspirational can you get than doing the bare minimum with a stripped down beaten down crew.
Also, why is testing and bug investigation and fix verification"Free" with no time dedicated to it. I feel like our "agile" just mean slots of reality denial and assumption of total success for everything we build with NO buffer. Reality gap number 947.
It should not be taboo to speak the truth about problems encountered on agile teams. It ...<< MORE >>
1. Be a terrible listener. To you active listening means mumbling "uh huh," on a good day.
2. Have it always be all about you. If ever it isn't, change the topic back to you stat. If they try to talk about something that isn't about you, check your phone, look at your watch, or otherwise show your displeasure.
3.Start selfish conversations where the other person can't respond, be it a story about someone they don't know, a relationship they aren't involved in, a dream you had, or a movie or tv show they haven't seen.The key here is that there is nothing they can contribute and it will be a monologue they have to listen to and let nothing stop you from telling the long version.
4. Take offense whenever possible and argue just to hear your own voice.
5. If numbers 1-4 fails to get the conversation back under your control, remember that you left your stove on, that you must be home in time for a critical illness your Grandma is about to have, or that you have an urgent reason for sympathy you need which trumps whatever the other person is saying. By all means,interrupt!
6. Be a bottomless pit for sympathy by constantly having a problem that is urgent and trumps anything they may want, be it help, relaxation, or just to have a fun time or pleasant conversation.
7. If items 1-6 fail, blame the other person in a dramatic display. Make it your mission to contribute more drama to the world than Broadway, London, and the Internets combined. I mean Reality Show level drama. Also, this includes blaming the other person, calling them selfish, and telling them they aren't a good listener or are selfish for not complying and fulfilling all of your needs regardless of the fact they most likely never agreed to.
I'm guilty of all 7 at times, but not so often that I can't laugh about it. ...<< MORE >>
This morning when I left for work I was pretty excited about Jon Bach coming to speak at Adobe! I'd seen him speak before and I like both his message and presentation style. I'd also had to miss this talk at PNSQC because of a conflict when I was moderating. Also on my mind was the performance tests I'd run overnight. My scripts have been back and forth and they just aren't ideal for exactly what I want to do, so I'm in a sort of half automated stupor with way too much human interaction on the part of collecting results. The problem is, to improve it I need time to improve the script which interrupts me doing the test and getting results so I continue to do this lame half-automated jig of woe.
I got to work despite an accident pretty reasonably early and was able to start compiling all that had happened to my tests overnight. This time I'd overshot the 8 hour target by a mere 2.75 hours, so not as bad as being 50% short on the estimated amount to send the night before. I mind numbingly entered data into an email categorizing crap for about 40 minutes. In fact, I was so intent in my focus that I missed Jon's call and didn't know he was there yet until the work phone rang louder and he was in the lobby. I save my accounting woe and get all jazzed to do what I really love to do! I really like to do things that I think will help other testers think about their testing in a different way. Jon's talk had about 70 people total, which considering the time zone difference from many of the testers was great! That reminds me, I'll send out the recording.
Lunch was great fun for me to get to talk to Jon about his experience with wanting to end well. I've gotten so much flack from people for staying in a job when I have an end date and I don't really understand why. This has been a huge part of my life for 10 years and I still care. Also, I haven't figured out my next right step. I'm actually working on my next right step all of the time. Jon is the first person who really "gets" why I want to end well. You don't work 10 years at a place you love and poison the well on your way out. It just isn't in me. The company has simply been too good to me for too many years.
So what is it about Jon that makes him great? He doesn't lead with just being smart. He's a good person first. He understands these concepts and forces that drive people like loyalty, teams, human interactions. Ok, this is going to get me so flamed, but here it goes. Lots of straight guys in testing have this emotional void that makes them kind of blind ...<< MORE >>
When I mentioned to a friend that I emailed Harry Robinson and asked if I could come see some of his test automation, they were teasing me because I'm so blunt I just ask to stop by. He was cool enough to say yes. I headed to see him last week in his awesome non-sunlight facing office and guess what? You get to join me for the summary, much like the mouse in my pocket who talks to me about coding.
So, enough about mice and on to Harry. Why is he my technical hero? He is the smartest developer I've ever met who is a tester first. Developers in test are a dime a dozen. Testers who can code well are rare. Harry is not about automation that sucks or trying to automate a bunch of silly blackbox test cases step by step so they become a headache to maintain over time. He's about figuring out the rules that apply and making automation that can separate interesting to look into from unlikely to be interesting to look at. His approach to test automation is why I went to see him.
What he is making is really remarkable to me in that it isn't much code total. It is asking the question "Does the result match this rule?" His talent is in making the rule simple and not making a big mess. If more test automation worked this way more of it would have good ROI. He showed me some cool stuff the Bing quality team is working on. Solutions to specific well defined testing problems is what Harry offers that no one else is even considering in most cases.
So I stayed and stayed and stayed even longer. I kept chatting with him and he asked me some super hard questions to see if I could guess. Well, sometimes I guessed right, sometimes I didn't, but I played along anyways. I learned some interesting things.
Did I learn just about test automation? No. The reason I stayed so long is our talk was getting much better. Here's what I cared about. I cared that he talked to me like a person. He told me true real stories. He showed me something about how to be resilient and I've never needed it more than I do right now, wandering around talking to people for the first time slightly lost. I've NEVER heard NO from a job I really wanted. I'm not brave enough to ask. His advice is to just try stuff. Do the next thing and go from there. Learn something new, try something unexpected and get some perspective.
The reason he is a tester first? He talked about a complicated engineering project the testers are doing that he's not sure relates to testing. It's solving a development problem. He wants to solve test problems. We don't agree on this issue because I feel if you hire people who even say they ...<< MORE >>
My first magazine article is posted in the January issue of STP Magazine at http://www.stpcollaborative.com/knowledge/544-9-tips-to-encourage-collaborative-testing. The article is 9 Tips to Encourage Collaborative Testing!
The issue is amazing and the theme is Women of Influence in Software Testing with so many great articles. I'm one of the contributing authors. Thank you to all of you who've encouraged me and helped me to work on my writing and testing ideas. It feels great to have a published article in a magazine!
...<< MORE >>
It occurred to me that while it is personal, it might help to know my back story to put some of my quirks into context. This has some to do with testing eventually, but for more to do with me.
I was born in Washington State to a married couple who had a 16 month old daughter. Before I was even born the first thing said about me was, "The baby has red hair! We don't know if it's a girl or boy yet." After that the jokes began as I stood out next to my entirely brunette family. When my brother was born a few years later, his hair was red too, although it's faded out to more auburn over time. There is no doubt about who my father is, since I have his nose and feet. My parents remained married until I was 18 years old. Most of my childhood my father worked for Boeing and my mom stayed at home with the 3 children until we were all in school. We were part of a religion who called themselves "the Truth". You might have seen them in your town. The woman are visually noticeable as they wear no makeup, hair up in buns (you can't cut your hair), and dresses, much like little house on the prairie. TV and Movies weren't allowed. Church was in the morning and evening every Sunday, bible study one week night per week, and intense conventions in the summer with up to 6 hours of "meetings" per day, with one long weekend on "special meetings" in the winter. Christmas and Easter weren't celebrated openly if at all, but because my Grandma was Catholic, we celebrated both, just not with a tree nor did we flaunt it to the other members of "The Truth".
Because of this environment I read for entertainment growing up. In fact, I read most of the books for children and young adults in the Sumner library by the time I was twelve years old. I read much faster than most people can because words are the format I'm used to digesting. My father, along with many of the other men in this faith, had some major problems sticking the to rules. He drank, had drinking binges and yelling binges and a few other habits in conflict with the religion and family life in general. My sister reacted by becoming more confrontational with my Dad. I reacted by smoothing things over and creating peace, often a pretty unsustainable peace, but it would work until the next time human nature and the rules of religion came to a head. I can usually find some level of comfort and positivity even in a pretty hostile environment because I have practice. This is part of why things that might devastate another person aren't so bad for me. However, if I feel tricked or set up for failure, I don't do well. I also don't accept people yelling at me. I ...<< MORE >>
Why does this matter?
This matters to me because when I envision the future of software testing I see intelligent people who are able to discuss the pros and cons of ideas they are passionate about in a way that doesn't alienate and exhaust those who are trying to follow it and learn from it. It also matters to me because in the last three years I've seen females leave the software industry. At the same time, I've seen some people stop sharing testing ideas entirely because they are tired of the negativity and constant bickering. Software testing is a young profession still and while some of the culture is already defined, some of it is being created and changing at this very moment. To see it become more cut throat, less tolerant, and more "male" in character is something I oppose. It matters to me because the users of software are becoming more and more diverse while the group who have employment in testing software is becoming less diverse. I fear a world where all software is designed, created, and tested by men from a few countries with a tiny minority of token women thrown in. I'd like to see the group of possible professional testers be a subset of those with the talent and interest as wide as the group of possible users we target.
It isn't just the lack of diversity of origin that I fear, but the lack of diversity in ideas. When new and unfinished ideas are nipped in the bud rather than explored collaboration isn't possible and often innovation is snuffed out before it can begin. I wrote an entire blog about my strange upbringing which may shed some light on why I am so touchy about gender bias and diversity. I feel that the ability to have respectful discourse when it is agreed upon by both parties can help software testing grow as a profession and can also create a safe sandbox to test out new ideas for some testers who are just getting started. I'd like to create a safe place for people to explore their own ideas and learn without fear of personal attack so that you can try ideas on without making it your "final answer".
And where does this suggested protocol come from?
This suggested protocol comes from my observations of the past several years and it is my opinion. It is more than just my opinion though. It is also what I see working to keep debate on topic and respectful. There are other types of discourse, but I think that respectful discourse is especially useful. Disrespectful online drama will gather a large crowd, but the difference between an audience and a mob is intent and purpose. If site visitors are the goal, by all means, tear someone to shreds and gawkers will come out of the woodwork to watch the carnage. The problem is, who is going to step up for discourse the next ...<< MORE >>
Is it possible to have a passionate disagreement respectfully in any medium? This is not a post like the last one where I just say no. Some forms of communication are more difficult than others. Face to face it is easier to have a respectful debate than it is online, and debating online in public is even more difficult. Not only do you have the lack of body language and vocal tone, but a subtle gang mentality can come into play as can "losing face", "public humiliation", and the peanut gallery of sycophants can make a normally rational person behave in ways they usually would avoid.
Here are some loose suggestions to try when you are attempting to have an online discussion with the main goal of exploring a point of mutual interest. There are some cases where the topic isn't the point, such as a display of ego or an attempt to discredit or silence another. In those cases respectful discourse is unlikely and these suggestions won't help much.
In respectful disagreement personal attacks are not acceptable in most circles. Avoiding cursing, name calling, and threats is usually better for the conversation. It can have legal implications to do otherwise in extreme cases! All repercussions aside, anger trumps logic. If you or those you wish to communicate with are too filled with anger even the best debate will be wasted.
A few more subtle types of content that may undermine your message are using CAPS which is yelling online to most people, or using terms of oneupmanship, like "actually", "whatever", "regardless". Sarcasm is risky and if a topic is heated, it may cost you a joke, but it is worth the price if you are seen as a bully.
Namedropping is also a weak form of content to most of us. "Well it was good enough for Harvard!", or "It's not Rocket Science." "Cem Kaner once thought my idea was brilliant, so who are you?"
So, in addition to this "let's be nice" stuff, how about not being a total wuss. If you are asked an on topic question, quit whining about your feelings and answer it. If you get feedback that you don't like, consider it and respond how best works. How you respond to critics is part of what defines you. Those who decline all character defining moments become weaker over time. More than that, they become dull and complacent. Being boring is a far worse crime than being a jerk. Think about that for a moment before sending me scathing comments (which I will consider respectfully and respond to when calm).
Most importantly, be on topic and insist on bringing the conversation back to the topic if respectful discourse is your intent. Your conversation be more likely to be productive, but as an added bonus others can follow it and find it again. They can even contribute ...<< MORE >>
This post is really personal, but I hope you understand why I share it. It is about my attitude and it is about learning how to work through it when there are some obstacles. If you hate long personal stories, please read just the summary.
Summary: Experience is a personal choice. There is no reason that testing obstacles have to bring you down. Approach them with optimism and rely on others and you'll make it through.
I've had a crappy attitude about the holidays this year. I even told my Mom I wanted to check it off the task list and just put it behind me. I felt justified for the following reasons, but I realized those reasons were just me being afraid. I'm going to enjoy this season to the fullest!
James Bach in an interview said many interesting things, and he mentions ME as someone to watch. Read it at http://blog.utest.com/testing-the-limits-with-james-bach-part-1/2009/12/.
Those of you who have looked far enough back will know that this blog was started as a result of the best training I've ever taken to date. It was a one day seminar at CAST 2007-Self Education for Testers by James Bach. It inspired me to share my testing ideas
My name is not the only thing I read and noticed about that link, although I did of course respond with "Hooray!" Other things that made me want to stand up and cheer:
Well of course! I’ve been a hiring manager, and the idea that hiring managers are zombies who only look at paper credentials is wrong. SOME managers do that, but you don’t really want to work for someone like,do you?
For me phase 1 was just having the courage to talk about testing publicly. Now that someone I respect so much believes I have potential, phase 2 is to learn more and be better, to contribute value to the profession of software testing.
...<< MORE >>
This post isn't about bias, but it is about something far less insidious. What if you just prefer what feels familiar to you or what is easier to read or you relate to naturally more?
I've had some interactions with some wonderful people lately, some of whom I respect deeply that made me wonder. I know that none of them consider themselves to have any gender bias or even preference. First was a minor argument with Craig in the kitchen after work. I was cooking us dinner and he came in to ask about my day. I told him that our wedding rehearsal was like dragging a drunk stranger to a Las Vegas chapel and having the Elvis minister not show up. He responded, "You know I don't like all of the metaphors. Just tell me what happened?" I was quite upset by this. I told him if he doesn't like talking to me that he doesn't like ME and that he was just rude and I don't get pissed and tell him to stop being so boring and literal when he tells me about his day. I don't insist he tantalize my mind a little. My metaphor took under 30 seconds while I was cooking for us, so really? He would begrudge me a metaphor? Well, it isn't about the metaphor, but I'll get to that.
Some of my favorite male writers have had me thinking lately. I've checked their blog rolls and the list of books they are reading and recommending. Not a single female writer among them. It isn't that I think they are at all biased, because I don't. They simply prefer the writing style of males. Well, also, there is less content to choose from that is topical and well written from females at this point, so I'm not trying to be critical, I simply noticed this and have been thinking about it.
The last and worst interaction I had was mentioning the decline of women in software testing in the last 5 years. You'll notice a huge shift of women out of engineering and software testing and into project and program management or even to management where possible. This isn't because women aren't capable of being amazing testers and software developers. It is because the system of rewards has moved towards processes which have a gender preference for measurement. Soft skills have no value in the measurement system and are given no credit. Style is worth nothing and cooperation counts for nothing of use. What can't be measured is thrown out, assumed to be of no value. When I brought this up to one of the women I most respect she asked me, "Have you asked the women how they felt? If they wanted to stay in testing and engineering?" I said that I hadn't because why would that matter? Why would you want to stay feeling undervalued and like you are in a no win situation? By the time the ...<< MORE >>
What's good enough for you
Is good enough for me
It's good enough
It's good enough for me
- Cyndi Lauper, The Goonies R Good Enough
We are the problem with quality. I don't mean software testers. I mean human beings.
My brother in law has talent as a carpenter. When our cat died he whipped up the most beautiful coffin overnight. It is nicer than what many humans are buried in. He created a covered porch on his house that is amazing. However, he doesn't work in carpentry. He would love to build furniture, but you see, I bought all furniture from China when I moved into my home. We really couldn't afford anything hand crafted in our first house having just paid the down payment. We are part of the reason that for fun he does carpentry and his talent isn't used on his job.
Those of us who love software want it to be perfect. We have a vision of the polish and groundbreaking delightful useful things it is going to do. I've been using twitter lately and it fails to load pretty often. I'd say between 4 and 5 times per day it doesn't work. Often I get the "fail whale" which is the cute page showing the site is overloaded. Sometimes it just times out without the whale. Either way, I still use it. Why? It is free and so I don't expect too much reliability.
I also think that some companies are competing against themselves. People don't want to upgrade because what they have is good enough for them. They know and like their older version. Unless something is amazingly different, they don't want the hassle and expense. Companies who are struggling certainly don't want to risk downtime. For example, my graphic designer friend has updated every Creative Suite for years. After 4 layoff rounds, she can neither afford the money, the time, or the learning curve to upgrade again because she's lost so many co-workers. I realize that she is lucky to just have a job right now, but the software she has is certainly good enough for now. Would she like new software? Sure, but it isn't practical right now. I think Office faces the same issue.
I have an online friend who creates beautiful custom corsets. I own two and they are of the highest quality, all original designs and they last. Yet, I bought a corset for a friend and because of the price I bought an inferior one from China, taking work from an artist I respect and admire. Why did I do that? I'm not happy about it. I'd rather have bought her a work of art from Electra Designs and instead gotten her less expensive gifts. I learned from that. I bought my best friend the base price of a corset for her birthday. She added features to it and paid the ...<< MORE >>
I have not started looking for a job just yet, but I'll be looking for a job in May of 2010. I have some work I need to finish up here, and I'm learning some new skills at the same time. This blog post is not about what is realistic. This is like an ideal wish list of what you would like to find in a romantic partner which is half movie star, half Messiah and 100% intrigued by your every move. Of course, much like Cheap Trick, I want YOU to want ME, so being into me is very important, but here are things I'm looking for.
1. Pays a livable wage that fit somewhere in the range of appropriate for an experienced and qualified test professional. Also, must have solid stable medical benefits, or be able to purchase my own at an affordable rate.
2. Bus or train accessible or has special commute plans is a plus! I love public transportation and will use it.
3. Software that I am working on is interesting and has potential that I can contribute to. It doesn't have to be great right now, but it must have potential. I perform really well when inspired, and I get inspired when I have a chance to make a difference and contribute to great software.
4. 21st century business approach or is ready for it now. Really does Agile or sincerely intends to and wants me to be a part of it. I mean by that an org that has team rewards and is willing to leave the carrot and stick, command and control ways of the past behind. I want to work for a company where the executive team is really for empowering people and teams and when they do reward people they aren't stuck in the unfounded "we reward individual performance" mind space. For example, what I am looking for is a company that puts their money where they mouth is. They understand http://www.ted.com/talks/dan_pink_on_motivation.html and want to move towards it or are already innovating in this space. In short, I'm looking for a company with a good future that I can believe in.
5. Wants balanced employees. By this I don't just mean work/life balance in terms of hours. I volunteer for things. For example, I am the editor of our internal quality newsletter. I do the design, publication, layout, editing, publishing, talking to authors, soliciting articles, gathering images, and troubleshooting the flex interface. I even make the action script buttons and effect for use in flash player. Also, I've worked on our video concepts at each tech summit where we've won a trophy for internal team building. I worked on putting together our quality summit for 500 people including scheduling and making signs and setting up our wiki and coordinating people. I want to work for a company who supports my flexibility and needs it. I want a company ...<< MORE >>
It isn't the announcements, milestones, or working on the products day to day that I'll miss the most from Adobe. It's moments that crack me up.
Things like the song "Word Up" by Cameo. When I went into Gretchen's office she was playing the song and dancing along. I hadn't been her "lead" for that long, and things had been "serious business" on the project for awhile and quite stressful. I walked in, closed the door and we both danced the rest of the song like nerds. The time both Gretchen and I made the finals for the pinewood derby and seeing her let her nephew take the prize for his part. Gretchen amazes me. Seeing her bloom in confidence has been one of my favorite things in my career and the fact she is staying past this rif is a total moment of pride and happiness. I hope she continues to dance every time that song comes on no matter what pressure the job may bring. I'll still come have lunch with her, likely more often than I get to now. Gretchen came to support me the first time I presented in public, and her support is part of the reason I won Best Paper. She was there supporting me, making sure I couldn't get too terrified to talk. I am so thankful for that.
There is a photo in my office of Tiffany when she was a contractor the first year before I worked on her team. I believe this was from 2002. It's on Halloween and I'm dressed up as "Spanish Fly", so basically a spanish flare ruffled dress and dragonfly wings with bug eye glasses. She is dressed as devil schoolgirl rebel. We were having a great time and both are serious about Halloween and dressing up. She's been a friend for years and I believe we've learned from each other so much. She's the friend who taught me to take a break sometimes and that you can never own too many boots. She is the person who helped me take action and be bold when it was needed. I'm always soft, but sometimes when it is time to be strong or stop accepting excuses, I want to opt out. When bold action and constructive action in need and outrage SHOULD be the response Tiffany doesn't back down and she helps me realize that justified indignation can be a brilliant catalyst for positive change. I'll miss being able to come see her as regularly. Even the fact that she kept the cuddling skeletons I set up for her wedding shower decorations because it delighted her how I brought in their dark sense of humor makes me know that those memories will stay.
It's Chris and his amazing vintage cocktail hour with the authentic ingredients and how much he loves his dogs. His tastes really have changed how I look at the world. I own a purse that costs over $20 because of his ...<< MORE >>
One phone call that would not have happened on any of the teams I was on before trying agile has stopped me in my tracks. This is the most important thing about agile so far that I've learned. Agile done right reveals disfunction to the team more quickly. It is easier to identify where the problem is, even if it is YOU!
There is a person I've been shutting out, resenting, and basically unfairly blaming for my frustration who just helped me a ton. A problem that has been blocking my progress for weeks has now been fixed on purpose and more quickly than I could have imagined. I am unblocked by someone on my team who could have helped me weeks ago if I just would have let them.
I'm the collaborative extrovert! How could it be me? How could it possibly be the "bubbly and smiling" one who is causing a problem with teamwork? Well, because I'm human and I make mistakes. In this case, luckily, not terrible unrecoverable mistakes, but like anyone I make snap judgments.
My bad feelings really weren't personal and I didn't even know they were a problem before tonight. The timing of introducing a new team member could not have been worse. Instead of giving a person some slack and ramp-up time in a tough situation I was just being selfish and immature. I wanted NO interaction and no new team members even if we DID need them. I didn't want any change to deal with. The person not being on the team was me. I wanted to be left alone and sulk like a whiny baby pee pants. Well, now I know it, I'm sorry, and starting right now I'm opening up to my team on purpose.
The best part is, instead of just feeling ashamed I feel like now that I know better, I can do better.
...<< MORE >>
It is Thanksgiving. I was at work until 9pm again trying to get something done for the product. I got upset yesterday and Craig told me that I need to care less. If it still hurts, you care too much. He wonders what I have to prove for a company that is moving on without me. I tried to explain the best I can, and so here it goes.
I love Adobe. Imagine if you were on a beautiful ship with many of your friends. A ship that had taken you far where you'd seen amazing things. In a storm it had taken on water and sustained some damage, and you'd lost a few crew members each storm up to that point. Last year you started taking on water and everyone had been bailing it out as hard as they could, you'd had to set even long term crew into life rafts and wish them well, and in rough seas too! Shivering and cold, but still trying, you've continued on, but nervous and working for many. Eventually the ship still leaking, they prepare you that you will go gently in a life raft with a survival kit and a generous set of supplies as well as an oar. You wish them the best to repair the ship and hope they end up at their intended destination safely.
Also you are preparing for a time in a small life raft. You can hope to be saved. You can row to somewhere else. Either way, until I get into my life raft I am doing all I can for the well being of those I care for on the ship that has taken me so many amazing places. I wasn't the right crew member for this trip, but they decided in an emergency, not at the dock, they had to get people out. I will always care. They do not toss me overboard in a disgusted heap. They kindly have warned me that I'll be going in a life raft with supplies and their blessing when the time comes. Of course I'll pull my weight bailing water, trying to get the ship where it is going, and raising spirits if I can until it is time to climb into my raft and row row row my boat.
I'm bailing water, trying to weld up the holes frantically, preparing with rowing practice, and trying to cheer people as much as I can. Me learn to not care? That isn't going to happen. If it could happen I'd be a person with separate personas for work and life. Perhaps the best and worst thing about me is that I do care.
I may not be on the ship anymore, but I don't risk going down with it either. This wasn't my choice. My team was picked, every one of us working on the team I'm now on with any experience or skill with testing, to get into the life ...<< MORE >>
Update: If you read this and hated it, please read the followup at www.softwaretestingclub.com/profiles/blogs/words-matter
Well, if "performant" isn't a word, it should be.
Craig (live-in boyfriend and real life developer counterpart) was telling me about a script with for loops 12 levels deep and how getting rid of some of the loops and caching common data gave HUGE performance increases. For that reason, his script is much more "performant".
How many of our test scripts are needlessly slow? How about our build scripts? Why not add in a task, just one day to see if we can make our existing tests more performant. If time is money, why are we wasting money?
Also, what do I need to be more performant? Mostly, right now, I need a shield. I need someone to stand between me and testing creep, the evil cousin of feature creep, who sneaks out near the end of the project and adds tasks to the front of the backlog. Don't be testing creep or feature creep. Be Master Performant!.
...<< MORE >>
When writing bugs and adding planned test cases to a database I need to define the expected behavior. This task seems very simple on the surface. The unwritten part of the test case bothers me. What do we NOT expect? Good validation in an automated test case means knowing the answer.
When I add 2 and 2 I expect 4 for the sum. But do I? 2 plus 2 is 5 if I'm adding high values of 2. When I add 2 and negative 2 I expect zero. Also, I expect 4 what? The number 4 to appear. For how long? Where? How quickly should it appear? How much detail will it have? How big is it? What font will it be in? Do I have control over the default? Will it always be the same color?
What do I not expect? I do not expect the calculator to crash. I do not expect the number 4 to flash. I do not expect the number to be partially off of the calculator. I do not expect the battery life to be so low that I can't add twice. I do not expect it to clear out so quickly that I can't see the answer. I do not expect an error message that the format must be 2.000 or 02.00. I do not expect the number to be upside down.
I'll be learning what is expected and what is not expected as I get experience with the system under test. Testing earlier in the development process means I can help the team define what is expected. Last week I worked with the team twice to define how a bug I found would be fixed and the expected behavior changed for the better. Compared to the waterfall projects I've been on in the past, this was really cool! This involvement in defining how the software SHOULD work boosted my morale. I feel good about my team despite my awareness of the expiration date of my work.
Static expected results in planned tests are often a waste of time. Expected behavior is not the "best behavior". It isn't even what the majority of our customers expect. It is our best prediction at thetime we planned the scripted test. I dream of test automation with genius validation which can learn to update it's own expected results. What if "expected behavior" improved itself and updated automatically without tester intervention? Imagine the regression test suites understanding instantly that when run on the Mac OS that they now expect About information under the Apple menu without you coding it. If your tests knew that the system was Japanese, so that string is now the equivalent glyphs instead? It would be powerful for the regression test to understand each environment and teach itself what is expected rather than a tester predicting every behavior that is and is not expected. Screenshot recapture is not needed with UI changes when the automation now expects a new ...<< MORE >>
Consider a study of the effectiveness of pain management methods when in agony from nerve pain based on a survey of friends online at the moment. Please check for yourself. No data was harmed in the making of this chart:
...<< MORE >>
Today I found and argued about and isolated many bugs on one topic alone. Time.
Testing tools used:
1 calculator (free with Windows AND Mac operating systems)
System Event Viewer and Advanced time control panel for Windows.
Times listed in steps did not add up to the "overall duration" ever. We are missing some time.
Client time is used for some calculations causing things to happen in negative time for some time zones.
The "time" server lied making things happen in the far future for negative time.
Some time is in GST and some is not which is problematic.
Time is always tracked in seconds (yay), so the displays in various ways all work.
Date last modified is shown and consistent.
Questions: What else should I ask myself and find out about time overall? Are there other tools which can help me test time I should look into? What interesting time related issues have you found?
In short, I missed my bus, am behind on other tests, and still I am interested to see if this software can stand the test of time. Yes, pun intended.
...<< MORE >>
I am swamped today at work and was up fretting pointlessly about my future last night rather than being my usual cheery self, but something struck me strongly today. If you have not seen this or haven't read it for awhile, slowly read each line of the context driven testing website.
Reading that and giving it thought made my entire day better. If you read that and nod, you aren't alone. I'm there with you, and you are in some pretty amazing company I am learning. Some generous and thoughtful people who help each other get better and continue to learn.
We stand on the shoulders of giants. When I feel alone I discover that I'm not giving enough credit where it is due. In my fear I didn't even reach out for anyone, and they reached out to me of their own generosity and I'm beyond thankful for it. I am entitled to nothing. I try to work hard to earn a spot in the discussion and will continue to do so. I hope that the generosity I've seen from other practitioners in context driven software testing is one day a great investment. Thank you for being everything awesome about software testing. I'm inspired.
...<< MORE >>
If you have iTunes installed do a search for Edinbus which is available in the UK version as it is for Scotland only. Gordon spent his money to become an iPhone developer and made a free application so that other people in his city can more easily use the bus system. He already has a day job. He is a newlywed, married just over a year ago, yet he wants to do something good for software users. He rode the bus around at all bizarre hours to test his application in many phone states. His application is far better than many of the applications other developers are charging for. Yesterday he showed me the objective C program, which to me looks like a bunch of brackets thrown into a pile and mixed all up, but he assures me it is meant to look this way. I showed him my python scripts I'm working on and we talked about procedural vs. object oriented programming design and why a person would do testing or writing or software development for free. His wife designed all of the icons in his program.
Why is Gordon so wonderful? He is one of the few people out there who gets what motivates me. He wants to work on software that he cares about that provides a wonderful user experience. There are very few companies who understand how important a polished and brilliant interface is. He is willing to spend his time and accept the less money to do so. He really loves good computer software. He asked me not to be hasty or distraught about my layoff, and I asked him to write a blog about his iPhone application development project.
He told me yesterday that I have a year to find a job and I should not just "jump at anyone willing to pay me money". In his opinion, I belong at a company who cares enough about the experience they are providing people with their software to appreciate the talent I have, and not a company who is "in the position that IBM is in or will be in 10 years".
What he is talking about is important for me. For people who are motivated by safety, by comfort, and by ego it is much easier to find a job they would like to stay at. For me it isn't just "about the people", it is about the software I work on. If I am set up to fail or not allowed to positively impact the product quality because of the company culture, I won't be happy there long term. I could lose my passion for testing and be gone from the industry entirely. My second lifelong dream is to drive large construction equipment and it is a life goal for me to drive a backhoe. At least then you really feel like you are making progress. See, I need to make progress or I become dangerous. I have lots ...<< MORE >>
Version 2.5: A test is an action which produces discoveries that can be used to evaluate product quality.
I'm discovering my limitations with writing. Unfortunately I am not talented with words in quite the way Matt Heusser is. I am trying really hard to learn and sometimes I just close my eyes and think "Learn faster, Lanette!" Anyhow, I hope I'll have another update and I'm still thinking about this.
A test is an action which produces data that can be used to evaluate product quality.
Why is a test an action? What about those tests that sit in your database? Do they not count? Of COURSE they don't count. They do not become a test until someone or something takes action. They are just a plan. Remember, TEST is a verb. Also, just because you want it to be so does not mean that software is going to test itself.
There was a big battle in my mind over produces. Does it create data? Or does it produce data? Or does it discover data that is already there? Well, the action of the test produces some sort of data I believe. It may not create it, but produces to me also means presents, so it presents it somewhere else. When I am testing I am hunting data to tell me something about the software under test. What about a case where you look at the launched product, notice a button missing and did not have any input or output, but still reported a value bug. To me, this is still a test because there was an action, there was learned information and there was evaluation for the purpose of evaluating product quality. I thought the word data made sense, but then I talked more with James Bach and Ben Simo and the word data was confusing a few other people, and it is very unclear what I mean to say by that term. That word didn't fit in the definition and it didn't convey what I meant either. A test produces more than data. It isn't only inputs and outputs and results that a test produces, but it is learned information. By "discoveries" I mean any information that we have now which we did not have prior to the action of performing the test. The information may have existed, but until I learned of it, it could not be used by me to evaluate product quality.
"can be used" is key. It can still be a test even if it isn't used properly. If I do a series of tests and the learned information is never evaluated, the test still happened because the data exists, but until the data is learned the test is not complete. This happens all of the time with automated tests. The tests happen and the data is never used to evaluate product quality because the resulting data isn't human readable easily ...<< MORE >>
From my technical paper Reducing Test Case Bloat:
Clinically defined a test case is an input and an expected result.* For my purposes it does not matter if a test case is automated or manual so long as it is a planned test. For the purpose of reducing test case bloat, I’d go further and say that it is a test you plan to execute a minimum of once in the product life cycle.
*IEEE (1998). IEEE standard for software test documentation. New York: IEEE. ISBN 0-7381-1443-X.
Why would I say that? Did I think about it? What am I talking about with the "planned" stuff? Do I really think that to qualify as a test case that a test must be "planned" and what does "planned" even mean?
I want to summarize why I didn't go in to what a test case is in this paper. I didn't think it would help. My paper is a survival guide. If I set even ONE tester partly free from a useless legacy test case so that they can do testing of value again, it is worth this shoddy definition of a test case to me. My intention is to offer a paper that helps a real human testing in a company go back with a practical list they can apply to the legacy test suite in their test case database. I wrote this paper to help testers, and I hope at the same time I was careful enough to not harm testing as a profession by limiting the scope. If I was harmful with this definition I apologize. I didn't mean to be. I do think that most of the test case bloat is included in this narrow definition of test case. This is not how I define a test case most of the time, but it is how I look for test case bloat.
My paper has a purpose. The purpose is not aspirational nor is it a paper about theory. What I mean by that is this paper is intended to help a person testing at a company which has test case bloat. In the situation where you have scripted test cases piled up to deal with and it has become critical to address, my paper is intended to help a tester evaluate existing planned test cases in order build their own escape plan. Wouldn't it be better to prevent it from getting to that point? Yes, but it is too late for most testers in large companies already.
Think about that person responsible for legacy test cases which are scripted, in most cases with very low craftsmanship. How are they going to contribute to better software quality? All of their testing time is being eaten up by test cases of low value which are unlikely to find bugs. When I was in this situation I'd come to work in the morning, and have hundreds of failures reported from my automation to ...<< MORE >>
About the Change
In 2007 I wrote a blog post on how to test better than Microsoft. It was based on information as an outsider pre-Vista and back as far as the Windows 2000 development lifecycle. At the time, I was convinced that Microsoft was determined to trail blaze a path to software hell and that no one was going to stop them. The unbalanced approach where "the code is all that matters" really concerned me for the user experience. Well, then something happened. Vista happened. And Microsoft changed! I don't mean changed slightly. I mean started taking good advice from thought leaders. The distance between reality and presented metrics became known and smart people did something to fix it! I am not sure if there was a test leadership change, or if it was due to layoffs, or what exactly changed there, but since Vista there is something new going on in Redmond. Maybe it was always there, but it wasn't visible to outsiders.
My opinion of testing at Microsoft has changed, but it isn't because I think I was wrong. It is because testing at Microsoft is different than I thought it was. Maybe I hadn't talked to enough testers on enough different teams, or maybe they are more open about sharing ideas than they were. The company culture has changed, or at least my view of it has changed. The arrogance has diminished. The attitude of "We have the right answer and everyone else in testing is to be mocked" no longer applies. They are sharing with the community and not just to bestow their wisdom from their pristine tower on the peasants, but they are opening a two-sided conversation.
And now? What happened to the Microsoft of old? Other companies are COPYING the failure in the old trail they have moved on from. I thought Microsoft was crazy three years ago, but who is crazy now? The companies who are following 3-5 year old ideas that have failed in this economy? I think that Microsoft, with the huge number of testers it has, really does influence testing overall. However, it seems that as the testers and higher up managers moved on from Microsoft some years ago they took with them ideas from the company at that time without the advantages of the experience since. Those companies who think Microsoft is no longer much of a threat? I think they might want to take another look. I think they might start to deliver some innovative software again. I am not saying they will, but they might. Do I know for sure? Nope. This is just my impression from what I've seen as an outsider right now. In 3 years my opinion might change again. The company might change again. Who knows?
At PNSQC the first Keynote speaker from Intel talked about quality mascots. First it was the Salmon--"Moving quality upstream", then it was the Hedgehog based on "Good to Great", until ...<< MORE >>
For seven years I did my testing work under the impression that it belonged to my company and the only word I said about it in public were to celebrate and point out where to find my name in the shipping product (for the first few products) to those who knew me the best, and I would write a traditional "new feature overview" for my Graphic Designer friends and the customers I'd meet at user group meetings. All the while I was blogging away in my private blog since 2000 almost daily, building a readership of people who love fashion and lipgloss, along with a few programmers. I met a young Scottish programmer by the name of Gordon Christie who was kind enough to spend his evenings playing online chess with me after I had my first surgery, when I'd still not adjusted to being in pain, simply because it helped me stop crying to focus my mind on something else that was hard. He helped me,even though I never won against him, and at best the game would last longer than the time I lost before. When it came time for his "Final" project to graduate college (they call it something else in the UK likely with another "u") I was glad to help him out with some testing. It was a home automation project, so I'm sure he was annoyed a bit when I turned off his lamps at 2am his time just to see if the fact they were already off would be ignored or would just switch them on. Awake and fixing the issue, he then learned that testers may be slightly evil even when we are doing something good to help out. He got his first degree, and I got my first chance to collaborate with someone outside of Adobe and I realized that the work I do for my software belongs to my company, but I have ideas that have value outside of the products I work on and I am a tester regardless of where I work.
In 2008 I liked the idea of getting in to a conference for free, and the economy was terrible and I knew there was no way I was going to get to attend a conference if I had to pay. That is why I wrote an abstract for PNSQC to present for my first time. There is a video somewhere of me finding out that my abstract was accepted, and it is hilarious! I was so enthused and shocked that they were going to let me speak. My mood changed drastically when I found out about the technical paper. Man, the first set of review comments I got I nearly quit and I had a million reasons, starting with the fact that I never wanted to write a technical paper and I wasn't a writer anyhow. The paper needed to be "rewritten" and wasn't "technical" according to one reviewer. I am glad there is no video ...<< MORE >>
If you saw me present at PNSQC, this is version 2.0 of this topic. I'll be going in to more detail about each suggestion and I'm also going to get into the topic of "what happened" as a result and explain why I don't give the metrics. I'll explain the data I have and why it isn't complete and you can draw your own conclusions from it.
When people giving presentations show a ___% reduction in customer issues and take all of the credit for it? Or a ___% increase in sales? Those people and I are not in agreement. I am part of a team. My team protects quality and provides information. When we write bugs, others make a choice about how to respond. The product quality is a combination of the design, the execution of the design, the testing done by any number of people, and decisions made based on the data from test, and then a number of factors beyond our control, such as the market the product is released in. I am a part of the product quality, but as an individual the results of the overall product do not exist in a scientific environment where the results can be reproduced the same way every time even if we did the same exact things for bug finding as the time before. When you compare software version over version without taking into account the factors you don't control you compare oranges to apples and quite often you are misleading yourself. So, I could get up there tomorrow and report that despite the changes in legacy test case coverage n% fewer customer calls were logged in this version vs the last version. I would also be a misleading you and taking credit for work that isn't mine. I would not respect myself if I did that. The fact that if you check into the revenue of the company that is available in public you can make assumptions of sales versus the last version, and you'd realize that I'd puff myself up based on selective numbers. So, there will be none of that. I'll tell you my experience, what I did, and what happened, but when we are talking about the work of many teams I'll tell you what I see as the trends, what the risks and rewards were, and what my perspective is. I can't tell you "the truth", I can only share my own perspective with you in a way that allows you to draw your own conclusions for how it turned out.
I'm excited to share with you some survival tips when you have way more legacy test cases than you can possibly test. I survived a seemingly impossible situation using this strategy and even if the story isn't pretty, it's real and it is an exciting one. There is one tip that I share with absolutely anyone who is testing in tough times, and you'd better believe I'm putting my money where ...<< MORE >>
I am in a wonderful position to know when my current job is likely to end. I have an opportunity to work on my skills while building work experience! I've already signed up for as much python scripting as possible, since I enjoy it and it helps my project, but there is also a chance for me to apply web testing technologies as I'm testing a flex dashboard as part of my job.
What are some of the key skills that medium sized software companies will be looking for in 2010? When your team is looking for an experienced tester or test lead, what tools are you looking for experience with?
In terms of the soft skills and test process and methodology, I continue to read books, blogs, go to conferences, and stay in proximity to the thought leaders I respect most, but my question is, on the technical side, what are the most valued additions I could add?
If you'd like to check out my linkedin and give me advice, I'm all ears!
...<< MORE >>
Today I found out that I've been impacted by a company reduction in force. In other words, I'm sitting here with a paper that says on the top, "What To Do Next for Terminated Employees on Transition," that some well intended HR person put together for me to stare at after getting this shocking news. Now, I realize the economy is a rough one, and I've been through this more than 5 times already in the nearly 10 years I've been an employee at Adobe, although this is the first time I've been one of the laid off group. So, the paper tells me some good things. For example, I have LOTS of notice. So much notice in fact, that I have a job until June 1st. It is early November. I am thankful to my company both for the ten years of treating me so well and growing my abilities and also for the kind severance and notice that so many testers do not get at other companies, especially in this tough economy.
Last fall and winter was spent in limbo in our household, with money so tight that I didn't get a haircut even for months. Craig had the same situation I do now, where he would report to work and it would be something like, "Good work, rest well, We'll most likely <strike>kill</strike>fire you in the morning." The whole time Craig was told he was NOT impacted. (yeah, when your whole team is dismantled and you have become the computer repo man rather than a coder, how exactly is that not impacted? I think they meant "at least you get a paycheck" but that didn't sound good.) Luckily for us, Craig got another job before his job actually ended and we celebrated like crazy. As hard as last winter was, and it was SO HARD, it turned out for the best and Craig loves his job now. He works on the Bing.com team and I can tell you, they are a good team! I know because I use the maps when Google is wrong (which is more often than I'd like to admit).
It appears this fall, winter, and early spring will be spent in limbo again, only this time for me. There is a very slim chance that a position will open up I can apply for, as I am an employee in good standing with a high performance record and good last review, but odds of a job in quality coming open? Not good. I am going to investigate every option.
I have had a job since I was 15 years old. I don't know how to not work. My cats may end up with a wardrobe if I don't find a job. And then there is the whole "feelings" thing. I know it is silly, but I feel betrayed and a bit hurt, as well as sad that I won't really enjoy celebrating my 10 years with the company. Perhaps this ...<< MORE >>
My ten year anniversary is coming up with my company. That doesn't even count time time I was a contractor. It's been nearly 10 years since I stepped into the doors of Adobe on my first day with all of my hilarious assumptions and misconceptions about what working for a software company was all about. I still love my company and feel like I have room to grow as a tester. The happy moments are essential to avoiding burnout I think, and when times get a bit rough it helps to reflect on some of the things that have resonated with me about testing over time.
Moments I like to think back upon and celebrate the most are the shipping of InDesign 2.0. This was the release where we finally took over the desktop publishing market from Quark. The team worked so hard on the quality of this product that I am very proud that we managed to pull off this release. What was special about it is that it truly was hard work, the best work we could possibly do, and ultimately innovation and quality of the product pushed us ahead. It was the integration of native Photoshop files along with better text composition that won that race, and I was a part of it. I really felt that team was strong, and back then success was far from assured. Adobe reached one billion dollars sales shortly after and it was announced and the company celebrated.
As part of that release I had the chance to go to New York city for the first time in my life and help out with the Uncork New York courses. Helping users learn the product and troubleshooting issues. New York pizza really IS that good. I went up to the Empire State Building and saw Ground Zero and this was still 2001, so it was pretty fresh still.
More recently, I've never been more excited or proud than when we shipped Adobe CS3. CS1 and 2 were very hard work, but to go from 4 to 16 products and integrate with Macromedia technology so quickly? That was an insane time, and once again the reason it was a great testing time for me is that I loved the result. The suites are THAT good. And I'm proud to say we reported the top customer issues (all of them) before we shipped. I say that not to gloat, but I'm proud of the job that we did testing that collection of products and the decisions that were made. Now that I think about it, as a test lead, this is the single best moment in my career to date. I felt like the people I'd mentored really flourished and each bit of trust given to them was returned in full. The skills of each team member grew naturally and the leadership of everyone on the team went up a notch. As a lead there is no better feeling than seeing ...<< MORE >>
Today was a banner day for me at work in some ways. Marlena Compton came to speak at Adobe and did a fantastic job! Seeing people really consider her new ideas and start to imagine where it could lead was just inspiring. Her work is scratching the surface of something so needed in software testing. It made me so happy to be able to see other people catching on to where this could lead. It isn't just the same old testing ideas rehashed. There is some new innovative thinking going on here and I think the newsmap she showed was fitting for the audience as it is made with Adobe Flash.
Anyhow, the other person who has really changed how I think about collaboration lately is a gentleman (and I do not use the term loosely) by the name of Matt Heusser who collaborated on some writing with me, and I must say it was the most natural collaboration with another tester I've experienced in ages. This guy is just a delight to write with and if you ever get down on human nature or feel that all testers are cynics and grumps, I urge you to go read Matt's blog because you will leave with a different attitude about the state of testing and a better and more balanced one at that.
So, you might think that today's blog is sponsored by the Letter "M" or people beginning with "M", but I file it under testers who I will work hard to deserve their respect now and in the future.
...<< MORE >>
Both times I've presented, afterward I wonder if I'm any good at it. It is quite hard to separate form and content when it comes to speakers, and since I talk on topics I'm very passionate about, usually I don't have people leave because they are bored. Those who were expecting someone as good as one of the keynote speakers? Well, I think I let some of those people down.
So, I enjoy speaking, but does that make me any good at it? Compared to the keynote speakers, I am not good enough. I get nervous, I talk too fast, tell many stories, and am not as orderly as I intend sometimes. I sometimes say things I wish I hadn't in retrospect because I'm too candid. I'm politically imperfect, that's for sure, but I think I am a speaker with potential. I need more experience, I need more feedback, and I need to see more GREAT technical speakers who I admire and respect.
For my second time speaking in public ever and my first time presenting Reducing Test Case Bloat (dry run I had to cancel due to sudden surgery) I am very proud. I think I did very well. I don't know how good of a speaker I can be yet. However, I'm presenting Reducing Test Case Bloat version 2 at Microsoft on Friday the 13th of November. I'll be adding in more detail on the "how" part because most of the suggestions were already on my list, so I want to convey the techniques this time, not just get people to read the paper. This time I'll ask anyone to mention suggestions during the Q & A portion if they have them and write them down rather than taking time out.
...<< MORE >>
Despite turning on the capcha, I still have spam which is annoying! No idea besides banning and marking as spam how to stop it further. Sorry for anyone who got emailed.
This morning has set itself against me. After spending money to make my clever pun based halloween costume decent for work (you ladies know what I mean) by adding about DOUBLE the fabric (leotard, tights, shorts, longer skirt, etc), the stupid zipper broke UNZIPPING it to put it on before I ever had it on. Quality, what? Ok, then the spammers got to my blog and emailed real people I respect despite my efforts.
Let's hope that there are no more tricks and far more treats in store for me this weekend.
In good news, Marlena Compton is speaking on Monday, revising her PNSQC talk just for my fellow QE! I'm so lucky she is in town. She's really smart and working on visualizing data for her Master's. Also, we met because she's a reluctant twihard who is on a pilgramage to Forks, WA.
...<< MORE >>
I had a fantastic time at PNSQC to the point I'm just worn out! I could not sit down and behave myself despite having recently had surgery, so it took me a few days, however, I have now prepared the reducing test case bloat technical paper along with the reducing test case bloat slides including audience suggestions! Soon I plan to group and reply to the suggestions, but here are the highlights.
Most of the suggestions are in the actual paper, but unfortunately NOT so much in my talk as I ran out of time and there wasn't time for the participants to read my paper before the talk, so I'm pretty sure most of them didn't realize how much work and research I did before speaking on the topic or how much of this stuff I've done.
I learned that I forgot to mention several things:
1. We need a paper for how to prevent creating bloat when writing test cases. That is not this paper, but I agree, good topic! I'd like to see some data on having an expiration date set for test cases.
2. I had not included the "start over" idea because I assumed that your test cases had more value than THAT, but that was an assumption that may be very invalid. By all means, if you are dealing with test cases of little value, starting over may be the only way to proceed.
3. The person who suggested to cut any case they couldn't automate?? You scare me so much.
4. I didn't go into detail about "remove duplicates" because from my findings so far, this is not the lion's share of the bloat, but it is worth mentioning.
The most creative ideas I heard back were to prevent bloat in the first place.
...<< MORE >>
I'm submitting a speaker proposal for the Better Software Conference 2010 which is a biggie! It's my dream as a speaker to do CAST, and one of the STAR conferences, and this year I want to submit for both of them and do my best to work towards my goal. I've been in contact with the program chair for Better Software and got his feedback on the outline. I'd like to hone in my description and title and I'm very open to feedback. I feel this topic is really what I'm about at the core, and is the reason why I go through the work of presenting, so I know I can speak about this and love it.
Main Message: The code is one important source of data to inform abalanced test strategy, but it is not enough to focus only oncovering and improving the code.While many useful discoveries can be made with code focused testing, if we make sweeping assumptions that everything of value is in the code and limit our testing scope accordingly, many important defects may be missed. Test forwhat is missing from the code, for problems introduced by integration,and you can start finding the bugs that become apparent when you aretesting with a user focus.
Description: Testing the code alone is not a balanced or comprehensive teststrategy, and while it is important, is the user getting lost in all of the process improvements? If our goal is to raise to overall goal of the software, it is key to test for the user experience and not with only a code focused perspective. The code may be entirely covered and delivered on time, but if we fail to report the issues which impeded us deliver compelling software that humans enjoy using, our test coverage could benefit from expansion.
I. How We Test Today
A. Unit testing
II. What Have We Missed?
A. The USER
III. Testing for the User
A. Data Points just waiting to be used
IV. Big Finish
A. Real examples of bugs that would be missed even with 100% code coverage.
One of the testers who's writing and work I'm getting to know, Chris McMahon wrote about Testing Innocence. Wow-the link interface doesn't like this long of a link. Testing, what? Ok, workaround time-Copy/Paste the following longest link ever www.stickyminds.com/sitewide.asp?ObjectId=15405&Function=DETAILBROWSE&ObjectType=COLsqry=*Z(SM)*J(COL)*R(createdate)*K(colarchive)*F(~)*&sidx=3&sopp=10&sitewide.asp?sid=1sqry=*Z(SM)*J(COL)*R(createdate)*K(colarchive)*F(~)*&sidx=3&sopp=10
One thing that sucks about being a tester is I never get to USE software. I'm constantly finding bugs and I'm driven to report them to see them fixed. It annoys other people. If you collaborate with me, ask me to be a speaker, ask me to write something, I'll almost always report a bug or two about the software we are using. It isn't on purpose. I'm really trying to use the software, but I continue to have the tester eyes as after so long it is just part of who I am. I would say I've always been this way, but it has gotten worse the more time I've spent testing. After reading Chris' reasons why we should all read the code, I realized I have much to say on that, so I wrote the following.
Understanding how the code works is one good data point, but it is not the only important data to consider. In fact, I would argue that what is missing (or NOT in the code) is where the most important bugs lurk. In my work I have had endless frustration trying to convince testers and test managers that code coverage is NOT test coverage, that functional testing is not "the testing" and that testing for the user experience is vital and our automation isn't very good at it. My concern is that rather than a balanced approach where the code is reviewed and understood and considered as one important piece to data that informs the ever evolving test strategy, it is seen as the ONLY important input. I think understanding the code and testing from that alone is far easier than testing the software with a balanced approach. It requires less thinking. It is possible to be more innocent because you can pretend "If it isn't in the code it doesn't exist, or if it does exist it doesn't matter." If you focus your mind in only on the code, the scope of anything seems more defined. It may be comforting, but because I love puns I must point out that denial is more than a river in Egypt.
First, let's look at what you mean by "understand the code" or "read the code":
1. You understand the design? Usually not. The code is not the design.
2. You understand the psuedocode. (You'd better! If you can't understand how it works, what are you testing?)
3. You can map/model the code. (Yes, I see this is critical).
4. You can write the psuedocode for the part of the product you are testing. (I think if you are pretty accurate here ...<< MORE >>
While I'm not sure I agreed with all of these types, I got a great laugh out of these tester type descriptions, and especially the illustrations.
I'm prepping for PNSQC, stripping wallpaper and painting my laundry room, healing from surgery, caring for a sick cat, and working on two articles today. Wish me luck!
By the way, I am "The Networker" (and also started out as "The Magician". I had a 2 year stint as "The Expert"). People come to my office and ask, "Do you know who I might contact to find out about _____ and where can I find a chicken to sacrifice and a partridge in a pear tree? Oh, also, do you know where I can find a 5 year old build of ____ product?" I must admit I usually enthusiastically send them out with a list and apologize if there is anything I don't know where to find.
...<< MORE >>
If you read one thing today, read The Fishing Maturity Model post. While I have seen some fantastic process improvements, I've also seen some pretty bad ones. Personally, the best process improvement I've seen has been moving towards agile processes and collaborative testing and development under any name, but any way where you are vetting ideas together, reviewing eachother's code and planning, and improving and sharing knowledge together. For me the worst is when every little thing is scrutinized to the nth degree, over documented, and stingy experiments begin trying to save money without proof they will pay off but still they harm the software and the people. I call this Malevolent Tampering privately and wish for it to stop, but try to take a "we'll see" stance which means I consider it unknown and unproven if it will work well in the context it is being tried and would not make bets one way or the other. Anything which reminds you too much of "The Bobs" from Office Space? Beware the Fishing Maturity Model and start asking questions.
...<< MORE >>
I'm gathering my thoughts and my courage to submit a proposal to present a StarWest 2010. I know. That is my dream presenter format. I would LOVE the chance to go.
So, if you've attended Star before or judged conference proposals, which topic would interest you more?
Code Coverage Goals are Reached! Now what?
Integration Testing Across Multiple Products
Which should I work on?
...<< MORE >>
Friday a very awesome milestone was passed. My first working python project that applies directly to my job has been completed! I am working on making it better as in order to make it work I had to put in some information I can't share, namely password. I've since been made privy to getpass.getpass() by my boss (Go Go Smart Boss).
This week I need to stuff a good 5 days worth of work into 3.5 days as I found out today I'm having surgery on Friday. What was a nice appointment with the doctor to turn in a "log of symptoms" which showed severe symptoms on 14 out of 30 days of the month and plan a surgery for Christmas turned into surgery on Friday after I scared his patients by screaming during the exam. (oops) Apparently if you can't make it through the exam without screaming, waiting to 2010 isn't much of an option. So, enough of that noise (pun intended).
In good news, October is now full to the brim of testing activity! First into surgery, then into the glorious world of flying to Texas to see a dear friend marry and navigate the world of being a bridesmaid. Then I go home for 2 days and go directly to PNSQC!
I suppose before I go I'll update with a picture since I'm no longer at all scrawny. In fact, I can report myself a plump 5-11lbs overweight depending on the day, so pretty much American, yeah? Also, I haven't gotten a haircut in an entire year, so talk about redheaded. Major red hair for sure. So, my goals for the year in some ways are being downgraded. My goal to not get surgery all year? Not met, but pretty close. My goal to be at exactly a perfect goal weight? Not met, but pretty close. Too bad these aren't horseshoes goals.
There are some areas of life however where my goals are being exceeded. I am shocked to report that I LOVE python so far! It is 20% more Lanette compatible than any language tried since Action Script 3.0. I still curse when what I write doesn't work, but I don't curse and throw things, so that is great! And when it works? I love it! I have to show everyone which is pretty immature I suppose, but it results in great improvements to my programming and knowledge as I get feedback. I love my new job assignment! I'm having major chunks of the week where I get stuck in "the zone" and get bursts of work done. I'm learning really fast and I feel supported and appreciated in my learning by the team. It is my first agile project where I am on the team and have a status to share. I need to work on being more concise, but my enthusiasm is in contrast to brevity sometimes. If you read my blog you know why I don't twitter.
I ...<< MORE >>
Last night at dinner Craig asked me to tell him about my new team.
I told him the name of each member of my team and something important about them, for example, one has a 10 year old boy who is in the Boy Scouts, one has an Australian Accent and runs marathons! I went through all the members on the team, and then told him I was excited to have a developer counterpart again on the job.
Craig laughed and asked why I told him all of this personal stuff when all he wanted to know was what the team does. Do we make software, or what? I then told him what I work on and what the team works on to answer the question, but I still think the most important part is what I told him first. What people are on the team and who are they really as humans? That's a vital part.
...<< MORE >>
I love this new job, but being Day 3 of "officially" having this new assignment I came in a bit early, day 2 of the smoke tests I insisted on, because we had this big "dry run" with the whole team present and lots of integrated parts. I found a bit of a problem, well, actually the smoke test failed. Ok, it wasn't a small problem. It was a MAJOR catastrophic problem.
So I emailed the team off of the chat room we were all in because I didn't want to shame anyone thinking that well, maybe what we have on the "dry run" setup is different than our staging server. I don't want to rock the boat since I'm already a newbie. So I send out the email, and 20 minutes go by, and I hear nothing. I join the conference room to "kick off" the process and they immediately ask me and the other QE if there are any issues. WELL! I'd sat on vital blocking information for 20 minutes. I was so afraid to cry wolf again that I didn't say a word to the public and no one had seen the email. So, I wasted everyone's time.
I've had strangers tell me that my mouth gets me in trouble. I just got fired from the HOA volunteer job I had for refusing to comply with a request from another board member that I didn't think was ethical and telling him that he could do whatever he wanted including fire me, but that I'd never comply with a request I didn't believe in and I wasn't going to cooperate until I felt I was doing the right thing. It turns out with the new job I wouldn't have had time for it anyways, so luckily for me I got fired. The point is, I don't like conflict, but I certainly don't run from it. I'm a big mouth and I'll stand up for what I believe in, when I'm pretty sure I'm right. That's the issue. I defer to those who know more. I'm just learning what I know and don't know on this job. I'm still digging through the log files to find out what is important and what is not. I'm still learning how everything connects and how to prioritize the bugs and tests. So this once I didn't speak up.
The last time such a thing happened, I turned to my best friend and sang, "God is mocking us, God is mocking us, God is mocking us,..from a distance." Now, she's a believer, both of God and of Bette Midler, so she understands I meant it in the best spirit, but even you atheists have got to admit, that's pretty funny when that happens. When the mouthiest person doesn't speak up, that's Murphy's Law.
Now next time I'm going to be all hysterical pre-maturely about a bug and it won't even impact the whole group and I'll look foolish.
...<< MORE >>
My wisdom of the day to you, in bitesized bits because I can only blog for 3 minutes while waiting for this critical bug regression test to run is to think small.
Why? Because when faced with a big challenge it is so easy to get overwhelmed. Do one small thing each day and it adds up.
There are so many things on this new job that we need to get done, but the first thing I started with was a small series of tests in the morning. Sanity, then smoke tests, then a tiny integration test. Once we establish a quality baseline at least we'll know if we are improving or not in quality. It is a tiny step towards what we need to get done, but it is something we can start now and build on.
It is better to have a small automated test that is working today than a brilliant framework that no one understands that is working 3 months from now. Think small.
Also while thinking small I minimized and shrank all windows of everything I was testing and reported tons of bugs. Then I changed my screen and font size. So, how else can you think small today for the sake of quality?
I don't mind if you tell me today that I'm small minded. If the tiny hat fits, the pinheads will wear it. Put one foot in front of the other and eventually we'll get somewhere sooner than those who are standing still waiting for a large brilliant plan.
...<< MORE >>
I am elated to report that I started working in a new role in my company yesterday! I've been wanting to take on a new challenge and I'd been in the same job since 2006, so I've been trying out a few things. One of the project I've been helping out on, luckily the one I've enjoyed the very most, it turns out can use my help immediately and on an ongoing basis. I'll get to contribute to the overall test strategy as well as do actual testing on a mission critical service for the company! I'm delighted, enthused, pumped, and I love the team I'm working with.
So, while the good news is I'm taking on a new role and I'm learning so much and I'm loving it, the bad news is the reason why I've changed roles is this team really needs my help because they have been low on resources. That means lots of overtime, hard work, and a need for me to be productive instantly and to pick up depth of knowledge yesterday. Also, in addition to my Action Script 3, I'm dusting off my rusty but trusty batch file skills and trying to ramp up on some python for some automation we also needed to be up and running yesterday. Anyhow, I'm very happy to be taking on this new role and I have an opportunity to make a big difference.
...<< MORE >>
Tonight I'll be heading over to the Geek Girl Dinner at Microsoft main campus. If you see me there, say hello!
This weekend I'll be working on some designs for the signs at PNSQC to help people get around during the conference. I hope they turn out well. Knowing my style, expect swirly, and a goth version of corporate.
Also, I'm teaming up with Jean Hartmann of Microsoft to host one of the Birds of a Feather tables at PNSQC on the topic of dealing with legacy test cases. He is also presenting, and her topic ties in with my topic, but his is much more from the automation side and explains how to reduce test cases using code coverage tools for more effeciency.
Last but not least, I'm working on completing my slides for the presentation since Jean has offered to arrange for me to come present at Microsoft prior to PNSQC! I'm hoping for great feedback, and if I'm able to get a recording of my presentation I'll share it here as well.
...<< MORE >>
There are certain sayings that people use that seem wise, but really say nothing. They may be used to deflect blame, change the topic, or just fill up silence. Here are some strategies for working with some of these sayings.
1. Thank you, Captain Obvious. These are sayings that I even find myself blurting out on occasion and I wish I could retroactively shut myself up.
"It is what it is."
"What happened happened."
"Let's leave the past in the past."
"What's done is done."
"No use crying over spilled milk."
Reactions: No, do not say, "Thank you, Captain Obvious!" or something equally sarcastic. Instead just ignore it and maybe even a little play on words to et back on track such as, "Now what was it that happened?", "Ok, well, I'd like to understand what it is, now what can help us do that?" "Well it is past, but it is still impacting us today, so how can we make sure it is better in the future?", "How do we best mop up that spilled milk before it stinks and the baby starts crying?"
2. So what? These are sayings that if you think about them too long make you wonder why anyone thinks they are helpful.
"There is no "I" in team."
"We just need to do more with less."
"I'm 1000% sure!"
"Give 110% to get the job done!"
Reactions: "While there is no 'I' in team, there is a me, and there is also MEAT, but it isn't kind to eat your team or beat your team, so treat them well, all of them, and do not say this." "While I understand resources are constrained, what are the priorities so we know what to drop since 100% really is the total. There is no extra 10% nor is there a realistic way to do more with less, so what is most important to you?" Also, I've learned the larger the percentage of confidence, the more of a lie you are being told. The person who is 1000% sure really isn't sure at all. The person who is 95% sure is way more sure than any percentage above 100%. Do not trust people when they have a creative numerical scale.
3. Yeah, and, that changes the situation because?
"It worked on my machine!"
"That isn't ready to be tested yet."
"I noticed that, I just haven't fixed it yet."
"Oh, I already fixed that in a future build."
"No user is going to do that!"
"That doesn't happen in my file."
Reactions: "Let's find out what's different on my (machine, file, monitor) so that we can fix it." "When will that be ready for testing? Can I have a handoff when it is?" "Great, send the bug back to me with notes so I can regress around it when I get your fix." "Well, I'm a user and I did just do that, but if you don't think ...<< MORE >>
We have this huge push like nearly any professional software company, to try to move our quality process further upstream and to reduce drama. This makes so much practical sense. Our senior director of quality is a super smart guy and he puts his money where his mouth is and puts down solid goals and really risks failure in order to change things. He isn't one of those people who 3 months later just gets distracted and stops talking about his previous goals. He's serious as can be about making less drama.
Well, I understand that goal but I can't say I find it emotionally appealing. The truth is that I started acting in plays at the age of 11. Back at Expo '86 in Vancouver Canada I was an elementary student and I had a choir, dancing, and acting part in a play at the World's Fair and I thought that was pretty cool. I directed one play and acted in 11 plays while in school. If you ask other people, "Do you consider Lanette to be low drama and laid back?" I'd be entirely shocked if anyone said yes. So, that leaves me conflicted. I do want less drama because I care about overall quality. That's for sure. I want predictable and excellent software. However, uncovering bugs in a crafty way, seeing them fixed, and knowing I saved someone from a nasty problem is where I get so much job satisfaction. I don't feel that way about just seeing a test pass. I feel pointless when I just do my part and don't see any result. I'm not fine being just another gear in the machine--pouring out reliable and steady automation that passes, or fails in an isolated fashion. I want corrupted documents, crashers, blue screens of death, and drama. I want the Young and the Restless of software right on my screen. I want a horror movie of database corruption and a torture movie full of performance problems to report. If you take all of the drama out of the software, then where is the fun and where is the excitement? I want to save us from the shame of delivering less than a worthy product because that is the really satisfying part of the job.
I'm working on the new job for Wonder Woman now, and I believe it's a good idea for me to work on this project. It's high pressure, high risk, and high drama. The difference between the testing and the real drama is that no one dies if we fail, and no one marries their wives sister due to amnesia in software (that I know of). I'm pretty sure if you are a test manager you have some testers who just want to be left alone to make nice reliable automation. Then you have your people who come in beeping and flapping about some bug or the other they just have to let you know about with that excited expression. ...<< MORE >>
I'm working on this great team but I found out yesterday that the question of load testing came up, and the answer the team came up with was, "Thank you, no."
I'm trying to phrase this correctly and instead of: Since we know it is so well designed that it is going to hold up, how about we throw twice our worst reasonable fears at it just once and if no issues are found at just twice the worst case scenario I promise the next day I'll come in wearing a t-shirt that says on it, "My paranoid tester thinking cost the company time and money. I made useless testing happen!" and on the back it can say, "I was WRONG, so wrong, and it isn't the first or last time either!"
I'm thinking a calm question of: Why did you decide it wasn't needed? is the more professional response.
Now I'm going to go home and have nightmares of people saying, "Testing? Yeah, we thought about that but we decided not to."
The top thing I love about this job is the products. I know everyone says it's the other people blah de blah. Fine, you be nice to people, and yes, we have great people, but for me you can find decent people many places if you are willing to listen and be selective. I'm here about the products. I consider myself defender and protector of products. The products here are quite good. Standout really. Worth fighting for quality in. Yes, it's likely I enjoy testing a bit too much.
...<< MORE >>
I have the amazing luck of spending part of my time right now working for this woman who I've wanted to get to know. She is warm and smart and has a way of accepting change that I could learn from. She also has this knack of being politically smart without being at all insincere or compromising or weak. I have no idea how to even start doing that. I really admire her.
So far I'm working really hard and enjoying her team. I'm trying to balance the old work I have to do with the new, but being me, I'm trending towards doing all of the work I want to do first and the other stuff I'm behind on. This makes for a sad realization on a Wednesday night that if I don't change my evil ways I'll be working too much over this holiday weekend and I sure don't need that. It appears I'll be stepping down a notch from project excitement. There are so many opportunities right now to learn and do that I can't seem to help but miss some of them. I'm just glad I didn't miss this one. Already I'm feeling pumped about it.
...<< MORE >>
Last night I told Craig about a bug I was glad to have found doing exploratory testing and how per the usual it makes me sad that it is undervalued as a test methodology. I told him I would try again to at least tell my boss that we are still finding quite important bugs with it.
Craig asked, "So, are these different people you are trying to convince that it is important, or the same ones?"
Me, "Oh. Yeah. Still the same ones."
I proceeded to think about it with a disappointed look. I've tried to not care about it, and it isn't that I disagree with using a variety of good quality practices at all, including well planned automation, using existing tools, and even creating tools sometimes. In fact, I'm involved in many parts of quality planning and execution. I just don't understand why having talent for exploratory testing isn't valued as one skill among many. It makes me sad because I'm not mediocre at it. I'm really fantastic at it and I love doing it sometimes.In fact, I quite enjoy doing other things as well. I just don't understand why the ROI on exploratory testing is so often ignored, considered too costly, or just skipped as being "the past", just as the ROI is inflated on automated testing when it is still missing so many bugs of critical importance and it is still so often sucking in the areas of sustainability and cost of adapting the automation to a changing product under test.
Reality. How much does it change when your perception of it does? According to "the Secret" all of it.
I'm planning to head over to see Harry Robinson speak tonight if my pain level is conducive to me sitting for that much of the day. There is no reservation status for "Living in a cage of pain. If walking with only a slight limp I'll be there, if grimacing and walking with severe limp signs point to no."
UPDATE: I drove over there and was so confused about why no one was there. Ummm DUH--It's September 9th!! Guess I hope that's a decent pain day because I'm excited about it.
I'd like to thank the good Dr. K and my wonderful and patient boss that I'm still employed at this time. I care very much about the success of the products I work on and the overall quality they produce. I put my talents to work in any way I can to reach the overall goals.
Talking about having good results with exploratory testing is sort of like talking about the importance of still testing what customers are using. It may be true, but it isn't an interesting story that people want to invest in. It doesn't sound good and no one wants to talk about it who has any power to finance more of it. It is something just taken for granted, like ...<< MORE >>
Whew! I've been working so hard that I've neglected my blog I'm sorry to say. However, please check the PNSQC 2009 schedule! You will notice that I'm on Tuesday, October 27th in the Testing track. The paper is final, but the slides are not, so I'll be working hard to make it a fantastic presentation.
I hope that you all are having a fantastic summer.
...<< MORE >>
I had the pleasure of taking a class in person this week from David Gassner at BardoTech that made more difference than I could have predicted. He also offers some online training at lynda.com from what I understand, and I'll be checking that out. I have a breakthrough day on Wednesday and after class yesterday I got home and proudly told Craig all I thought I knew about programming and far more of it was accurate than ever before. The reason why is not just the length of the class, but the teacher and the other students. I wanted to share some of what worked for me in case you are trying to help someone else see some progress and finally gain some confidence in their code enough to not hate it.
1. Paraphrase constantly. Do not just say, "We are now typing addEventListener,...", instead say, "We need to know when a user clicks the mouse so that we can react. We have this class that comes with Flash that knows about all sorts of Mouse Events. So, we are going to be listening for that now.
2. Repeat, repeat, repeat. Not back to back, but at least 3 times in the day talk about the same key concept in different ways. Having multiple chances to understand really increases the odds to improve.
3. Explain WHY it is wrong when the student makes a mistake. Don't just say, "Well, you need a colon there, not a period." Instead of saying, "You need to move that code into the function above so it will work." you can instead talk about scope a little bit.
I am super excited because I went from everything looking like magic from the library to understanding about 40% of the basic examples (NOT complicated stuff) in 3 days time. It is the first time I enjoyed writting code. I am so excited to take a class on object oriented programming fundamentals because I feel like my weakness in that area is the most key factor that is holding me back. Once I get a little more understanding I don't improve a tiny bit, I improve in leaps. Any ideas of where I can take a good classroom Object Oriented Programming foundations course in the greater Seattle area? I want an in person course if possible as that is where I learn best.
I'm just so thankful today and wanted to share with you how much I loved my course! In other news, one of my co-workers has offered to think of an assignment for me to practice my ActionScript 3 with once I finish the 2 tutorials I have. Once I'm feeling more comfortable with writing my own custom classes and using what exists in Flash Authoring, I'm going to try learning Flex.
In other news, I'm mid-draft on my PNSQC paper and need to get the final revision turned in by Sunday. I'll be ...<< MORE >>
Several nights ago I awoke from a terrifying dream. I was in a classroom where they were training testers. Large banners of mission statements were hanging near the front and acronyms were posted around the room. The teacher upfront was sort of like an Amway spokesperson and would call out, "What are our A.B.C.'s?" This eager clean faced young Skippy replies, "Always Be Certain!" Everyone in the class agrees parroting back their learned acronyms. The guest speaker arrives and it was this developer I used to work with who I really respected, someone very smart but soft spoken. The slides come up and the presentation is a very technical and engineering focused slide show explaining nothing about testing in any way. As the presentation ends I start to ask questions about what testing risk do the changes introduce to try to get some discussion going about that. Silence and dirty looks. I try again and ask what development challenges were faced and get a vague answer. I give feedback that I'd like to learn more about the topic as it impacts testing, or at least follow up with someone who knows about the testing aspects of the technology and was looked at like I was crazy. Knowingly, the people looked at each other in the classroom. I was somehow shameful and an embarrassment.
I'm afraid that testing itself is becoming antiquated in the opinion of some people who are smart people, but simply do not see the point of testing beyond getting to complete code coverage. I worry that at the core there are some business people who do not understand that software testing has value because they are trying to engineer their way around doing any testing. Please note that this isn't about automated tools or test automation, because test automation when done well still should be about solving testing problems, and accomplishing tasks which result in higher software quality.
Assumptions that I fear:
1. Testing tasks can be done by anyone when using an incremental development model. Testing should be done by anyone on the team who has time in order to be efficient and "agile". In fact, by not having designated testers, you can possibly keep a faster velocity because everyone will do everything, including everyone coding on the project at the start of a sprint and everyone testing the features to get to done at the end of a sprint.
2. Testing tasks should be all done by developers. In fact, a CS degree and a testing certification are worth more than years of experience.
3. Testing qualifications are based on certification and coding expertise. Test knowledge is coding knowledge. Knowing how software is built in theory is far superior to testing because any non-code testing is "blind", "needlessly time consuming", and "manual" and is only done by the poor peons who do not know how to code well enough to use the better (automated) way of testing.
4. Good development methodology produces quality ...<< MORE >>
I've been putting off getting a new phone for many reasons. The last time I got a phone was 2 years ago and I got so angry about a text messaging bug that I got in trouble with Craig for cursing and talking bad about Verizon. Craig even argued with me that it isn't a bug, but I told him they had more than 5 choices of how to handle this issue and they chose the 1 worst possible answer for the user. Here is the situation.
When you send a text message from a Razr to any non-verizon phone which has more than 160 characters the additional characters would not fit into one message. What that results in is a series of choices. Either Verizon could restrict the entry to 160 characters if they KNEW the message was going to a non-verizon number (but that would require more work to actually know in advance what network the message was going to), they could alert the user before sending that the message would be lost after 160 characters IF anyone they are sending to was not on Verizon. They could give the user a choice of sending the rest in a new message before sending. They could offer a "settings" option where in this situation a user could set the default to send 2 text messages in this case. Worse, but still useful, they could save the rest of the characters in a draft message if it couldn't be sent. But no. Here is what they did.
They give the user NO alert, but once you sent the message they text you back immediately that you MAY have lost the rest of the message without specifying WHICH recipient wasn't on Verizon. You lose all of the remaining characters, so have no way to send them again. This has resulted in partial freaking addresses. Unintended meaning in sentences. Jokes with no punchline. Frankly it makes me so mad when I hear that sound of an immediate text message coming back that it LOST my message and I have no idea who would get the rest even if it bothered to save it for me (which it didn't) that I hate my phone, I hate Verizon, and I don't want to buy anything from them again even though the reception for phone calls was better than any other network. What Verizon fails to understand is that I don't like to talk on the phone. I like email and text messages. They made a terrible decision on ONE common situation and failed to make a reasonable option for a texter who can get verbose.
Yesterday I bought an iPhone. WOW. I am blown away. I feel so bad for Craig. He bought a Fuse. I experienced absolute wonder and delight discovering my iPhone features. He discovered frustration and disappointment with intermittent excitement. The difference? It's all the UI and the experience. I can not believe how attached I already am ...<< MORE >>
You will be happy to know that our house is 17' tall. We first measured with the laser. I then got the rickety old ladder out and measured by flinging the tape to the gutter and measuring from there. I have video of the laser remeasure to share with you and the math. After the measuring was complete we watched a TV lecture about robotic cars. I brought in the gutter cleaning robot for Craig to cuddle up to while we watched it. I have such a fortunate and geeky life! FYI-you should have seen Craig's irritated expression when I told him that 5 and 1/8th inch was the same as 5.18 inches. It really is too easy to tease him.
I just wanted to share. I'm writing like mad to finish up draft 1 of my PNSQC paper. I hope the reviewers like it. I'm really open to input and I just want so much to present and discuss this topic with others. I'm considering doing the poster paper just so I can hear the ideas others have on it.
Measure gutters with laser.
...<< MORE >>
I share this with you because as a tester, one of the things I love the most about my job is working with other geeky people. Now that I have my very own dev counterpart at home, I am also amused with how engineers approach problems other than just customer problems, software problems, and bugs.
Mission: Clean the Gutters
My Idea: Hire someone.
Craig's Response: Too expensive, besides, needs to be done often. Let's do this ourselves.
My Next Move-Buy adjustable ladder which claims to be the "only ladder we need" on sale for $99. Assumes this is absolutely good enough for the gutters.
Craig-Reads reviews, watches online performance, and then buys gutter cleaning robot from Roomba to automate this task while negotiating half payment of robot by me.
Testy Redhead-Gets robot in the mail, reads all instructions, puts it together and charges it.
Craig-Finds ladder not tall enough to reach gutters in some areas of the house.
Both of us last weekend-Go seeking extension ladders. Even the $200 ladder holds only up to 200lbs WITH all supplies including the ladder itself and the robot. Realizing this means I now have to do ALL tasks on this ladder, we refuse to buy it as to be safe with the ladder itself being 33lbs anyone over 167lbs shouldn't be climbing the ladder according to Craig, which rules him out even if I don't feed him for quite some time.
Testy Redhead-Sends Craigslist links to Craig for ladders that are taller, cost less, and hold enough weight for Craig to climb it with the robot.
Craig-Being unsure how tall we need the ladder to be determines we need to know maximum height.
Testy Redhead-Suggests we get a tape measure and climb our current ladder to measure the difference.
Craig-Shoots down this idea because there is no way that will work and my tape measure will flop over (I don't think it will, but he does).
Testy Redhead-Suggest we tie a rock to a long piece of her knitting yarn, throw it into the gutter, straighten it to the floor, mark it off and measure the string.
Craig: I've seen you throw and we have windows. I don't like the idea of you hurling rocks at the house. This could end very badly. I have a better idea.
Craig's Brilliant Idea (that we are about to go do): Measure the height of the gutters using a laser pointer and the Pythagorean Theorem. We'll measure the distance we stand from the house and the angle it takes to get the laser to the top of the gutter. I kid you not.
My reaction to this was to laugh hard for about 4 minutes, and finally say, "I'm so blogging this." ...<< MORE >>
I've been out from work ill this week with an irritating virus. Considering that I've emerged victorious from 3 surgeries in the last year I believe I deserve a break from all airborne illness, but I digress. Stay away from others who I could infect gives me the perfect opportunity to take this entire weekend and get my technical paper on reducing test case bloat to a reviewable state so I can goof off next weekend instead of working furiously towards the deadline and falling asleep on my laptop risking getting drool into the keyboard like last year (ick), now that I've said that I want to sanitize my poor laptop.
I just attended a tech talk on virtualization (cloud computing in particular) and it energized me so much. Then I got my detailed assignments for next week and after a moment's panic realized, YES, I CAN do this now. While I'm so happy I wanted to write it out. Here is it.
Reasons I'm Thankful
1. The opportunity to learn has never been more apparent than at this time in my career and the work of mentors has made it possible.
2. My boss and Ajay J all working so hard so my team has a good build to go. They listen, they act, they make it happen.
3. My co-worker Chris for giving a Java class and being so patient. I'm learning and having some moments now where I don't HATE coding. Having a good teacher helps so much, and being able to work on building skills over weeks rather than in 2 days works much better for how I learn.
4. My team for being able to take over so that our team goals don't ever fall apart if I'm not there. I'm so proud of them and I believe there is nothing they can't do or learn. They amaze me and I am proud of how resilient and professional they are under pressure (which everyone IN test has been this year, in fact everyone in the country has been). How someone acts when things are rough shows their true character more than just how they behave during a good economy when budgets are plush.
5. My Action Script is improving! This is going to sound so silly, but for the first time ever, I'm assigned Action Script code to write next week and I'm excited about it! After doing just 3 lessons of Java I'm feeling less intimidated by having some scripting on my plate that I get to do, and if I run into trouble I can scale down, but if it goes well (and when I'm happy things tend to), I'll add some really cool visuals which will be so fun!
6. I have joined our Wiffle Ball Team, and while it's likely I'll be mostly a backup player until I get more experience, just the fact that I'm in good enough health finally to join any sport for fun? ...<< MORE >>
In email today I was thrilled to see this:
Congratulations! The Program Committee of the Pacific Northwest Software Quality Conference has selected your paper (Title: "Reducing Test Case Bloat") for inclusion in this year's conference!
So, pending final paper acceptance, I'll be presenting at PNSQC and attending!
Now, on to writing the Technical Paper with "the best research ever", which I'm looking forward to! I want this paper to be my best work. First draft is due June 20th. I'm going to possibly take the train down to Portland this time so I can read on the way if I'm the only one from my office going. If you live in the greater Seattle area want to carpool down to Portland, let me know. I'm an excellent navigator and can pitch in for gas. I'm generally cheerful and pleasant so long as I have lots of cool Diet Coke to drink and you don't force me to listen to country music or right wing talk radio. ...<< MORE >>
While I almost always prefer to focus on my areas of strength, there are a few areas of weakness that I'd like to address to some extent because I feel it would help in terms of credibility and make me a better tester and enable me to better collaborate with and understand other people.
For this reason I'm taking on some exercises to practice my thinking and raise my tolerance for tasks that I think of as "uninteresting" and mix them with things I do find interesting, like research.
So, I present to you the results of last weekend's training exercise. This is an excel spreadsheet that is a breakdown of household grocery expenses over the last 3 years. It also includes the national average adjusted for the cost of living in King County Washington (which is higher than much of the nation). Were I able to more easily find the data I'd compare against the costs of eating out because what this doesn't show is that I cook on average at least 10 times per week and only buy lunch 1-2 times per week at work. If the only goal were to lower the grocery bill, just eating out more often would do that, but it would also mean that food and beverage would consume more of our budget. I should also note that while most people get coffee out or go to the bar, we only do so about once per month, so the wine consumed at home is part of the grocery budget. What this chart also doesn't show is that when we first moved into the house we had never owned a home before and we had to buy many basics at the grocery store that were non-food household items. Those items tend to be expensive things like cleaning supplies, laundry detergent, cleaning tools, cooking utensils, and one time staples that are only replaced every so often. What looks like "waste" may not be. Yet most business decisions are made by this kind of "valid data". Creating data that is viewed as valid is very powerful. It needs to be "not wrong" and show how things are trending.
...<< MORE >>
I got up at 6am today so I'd be ready for today. I had emails in to my colleagues in India clarifying something about the builds I needed to know and got a very thoughtful and helpful response. Today kicked off the very first cross product workflow testing of this product cycle! The setup is all automated on the client side and I'm working over the next 4 months in that legendary spare time I'm rumored to have to automate the creation part which I'm doing manually. The people participating are great thinkers, have decades of experience as a group, and I have much respect for them. They care about testing end-to-end scenarios and reporting back on usability.
This time it feels even better than ever to start my testing engines. It makes every conversation where a person just "doesn't get it", every difficulty getting setup where it feels like herding cats, every conversation I've had with other people who feel like they should be the top priority and direct all of the testing that is done, every assumption that the reason for confusion is somehow communication on our part is all well worth it just because this testing is happening at all. Less often and with fewer resources than I might wish for, but it IS happening and that is a very exciting thing. That is worth every downside. That makes my entire year.
The thing that most people don't understand is that coordinating testing is much harder than working on one product or technology. The planning is insanely complex. Talk about stakeholders! It's a conglomerate of stakeholders and ultimately "the software user" is the most important stakeholder, but not everyone agrees on which customer is important. It's the ultimate test of managing up, down and sideways all at once.
While most people involved in software that I know will claim that user focus is important, when it comes down to making the tough business decision to slip a date, allocate resources, or follow the advice of a user study rather than design what engineering wants to make, you find out just how important it is. The truth of priorities comes down to the question of, "Is it funded?" Companies vote for which customers are important by investing time and money. In testing usability we try to report back what they are getting for the investment, both in the new user and the power user scenarios.
It's tough to explain when someone who is very focused on their particular product asks what is in it for them if they choose to participate in collaborative testing for the user experience. It seems very flippant to answer sincerely. There is nothing in it for you personally unless you use multiple products or a majority of your users do and you care about their experience. Immediately there would be no gain, because you can hit milestones more quickly by only verifying that you match the spec exactly ...<< MORE >>
There MIGHT be an opportunity for me to create some models and work on some non-static automation! Oh just the thought of it has me so happy. I'm geeking out. I know, with my critcism of automation, why? Well, when the automation changes some each time you run it and is based on likelyhood I get super excited because I can see this becoming the ultimate smoketest! It's like a super smoketest. It's not at all the same as user testing, but this is the type of automation I want to work on because I believe in it. I think it is interesting. It's doing what I consider "real testing" and it isn't dull and repetative.
Anyhow, I need a UML book, tutorials, and practice as well as a few good books on model based testing. We have a tool here called "gliffy" that is part of a wiki. It's pretty painful to use to create models. Are there less painful modeling tools out there? How about FREE tools?
I'm not exactly sure how to get my boss to pick me for this project but I'm like the Donkey on the Shrek DVD leaping up and down "Oh! Pick me! Pick me!" Enthusiasm might help, but I think what will seal the deal is showing up with an amazing example. The problem is I'm "high will" in this area, but not so much the "high skill" that I want to be. However, I'm more motivated to do it than the other people and I want to do it more than some of my currently assigned tasks. Any tips for me on this? Reading recommendations?
...<< MORE >>
Before I share personal entry, I know I'm one of the most fortunate females in all of the world to earn a living with my mind and to be judged on what I do rather than my gender or any other traits. That said, even in the country where the best opportunity for equality exists, sometimes something will happen where it is clear that there is still a need for women to fight for equality. This represents only my impression of one rare event, not an impartial view of any intentional bias.
You make me feel so stupid sometimes that for a second I forget that I'm a fantastic person and a capable employee. But then slowly the truth leaks out. The fact that you don't value my talent doesn't make it disappear. You look at me like I am nothing but a problem. You aren't even the only one or the first one today to entirely overlook my value.
I had to look in the mirror, stand up straight, smile sideways at myself, and envision a tiny pebble *dink* bouncing off of my armor.
So the tide of confidence pulls away, dragging me in to doubt and insecurity. Telling me just to quit, just to avoid you and let another man deal with you that it isn't worth it, that talking to you is pointless and that I don't have the ability to even make you understand. That negative voice just creeps in. You don't know enough, silly GIRL and that is implied in the way you look at me and I almost believe it for a moment too. My knowledge and passion is worth nothing and you make it clear that you don't support me and that see nothing I contribute as valuable and you even sort of laugh when I offer to help you or work with you.
When you are judging a person as an idiot, what criteria are using? I would hope that the way they treat you would come in to play at some point. I'd never treat you as though you had no value even if I disagreed with most of what you said. So long as you had ethics, I would respect you as a person.
So I don't have the depth of knowledge that you do. I don't mind if you consider me less intelligent than you are at all. I'm not even close to one of the top 1000 most intelligent persons in the state, let alone in the world. Scores of minds are thinking circles around mine at any moment. It's only the fact that you don't acknowledge my value at all that hurts.
It's small incidents like this where for a few minutes I want to be done working in a male dominated industry, take my ball and go home. Just be done playing with those mean boys where each day I go to work there are fewer females ...<< MORE >>
I got my first chance yesterday to really use a web hosted server/client virtualization tool and I loved it so much that I've become sadly spoiled in one day and now feel upset when I have to test using a regular machine. THIS is how I want to test from now on. To log-in, start the environment I want in exactly the state I want, not manually be messing with multiple machines anymore, not having to manage my own disk space or resources anymore, but to be the queen of the virtual palace of testing!
I Love it Because
2. Easy to share the "exact state" with others by just sending them a link.
3. No one else can mess up my state or configuration, NOT even me! A tired testy redhead without caffeine is no longer a threat!
4. I can keep the configurations I need and if I want to get rid of any it is super quick and automatic.
5. It just makes sense to share hardware this way.
6. No more annoying switches that beep.
7. I love to work from my laptop. I've been switching between machines all day for so long that just switching browser tabs is so much nicer. It feels organized, in control, and great.
Still not perfect
1. Why no Mac OS? I can't use this until it supports the Mac as well.
2. The tool still crashes IE all of the time and has issues on Vista. Need to test the testing tool. I'm glad to send in bugs, but PLEASE take stability seriously? If you can't run the VM in the "supported" browsers, it shouldn't be on the box.
3. Very expensive per user, so hard in this economy to convince others that it is needed.
4. I haven't figured out yet how in the world I'm planning to print from my virtual world. Input/Output is still a bit hazy to me. I need to learn more.
...<< MORE >>
This weekend we used my Garmin Nuvi GPS to direct us to a friend's house we've never been to before and got some interesting results.
1. According to the GPS we were driving on water! As I don't own an amphibious vehicle, this data was false.
2. The humans told us why we shouldn't go the way the GPS had us go even though both paths technically would work.
Good things about the GPS
-It didn't seem to mind that we were driving on the water, so at least it didn't stop working or error out. Our car was on a ferry, so in a way, we were driving on water.
-The GPS efficiently got us from point A to point B with the fewest turns possible.
Factors the GPS Disregards
-Safety. The humans don't take that route because it is hard to see around the corner with the overgrown vegetation.
-Comfort. The GPS doesn't know which roads are bumpy or smooth or which have potholes.
-Police. One of the roads contains a speed trap often. Locals avoid this road.
I bring this up to explain why unit testing and a high percentage of code coverage is NOT enough testing alone. It's a great start. We most certainly should perform this testing and move quality upstream as much as possible, but when we neglect user research, user input, and devalue product expertise in the profession of testing, we are driving like a GPS and not like a human. We are shipping software with an unknown user experience which lowers overall quality.
Using the product is not enough. Testing the code is not enough. A brilliant combination of both can come together to make a good software testing strategy.
...<< MORE >>
I wrote an email yesterday that got results. Yes, on a Sunday I wrote an email and as a result, two of my neighbors ended up in my livingroom giving me a high five and we are getting together in a few weeks to have a wine tasting in celebration of some positive changes that are being made in the neighborhood.
Two years ago I could not have written an email with that result. There is no possible way because instead I would have been.
1. Avoiding conflict.
2. Beating around the bush (not getting to the point).
3. Escalating anger and riots with a snarky response which while it may have been funny would NOT have been productive.
4. Rambling on for 2 pages writing a charming but unconvincing prose filled page.
So, what has changed? How did I go from writing a totally ineffective email to one that not only got across the key points, but gained promoters who are now friends and also support my ideas? It is only through the mentorship of some amazing test managers who both by example and feedback have helped me gain a few skills. When you get an email or there is an issue you strongly disagree with, here are the things that have worked for me.
1. Respond while it still matters. Time moves fast. People move on. You may need to take 15 minutes to calm down, but when it is really important waiting 24 hours may mean your response is irrelavant. Don't react out of anger, but respond in a timely manner. Do not put off responding when it is important. This could not wait even one more day because I wasn't willing to dream about it at night.
2. Don't take it personal and don't make it personal. If you are defensive, offensive, or just clueless you aren't going to be effective. There is never a reason to be unkind, personal, or use a low blow. I'd say not taking it personally is really really hard and I'm only just now getting some practice at it. People with self-esteem don't take it personally even if it was intended to be. A confident person can take an insult and put it in context. That's just the opinion of one person. Don't let their opinion define reality nor should you assume that your opinion IS reality or can define their reality.
3. State your assumptions and your intent. Don't make it a guessing game. If there is a common interest or even somewhat of a shared goal, state that.
4. What's in it for them? Why should they care? This information should be on a silver platter.
5. The bottom line is now the top line. (Thank you to Laura Browne who taught me this). People hate reading. The conclusion should be the first line of the email right under your greeting.
6. Details should be labeled as details, contain ...<< MORE >>
Ok--Scratch that. -Please review this
First Draft Below
"We may be through with the past, but the past ain't through with us." Magnolia (1999)
Picture two groups of plane crash survivors suddenly stranded together in a remote location, a few survivors out of hundreds, yet somehow all of the luggage has made it through unscathed. These groups of people must travel to make it out of the wilderness effectively together, with as many of them as possible surviving. Group 1 takes all of the luggage, distributes it equally on to the backs of each member, and as a member falls to being eaten by predators, hunger, or injury, they redistribute the load on to the remaining survivors risking more fatigue and injury. The forward progress is hampered by the weight of the supplies they have with them.
Having seen this strategy fail, Group 2 instead gathers information about where they are and what is likely to be found along the way, assesses the ability to safely carry the load, and distributes items based on need and ability. As members fall, they ruthlessly cull through the items, balancing the need for forward progress with the need for the items they will carry for their ultimate survival. In the end, a strategy is not enough. A well muscled person from Group 1 may emerge victorious with a huge pile, where an unmotivated and injured person from Group 2 may not make it, however, the odds are in the favor ...<< MORE >>
What topic sounds more interesting on the topic of the future of software?
Automating User Workflows-Strategies for identifying, prioritizing, and testing end to end user scenarios and then automating them.
Constant Beta-Testing to "good enough". More and more it seems that consumer software is expecting the end user to do most of the testing. How do we increase our smoke tests to cover what is important in order to get user feedback. How is the user feedback then verified and made actionable in an efficient way? What does it mean for testers when the new "good enough" doesn't have to be that good in some sectors?
Testing by Numbers-In this very difficult economic environment companies are looking for quick solutions. Any cost cutting measures can be the difference in a company surviving. For that reason, numbers are being considered more than ever. As test leaders and individual testers, how can we find the metrics that matter and present them to best show our value? What can we do to communicate the options to company leadership when they want to cut testing and quality or the schedule to ship a product sooner?
Reducing Test Case Bloat-See earlier blog about this, but I'd go into detail with examples about all of the ways to reduce bloat so that we can move on to testing future features.
...<< MORE >>
Comparison chart of Integrated Development Environments.
Most everything I've tested in my career has been C++ code, but lately I've had a chance to work with some ActionScript based web hosted applications. I had a chance to look at one browser based application and I realized I have no idea what language it is written in!
Why does it matter? Well, look at this chart. Depending on the development environment, the challenges and advantages vary greatly. This means the risk of introducing bugs will vary to some extent by the attributes of the environment the software being tested was created in.
Have you found in your testing that the programming language or development environment used can accurately predict where bugs are introduced?
...<< MORE >>
In the last few weeks I've read the entire Twilight series. Although I'll admit sometimes I had to stop and laugh and read the dialog outloud. While it was a good stress reducer while mourning the loss of our much loved cat who lost kidney function and sadly passed away on Wednesday, I thought it had some good lessons for testing.
If Edward just went on instict alone it would be a short series ...<< MORE >>
Feedback is always useful because it's information, but it's only useful if you consider the source. How do you go about addressing concerns and complaints that other people have? What if everything you do to address their concerns just backfires and anytime you interact with them at all it gets worse and you don't know why?
What if you have to defend, define, explain, backup, and triple check every thing you ever do or say but they don't? The balance of power is not in place for a fair debate, my friend. Don't be fooled. Professionally there is no room to be defensive if you get "other than positive" feedback in any area. Suck it up, say thank you, and ask for details if possible, but sometimes, just a thank you is the best you can do. I've seen different ways of handling this in the past. As a team, if this happens higher up in an org, the culture changes to one of top down feedback only in some cases, because that's the only direction that "matters", or people game the system as they find how it's measured. How about when the effort you put in to please the person and talk in their language is dismissed entirely? What about when you find out that you have no voice? Well, you stop for one. You stop entirely because you are at the end of usefulness for that one way discussion and you take it. Then you get back up.
Why? Because you are resilient, passionate, diverse, have more than one stakeholder. You get up because others are counting on you. You don't take it personally because it is just business, it really isn't personal (even if it IS about personality). If one direction fails, you try another. If you can't please some people no matter how hard you try, you please enough of the others to make their opinion less relevant. For every detractor you may find, you are going to need about 10 very strong supporters. I don't mean networking when you need it. I mean you are holding up others when they NEED it. They can count on you. You helped them at every turn. Why? Because you have ethics and you spend your time trying to be positive and helpful and honest. For each bad thing you say, you need 10 good things I estimate. In some situations you just can't win. For them is it just about winning? Can you give them the, "You win" that they need and move on? Can you find other stakeholders?
A female executive who I admire told me last year, "Never let the opinion of one man stop you." To make a difference you need visibility. With increased visibility will come more feedback, both positive and negative. All of it can be of help in context, but none of it can make or break you. One man's opinion at one point in time should not ...<< MORE >>
An online friend shared this link and I did check it out and it's over 5 years old, but some of these problems are STILL happening today. Why does it take the CEO to notice or someone high up for usability concerns to be taken serious? To read the entire thread, check out http://blog.seattlepi.nwsource.com/microsoft/archives/141821.asp
From: Bill Gates
Sent: Wednesday, January 15, 2003 10:05 AM
To: Jim Allchin
Cc: Chris Jones (WINDOWS); Bharat Shah (NT); Joe Peterson; Will Poole; Brian Valentine; Anoop Gupta (RESEARCH)
Subject: Windows Usability Systematic degradation flame
I am quite disappointed at how Windows Usability has been going backwards and the program management groups don't drive usability issues.
Let me give you my experience from yesterday.
I decided to download (Moviemaker) and buy the Digital Plus pack ... so I went to Microsoft.com. They have a download place so I went there.
The first 5 times I used the site it timed out while trying to bring up the download page. Then after an 8 second delay I got it to come up.
This site is so slow it is unusable.
It wasn't in the top 5 so I expanded the other 45.
These 45 names are totally confusing. These names make stuff like: C:\Documents and Settings\billg\My Documents\My Pictures seem clear.
They are not filtered by the system ... and so many of the things are strange.
I tried scoping to Media stuff. Still no moviemaker. I typed in movie. Nothing. I typed in movie maker. Nothing.
So I gave up and sent mail to Amir saying - where is this Moviemaker download? Does it exist?
So they told me that using the download page to download something was not something they anticipated.
They told me to go to the main page search button and type movie maker (not moviemaker!).
I tried that. The site was pathetically slow but after 6 seconds of waiting up it came.
I thought for sure now I would see a button to just go do the download.
In fact it is more like a puzzle that you get to solve. It told me to go to Windows Update and do a bunch of incantations.
This struck me as completely odd. Why should I have to go somewhere else and do a scan to download moviemaker?
So I went to Windows update. Windows Update decides I need to download a bunch of controls. (Not) just once but multiple times where I get to see weird dialog boxes.
Doesn't Windows update know some key to talk to Windows?
Then I did the scan. This took quite some time and I was told it was critical for me to download 17megs of stuff. ...<< MORE >>
How do businesses evaluate and measure their test effort? How do we know if we are doing the right thing, taking the right risks, or investing in the right area?
I've heard many presentations lately where automation teams will say that finding bugs is not their goal.
These developers in test have the goal of either driving a product direction (Test driven methodology), making sure bugs aren't reintroduced (Pure regression automation), validating that functionality is working and stays working (pure functional testing), or my favorite cause of all, inventing tools for other people to create tests (automation as a service).
So, what happens when the overall number of people expected to "find bugs" goes down and all of the investment is on the number of tests run? How are they prioritized, run, maintained, reported on, and how is quality evaluated? When you see a number, what numbers don't you see?
What did 90% code coverage cost you? What code did you cut? How is the user experience impacted? What did you trade for to get to that number? What didn't get tested? Is the product actually better for it?
I ask not because I have the answer, but because I am seeing some terrifying responses industry wide.
If testers don't find bugs and test the product who does?
Customers BUY and use the software. Why are businesses deciding not to invest in the product of value? That's the product of value? Why do I feel like I'm taking crazy pills to say something like this. I love good software. It makes my life better. I have passion for it. I don't want to use crappy software that some companies are making and I certainly don't want to participate in making really bad software to use.
Good software makes money. New methodology and internal tools do not, especially if they don't save money. Why is it politically incorrect to say this?
Metrics that matter=Customers buy product. Customers like product, can do what they want better than ever before, recommend product! Perceived quality from the customer is what matters, and long term at that.
Are you in quality? What are you doing to avoid buying the test snake oil? How do you convince others that having people to find bugs is important?
...<< MORE >>
When you throw someone under the bus you harm more than just that person. You make a mess and you slow down the bus.
One would hope that karma, or the law would kick in at some point. Even if it never DOES you still are less efficient. The tech industry is really hard and competitive right now. It's going through a difficult time. Don't forget that it isn't worth your integrity. Even life itself is temporary. Do not sell your soul for the illusion of security. ...<< MORE >>
Switching Languages for Mac OSX
Select Apple menu, System Preferences. In System Preferences, select the flag, also known as “International”. From here you can scan the list of languages and select the one you need and drag it to the top and log out and in again. If you don’t speak the language you are using, it’s helpful to remember that Shift+Command+Q is log out.
If the language you need to test in isn’t present, click the Edit List button on the right to add additional languages.
...<< MORE >>
Why is it that medical tests don't have to show much to still be run often?
I had 3 ultrasounds fail to detect endometriosis. When they finally gave up and gave me surgery I had over 81 implants of Endometriosis and stage 3 out of 4. In my support group for this chronic disease (one of the more minor health issues I'm dealing with, but still problematic), a majority of the women had been given an Ultrasound which had turned up nothing, yet they are still routinely run. This test is terrible at detecting this particular disease, yet it seems to be the first diagnostic tool they use. The second thing they do is inject women with this terrible hormone reducing medication that has side effects such as bone loss, and memory loss. When I was on this medication I would walk outside and promptly forget where I was going. I had to request things in writing at work because I couldn't remember what I'd agreed to. Needless to say, I refused the second dose (each dose lasts 6 months). They do these tests all to avoid what is now an EASY and fairly safe laproscopic surgery. The surgery is excellent at not only diagnosing the issue, but also at treating the symptoms. I'd have surgery every 6 months before enduring another round of those drugs.
So, why do we as testers use ineffective tests and put up with terrible side effects, such as spending more time troubleshooting WHY our automation broke again with each version and each change rather than just getting in there and doing what needs done? Is it an irrational fear? Is it habit? Is it because it sounds better on paper? Is it because of this false idea that it is more efficient? Why is it so unpopular to point out that it might be faster, more accurate, and save time and money to "just do it", especially in one off cases or a situation where the test just doesn't need to be run that often.
I'm had a meeting today about one of those things. You know something where there is the "right way" to do something, but it's so expensive and so many people would have to agree that it's unlikely to happen? I really hope that the "right way" happens, but I'm thinking I'm not the best person to get involved in that part of the task. A person with patience who strongly desires to negotiate a deal between two managers is the right person. I could show that leadership and be that person, but it doesn't excite me in this case. I should allow someone the opportunity who really WANTS to work on this. Passion makes many things happen that wouldn't otherwise. Part of the request was that it be "as automated as possible". I am not sure I have the heart to share the truth. The truth is that it isn't worth the cost to automate. We ...<< MORE >>
Despite layoffs at my company, I currently still have a job which I am very thankful for. It's been a difficult time seeing co-workers go, but my team is most not impacted at this time. It's a rough economy, so I'm well aware that job security isn't a given for most of us at the moment.
I couldn't possibly be more thankful for my boss and his boss who have been supportive and tolerant as I've gone through such a tough time medically, and I'm looking forward to making them very glad they kept me around during 2009. I have always loved the software I work on and the company and I'm pretty unreasonably loyal. As long as they want me here and are good to me, I'm not going anywhere anytime soon.
It was very flattering that an old friend contacted me yesterday, kind of hoping I'd been laid off and offered me a possible consulting gig. It made me feel cared for, but I wanted to set the record straight that I have a job and am not looking for another one at this time. At some point in the future, the idea of consulting sounds exciting and like it might be a good fit for me, but not right now.
I hope that some of the good people who have been laid off recently find work soon. It's a great time to be hiring right now because there are so many talented people looking for a job. I have some friends, an experienced Whitebox tester (Ex-Microsoft) and a very experienced PM friend (Ex-Microsoft and Ex-Adobe with tons of agile projects under her belt) that are looking right now in the Greater Puget Sound area.
...<< MORE >>
A few days ago I had the following experience.
1. Open Windows XP SP3 based laptop.
2. Machine failed to sleep when I closed the lid, so it promptly sleeps when I'm trying to use it.
3. I wait for the machine to wake up again.
4. Upon waking, Outlook crashes.
5. Outlook will not die, even with end process tree. It is following the philosophy of "Never give up, Never surrender."
6. I force the machine to restart anyhow.
7. Five minutes later, the Windows restarts.
8. Upon restart, Office would like to update, wants to know if I'd like to report it crashing, and needs to do a full inbox scan.
9. While awaiting Office, all of my other software, including BOTH of my beloved Creative Suites and Windows itself would like to update.
10. Firefox and IE would like to update.
In short, it took me well over 35 minutes before I could get my work email even though I declined all other updates.
My computer using friends, we have a major problem. My software creating friends? We have SHOT ourselves in the foot. No WONDER people aren't updating and taking our security patches. We have done a TERRIBLE job of creating a decent experience! It's shameful. Really. One of the most annoying things about software.
Here are my suggestions:
1. Update on start or launch is a TERRIBLE idea. Let's explore the alternatives. This could be an ok option for some people, but is a horrid default. Think about the user. They are trying to do something with the software and we are interrupting them and delaying them. I realize this is the default because it is easy and there is a WRONG assumption out there that a user wants to know "as soon as possible" about every update that exists for every little thing. No, they do not.
2. Outlook needs to improve immediately at it's utter fear of death. When I say DIE, I mean DIE NOW and give me my resources back. I have no patience for Dumpprep when it's the same issue over and over. Dump THIS. End means end. It means give up right now. Internet applications and Windows are both guilty of this "never say die" attitude. Stop being selfish and greedy. The problem with the design is that it's so arrogant. "My application is the only thing that matters." That is the attitude that went into the over inflated sense of importance of refusing to die. If someone is ending task, it must be in error. They must WANT to tell us about it, because our software is more important than what the user is doing. This sort of thinking needs to be discouraged in companies. Your software is NOT more important than the user. They get priority, not you. Server/Client relations of many kinds fail at usability in this department. I think this issue is more technically difficult to solve, but we need ...<< MORE >>
I am told that if you buy a Johnson and Johnson rectal thermometer and take out the literature from the box and read it carefully there is a notice that in small print says:
"Every Rectal Thermometer made by Johnson &Johnson is personally tested and then sanitized ."
Whatever you are testing today, be pleased and repeat, "It's only software." ...<< MORE >>
It is sort of tradition for me to geek out and share what I like about the new Creative Suite with my designer friends when it first comes out, only this time I'm sharing it with you in case you are interested. I use these products (all of them in the Suites with limited exposure to the Video products, so this is NOT about Production Premium). There are an insane amount of features, so let me tell you only what blows me away and I like most. Of course, there is an official overview and demo if you want the real overview and not opinion from me. This is my honest opinion no hype version, but I am by no means a neutral party. I am a flat out fan of Adobe design products and always have been. I'm elbow deep in the technology and solidly in love with Vectors.
Lanette's List of Wow Cool
Why is it cool?
Stuff in the Products
This overview on Photoshop CS4 by Martin Evening is a good one. I agree with him.
Photoshop GPU enhancements- Because performance matters hugely in Photoshop. To get the no hype, no marketing version of what you actually get, check out the knowledge base article. It is cool because it speeds up what you need to get done and we all hate waiting. Faster is good. Ok, while still in the Photoshop topic, let's talk about the coolest thing (note: Not most useful to you, but COOLEST) in all of CS4.
Content Aware Scaling-Because it is wickedly innovative. When I imagine that this is just the second feature based on this concept, I get excited for the future of Photoshop and digital imaging in general. Ok, we bought this technology from a school, but it RULES. It is some good koolaid to drink. Photoshop knows what is important in your pictures (sort of). I thought that Auto Align Layers was the best thing in CS3, and this is just variation on a theme taken much much further.
Illustrator Gradients-This you just HAVE to try. Download the trial version and check it out. It's the coolest thing since gradient mesh. Now you can have transparency in your gradients and they are so much easier to edit. Everyone is going to be so into the Multiple Artboards that they won't give the gradients the proper WOW they deserve. Check this out.
I'd also like to state for Ellen that NO, this version of Illustrator doesn't suck as much as some of the past ones in terms of stability. You know that when you say some of our versions of AI suck I shake my head sadly in agreement, but I know you are just disappointed as a fellow vector lover. Check out the trial and I think ...<< MORE >>
I am proud to share with you the published version (in pnsqc 2008 conference proceedings) of my first technical paper, Testing for the User Experience!
Once the video presentation is ready, I'll post that too! The presentation is "based on" the paper but very much not the same as the paper. I wrote the paper this summer before I could talk about Creative Suites 4. The examples in the presentation are all more current than in this paper.
...<< MORE >>
I just wanted to report that I survived toe surgery and am recovering nicely. Once they got in to my toe the ligament was entirely missing from my toe rather than mostly gone, so I ended up with a pin through my toe as well as a metal brace screwed into the toe bone to fuse it. The pin will come out after 2 weeks (Umm, I'm scared for that?), so it is covered in a bizarre plastic cover at the end of the pin which looks like a gumball. I will have "the boot" on for 4 weeks and it will swell from 3-4 months. I will be unable to wear heels for 4 months, so no fancy holiday parties for me. It will be worth it to have my toe not hurting and the ability to walk without swelling back. They expect I'll be able to do everything I normally do including dancing once the fusing is completely healed. The only limitation is I will not be a prima ballerina. Alas, let's hope this software thing works out instead.
If you tried to chat with me last week, please forgive me if I fell asleep or didn't make much sense. I had very strong anethesia and medication to make sure that my muscles didn't cause my toe to go out of alignment for healing. I'm afraid I wasn't not great for conversation or anything intellectual. Please try again in a week or so when I'm more recovered and have my memory working fully again. I was supposed to be back at work tomorrow, but it depends on my ability to walk and drive if I'll be going or not.
I am terrible at lying low and recovering. I get easily bored. I decided instead of resting to begin writing a Science Fiction novel. It is much harder than I thought and I'm only up to 800 words. ...<< MORE >>
I am working on learning UML right now. I naturally speak in models in my head and have even devised a "roadmap" way to express how I envision the functionality layout in my head. The issue I find is other people can't understand it. For that reason, I am working on gaining a deeper understanding of UML so that I can experiment in model based test planning. I mean applying workflow testing and exploratory testing based on models. I am less interested in the uses for creating automation based on the models. I see my role in creatively coming up with a better way to plan and communicate using models, a better way to reduce existing test cases and create new ones and communicate risk and coverage using the overall picture in models rather than words and statistics. I've done some research to see what exists, but it seems to me that this area is largely unexplored in terms of large scale software projects like the Creative Suite.
How do you currently use models for planning testing? Do you use them to plan when things are testable? How about just to organize your thoughts on risk and importance and communicate with other people?
Can a set of models be used with any sort of consistent results as an overall map to organize collaborative testing? I'd like to try.
I think my team must at this point roll their eyes every single time I want to try another cooky idea to improve our collaborative testing documentation. I have really only a few traits that make me a good tester. Above average curiosity, above average enthusiasm, and a passion for ranting and seeing things improve. Basically, I'm meddlesome and problematic. I think that my drive to always improve is what makes me useful in quality, but can be an absolute pain in terms of romance.
...<< MORE >>
Consider if you will, the Great Onion Nebula. In reading about it today it cracked me up that the professional astronomer described this as "Hot young stars" in keywords. Well, my scientific friend, that's one way to increase number of hits. Since I was a child I've had interest in the night sky. Upon seeing these beautiful images and those from the hubble telescope (in my opinion THE best use of money in all of space exploration in my entire lifetime), I began to imagine if I were able to float around in space that the colorful beauty of nature would surround me and exceed even the beauty available on earth. Then the truth. OUCH the truth. It's like finding out that Santa Claus isn't real. How bored I was with my first telescope. It represented a shattering of one of my fondest dreams. I'd been tricked! These photos aren't real! Real or not, they are a beautiful creation, we just need to explain what they are. They are art. They are enhanced reality based on science. Partly real, partly art. Like every magazine photo you see. However, we need to explain that only parts of it are real. We also need to show the unenhanced reality to people so that they do not feel tricked. Do not blame Photoshop for the human desire to see beauty and art. Do not doubt the integrity of the artists who create these. Realize this is their craft and appreciate the talent it takes. They do not create the demand for art and beauty. Even Reality TV is enhanced reality. No one wants real reality. Have you seen the "depression channel"? It's all footage of people starving, death and dismay. Commercials just flash up, "You are slowly dying. No one will get out of this alive." No, we can't stand that emotionally in large doses. I don't think that cable channel is likely to exists soon. Even the horror films that get popular are almost never situations very close to reality. People who love to be afraid enjoy the excitement, but if it's too close to home they no longer have the sense of relief that it isn't them. What does this have to do with testing? I've noticed two main schools of thought in testing. We have those who believe in giving managers and stakeholders a false sense of security in our testing using measures and statistics. Then we have the context driven school of thought who are much more in your face about presenting an unenhanced version of reality for others to deal with. I don't believe I belong with either group. I see myself somewhere in the middle. I'd like to present both a polished view with some science basis, and explain what it is based on and let others make their judgments. Bringing reality to the table IS part of my job, but that doesn't mean I have to bring the harshest reality in ...<< MORE >>
When "The Paperless Office" was mentioned at the conference it hurt to hear everyone laughing knowingly at what a failure it is. I wonder if people making automation to replace testing feel that way yet. I got to thinking of how they compare and why it is folly to dismiss them wholesale. Far be it from me to point out the ways that automation is useful, but when it is done responsibly it has great purpose and potential.
1. The goal should be go as "paperless" or as "automated" as makes sense in the context.
While our office isn't entirely paperless, things have changed a great deal in the last 10 years. Insurance forms are done online. Taxes are done in PDF format. PDF format was created with the understanding that the ability to print is IMPORTANT. That's what makes it such a great technology. I think I was the only person who freaked out about the first version of Acrobat. My immediate reaction was "It looks exactly the same on ANY platform? Imagine the potential!" The fact that it doesn't make sense to go entirely paperless doesn't mean that it isn't worthwhile to try. Any progress we make saves money, time, mess, and trees.
BVTs need to be automated so that they can cover more builds in more languages at any time of the day to speed up testing. It just makes sense. Why should one person be mindlessly running the same basic tests on every build and holding people up to start real testing? I really think there should be a rule that until your BVTs are good enough to catch 100% of untestable builds without human intervention that you can't move on to automate anything else. This is the single best use of automation that I've seen and until it is good, time of humans is being wasted. Any software company that has fully solved the time wasting problem of bad builds from code checkin out to final media without human intervention, without false pass/fail results can be very proud even if they don't automate anything else.
2. Even as people knowingly laugh at failure, change is happening. Results are being enjoyed.
Almost all offices are more paperless than they were and almost all companies have more working and successful automation than 5 years ago even if it falls short of the paperless and fully automated world some people imagined.
So, welcome to the paper reduced and automation enhanced world already in progress.
On a very personal note-Long, about surgery, healthcare, and other non-testing stuff:
I am trying to think of how to solve my own paper issue at home. My medical paperwork is an absolute mess. I can't find what I need. My healthcare account card was suspended because I couldn't find the receipts they wanted while I was recovering from the worst surgery ever. I have decided this year to give up on having a managed healthcare ...<< MORE >>
Measure everything of significance.
"I swear this is true. Anything that is measured and watched, improves." -Bob Parsons
I think the opposite also has to be considered. Be careful what you measure to make sure it is the MOST important because you are robbing the unwatched areas to put focus on the area being measured.
I believe that there are only 4 important measures of quality in software.
1. Customer Satisfaction.
2. Sales verses the last release and vs the competition.
3. Costs of creating and maintaining the software overall.
4. Total cost of tech support.
You must raise number 1 and 2 without sending 3 and 4 higher, or you can reduce 3 and 4. It's a choice much like you get with food and ladies. Healthy, cheap, and tasty. Pick any 2. Pretty, Smart, or Laidback. Pick any 2. I am sure there are some exceptions where you can raise 1 and 2 WHILE reducing 3 and 4, but in general it's tough to do.
I am pretty sure there are hundreds of ways to measure if not more. How do you measure? I have reasons why and abuses of measures I've seen for each of the items I think are harmful to measure. I am hoping that you can convince me otherwise. Explain to me why these items are worth the time, effort, and expense to track?
p.s. Whomever found this blog by searching for testyredhead and boyfriend, I've got one, but you should read my blog anyways! I swear I am qualified to make a testing blog, boyfriend or no. I'm a very difficult woman and certainly am easier to talk about testing with than to date. ...<< MORE >>
The last few days I've had a chance to help some customers with a few issues. As one of a group, I remember my tech support days and it troubles me that some engineers (both developers and test engineers) seem to be missing the basics.
When you hear hoof beats, think HORSES first, not zebras. All of these elaborate possibilities are considered rather than finding out by covering the basics. While I don't believe we should EVER be condescending to the end user, it's more likely we are missing some of the basic information than that some elaborate and exotic situation has caused the software to fail. When isolating a bug or troublshooting for a customer-look for the following first.
-How large is this problem? When did it begin? Has it always happened? Does it happen with other software? Can we even reproduce it? It is operating system or hardware specific?
-Does the software even do this? Is this a workflow we expect to be supported? Many times as a customer or a tester we are expecting the software to do something it isn't even designed to do. One customer was using a server 3 versions old! That was never expected to work or tested with this version of the client software. Rather than all of these elaborate zebra stripes painted on the client, we needed an upgrade to the workhorse server badly. They can upgrade and migrate the data fairly painlessly if they know the server is the issue. GET the versions on everything. Investigate first, act later.
3. What is happening again?
-I will say as users go we have AWESOME users. They give us screenshots, exact errors, and often times even log files. Most software companies do not have users even half as educated as ours are. They certainly know their business and can show us things about our own software we didn't even know in some cases, however, they sometimes are blinded by their own focus and area of expertise, just like we are as testers. Take a step back from what you KNOW is happening and consider the bigger picture. JUST the facts. What are the experiencing overall. Take out the context and consider just the undesirable results. Not what they told you happened first. Not what they told you happened after. Just what is happening right now, this second. Sometimes they forget to tell you about the many beta versions they installed and didn't fully remove, or the custom plug-ins they have. There are times when just considering the current state you can more clearly isolate the issue than with all of the extra information. It's like one of the story problems in math when you need to strip out the irrelevant information in order to discover the answer.
4. What is our goal?
-Does this customer need to meet a deadline? Are we looking for a solution, or a clear problem? What do they ...<< MORE >>
Alarming-Like a bucket of water over the head
One of the best things I'm taking home with me from pnsqc was the one paper presentation that I left a red card for. The speaker was nice. No problems at all with the person. The red card wasn't one bit personal. It was the dangerous assumption that their company made and was proudly sharing. They assumed, as a large and experienced group, without asking or verifying that the main thing that caused customer dissatisfaction was stability. This was not based on customer surveys, user research, or really anything at all. I know because I asked. Shocking!
The time, money, and effort they spent to reduce crashing was VAST. It raised customer satisfaction less than one percent! They still don't know why their customers aren't satisfied. Really? This is a group of smart and scientific educated people, but where is the common sense? Heavily investing in a solution when you don't understand the problem is a very common mistake.
It is part of my job to stick my neck out and give the red flag. "Hey,..wait a minute, did we ASK the customer? How do we know? What proof do we have?" What if one person in the first meeting had said instead, "The idea that stability in the form of crashes (that can be logged) is the main cause of dissatisfaction for users of our software is an interesting THEORY. How should we verify that, Bob?" (See, much like the movie Office Space, the person who stated this idea as fact has to be one of The Bobs).
So, I ask you, what research do you know of that explains what the leading causes of software dissatisfaction is for users? Does it vary widely by industry? Does it vary by program? If no one has studied this, how is Fortune Magazine able to write it's annual "Most Admired Software Companies" article? Are we just in business for the stockholders now, is it the awards our product gets? Is it the reviews, or the sales? Of course not. For the long term, we need satisfied customers who will recommend our products to others AND buy it again. How can we fail to gather data in this area? I'm just saying, this hole is a huge gaping one and it struck me, right before I slipped in the red card, which may not have been entirely fair, as I think this mistake is common in quality. What else are we assuming as "common truth" that we aren't even bothering to verify? This isn't just bad science, this is bad for software quality.
Comforting-Like a cup of tea
The best thing I learned wasn't from a speaker at all. It was from the conference participants and volunteers. There is something amazing about PNSQC and CAST that some other conferences don't have. It isn't commercial. The reason I went to this conference is not because I have an ...<< MORE >>
How did it go?
A++++++++++++ Would present again.
While it may be hard to understand all of it, here's a version of the PDF slides from the presentation.
Well, the way it went exceeded my wildest expectations for my first time presenting. I got a little sweaty at first as I was scared, but once I relaxed it was great! There were about 100 people I estimate and they nodded, applauded, seemed to understand, and even laughed a few times. I felt very appreciated by all involved. I was still chatting with individuals and answering questions when the next speaker was ready to start! One person asked about my book and I cracked up. I have never written a book. My team of 4 people (including me) are testing the Creative Suites as a whole. I have had no time to write a book between that and The Worst Surgery Ever™. Gretchen told me that I have talent at speaking, but since she is my teammate, I assumed she just liked the topic and was biased. However, someone else told me I had talent at speaking that I never met before and meant so much to me! Now I believe Gretchen that it was a great start. While there are always things to improve, I'm happy my first presentation went well.
There are a few minor issues with me personally on my travels. First, I'm experiencing problems with the nerve pain, so if you see me limping around or laying on the floor today, that's why. The reason is, lots of sitting in less than ideal chairs. Because of the pain I'm nauseated, so not eating much. Gretchen is about to burst a blood vessel with my non-eating and chatting people up during meals. She and I will stop for hearty potroast on the way home at the Country Cousins (a.k.a. The Kissing Cousins). If you'd like to learn more about our journey back to Seattle, you must visit the website i5slog.com.
I didn't know how amazing the audience would be. I regret not leaving double the time for questions. Had I known how many SMART, awake, and cool people would be coming I'd have chattered on less and listened a bit more.
I decided to write this paper and speak because I really am passionate about collaborative testing. If you came and saw me speak at PNSQC and want me to come chat with your team and see about starting up this type of testing, just let me know. I'll do what I can to help out.
Also, when I get back home I'll meet with Erin to discuss writing our abstract on reducing test case bloat to submit for PNSQC 2009. I feel we can't be ready for the future until we've dealt with the bloat from our past. We may be done with the past, but the past isn't always done with us. That's what ...<< MORE >>
I was inspired and reminded of what I've learned from my years of dance lessons by Jonathan Kohl's blog which I check out from time to time although he's more "agile oriented" than I am at this point (so far).
Please check out the Improv performance video of Infusion Tribal Bellydance to get an idea of what I mean.
American Tribal Style is special in that it is an improvisational style of Belly Dance done by groups of women who communicate changes in moves using "Cues" which are seen and heard, but subtle. For those who don't know the tribal vocabulary, it looks like a choreographed routine. It incorporates dance from all over the world taking influences from the Middle East, Africa, Flamenco, and sometimes modern dance such as Hip Hop is incorporated. It's known as American style because of the "melting pot" of dance ideas concept. Also, it is danced proud, without the subservient aspect that some other dance styles have to it.
I have a sticker on my office door that says, "Life can't be choreographed: improvise." I believe that.
There are three types of Tribal Style dancing mainly
1. Practice/classes-This is where you learn technique and the vocabulary.
2. Hafla-Free dances where any number of people dance together at an open jam.
3. Performance-Two or more dancers perform for an audience.
Basics needed to Dance
1. Some amount of natural talent to hear music and some sort of rhythm.
2. Dance posture (this is how to hold your arms and position your body so you can dance without injury).
3. Know a few basics of the vocabulary including the cues.
4. Ability to lead and follow.
I would say these are extremely important aspects to have in testing before you collaborate with other testers. First, you must have a common vocabulary and a good understanding of what you plan to accomplish together. Secondly, you need a firm foundation in test methodology and some experience in testing and isolating bugs so that you are a help and not a distraction. While you can warm up by just "following", to truly collaborate as part of the group, you must be able to lead as well and take your turn, adding your self to the chorus and showing your special skills and talent when your time comes.
Some of the key things that make Tribal Dancing work well
1. Cues that are easy to read from the leader wherever you are.
2. Support and positive interaction/energy between those dancing.
3. Able to start dancing immediately! Less time learning exact choreography, more time to dance.
4. Flexibility to change the dance for maximum audience reaction.
5. Varied experience is no problem. Those with less knowledge can learn from those with more and the most experienced can show off in their solo even if the beginners can't follow.
6. No ...<< MORE >>
I've been working my tail off to ship CS4 suites as well as get my technical paper presentation ready for PNSQC. My co-worker Gretchen and I have our rooms all booked and transportation arranged. I am lucky enough to have a chauffeur (Gretchen volunteered to drive) for this event now so hopefully I'll be in less pain when we arrive. My role will be navigator/beverage girl. We will arrive in time for the Monday night festivities, so if you are going, please look for us! I am going to post a photo in this blog so you can find me and say hello, and even introduce yourself.
Version 1 of the slides turned out to be 19 slides. Then they announced CS4 shipping and I revised them with new examples and they ended up being 23 slides long. I then found that I didn't like the lack of focus on collaboration and it didn't give enough background for those who weren't familiar with this sort of testing to figure out how we created our documentation or why we did it this way from the feedback I got on Friday during the first dry run. I'm now on revision 2 and I am scheduling several more dry runs before October 12th so that it can be a tight presentation. I'm really excited that I'm one of the earlier speakers, so that I can enjoy the rest of the topics without being nervous about my first presentation ever done external to my company. If you are willing to review my slides, please comment with your email and I'd really appreciate the feedback.
Anyhow, if you are going, please look for Gretchen and I at the conference. I'll be in my reading glasses all day so that I can see people far away and read small fonts.
Anyhow, this is me (yes, this is a super dorky smile in my office on my iMac camera). If I really like what you are geeking out about I might give you this look. Yay! We love Roombas, lipgloss, and StumbleUpon as well as collaborative testing!
...<< MORE >>
Erin and I met yesterday on the topic of reducing test case bloat. While on her team Automated cases have not yet grown to the level that they are causing bloat, I'm worried about it as a potential problem. Automated cases are no different than manual cases in the fact that they take resources and time to maintain. It may be free to run them each time once it is set up, but fixing them when they break and going through false error reports is a huge time sink and that adds up to real money a company is spending.
For that reason, I believe we should set up a better process for reducing test case bloat for automated cases. What strategy does your team use? Are you using the addition method like we are? Just keep adding more and more cases, never remove any? How long have you done it for? Is it still working, or is it causing madness and wasted time/effort?
I think the idea that we should always add more automated cases is based in false assumption and we should only bother to run and maintain the most important automtaed cases. What would you use to pick the optimum set of automated cases to run? ...<< MORE >>
Requirements-Not to be Taken as Scripture
I've been thinking of the important reasons to go beyond testing "to requirements". I've fought for and gotten 3 bugs fixed recently that are clearly stated as "not supported" in requirements. You have to make sure you have a good case for how many users it will impact, how leaving this as "unsupported" makes the product/company look bad, or has a negative impact on adopting the technology. Something like "_____________ happens when you use _____________ with _____________" and explain that ________ people use ___________ and the interaction is likely with __% of customers potentially having (customer impact). I find it helps to say that it is a usability problem and not a code bug so that it isn't instantly closed "as designed". "As designed" is no excuse if it is harmful to the user experience. I don't really check my deferred or closed "as designed" bug count or feel it is a problem to be corrected. I've had bugs closed "as designed" which were later huge customer complaints that got fixed in dot releases. I don't feel bad about having written those bugs. They were not a mistake. The key to testing "unsupported" areas and is making sure you know which ones are important, and never fighting for a trivial bug needlessly.
I attended some training where the teacher told us that it isn't our job as testers to be involved to this level and that those sorts of questions should be raised during requirements review. I agree that test needs to be involved in requirements review, of course, but some situations come up long after the requirements are set. How about new environments or technologies that become important? The web moves faster than our product cycles, so you have to be flexible and adapt as things change. I just realized, I seem to be making an argument for agile development as well as going beyond the requirements.
Keeping your mind active and the user first is always better than feeling "good" about the scope of your testing. If you are sure you did everything in "your area of ownership", but nothing beyond it, that isn't good enough to promote quality improvements.
As a test lead, I've had testers get really caught up in what their "bug count" is, or what percentage of them gets fixed. I hear little about what disaster was averted, or how important the bug was. Bug impact should be just as important as number of bugs. One high impact bug can be much more important than 50 bugs found. Don't measure your progress just in bugs. All it takes to have a high bug count is a very careless Dev counterpart. Testing talent isn't measured just in bugs. It should be measured on the improved overall quality going out the door. In fact, moving your testing upstream can be one of the most positive ways to impact quality. ...<< MORE >>
I'm meeting up with a long time colleague next week to discuss my ideas for reducing test case bloat. I thought I'd share my ideas with you all in hopes that you'll share your thoughts with me as well!
Here are my ideas starting with the most common and ending with my favorite ideas.
1. Pairwise testing-Make sure to screen with equivalency cases.
2. Tiered by importance-Create a frequency subset based on risk.
3. Change based-Do a second pass and add more to lower priority tiers based on low risk due to code change.
4. Timing based-Ignore some test cases until major code changes are made, so schedule WHEN the testing will have maximum impact. If it isn't that time window, plan to ignore those tests.
5. Performance of the test case -How many bugs did that test case find last time? Tier accordingly, if low risk and low impact, ditch it.
6. Complexity-How many code paths does this test case cover? I prefer one testcase that covers maximum lines of code over a simple case.
7. Model Based-Draw model using UML. Map out which test cases cover what. Based on risk and planned code changes, assign tiered priority that way. Lower priority/low risk goes into "if time allows" bucket.
8. This is what I actually do-Use customer surveys and ask product marketing and project managers what their "top features" are for this version. Use actual usage data to prioritize tests-How many customers will this impact? If very few, ditch the test. If many, automate as BVT. Try to automate at least the top 5 for testability of basics. Set out in test plan what new features and what legacy workflows you are protecting and what you are ignoring because they aren't important enough. Recognize the RISK and get the guts to not test the low priority areas and get people to sign off on it. If the test doesn't fall into one of the most used workflows or one of the top priority experiences that the software is delivering, it can't be a tier 1 test. Tier 1 means that the test failure will stop shipment of the product. Tier 2 should be ran until RC submit. It means that if there is time, most likely it will be fixed if the test fails. Tier 3 means it may or may not be fixed, but would be good to know about. All of this testing should be complete and abandoned (as finished for the cycle) before RC submit.
So, when you have infinite paths which could be tested, what makes sense for selecting test cases? In my situation, testing between products, my assignment is too large to do model based testing, or I would. I think it is a fantastic way to arrange tests. I hope that there are other ways to prioritize and reduce bloat that I missed here that some of you can share with me and I also hope some of these ...<< MORE >>
Never get too comfortable. Always be looking to the future.
This is advice I take to heart, but I'm not sure how to express it sometimes. I'm still learning and growing. I wonder if it really is ok for me to continue working in a job with the same name for so long. It's been since 2006 and my job title hasn't changed, but my abilities and duties certainly have. I'm happy with what I'm doing, but I feel like I can do even more. I want the chance to do more. I've tried asking what I have to do to get more opportunity and the answer I hear back is that I am doing these things and I am performing well. That I have to keep my eyes open for an opportunity. I have even asked flat out if I need a different degree in order to go further. I don't believe this has anything at all to do with my gender or me personally, but with the software industry.
I think I need to search inside myself and figure out how long for. How long does the "grow, prove yourself, wait and see" last for? Is 5 years too long with the same job title? Have I already hurt myself by waiting too long? Has my company loyalty limited my potential career? Would I do better to get some variety of experience? I am so deeply invested in my current company and I love the software we make. I always thought that was a great asset. Now I'm not entirely sure that it hasn't clouded my logic. Did I already choose wrong? Some of my favorite people, people who have talent more in line with my kind of talent have already left QE and gone to Program Management. Am I making an error by not transitioning my love of the software we make to a different position? I flat out love doing testing. Is that no longer important?
I've been asking these sorts of questions. I asked this week if it was important that QE Developers know how to use our software and can advocate for the customer. The answer I heard back was not what I had hoped for. I heard that QE Developers need to know testing so that they can understand THEIR customer, which is the "product tester". Ok, but since all product testers also must code, shouldn't all coders also know the product? Apparently it isn't that important.
When I see survey results change in terms of employee satisfaction, I wonder, how much of that is change in employees and getting rid of anyone who isn't satisfied or doesn't agree? How expensive was that turn over? I mean, I hate working with a bunch of negative nellys myself, but replacing independent thinking collaborators with yes people is dangerous to the company and bad for quality. This is the way of business, I know it, but it does feel wrong to ...<< MORE >>
One of the biggest challenges my team faces is getting the bug to the right person. This seems like such a simple problem. You just properly isolate the bug, and enter it in the bug database. What could be easier?
Just about anything when you are dealing with dozens of products, at least that many shared technologies, and now, more than ever, a number of services which are on an entirely different product cycle than all of the standard desktop products.
I got a chance to work with an amazing intern who recently became an employee on a new tool to make version of components and products easy to verify and detect problems with as it became impossible to do manually with any accuracy. Now, if only I could make it crawl our bug database and detect when any bug was sent to the wrong person or team, we could save major money. But the problem is, with a lack of consistency, there is a twisted web of logic to follow.
Who owns this problem? The first step to finding out is isolating the bug. Can you try it directly on the server? Does it happen from multiple products/paths? How about multiple operating systems/browsers? Other software that is released? Did it happen in earlier versions?
How about coordination? What if the service update on the staging server isn't testable live until well after you ship a product that it should work with? What will the experience be? What if that item is delayed? It's easy to let another team know that you'll provide no testing and call it a day, but ultimately, you need to know what your customer will experience if your product interacts.
So, here are some things I find useful in getting a bug to the correct place.
1. When in doubt, ask in email to all of the QE owners for the possibly responsible product/technology/service, and set the bug status as awaiting information if it is not urgent. You can network this way and learn how they isolate where the problem is happening. You may find that they have a tool that you don't.
2. If urgent, write the bug for the part that ships first and email the dev responsible. Be as factual about the impact and isolation information as possible.
3. Ask how they determined where the bug was so that your skills improve at routing the bugs and you can save time in the future. Sometimes "there is no way to tell without more access" is the answer. If they choose not to give me access, they get a few more emails.
4. The bottom line is now the top line. Be concise and link to the information for all of the details. If you are going with the product that ships first as your default in cases of urgency to be the best possible customer advocate, you are putting your reputation on the line. Waste as little ...<< MORE >>
This only relates to testing if you are working on teams, with other people, or trying to attract people to your team for collaboration. I didn't come up with this saying. I saw it on a small rural city church sign 7 years ago, but recently have been wondering why it keeps coming to my mind and why during times of difficulty it resonates with me.
I'll start with the simplest reason that I've always identified with water in that it is unsurpassed in strength, flexibility, usefulness, and beauty.
I don't want to just be a fountain. I aspire to become this fountain, one of the most ambitious, lovely, appreciated, and well resourced fountains that does great good for the city of Rome:
1. Useful: A source of refreshement and vital life sustaining force. Also a source of comfort and fun.
2. Enduring and self-sustaining: Under many circumstances, when properly designed, fountains remain useful for hundreds of years.
3. Able to accept input of varied intensity and still output something beautiful, safe, and useful. This is a hard one for me. First off, you must be selective about where you get your input. If it is from somewhere unreliable or contaminated, you may stop the fountain's function. It's said that the original aqueduct of Rome's source was found by a virgin. When in doubt, get your input from the innocent, but built with experience.
4. To function well, fountains need to be cleaned and maintained and on occasion repaired and rebuilt. It is worth taking the time to do this so that they can serve the greater good.
5. The water is part of the beauty, but there is beauty even without the water. When the water isn't flowing, the potential for usefulness doesn't go away.
6. The outdoor fountain is fed by and in tune with nature. For the fountain to remain functional and useful, it can't be protected from the elements. It depends on the elements....<< MORE >>
Long time no write! I'm finally back from the most awful surgery of all time™. I don't remember the first 2 weeks after it, and quite honestly I've only slept 10 nights uninterrupted in the last 49 days. The good news is my surgery is a modern miracle of science and my 60" of incisions are healing up like a champ although swelling remains a major problem. I start Physical Therapy today, thus may spend tonight in the land of Nopantistan due to swelling. It's possible I'll lie belly down on a slab of ice like slide around like a penguin, but with my laptop so I can finish my paper.
Well, back on topic, I'm working on my "Technical Paper" and have been. It is due on Friday. I was stuck, stuck, stuck. My boyfriend helped me identify the problem by talking it out with me. The problem is, per the usual, I think I am a unique and special butterfly. Because I have the charisma in person, I don't feel I should be required to dig mud in the trenches with everyone else. I call it "pretty girl syndrome" and it's shameful. Yes, in addition to the surgery, I was having an arrogance problem.
Me: I don't want to write a scientific paper! I never did. My presentation kicks butt! All of the people who saw it (both teams) joined us for the next test exercise! Can't they see that Collaboration has little to do with making my paper boring? I feel like they are trying to limit creativity. Why must all square pegs go into round holes? My paper is going to be boring and dull and changing it this way is not going to make the presentation better. Besides, I feel like crap, they don't like it, I'm gonna withdraw it, they are going to kick me out of their conference anyhow.
Craig: Listen to you! You have a great idea. You have all of the talent and passion. They ACCEPTED and like your idea and here you are flipping a bird to proper scientific methodology! If you really are too immature to write your paper out in proper form, you don't deserve to give a presentation. You are smarter than this. If you didn't have an attitude problem this paper would be done. I watch you write PAGES every day. Yet you procrastinate because you are too arrogant to put your idea into scientific format?
Ummm. One thing about that boyfriend of mine. He can read me like a book. I already have a new outline and am writing my little fingers off. A little humility and respect for science isn't too much to ask, even IF it makes me feel hostile and bored.
Outline, Introduction, Title Page, and Conclusion are finished. Now on to the meat and "figures". ...<< MORE >>
I'm thrilled to report that I've just graduated my 6 month training program! Business travel is something I love. Last Thursday, sitting in a hotel in San Francisco, the best meals you can get, and being in so much pain I was unable to leave the room or even eat dinner got me to the point where I have to admit it. I can't travel for business until my health has improved and my pain is under better control.
It's been really bad lately, and that got me to thinking, why would anyone hire a person with disabilities? Here are my reasons why you should, and how to work with such a person, although each person is different. First off, I am a person with a disability, not a disabled person. I have nerve damage in my right leg which causes significant pain. It is not something that is currently curable, so for right now, keeping the pain under control to live the most excellent life possible is the strategy. I believe it will be cured in our lifetime, but until then, it is simply something to live with.
-Hire a person WITH disability, not a disabled person. Know the difference. Does everything "happen to them"? Is it an all day pity party every day? Are they actually doing their part to get excellent care? Do they have a victim attitude? Does the health challenge they have define everything about who they are? If so, it's useless to try. Don't hire. The disability isn't physical.
-I really want to be working. My health problems are severe enough that it is quite possible I could fight to not work and get benefits. I don't want to. I want to be here. Not just to pay the bills. That's HUGE. Having a job helps give me a reason to keep a regular schedule. To get up every day. To keep my personality. So many people with the problems I have just get lost. They lose who they are. They take more and more narcotics and before you know it, they aren't themselves anymore. I don't want to be that person. I'll fight as hard as I can to avoid it.
-I'm more loyal than most employees because I need my health insurance. I can't function without it. Please understand this and never needlessly make me worry about the stability of my employment. If there is a stability problem, please give me as much notice as possible so that I can get this covered. A gap in health care really could knock me out of the workforce long term. It really could change the course of my life in a negative way. I'm a planner, so I have savings to make sure I'm reasonably able to take care of myself in this regard, but I can't be productive if threatened and it just isn't cool to do.
-Give me feedback about my performance just like you would anyone ...<< MORE >>
I just got my first look at a must anticipated upcoming feature and I'm blown away in a good way and now I am so excited!
I wish that 3 other features I looked at and was disappointed in would be magically removed and every resource used given to this one feature that outshines the rest of them. Why waste engineering resources by spreading them out so much? When a test team is working really hard and their area of focus is just lame, there is nothing they can do that will make people want to use it. However, over here there is a feature with all the potential in the world if the quality is high enough not getting test resources. Software project planning is pretty complex, and I know there are lots of negotiations that take place.
I'd love to have a release where someone is tough and says, "We are cutting half of the planned features and taking twice as long for this project." Not financially viable initially, but what if the half of the features you are doing are groundbreaking and have world class quality?
We have this one feature that has disappointed me every time I've tested in for over 5 years now. In my entire testing career, I had one opportunity to ask a question of our CEO in a small setting. I asked him simply, "Have you ever used feature ______?" We don't have that same CEO anymore. His answer was clear, honest, and diplomatic. He had used it, recognized problems with it, and expressed hope for the future with it. Have you ever spoken with executives? They say more in a few sentences than I can convey with 2 pages of text. That kind of consolodation doesn't happen overnight. They are true artists at communication efficiency.
I'm not sure who in the company is so smart and charismatic that they are able to keep resourced with something so terrible to use that I was willing to use my one question to the CEO to find out if he'd ever used it, but whomever they are, I promise I want to stay off of their bad side, so I'll never specify which feature it was or bring it up to a CEO again. It's caused major resource drain and stability problems, while remaining unpopular with the vast majority of our users. As a serious advocate of usability, this particular feature is a villian in my world.
Anyhow, this new feature I can't talk about. Simple, elegant, fast, easy, AMAZING! What you can do with this is going to make my top 10 list.
I freaked out about chatting in 1993 and people thought I was crazy using the modem and talking to people with my computer. In 2000 I thought Livejournal was very cool and I started blogging. Digital photography was the coolest thing I'd ever seen in the early 1990's and people thought I was misdirected for taking so ...<< MORE >>
Today was a brilliant day! I had a wonderful day of work in every way. Dinner was fantastic. Even the cats behaved well.
So why did I just go on a 5 minute swearing tangent including writing hate mail in my mind?
Because it just took me 5 minutes to get a hyperlink into my Word 2007 document. Brilliantly, even the help menu was hidden to protect me from peril!! Hooray! Nothing on the context menu indicating that hyperlinks exist even though I have text selected and a hyperlink on my clipboard. I also need a psychic friend to paste special. Also, hyperlinks are now considered links and not "text formatting". Ok, that makes sense, but since when did Word try to make sense? They have gone so far protecting me from menu items that I can't do anything. It's sort of like the fine security we got with Vista. A great idea, but I'm so safe I can't do anything in this straightjacket. Little harm of me hurting myself (or getting any work done). Someone, please take the protective lid off of my spork?
I casually bring up my lack of joy with the new Word. The TWO users who used to work at Microsoft tell me they LOVE this interface. *blinks* *stares blankly more* I have no response for that. They have some very powerful kool-aid over there. Either that, or it's their policy of hiring only very very smart people. I will admit that both of these people are much more intelligent and patient than I am. They are quite amazing that way. That does however, make them sort of aliens in the American culture. I call this calm rationalization a problem of sick pants. I can't spell sycophant without a dictionary, so I call it sickpants. Too many smart people loving eachother. No one willing to remember that users may HATE your clever idea. This is why you need some testers willing to point out the naked regent about to stroll down the street even if it is career limiting. I want to shake the hand of the one MS tester (most likely a contractor who can't code), who brought up that in the future some crazy redhead who's been using word since the DOS days is going to go on a 5 minute tangent and hate this so much she will blog about it and scare other people. Maybe enough people love it that it was worth making me hostile. Somehow, I'm guessing on that particular product they have more upgrade users than newbies, but that's just a guess.
Well, I suppose at least people notice it? And have a strong reaction? I just want to see the percentages. I'm thinking there are more users with the hatred that I have than the joy and love that they are showing, but perhaps I'm a small (and admittedly ranting) minority.
Here's some background. I stopped watching Lost after the first episode. I do ...<< MORE >>
My abstract was selected for pcsqc 2008 which happens in Portland from October 13th-October 15th! The theme is collaboration.
I am just over the moon with excitement to be speaking on my favorite topic at a testing convention for the first time. I have lots of work to do before the conference, but I hope that some of you will come out to the conference and attend. Come talk testing with me.
It could have been the Grand Canyon, the training I've been going to, or all of the wonderful people I work with who have been supporting me all year in trying new things, but I'm so delighted to have this opportunity. I feel like I did the day I got my first job in tech support. I have the feeling that the hardest part is getting that once chance, and now I've been given one chance. That's all I really need is the opportunity, and where it goes from there depends on my hard work, dedication, passion, and talent. The part that I can't control (being given a chance), due to luck, due to persistance, due to kindness from other people, has fallen in to place. I'm overwhelmed with gratitude. It may seem like it isn't a big deal to those of you who speak at conferences all of the time, have multiple doctorates, or are published authors. To me it is huge!
One of my goals is to add my voice, my perspective, and my passion for software to the chorus that is constantly changing in the industry. Just as we need people who are brilliant with tools, who are fantastic with numbers, and who are great with theory, we also need people who have intimate knowledge of users, who care about the soul of software, and who never stop fighting for an improved experience when you sit down at your computer to get a task accomplished. I may never be the person who has the most impressive metrics, or who wrote the best testing tool, but I can be the person who contributes some new ideas to protect the less tangible aspects of software that make it memorable and amazing to use, and that is something worth working to contribute.
I've also learned something else comforting. Not being a manager doesn't mean you aren't a leader. Also, being a good follower doesn't mean you aren't a leader. If I believe in the person, I love to follow other people. There isn't any shame in being a good team member. I don't have to lead everything I participate in in order to be happy. In fact, all of the leaders I like and respect are good at following too. I want to remember that as I try new things. Listening and taking feedback is how you learn. Following the right person and ideas is a sign of good leadership and followership, not a sign of weakness or lack of initiative.
...<< MORE >>
My company has something about the culture for years that has been really special. Real substance behind the philanthropy efforts, a very human feel, and a sense that fun belongs everywhere, not just in a play hard, then work hard (mostly work hard), but never combine the two sort of way.
I had a testing assignment this week and last night was FUN! I worked really hard. I found a great problem, and I had so much fun communicating it. It made my whole night and I was late to dinner and I didn't even care. That's the sort of thing I like to work on.
I want to be the person who makes sure as we move to every kind of possible metric to measure a person and a task that fun doesn't go away. Just as the soul of software can be at risk when you make changes, so can the soul of your entire workforce, and with it, what made it special and successful in the first place. If you hire just one type of person, you lose every voice of dissent, and with it, often the voice of reason. It is generally bad to mention anything negative to those above you in the food chain, but sometimes they need to hear it. Otherwise they have a year like Britney Spears and everything's gone down the tubes and someone else has to go in and do a very expensive cleanup. When there is a cleanup like that, it's never announced "someone Royally made some poor choices and apologized and now we are going to fix it". Instead we are just "going in a new direction" and "improving our process". I have a way with words so long as I believe them. My friend will sometimes ask me to rephrase what she says before she has fights with her boyfriend so that they go over more favorably. However, as a matter of integrity, I think if you make a huge error, you admit it, apologize, and explain how you are going to move forward.
I recently found out that pretty much you have to be into code or have a CS degree and significant coding chops to be considered for a QE Manager job. I think that is industry standard. Why does no one ask you to give them a demo of the software they are supposed to be managing, yet they must know the code? Do they even know software has a soul? Do they know that their people do, or are they just good at making charts to show how the metrics are doing?
So instead of conversation 1, you have conversation 2.
Person 1: "We should make this feature. It's really cool!"
Person 2: "Yeah, but it isn't useful and really sucks when you take out all of the stuff you can't fit into THIS version."
Person 1: "We should make this feature. It's really ...<< MORE >>
As promised, I'm reporting out on the Large Dirt Hole from the perspective of the upper South Rim.
I did an exploratory pass of the entire South Rim by doing a quick sanity check on the edge and going in deeper and random points up to the fence at viewpoints as well as looking into binoculars for a closer view. We did climb the tower at Desert View on the far east end for an overview. At first the functionality was overwhelming!
The depth could not be explained in photos or numbers or written comparisons, so I understand why people told me I had to just experience it for myself.
Luckily I had someone there with me who was unwilling to accept the current boundaries. Safety was really not a concern. After watching him go on one life risking stroll after another, I followed him out one area. Do you see in the photo below the portion in the foreground that juts out into the canyon?
So, on the paper? I've decided to go as far as I can. This means it will follow MY style. It will be personal. It will have jokes. It will have more heart and fewer numbers than most other technical papers. In fact, it won't be a technical paper. It will be an article of ideas. If that is too far over the edge, I'm lucky enough to have backup. ...<< MORE >>
Look for a few moments at "Pillars of Creation", one of NASA's most famous images of the Eagle Nebula. No one is going to bother to read my paper if I call it the "big dirt hole". Perhaps some marketing is needed to get people to come and see it. If it is good, word of mouth will help me. If it is bad, I can get feedback and try again. Why would this be terrifying? Only because when I finish it, I face the chance of rejection. Also because I overthink everything I do. How many people out there just do it? Just declare "Grand Canyon" when they wonder somewhere deep down, "Is it possibly big dirt hole?" ...<< MORE >>
I had the pleasure of attending a User Group last night of a product near to my heart. I worked on the first version of it and always was a huge supporter.
During the event the speaker and teacher kept referring to "cold hard logic" to explain that while he could understand WHY things worked they way they did, or could explain it away, that he still couldn't do what he wanted. It made sense logically, but it wasn't intuitive.
This is why listening to your testers is important. This is why testing for the user experience is important. No one cares if your decision makes sense. They care if they can do what they want to easily. They care if they are disappointed and have to use workarounds, or if you provide what they need and more.
Obviously, you can't make all of the users happy all of the time, but if your decisions have to be explained away by "cold hard logic", obviously you've made some regrettable choices along the way. Yes, there are reasons, but the facts must be faced that cold hard logic isn't what is important in life.
Love of a thing or love of software for most of us is how it connects us to people. This is what Web 2.0 is about. This is what viral video is about. Cold hard logic just won't cut it anymore.
The next time I hear a complex explanation that makes sense about why a feature is usable, I'm going to think of it as an excuse. Yes, you make sense, but it still doesn't create a passable user experience, let alone a good one. Not to say that we should be uncooperative or unconstructive in our language or dealings with others, especially well intended developers. I'm just saying, it is our job as testers to represent the customer, even when it doesn't make logical sense. ...<< MORE >>
I had the honor to visit an office I'd never been to the last few days. I met some people who not
only want to work with my team, but are willing to train and mentor us in something.
They also understand that web creations do not maintain themselves and still remain relevant. The important data is the data added by humans. There is information everywhere, but what do we care about? We care about things that make us feel and think.
I gave a short presentation in a meeting about collaborative testing. I showed one way we represent an overview of a path through multiple applications in complex scenarios. We showed areas where there were some problems, areas where there were serious problems, but we could work around it, and areas where we were totally blocked from completing a task during the collaborative testing. I then told them that in representing it this way, we just weren't good enough. We aren't representing the experience. In order to do that, we must also show what things were delightful. What should we "not mess with"? Just as software can need improvement, I believe it also needs wildlife preserves. If it is something so delightful that it is the only reason many users enjoy it, please, just leave it alone unless that changes. It is fine to add to that. Maybe new options, but do NOT change the default when it is brilliant. The team I met with contributed many ideas about this and they took my overview to play with it. They had never even seen the overview before and thought it was great even without the missing part, but they liked the idea of seeing both.
I'm not sure why we have been ignoring the opportunity to provide this data. It is a huge part of overall quality. Testers, managers and developers assume that if it wasn't fantastic, bugs would be written against it. I've tested some very stable code for a feature that sucked so much to use that I met a loyal customer who was using a script to work around using the feature entirely.Software users ultimately will provide some of this data, as will the market and research. However, as a tester, why not share this critical information? I think it is because it is subjective, and so often rejected as information of value. Collaboratively, however, if we agree on what the top 5 delightful things about the software are when we use it, our odds of predicting user reaction improve dramatically.
I know I harp on this collaborative testing, as it is my passion, but we are getting better at finding the dull subjective data. Does it work as designed? Does it do more than it was designed to do? These questions can be answered with "Yes" or "No". These are things that can be determined with automation.
How do I feel about this software? Is it just fine if this one feature is mediocre? ...<< MORE >>
I'm in the process of putting together my first technical paper. In general it is about how you can use collaborative testing to test the user experience. I'm not sure what is going to happen with the paper, but I hope that once it is approved, I can share it here.
If you have any tips for me on writing a compelling abstract, an original and focused technical paper, and/or presenting based on a technical paper, this is my first time. I could use some guidance from the old pros.
In other news, I participated in my first every Pinewood Car Derby. My auto, based on a lipgloss theme, did well enough to make the finals, but did not win a medal. However, I stayed on the track and looked good doing it. For a first attempt, I'm quite proud. I know where to improve next time.
...<< MORE >>
I've been working a great deal on professional development. I've never grown so much in so short a time. I'm looking for tips on how to raise my confidence and how to believe in myself more.
This week I submitted 2 ideas to an internal innovation website contest. I didn't win, but for a first try, both of my ideas were slightly above average in terms of votes for all ideas submitted company wide. That may seem like a loss, but if you consider how smart the people I work with are, I don't think so. In the past I would never have submitted them at all, just making excuses that my ideas wouldn't be taken seriously. You can't make the top 3 ideas if you never try, and you have to start somewhere. Mediocrity is a fine place to start because I'm not staying there. This is just my first try. Besides, average here is way above average in the world at large. It takes experience, influence, and popularity to get traction on an idea.
I'm finding out that the main thing holding me back from my dream job isn't skill or experience. It's fear. I'm afraid that I don't have experience. I'm afraid to fail.
I signed a contract last week for my special training that I'd be doing 3 things by March. One of those is applying for a job that I really want that is offered internally at my company. No matter what the results are, I need to toss my hat in the ring. When I signed that contract I tried to think of every reason in the world I shouldn't go for it. I explained to the mentoring group why it wouldn't work and why I was conflicted about doing it. I was shaking while signing that I would do it. The time for self-defeating internal talk is over. If I'm held back, it shouldn't be by me. No only means no for now. What's the worse that can happen? I hope the worse that can happen is they don't interview me and at least tell me what to work on to be qualified for that position if they don't think I am. The best that can happen is they see my passion, potential, and how fast I'm learning and give me a chance to grow in to that role. The medium thing that could happen (neither great nor terrible) is that they interview me so I can get practice interviewing, and they give me feedback. For me it isn't so much that I have to have the "job right now", it's that I want to get there and know I'm moving towards it. Besides, it's reporting to the one person I most want to work for, and opportunities don't come up that often. I feel like a crazy person to say the truth, which is, "I really want to be on your team. You want me because you don't have anyone who will work harder to make you not ...<< MORE >>
Things that seem strange and negative to people are considered pretty normal to me at this stage in my testing career.
Things like reorgs. We had a really good one a few weeks back. Didn't lose any people, just some people reassigned. I have a new boss. It's my new boss #8. So far, I really like him. It's kind of a setback to have to earn the trust of yet another new boss, but I consider it normal and look forward to demonstrating my talent and loyalty as quickly as I possibly can. Each new boss is another opportunity to learn something.
Things like testing that wasn't planned or agreed on coming up and having to make a decision. This "fire fighting" isn't strategic at all. However, I think it is important to efficiently do what needs to be done. I PLAN to be flexible. Some people consider it a weakness. I don't agree. If I can do something to help us ship something on time, I'm easy in. I've seen different strategies when this sort of surprise comes up. Some leads will take a hard stance and refuse any work they didn't agree to in an effort to "protect their testers". I don't agree with that strategy. Creating a false reality for your team isn't true protection. For real security, you have to be mission critical with needed skills and do something that has recognized high value. On the other hand, if you are nothing but a dung heap that people pile their unneeded work on, you can't do anything of high value. All you are is reactive.
I know that it is human to like to be rewarded by money. Money is a show of how valued your work is. While money always matters when it comes to work, mainly, I want something else. If money were no object, I still would work. Most likely I'd work 4 days a week and not 5, but I wouldn't quit working if I had endless money. I want to feel like I matter to people. I want to feel trusted, appreciated, and special. I want someone to believe in me and give me opportunity. I would take a cut in pay to have the chance to do more of the work I love doing.
I've had some people tell me that my style is "Ready, Fire, Aim". Those people don't understand what my style really is. It is "Ready, Fire, Aim, Fire, Re-aim, Fire, Aim, Fire, Aim, Fire, Get machine gun after research, fire and continue until the objective happens." They don't take into account that I have more tenacity than they anticipate. My lack of patience for inaction is not accompanied by a lack of follow through as it usually is with people who have my personality type. I'll do what it takes to not disappoint, even if it is harmful to me. For that reason, having someone who cares about ME as a ...<< MORE >>
How important is user focus? Which users and who determines that? Does a user become unimportant because they are considered a "sure thing", much like after the honeymoon? New users become the focus, so we can take our core user base for granted? Or do we only care about the loudest customers? Do we only like the nicest customers, or those who come to us willingly in a format that works better for us, like forums? Is the only user information that matters what comes through a scientific process, such as usability studies, or are survey results sufficient to stand alone?
Are money, comparative sales statistics, and support cost comparisons a true measure of focus on the user?
How do we sift through that user data?
It matters to me very much how users feel. That is not scientific. Do you love this software?
At my company, I used to feel that user advocacy was a valued part of testing. Now I feel the trends are shifting. If the user you are advocating for isn't the main focus of the target market segment they would like to capture, they are of little importance. Even in Girl Scouts we learned "Make new friends, but keep the old. One is silver and the other's gold." It isn't stubborn or holding on to the past to stand up for the CORE users who built your company and paid for everything you are developing now, nor is it betrayal to keep up with industry trends and note what people need to do right now and in the future. I think it is critical that all users are considered.
Have you ever gone to a college class where they are teaching your software and talked to the people there? I have. I helped at a class held in New York for a product I worked on on a customer visit. I also was a student. How hard is it to learn to use this stuff? Are they having fun? After that class we went to a shop that had been using it forever. There were some things still keeping them from having fun even though they knew so much about the product. More than we did in some areas, especially on how it interacted with other software.
This battle being waged for the developers has gone too far. Most users of software are not all scripting and coding (except, of course, for Visual Studio and other products which coding is their only purpose). How as testers can we stop corporations from throwing their loyal users out the window to make more room for untapped markets?
I'm still looking for the answer. I'm hoping that some percentages would help. What percent of our users are doing ________ vs. what percent are doing _________? How much do we invest in maintaining the users we already have vs. getting new ones?
Some growth is good growth, even if done fast. Do you know what you ...<< MORE >>
Forcing an Error Pileup-A Fun Tester Trick
Long time, no blog. The holidays were brilliant, but now I'm back in action, being as testy as ever, so I want to share with you one of my favorite ways to test for errors.
Automation is a great way to "force errors", however, almost always it is one at a time. Causing error message stacking is a great way to test for race conditions, find crashes, and get into those states where you can't access a modal dialog, so you are stuck until you force quit.
Here is my big secret: I have no patience. I will not wait for an error to appear before moving on, nor will your users. They are clicky clicky mouse movers in many causes. They will refresh like mad, move on while one process is running.
So, my testing tip of the day is, don't wait for the program to finish. If you know of error conditions, in addition to trying to cause the same one to fire two at a time, try mixing them up today. The first time you find that state where you have an error dialog without focus and you have to force quit, come comment in my blog and it will make my day.
Automation and Those Darn Robots
Hope that the '08 is off to a good start. My resolution this year is to work "with those crazy robots".
Industry wide, it is time for the investment in automation to stand proud and be trusted. For those humans still testing to compliment the robots and let them be judged on their own merits. Those robots with value will prove what they are worth. Those with lower value must be allowed to come to light to improve. Improvement and not just change. I love that idea. I mean, do I really ever want to manually smoketest an installer in every language on 4 platforms again? Of course not. What a waste of testing time, experience and money. If any monkey could do it, why isn't it automated? If we paid to automate it and are still testing it manually, we are stealing our own money by not trusting our automation. I spent part of today trying to convince someone on my team of this. They looked a bit nauseated and doubtful. I hope they will be afraid and do it anyways. I really really hope so. It's past time.
I had a discussion today with an ex-tester who is now a tech writter. I was explaining to him that what it really takes to get a testing job right now is a whole lot of coding skills, well, at least the ability to talk like you have lots of coding skills. Notice, I didn't say you need talent, experience making anything useful, creativity, or good testing methodology. You don't even have to be great at working with a team. You don't need to have any talent for finding bugs. ...<< MORE >>
I think the main reason I ended up being a tester is because I'm more curious than average. You could say that I'm nosy, and it wouldn't be too far from the truth, but beyond nosy, I'm interested.
Last week in a meeting I heard someone refer to change management, but not in the way I understand it. I understand it as a way to track versions or a method to control code changes in a system. As I do sometimes, I wrote myself a note to find out what in the heck this change management stuff is about in the context it was mentioned.
I've attended a day long seminar before on "Introducing Change" given by a woman who was a software developer and had a doctorate in Psychology. I was approaching the information presented as a way to get my testing ideas to see the light of day.
Reading more about it, I now realize that I have been naturally doing some of this on my teams over the years. If I really believe in the ideas, regardless of who's ideas they are, I get behind them and really move them forward. I do have some of my own ideas, but over 7 years I've done much more work on bringing momentum to good ideas that other people have.
I have a double edged sword of strength/weakness in this area. The strength is, if I really believe a change is going to work, and is for the better, I'm all in. I'm the first one in line to be an early adopter. I'm not change resistant and I will use my enthusiasm and charm to get other people either excited about it, or to feel less threatened by it. This is easy for me. I am one of those people who likes change. My current job is never the same from day to day. I work on many things. This is fun, but I think it would give some people whiplash.
The downside is, if I think that the change will not work or I don't believe in it or trust you, I'm very effective at creating an angry mob. Not just a verbal group of people disagreeing, but the underground resistance as well.I don't mean to do this, and I think I'm just sharing my opinion. I give little thought to how my venting might influence other people. I am not part of the underground resistance. I can't fake it. If I don't think an idea is good, silence or "agreeing to comply even though I don't agree" is the best I can do. I can't pretend to support the idea and lie about it. Many people will appear to do as the Romans do, but actually do what they believe is best as soon as the Romans are out of the room. Others will leave Rome never to return.
So, there are many many suggestions on how to manage change. What ...<< MORE >>
This morning in the shower I was thinking about collaborative testing (Yes, this is a normal thing for me). I was thinking about some of the things humans are good at doing together than machines are not. One of those things is prioritizing and eliminating unimportant tests. Those decisions take subjective information....<< MORE >>
It is very common in testing to target tests to areas of change either code changes, or feature/product changes (what is new or altered). We use this practice on a daily basis. It is more difficult to use across multiple products and/or silos.
My idea today was what if I could simplify? Could I make a visual respresentation of the areas of change over multiple products? What information would have to go in to make it useful over time? In my context, it would be impossible at this time to compile all of that data on a build by build basis, but what if I could compile it at milestones, or even just for the release in general? Would it be useful if not precise? I think it would be a good guide as long as we knew it was just a general pointer (that way), and not accurate turn by turn directions.
I even started thinking about how it would be possible to automate for updated build to build information, but of course, I reminded myself that automation isn't my talent or interest, so while it may be possible, I'm not the right girl for that job. However, I do love maps. I'm one of those females who can not only read and fold a map, but who can navigate the roads of New Zealand, Italy, or any country we might be travelling. I have a compass on my keyring (shout out to Rick Steves). Each time I travel with other people, I make sure I have the map and say, "I'm the navigator!" Seriously. My family even refers to me as "The navigator" sometimes. When testing with other people, why are we not using more overall maps? What is this idea? Map based testing? Ha!
Have you used such a method before or heard of a team using this? I talked to one person about it who wasn't excited, but I think it is likely I wasn't expressing the idea in any detail and the discussion turned to feasability of information collection across multiple teams (human issues).
I'm thinking of the idea more from a scientific perspective. It's more of a "what if I had ___ thing? Would it help me?" Can I get ________ thing is a different discussion all together.
Each time I review the "testing basics" to make sure I haven't forgotten anything (I do this each year or so, I recommend a refresher for anyone), the topic of Pairwise testing comes up again....<< MORE >>
In trying to get into more depth on the topic, I came across an article from 2004 by James Bach. What I like about this article is the research he did.
Best practices only save time and money and improve efficiency if applied correctly and with context.
The typical pairwise testing story goes like this:
1) Pairwise testing protects against pairwise bugs
2)while dramatically reducing the number tests to perform,
3)which is especially cool because pairwise bugs represent the majority of combinatoric
4)and such bugs are a lot more likely to happen than ones that only happen with more
5)Plus, you no longer need to create these tests by hand.
Critical thinking and empirical analysis requires us to change the story:
1) Pairwise testingmight find some pairwise bugs
2)while dramatically reducing the number tests to perform, compared to testing all
combinations, but not necessarily compared to testing just the combinations that
3)which is especially cool because pairwise bugs might represent the majority of
combinatoric bugs,or might not, depending on the actual dependencies among
variables in the product.
4)and some such bugs are more likely to happen than ones that only happen with more
variables,or less likely to happen, because user inputs are not randomly distributed.
5)Plus, you no longer need to create these tests by hand, except for the work of analyzing
the product, selecting variables and values, actually configuring and performing the
test, and analyzing the results.
Today I came across some questions I'd written down nearly 2 years ago. I was looking to hire someone to replace me as QE Lead . Here are the questions I came up with.
After reading the questions, I realized I only wanted to know 2 things.
1. Is this person a good, creative tester with interest and experience in this area?
2. Can this person work well enough with different types of people to be a lead?
I guess those are the top things I consider "must have" items for a QE Lead. A pretty short list. The round of interviews resulted in a good hire. The person has worked out really well in that role. They had much more than my bare bones hope that they could "do the job". I'm glad it turned out, but I've been thinking about how to incorporate questions to find out if I can get what is "ideal" for the job, not just functional.
The most hilarious thing about the person we hired is that on paper, they had the resume that annoyed me the most of any resume I'd ever seen. It did stop slightly short of saying they invented the entire Internet, but it came across as over the top. I was shocked to meet a humble and intelligent person who was anything but a bragger in person. It just goes to show you that you can't tell everything from the written word. Once I got to know the person better and they'd been on the job while, we discussed what my impression of the resume was and why I interpretted it that way.We both thought it was pretty funny and laughed about it.
So, I ask you, what do you think are important qualities for a QE Lead? What questions would you ask to find out if a candidate had those qualities?
Questions I Had Prepared
This blog entry on software quality is one of the most amazing I've read recently.
Whenever I feel alone, or like I simply can not win the losing battle in defense of creative human testing, something like this comes along to provide me with hope. Yes! Smart people who see the value of testing beyond what you can programmatically verify....<< MORE >>
I got to thinking about performance in general. Who's responsibility is it?
1. User Research-Should get some data on what performance users expect in which context.
2. Program Managers-Should define performance with comparisons per system (Faster than, as fast as, no more than % slower than _____________ on the same machine.)
3. Developers should write the code with this in mind and explain to testers when the code is optimized and ready to be tested. This is a performance handoff.
4. Testers then test against these requirements and pre-defined goals. They try different situations, stress tests, repeat scenarios, memory intensive tasks, different OS settings and hardware, long runs, benchmark tests. These tests are some of the best automation candidates.
5. Testers look at perceived performance (Progress bars, number of steps to do something, screen feedback, cursors, ect) from a customer perspective.
So, in general, software performance has split responsibility.
Work performance does not have shared responsibility as much. If there is something getting in the way of you giving your best work performance and you say nothing and do nothing about it, that makes you responsible. It isn't the fault of your co-workers, your boss, the lack of requirements, the lack of a spec, the failed delivery of testable code. It is your fault. As a tester, it is your job to make sure that you can do the best possible testing. Obstacles will come up. Find a way around them. If you can't, directly address them.
I'm very lucky to have had some feedback last week from someone I really respect. There are people I like, and people I respect, and sometimes both, as in this case. As far as work is concerned, I'd rather work with someone I respect but don't like than someone I like and don't respect. In my personal life, I need someone I like who likes me more than I need to respect everything about them. At work, there was a situation I was just tolerating. Basically, I was waiting for it to improve or go away. I've now had a revelation thanks to a gentle reminder.I'm no victim. The only person who can make sure that my performance is something I am proud of is me. The only criteria for me to be proud of my work is to know that I did the best I possibly could given the circumstances, and that "my best" continues to improve in a tangible way as I learn. It's been a rough few months for me on the job. This is the first time ever where I know I made some mistakes and could have done better. I know I should have been brave enough to admit when some things were a total waste of my time. Knowing when to call it quits on working on something is a tough lesson to learn.When I do things that my heart just isn't in, I can't be more than mediocre, and I'm a very ...<< MORE >>
This holiday season has been unusual for me. Having just purchased our first home, we get the chance to host Christmas dinner! While I'm excited about it, it is expensive to make dinner for 15 people while putting up out of town guests, and we didn't have any decorations for the outside of our home, so that added expense as well. Then our cat got very ill and almost died, requiring many emergency vet visits and both cars unexpectedly needed repair. As a result, I didn't have as much budget as I would like for gifts this year, so had to think of a strategy.
I heard about hand made gifts, and love to give unique presents. I'd assumed that I could not save any money by getting hand crafted items. As a hobby, I design and make knitwear, so I know how expensive and time consuming it is to make things, especially here in the US where the supply costs are so high. I stumbled across Etsy.com and found some absolutely amazing gifts. Not only were they unique, but they were thoughtful, personal, and some created by true artists.Yes, some items were really costly, but I ended up spending an average of $23 each on many amazing gifts I gave the first one to a friend last night and she was blown away! I know she will remember and treasure it so much more than if I'd given her a $25 gift card to someplace.
So, what does this have to do with testing? Well, hand crafted testing may not cost as much as you think. There are situations where you just need the cheapest thing, or where you need some testing that isn't practical to make by hand. For example, an iPod. However, it is more meaningful and useful if it has a hand crafted cover and a song list you created for that person. How the person getting it will feel is different, because it really is customized for them from someone who cares.
How the people using your software feel about using it is vital. That is where your reputation as a software company comes from. It can not be trusted to robots. It should not be trusted to someone who doesn't take personal pride in the quality of it. I will always prefer an naturally talented tester who sincerely cares over a burned out person with the best education and "skills list" than you can imagine. It doesn't matter if you can write circles of code around another guy, have a doctorate degree, are a published author, a well known expert, or have dozens of patents if you have no personal investment in the results. You can't fake caring, and it is required to do an excellent job. You can do a mediocre job without it, but I've never seen someone do a great job without passion.
My point is, there is still a place for artistic hand crafted ...<< MORE >>
If you read just one thing on test automation before trying it,..(or trying it again after poor results)
Test Automation Snake Oil by James Bach in 1999. Of particular interest to me are the "Reckless Assumptions" and the Sensible Approach to Test Automation section. In fact, if you could only read 1/2 a page, the Sensible Approach section alone would save time and money.
I've read this article a few times. Sadly I then got feedback on my Automation Plan telling me to "put in (this) tool". I tried to explain why it doesn't help us or suit our needs, as well as why it wasn't realistic for our entire test team to become full Java developers in one month, no matter how intense the training is. Positive thinking is good, but in testing, realistic thinking is more important. Well, I try to balance it out with this link. This is the link I wish was in my test automation plan instead of the link to the automation tool which made me think seriously about becoming a waitress.
For those of you not familiar with test automation I'd like to also provide a few fundamental things that most people don't seem to understand who have never tried it before.
"Automation Tool" is a very generic and broad term. Does the tool schedule and run automation? Does it allow you to test through the GUI? Does it allow you to write unit tests? Does it report back results? If so, how? Can you set it to a tolerance to avoid unneeded false negatives on cases? Does it just track your automation? How easy is it to use? My point is, don't say "Automation" and think that everything that falls into the category is the same.
"Scripting" is not equal to "Test Automation". If you are using scripting to run a step by step test case, even that isn't an automated test case unless you've created proper validation and reporting. Sure, you're scripting it to DO something, but if you didn't validate properly you didn't test anything. I've seen test teams with "80% Automation Coverage" but NO Test Automation. Don't just DO something, TEST something. They are different entirely. If you didn't validate, all you know is that the machine didn't explode when you executed that script. Any number of other things could go wrong, including it not working at all, and you still wouldn't know.
"Automated" does not mean that human tests no longer need to be run.
I took a risk management class last week and ...<< MORE >>
I took a special class today at work that was specifically about testing for internationalization and "localizabilty", which means you are "faux localizing" your resources and testing before your translation is completed....<< MORE >>
I've now been testing for almost 8 years! I tried to count, and I can safely say that this is at least my tenth product cycle. I've tested in most every language (Most Latin Based languages, the Americas, Japanese, Chinese, Korean, ect). I've never tested in Middle Eastern languages or Cyrillic (Russian, Eastern Europe).
Shockingly, having never tested on many features where sorting was of great significance, there is an entire area of testing that is brand new to me. Searching, GUI changes, Truncation, consistency, encodings,..these are all old news. Here is the biggest thing I learned all year: Not everyone sorts alphabetically in ways that make any sense to me. I've never even considered how in the heck to sort Asian characters.
It just makes my week to learn something so key, that I've been missing from my testing knowledge all of this time without ever knowing it! It wasn't just a lightbulb moment for me, it was one of minor shame that I could miss getting such an important and obvious concept. I knew this was important for search, for metadata, and have written great bugs about those items. Right now I can't wait to get in there and use my new information to break some sorting. I'm going to be looking like mad for ways that sorting is possible.
It has been so long that I forgot, many years ago I created a hilariously geeky set of test files which tested input/output of every possible UTF-16 character possible both in the file name and in XML content and allowable tag names each individually named so that it was very quick to identify problems. I think input/output is a wonderful area to automate, and I had to share that I have had good results when automating mundane tasks such as verifying correct encoding and other functionality tests. Automation is not so good at finding bugs, but it is very good at doing some functional testing, so long as the expected result is pretty well defined.
In other thoughts, MS Arial Unicode is the biggest test font I've found for doing unicode testing yet, but is there anything as large and complete in number of characters for the Mac platform specifically? Help me oh fellow lovers of Steve.
Steps to Create a Bad Internal Test Tool...<< MORE >>
1. Have people who are not testers define the requirements.
2. Have someone who doesn't understand the context of the problem, hopefully someone who doesn't speak the same native language, make a very liberal interpretation of those requirements and "let the technology guide them" to the right solution.
3. Do not listen to the main users of the software, assure them it is a staged development model that will improve as time goes on.
4. Keep implementing features on top of the features that are already impossible to use.
5. If people tell you it is difficult to use, show them how wrong they are and write down the exact 87 steps it takes to do one simple thing. Explain to them that they must not be using it correctly.
6. Have the engineer who implemented the code write all of the documentation and training, and then if someone points out that it has no context or conceptual data and doesn't make sense, argue with them and tell them, "Just follow the steps."
Steps to Help Avoid a Bad Internal Test Tool
1. Have very early pilot users who are testers, test leads, test managers, and even higher up stakeholders, but not just at one level.
2. Create a very early prototype that a person could use on a small scale.
3. Take usability bugs SERIOUSLY. This will block adoption of your tool. It isn't a minor UI issue if people can't or won't use your tool.
4. Have your power users create and review your documentation if they are willing to. Even ask them to create short training workshops and do demos for you. They will be better at explaining to people how to use it than you will because they ARE using it, not writing it.
5. If more than 20% of the people you've asked to look at it tell you that it is too difficult to use, do NOT start writing more features until you fix the useless ones you've created already.
6. Don't start adding features just because one person asks for them. It should be based on how many people need it, not on the title and visibility of the person who asked for it.
While I'm on a rant, some tester had the audacity to say, "You can never have too much automation." What? My head nearly exploded. You can never have too much well designed, effective, cost saving, reasonably maintainable automation which start to finish saves you time over running the tests manually. Sadly, there isn't enough automation currently meeting those criteria, and far too few people actually measuring. Automation doesn't equal GOOD. It just is a buzz word. Garbage in, garbage out.
Thanks for letting me vent, oh internet.
In taking a training course I got another copy of Now Discover your Strengths 1.0. This is the third book I now own. I decided to retake the test. Only 2 of my stregths remained the same over the course of this year.
Here are the new strengthfinder results:
As previously blogged, last year they were:
So, to summarize, I don't think I've lost my empathy. I think that what has happened instead is that those softer traits have taken a back seat during a time of massive change. I need the Communication and Woo skills more right now. I don't think woo is a real strength above other things. As far as the "Arranger" part goes, that is most of what my work has been this year. I've gotten better at that through practice, but I don't think it is a core part of my personality.
As a result of taking this test again, I think I have three strengths worth looking at, not five. It is silly to think that each person should have five or focus on five. In fact, Activator and Ideation above all others are strengths that are especially dominant in me. The others will change each year I'm pretty certain.
Activator (I fit the description perfectly)
How do we judge what quality customers will accept? How low is too low? When do consumers start to notice?...<< MORE >>
I saw this article about Toyota quality today. It startles me that this could be nearly ANY of the software companies who are rapidly growing right now. I hope it is never my company.
I don't blame the testing department of Toyota for this issue. It's the competative spirit gone wrong. It's a lack of emphasis being put on quality. Those little sacrifices and compromises add up. Now they have to pay in good will and customer loyalty. The decisions made back most likely in 2004 come to haunt them. I wonder how long it will take them to turn it around (if they can).
It is much easier to keep a reputation for having the highest quality than it is to gain or regain it. I wonder if it is cost-effective? I've never seen data on this.
I was inspired to make a blog after reading this. The context under which the word Religion is used is really interesting to me. Partly because it indicates that testing ideas and methodologies which can't be quantified aren't scientific and are just matters of belief....<< MORE >>
As a touchy feely type person, and also a person from an artistic background who has since gained an interest in science, I feel sorry for people who have no belief beyond what they can verify. I think that the things that matter most in life can't be verified or quantified. I think that innovation can't be proven. You can't prove a new idea is good before you try it. This way of thinking makes some people feel really uncomfortable, but I'm not sure why. The most basic of scientific principles starts with a hypothesis. That is scientific curiosity. Even if an idea proves to be false after testing the theory, I have great respect for those who "wonder if" and will go find out. Those are the people making a real contribution to the testing profession. Those who seeks to stabalize, quantify, assure rather than test, and compartmentalize all testing really depress me. Trying to quantify testing is not a new idea. I find it rather boring. It is something I do because I have to, and as quickly as possible. I don't think it really adds much to the end quality of software.
I'm not suggesting that we shouldn't verify our assumptions, test our ideas, improve and adjust based on the findings, only that lack of evidence and proof is no reason to prevent us from trying something new. If we are to make true advances in human testing, small or large, we must have the courage to apply new ideas. Then as we are trying the new ideas, still have the humility to logically figure out what is working and what is not and make changes. Would the same idea work in another context?
I haven't been blogging because I'm learning to become a coder part time. I've now made a deal with my boss so that I don't go crazy (well anymore than I already am).
I have yet to find the man, however exalted his station, who did not do better work and put forth greater effort under a spirit of approval than under a spirit of criticism.
Each time we ship a product I have this phase afterwords which is sort of like the depression that sets in after the holidays when all you have is winter and the part you looked forward to is over. Now it's just paying the bills and taking down the decorations.The waiting and excitement are over. I'm no longer in a frantic state of final testing. Now begins the slow task of planning, requirements, and the ever dreaded "side-projects". I'm not much of a "side-project" person. I don't like writing code. I like learning, but really, I like testing. I enjoy being constantly busy and changing what I'm doing all of the time. I don't get whiplash from doing 5 different things in 2 weeks. I want someone to give me an impossible task to accomplish.
So, when things slow down, I start to get critical. Rather than doing everything I can to make it, I can see every flaw. Every way that the process can be better. That we can be better. Not just the place I work, but myself, and everyone around me. I can't stop trying to improve things. I am used to taking out all of my energy on the software I'm testing. Now what?
It's tempting to just turn that energy on something else.
I think I've lost the ability to sit back, relax, and enjoy the results of a goal met. I sit around anxiously thinking, "What now?"
To make matters stranger, I've reached two monumental goals in my personal life. I bought and moved into a beautiful house. I've always wanted a house, and this one is really wonderful. It is the culmination of years of saving and much effort and risk taking. To top it off, I've completed a very difficult health related task, and for the first time ever reached a physical "goal weight". That goal was over 5 years in the making and is always a "work in progress" even now. I felt on top of the world for a few days. Now I realize how much I have to maintain, how much I have to lose. I feel the responsibility of it and not the truth. The truth is, I am quite lucky and I can handle this. This happened in part because of my work, and in part because of luck. It didn't happen by itself.
The other truth is that I love the company I work for, the software I work on, and above all else, the team of people I work with. Being too critical is not a good quality, even in a tester. It is certainly not a good quality in a test lead. ...<< MORE >>
What fun it is to type "household appliance" as a keyword for my testing rant today. My boyfriend brought home a Roomba iRobot for us to use in our new house. Not only do I enjoy shouting, "Release the Robot!" but I also love watching it work. It also doubles as a cat toy/cat torture device, depending on which cat. The younger cat looks interested, while the old one looks horrified.
How it works
It stumbles along trying to find the boundary of a room. When it runs into a wall (imaginary as created by the false wall signal or a real wall or object), it bounces a bit as to not damage either participant in the collision, and then goes in another direction. If it encounters significant dirt, it spins in one spot for a moment before moving on.
We did encounter one error where it got stuck under our dining room buffet hutch. The two previous times it was stuck it was able to unstick itself easily by trying different angles. However, this time it really was stuck. It alerted me to the situation by making a sound so I could manually unstick it.
On the down side, it takes much longer than a human to vacuum a room of equal size. On the up side, the floor is really clean when it is finished, it is fun to watch, and I can do something else while it cleans the floor. Plus, it is fun to use and I think of it as my "little buddy". It is easy to remove the bin to clean the dirt out. It is easy to tell the battery state from the lights on the top of the vacuum. It even finds it's own charger when you are finished if you ask it to.
Any person of reasonable intelligence willing to read the manual who has electricity and some D batteries for the fake wall can use this thing to clean floors. Now, in all fairness, repairing it would be difficult. You have to be reasonable about what limits this system can handle. I'm not going to expect it to vacuum up huge items or anything wet.
Why is my test automation not like this? How can I make it a trusty sidekick, which while it isn't perfect, is honestly useful and enjoyable for me to use? I think that the key is, I didn't create the iRobot. I didn't program it. I just use it. I love using it. It works very well for the purpose intended. I think if I tried to get it to do dishes I'd be less satisfied. The key for me is getting a tool that is already for the correct purpose and using it well. I think my attitude towards automation will improve vastly if I can do that. Not being good at writing code isn't a crime. It doesn't mean that I'm not a ...<< MORE >>
PLEASE COMMENT-This is the first time I've taken this idea public and I'm really looking for honest, constructive feedback. Even if think it isn't at all useful, please explain why. It will help me.
A bug harvest is an organized and focused blackbox group testing exercise with a twist. It is called a "harvest" because just as those who pick strawberries may not be the fastest at picking apples, you want to select testers who already work on similar areas or technologies for effective and quick group testing in this context. The word harvest also implies that the fruit must be ripe. It is called a harvest because of the notion that bugs are introduced into the software with code changes, making certain times very "ripe" for the picking of bugs. Most experienced testers know exactly when that time is, and are used to using code changes to prioritize their testing.In some companies there is a handoff process when certain features are ready for test. There may be multiple times in the project where fast coverage by multiple people is very beneficial, especially if the development is staged. It is not meant to replace any other test methods, such as an open bug bash or bug hunt, but instead is an additional method that for use when bugs must be found under tight time constraints. It is intended to cover new code changes as quickly and efficiently as possible to compress the time it takes to get feedback and bugs to developers. It can be used in basically any software development model so long as your testing department has more than one tester, but I have only personally used it in a waterfall development cycle and one staged development model.
The other time I use this method is when fire drill requests come in. Wait, a new operating system and we have 3 days to test on it before they lock down the code? Oops, we forgot to tell your team about our new dot release, and it could impact compatability with your software. In this case, why not throw every tester in the world at the problem? Well, because it leads to duplicate bugs, takes everyone off of what they are working on and stalls your project, and because you can do just as well, especially in early stages with a small focused swarm of testers attacking the area as with a large misdirected frantic swarm. I love Bug Harvest as a method for dealing with firedrills and have gone to it more than 5 times in my last product cycle with great results.
Who, When, Where
One of the keys to holding a successful bug harvest is to invite the right testers. This is not a bug hunt or an open call for all people to beat on a new feature. This will most likely overwhelm the developer with bugs, some "not bugs" and create a large pile of defects to be sifted through which may or may not be about ...<< MORE >>
I'm working on my automation plan today and found this article. I can't believe it is written in 1999 and the same mistakes are being made at most companies still. My blogging time is really short right now, but I'm hoping in a few weeks I'll be able to blog more....<< MORE >>
I was told by someone that my dogmatic talking about human testing is dangerous and that most people don't agree with me. It feels sort of like the mafia to hear that sort of thing, although, I know the intention was friendly, just to let me know that I'm most likely making career limiting moves. My desire for balance in testing is unpopular? With whom? Certainly not with most people who test or use software that results from it.
I must however give thanks for the reminder that I'm fighting a losing battle, but I've never been a political or popularity motivated person. I'm the dangerous kind. The kind who does what they believe is right despite criticism. While I view this as being ethical, I think others view it as stubborn, naive, and delusional. I also realize that taking on all of the things you perceive as injustice is one really good way to ruin your life if you don't put limits on it. Activism is tiring, so you have to be quite selective.
I may not have enough power or influence to do anything, but I have something still more important to me than having a big impact. I respect my own actions, even if other people don't. That is worth more to me than my job. I wish that more people had the courage to speak dogmatically about testing if they felt that way. Holding back ideas because they are unpopular just makes me want to scream that the Emperor is naked. Hey you, yes you, Test Automation. Put some pants on!
Summary: Make usability and the customer's human experience using the software more important than creation and use of any particular method or tool in testing. You can't beat them in tools, number of people, amount of money, automation, or willingness to be competitive (well, I would argue that dog fighting rings could beat them in being competitive, but that would just be snarky). They have one huge weak spot, and that is in the area of creativity and seeing important things that can't be measured.
Judging from my views on Automation, I'm guessing most of you can deduce that I'm not a Microsoft Employee. Many people feel that Microsoft is a huge leader in software, and for that reason, they must have the best quality principles and methodologies in use, and every other company should follow them. In my blog today, I'd like to share why I completely disagree with that notion.
Having talked with many people, both Microsofties and Microserfs former and current, there are many positive things about testing at Microsoft. The availability of tools, the ease of finding them, the constant process improvements being driven by the competitive culture, and even the perception that aggression is "effective" in some groups have been sighted as strengths. I've also heard that the culture encourages people to take on side-projects which impact as many people as possible in order to get raises and bonuses. I am not suggesting that good testing isn't happening there, I'm only suggesting that it is possible to do better. I think that Google IS doing better. I think that our company IS doing better. If companies take the lead from Microsoft while they are growing, they will not be doing better for long. I haven't seen anyone have luck at imitating them and still produce better software than they do.
1. Currently having the most money is not a good measure of testing success.
2. Saving the most money is not a good measure of testing success.
3. Many of their users perceive their quality as very low and hate using their products.
4. Their products have very little "soul" and feel bland, generic, and slightly boring and inhuman in general. From this I assume that usability bugs are not taken very seriously, or, even worse, aren't being found and reported because it isn't easily tested using automation. How can something both be boring and "needlessly complicated?" Use Outlook and find out.
5. Who can automate the most and who can pass code coverage are also not a good measures of testing success. Covering the code is NOT equal to testing the product.
6. Who can cover their butts the most while testing is also not a good measure of testing success.
7. Having highest percentage of testers who can code does not mean you have the best test team.
8. The lengths someone will go to, cutting out their personal life balance is not a good measure of employee loyalty and quality. ...<< MORE >>
Do you remember when every celebrity under the sun was paying hundreds of dollars on Ugg boots? They were such a huge trend, and so very very ugly....<< MORE >>
I am tired of using automation tools that could be Armani Suits but instead are Ugg boots or a $1200 handbag, or even $3000 jelly flip-flops. Can I just get a sturdy backpack? Please? Didn't so much need the high pricepoint in learning just to have my tool go out of fashion in less than a year.
This is what happens when test managers don't understand what they are asking for. A test automation tool IS a software project. Ignoring the users of it is really not a good idea. Designing it for 2% of those using it, also not a good idea.
I have trend whiplash so badly that the last automation tool I saw (it was a mandate-I had to go), the entire time we were looking at the code, my only thought was, "I've been poor. I'm good at it. I'm a great saver. If I have to choose between doing this all day and my job there is no choice. I could wait tables. Seriously, I'm kind of cute, I'd do ok." It is not a good sign if Automation has been rammed down your throat so much that you have a gag reflex whenever Automation is so much as mentioned. Umm pushy much? I only blog about this because I think this is industry wide and a huge problem. I'm extremely passionate about testing. Does my burn out on Automation mean I'm a "burned out tester" now? How could I not be burned out when my work on automated testing in the last 3 years has been much like digging a hole just to fill it back up again? I will say, however, there are 2 automated tools which I DO support, will use, and almost (squirm) like? Yes. I like them.
Companies who are reckless with their talented testers, their brain engaged testers, who can't appreciate and value people beyond their coding skills deserve to be brain drained by other companies. We've seen the crappy results from other companies in the industry and I hope we don't need to repeat their short sighted and failed experiements in order to fully understand that having all testing automated is a horrid goal. To have all software tested by "developers in test" means that anyone creative who is scientific on the side no longer has value.
I've got my hiking boots on. Keep those furry monstrocities off of my feet. I've got somewhere to be!
According to the book Now, Find your Strengths. here I think it is pretty accurate. I love the boss who had everyone on our team read the book and take the test. The idea that you should focus on areas you have natural talent is a very simple one, but effective....<< MORE >>
Here are my "themes" as according to the test. What does a person like this love? A person like this LOVES to get ideas on collaborative testing, share ideas, and put them into practice NOW NOW NOW. Ha! I also love working on product interaction and feature integration because the way that code connects is interesting to me.
C O N N E C T E D N E S S
People strong in the Connectedness theme have faith in the links between all things. They believe there are few coincidences and that almost every event has a reason.
I D E A T I O N
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.
I N P U T
People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.
A C T I V A T O R
People strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.
E M P A T H Y
People strong in the Empathy theme can sense the feelings of other people by imagining themselves in others' lives or others' situations.
This just in: My manager has agreed to allow me to follow my dreams of cross-team QE demos and bug finding competitions. At my company, agreeing to let me persue this does not mean time and budget or resources to persue it, just that I have a chance to stalk people for resources, convince them to help me do it, and to use my charm and charisma (plus begging and making cookies), to try to get it to happen. On my side? Excessive enthusiasm. Against me? I'm already pretty overloaded, but hey, it's worth some risk if you really really WANT to make a difference. It's worth me giving mediocrity to less important things to really give this area I care about my very best. Nothing gives me thrills quite like testers from multiple teams in a bug finding frenzy for prizes and small scale fame. I'm doing my best to make testing more fun and efficient at my company in the way I believe is best. What else can I work on that is as important? Making more useless automation to maintain? Covering my butt more completely with further layers of documentation?...<< MORE >>
I just heard back from the legal department at my job! I am now free to talk at will about my testing idea with the general public!
This is great news.
Plus the lawyer told me that he hopes I write a paper. I plan to not let him down, although it will be much more blog than paper.
I'm swamped with bugs this week and testing shiny future operating systems, so most likely I'll get time to start this weekend or next week. Expect few blogs here until "The big one". I want your feedback, so please be ruthless. Tell me my ideas are NOT new, NOT origional, and pick them to shreds. Umm. Then help me put them back together as the stronger leaner few survivors?
Coming Soon: My Bug Harvest Idea in detail.
*wanders off singing to herself much like Bruce Almighty-"I've got the powah!"*
It's impossible for a creative artist to be either a Puritan or a
So, I haven't been blogging this week, but I wanted to share what I'm working on. As a test lead, I have quite a few tasks in process that I need to complete by the end of August. I have a difficult task as my team does more human testing that requires interaction with the real software than most teams, which is not very popular at any company at this point in time with software management teams who wish that everything would be static, test case based, and automated. We do very broad testing across MANY applications (well 16 applications is the most so far). I've taken some of the inspiring things that I've learned at recent conferences and by reading some blogs about some of the new directions in testing techniques and have tried to align my goals to them. I have sanitized the portions that are company specific so I could show you and also get some feedback if you can see some ways I could improve my goals to match my real overall mission.
"Take some more tea," the March Hare said to Alice, very earnestly.
"I've had nothing yet," Alice replied in an offended tone, "so I can't take more."
"You mean you can't take less," said the Hatter: "It's very easy to take more than nothing." Lewis Carroll, Alice's Adventures in Wonderland
I'd say that it is very easy to do more than nothing and very difficult to do the right amount without considering the results. Taking one cup of tea vs. say about 15 pots of tea. How much should we do now is a good question. Is taking no tea and leaving the party a good option? ...<< MORE >>
I couldn't leave that last blog out there, so negative, without the happy side.
I'm a strange tester because I don't like working alone. Collaborative testing is one area that I'm always researching, experimenting with, and trying new things with. One of my dreams is to some day make a valued contribution to this type of testing. I keep trying my ideas, and some of them fail, and some of them are works in progress, but one made it out into actual practice.
One of the days that I remember the most was the day my manager agreed to let me try out a crazy testing idea with other participants! I really want to go into detail about this idea in my blog, but I haven't been cleared yet to talk about it.
What I learned from sharing my idea and involving other people was that not all people who test imagine things visually inside of their head. Many testers understand what they are testing only in words, and pictures confuse them. Some people will look at an idea I've drawn or represented visually and say, "Oh! Now I understand", and the person next to them is staring at me like I'm some sort of fraud who came up with an idea that will never work. If I take the same information and write it out in a list with levels, the second person says, "Why did you overcomplicate this idea? Now it makes sense and I'd be willing to try it." This was earth shattering news to me. Some people are terrified of a big picture and resent those who try to present it. Not because they disagree with your view of it, or question it, but because they feel overwhelmed by it and don't feel that they should need to see it to get the job done. I was hoping that those giving me feedback were just going to argue about how I hadn't been complete in my representation, or that they disagreed with the content. I was shocked to find that seeing everything at once was a barrier to understanding for many people.
I've done some reading on learning styles, personality types, leadership, change, change resistance, introducing ideas, and different ways to visually represent data since that day. I now realize how easily a great idea can be killed by the wrong reprensentation, and by assuming that other people think like you do. Luckily, this idea wasn't killed. It was seriously reformed and more chances were allowed. It still lives in a small and very altered form.
The second "best testing day ever" was really a 2 day period of time. I kept corrupting documents while testing, but was unable to get a fix because once the corruption existed, the data was unrecoverable, and no log data was helpful enough to debug the issue and create a fix. I believed that I could find a way without an 87 step bug report ...<< MORE >>
Some of you may consider this blog quite off topic, because it is very personal. I want to share with you my survival strategy for some of the biggest problems I've ever faced since I've been testing, and none of them were testing related.
Here are some blogs I like about testing, or that I have been enjoying reading for testing inspiration.
First, we have someone else with an insane interest in collaborative testing techniques, but with more experience and internet fame than I can imagine, that is Jonathan Kohl. I've never met him, but have started reading his blog and am inspired. http://www.kohl.ca/blog/
Secondly, you may ask why this feed is about testing, but reading the Astronomy Picture of the Day is an amazing source for testing ideas. They are discovering and explaining so much that I've been inspired with testing ideas more than once from a daily glance at http://antwrp.gsfc.nasa.gov/apod/astropix.html. Seriously. It may sound silly, but it works for me.
Thirdly, one of the most hilarious people I've ever worked with has started a blog at http://pharrmentation.blogspot.com/. He is versitile, warm, and a great tester, so give his blog a read.
Next week I'm hoping to really go for it. There is one testing idea that is sort of "My Baby" and I'm going to make a big blog about it. I'm hoping for constructive feedback, but bashing my idea is also allowed. I'm making a study of collaboration in general right now, so if you have any links to help me in my learning, please comment. ...<< MORE >>
"The great question is not whether you have failed, but whether you are content with failure."
— William Shakespeare
That is a great quote to bring to a contested bug deferral.
I got into a conversation about testing mistakes with someone. I don't know any practicing testers in the industry who do not have at least one bug they have shipped with which they really regret and feel ashamed of.
When I was a brand new tester, working on contract at a big company, I was assigned an area of the product which had been tested. It was legacy code and I was handed an existing spreadsheet of well defined test cases along with a spec and test plan. I went about running all of the test cases and even went off of the script from time to time. When we shipped, I certified the milestone and felt great about how well tested my area was.
Then a bug came back that if you were to drag anything over one disabled icon in a peice of UI that was MY responsibility, the application would crash! This blew my mind. I had already checked that it was disabled in the script. How could it not be disabled? It was greyed out, not disabled.
With such an obvious miss, why am I still testing? Should I have been fired? Why did they let me continue my contract? I am still testing because I learned something very useful from that missed bug. I am more curious, skeptical, and I do not follow scripted test cases a majority of the time. Missing a bug is not a good reason to fire testers. In my opinion, dishonesty, being burned out, not testing, not learning, not working with other people, not communicating, doing the minimum required, needing constant hand holding, having no passion, being brain disengaged, and refusing to seek your own answers should be career limiting offenses. Those are good reasons that you shouldn't be testing. Making a mistake is not. Being human is not. Doing the best you can with an unreasonable schedule should not, so long as you communicate the risk.
I feel that if you aren't making any mistakes, you should be increasing the level of risk that you take. ...<< MORE >>
One of the responsibilities I take very seriously in testing is protecting the "soul" of the product I work on. If people hate using it and I have not shared the reasons why I believe they will and reported that, I have not done a good job as a tester. To explain what I mean by my unapologetic anthropomorphism of software, I want to get into my favorite and least favorite software of all time and why.
Astronomy is one of my interests and minor hobbies and I saw this picture in the feed of the picture of the day. It is an interesting example of human bias. If those objects (In this case color squares in an image) are mean to appear the same, there is a bug here, despite the fact that the colors are entirely the same scientifically.This is a bug that won't be be found by most automation because the context of the problem is the source of the problem. This is one of the best justifications for human testing that I've seen. If software is meant to be used by humans, there must be a viable balance of thoughtful human testing.
Just because something IS the same doesn't mean it appears the same to human eyes.
I can just hear now the response "It is working as designed" coming from the rafters as I type this. Testing SHOULD provide feedback on the design as well as the functionality. ...<< MORE >>
Yesterday was a great work day for me. After much complaint, ranting, and worry, I am now in charge of writing the automation plan for our team. It seems that rather than just catagorizing me as someone who is "anti-automation" and telling me that I either comply or get out, a few people are willing to believe that I'm just anti-bad automation, automation where it doesn't belong, and the wildly irresponsible assumption that everything automated is somehow better than everything which is not. Why is this good news you ask? Because I have some ideas of how to reduce the likelyhood that the automation we are working on will become useless to us and a waste of time.
Recently, I attended a testing conference named CAST 2007. I've been blogging since 2001 in my private blog, but I've never really published most of my testing thoughts for the general public, for a number of reasons. One being that non-disclosure law makes me feel kind of nervous, and I don't like criticism without a point. I've felt like I have the best job in all of testing for years, so protecting my company was more important to me than sharing with any community at large. This seems really selfish when I see it in writting. I'm not like many of the people active in the testing community. I have no problem with authority. In fact, I've even written "Best Practices" documents for creating automation that is based on written test cases. I spend months plotting out the most complete new feature test case documentation only to have it become out of date almost instantly. I have experiences that every tester has, and a few unique to me.
I was inspired enough by one of the sessions I attended to finally come out of the blogging closet, and take a chance that someone might benefit from my testing rantings, and that someone might even be me.
I want to gossip for a moment about James Bach. I've been testing for seven years now. I've seen at least 25 different speakers about testing. He is my personal favorite, and the weird thing is I don't know exactly why. It is disturbing to me that I find what he says both so charming and correct. Is it because what he says makes me feel good? Or is it because I believe he is right? Is it because he likes people and I am "people"?
I know why it isn't. It isn't because he's "My Type" and the redheaded tester girl has a romantic crush on him. First off, he has a beard. No offense to James, his lovely wife and family, or any other of my furry faced friends, but beards are a huge NO for dating in Lanetteland. Luckily, I have a wonderful boyfriend (clean shaven, of course), so the fact that many computer loving folk have beards won't be a problem. Secondly, he likes video games, and it sounds like he does quite a bit. Thirdly, he has no real problem with confrontation and discussing the meaning of the word "is" or any other philisophical discussion for as long as you may like. I bet you could even ask him, "What if the word D-O-G really spelled cat?" and he'd think about it and discuss it with you for a long time. I have the patience of a three year old waiting for a cookie.
The reason may be because he believes in the value of human minds in software. He is one of the people in the software industry who does not seem to believe that I could easily be replaced by robots were ...<< MORE >>