"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 >>
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 >>
A. Unit testing
B. Code coverage
C. Reviews and inspections.
D. Functional Automated Tests
E. Automated Regression Tests
F. Internationalization/Globalization Tests
G. Performance Benchmarks
H. Compatibility Tests (systems, browsers)
I. Beta programs
A. The USER
B. Anything that is missing from the code
C. Integration problems
D. Requirement problems
A. Data Points just waiting to be used
B. What is the code missing?
C. Integration testing.
D. Collaborative Workflow Testing
E. Scenario Testing
F. Usability-More than just “is that pixel right”
A. Real examples of bugs that would be missed even with 100% code coverage.
B. Big Picture Quality-Focus on the code early can be useful, but it aloneis not a complete balanced strategy. Starting with reviewed and testedcode will give us a strong base to test from. When the code is covered,then what? Then you are ready to test for the user experience and useyour creativity and testing expertise to report bugs on anything thatdetracts from the overall quality of the software under test, if thatis in the ...<< MORE >>
Ok--Scratch that. -Please review this
Draft 2
"We may be through with the past, but the past ain't through with us." Magnolia (1999)
How are you dealing with your existing test cases, and what does this have to do with the future of testing? Unless you are on a new product without any existing test cases, you may have some test case bloat you are carrying around with you. All of the time that you spend dealing with the quality of existing code is directly taking time away from developing and testing innovative new features and software. In short, the past may be hampering or even preventing you from having a future.
I'll discuss six different strategies which can be used either in combination or alone, the barriers to ruthless reduction, many ways to identify the keepers, and a few strategies for letting go. Once you decide on a reduction strategy it may be difficult to execute on unless you deal with the emotional attachment and fear that comes with leaving what some consider "needed survival supplies" behind. In addition to sharing many methods for reducing test case bloat, we'll discuss reducing duplication in the form of trusting the automation, trusting other teams, and finding areas of overlap. Find out why more is not better and go home with a goal to test less. If you are covering what is most critical, reducing testing where the priority is lower can result in improved efficiency while maintaining excellent quality.
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 >>
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.
1. Does it dazzle you in the sunlight? Beauty.
As yourself, as a user, is this stuff sparkley? Is it really something special? If not, what would be like sunlight for this user experience? As a tester it's your job to help shape the product. We get so used to thinking in the negative that sometimes we forget that we can have a powerful influence for the good of the user beyond just protecting them from bugs.
2. Don't forget to be human. Imperfection.
For our vampire friends, it's all about moving enough, blinking, but for testers who've been in the industry for awhile, we have knowledge the user may not have. Well perfect! That makes us enhanced with supertester vampire powers, but mere humans are going to be using the products, so let's not forget the impatient, imperfect humans and pretend to be human for your test cases. Don't forget that your automation isn't usually the best at being human, so it may need to be supplimented to get that sort of coverage. I mean REAL human. A very imperfect scenario.
3. When things go all Werewolf--be prepared. Phases.
No what are the wolf phasers? That would be leap years, that darn Globalization/Localizability (test early, test often, phase in advance), environmental changes (operating system, browser, ect), and that most dreaded PHASE of all, maintaining and supporting it once it's out the door. Also, don't forget our natural enemies, those who are waiting to exploit any security hole.
4. Hunt early, Hunt often, Hunt together.
In the books it is dangerous for the vampires to wait too long to hunt because they will lose control and start killing. So it is also dangerous for us to wait too long to test, let the project get out of control, and kill the quality. The hunting may not be ideal, but as soon as something is ready to test, jump right on it. If the timing is just right, set up a hunting party with a few buddies and really take advantage.
5. What you want may not be possible, but explore what is.
We all know that love between a vampire and a frail human has many limitations. You are but one frail tester in a den of test cases. What will you do when ideal isn't available? Well, you will do what you can the whole time working towards ideal. Impossible is not an excuse.
6. Love is powerful, but you can't ignore fact.
If Edward just went on instict alone it would be a short series ...<< MORE >>
| Common Measures | My Opinion |
| Test Cases Passed/Failed | Waste of time |
| Number of bugs written | Total Waste of time |
| Number of bugs fixed | Can be useful if you know where and use this as a way to judge risk |
| Lines of Code Covered | Can be useful IF used wisely with known numbers for 1-4 above. Those trying to get to 100% deserve rebuke. |
| Percentage of test cases Automated | Total waste of time. I realize that people measuring this way just don't understand and aren't really evil, but I have to remind myself. |
| Duplicates | Only of value if used to determine how many testers noticed this bug. |
| Number of crashes | Somewhat useful if taken in context. |
| Days/Hours/Weeks/Months/Percentage of up time or mean time to crash. | Very useful if this is critical for the workflow of the users. A good measure taken in context of items 1-4 above. |
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 >>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 combinatoricbugs,
4)
and such bugs are a lot more likely to happen than ones that only happen with morevariables.
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 testing
might find some pairwise bugs2)
while dramatically reducing the number tests to perform, compared to testing allcombinations, but not necessarily compared to testing just the combinations that
matter.
3)
which is especially cool because pairwise bugs might represent the majority ofcombinatoric bugs,
or might not, depending on the actual dependencies amongvariables in the product.
4)
and some such bugs are more likely to happen than ones that only happen with morevariables,
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 analyzingthe 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
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:
Ideation
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena. ActivatorPeople strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.
Woo
People strong in the Woo theme love the challenge of meeting new people and winning them over. They derive satisfaction from breaking the ice and making a connection with another person.
Communication
People strong in the Communication theme generally find it easy to put their thoughts into words. They are good conversationalists and presenters.
Arranger
People strong in the Arranger theme can organize, but they also have a flexibility that complements this ability. They like to figure out how all of the pieces and resources can be arranged for maximum productivity.
As previously blogged, last year they were:
Connectedness
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.
Ideation
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.
Input
People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.
Activator
People strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.
Empathy
People strong in the Empathy theme can sense the feelings of other people by imagining themselves in others' lives or others' situations.
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)
Ideation
A mixture of Empathy and Communication (I use both together, but not each alone. I call this ...<< MORE >>
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).
It looks a little something like this:
Half.day perWeek testyRedhead="coder". If testyRedhead != coder then resume testing and being <hostile
My reluctance, mistrust, and feeling that I can test better than automation can reminds me of the story of John Henry's Hammer. In this story, John Henry tries to beat a steam hammer but kills himself in the process. Ultimately, he fails to beat the industrial revolution. Is this heroism, or is he just stubborn and dead? My issues are no different. Being change resistant is unwise in the face of a steam hammer of changing industry trends.
I've been attending training. In fact, one of the best classes I've ever taken was last week. I feel 20% more comfortable with object oriented programming than before. I did quite well in the class, especially considering my lack of experience. However, it pointed out several things to me and clarified them by shedding a blinding light on several facts.
1. It isn't that I can't do it, it's just that I hate it and am not interested.
2. I like working on UIs, skinning, and overall project design and even pseudo code, but I hate writing code.
3. I'd rather get a root canal than work on any back end database code.
4. I could force myself to do this, but if it becomes a major part of my job I won't even make it one year more.
5. Each thing I learn points out the vast area that I have no knowledge of, and rather than a curious interest, it fills me with an unexpected level of dread and unhappiness.
6. My favorite part of the class was finding the bugs I found in the released software.
7. I wasn't put on the earth to be unhappy. Yes, there are things that must be done that we don't like in every job. If those things are growing and the parts you love are shrinking, much like a failing relationship, you must try to turn it around, and repair it. If you can't, you have to get out before you are no longer yourself, and become something miserable that is barely surviving life. I am hoping the "contain to 1/10th of job" compromise will take hold and will be something that works out for both parties. You can't have everything your way all of the time.
In other news, I'm hoping I don't get the "opportunity" (a.k.a. mandatory order from boss) to attend another course (a.k.a.self-impressed speech) by famed professor/author and Florida Software Testing Posse Member James A. Whittaker. The last "opportunity for learning" I had on the topic of Breaking Computer Software was the one and only training I've ever walked out ...<< MORE >>
It's impossible for a creative artist to be either a Puritan or a
Fascist, because both are a negation of the creative urge. The only
things a creative artist can be opposed to are ugliness and injustice.
Liam O'Flaherty
Ugliness and injustice are two of the things I really don't tolerate well in software. This is why I'm so passionate about human testing. Testing for usability. Buying software that is terrible to use is both ugly and unjust! I take great pride in preventing that from happening whenever possible.
I had a conversation with my boyfriend this week. He was telling me about his day. He writes code and actually enjoys it. He explained to me calmly what branching was, to which I replied, "I know what a branch is, remember?" He continued to tell me the tale of code until 10 minutes later I said, "Can we get to the more condensed version of this story, because you lost me 30 seconds ago?" He replied to that, "Oh, I forgot, you aren't really a technical person."
For about 3 hours I felt offended by that. Finally I came to a realization. He is entirely right. I am a creative person with technical ability. When I make effort to understand technology, I get my jollies thinking about the big picture. What that technology could do. For me, the exciting part is in the application, not the details of how the technology works.
Some people are scientists at their heart. I am proud to be me, an artist, who has learned science, but will always be an artist first.
I believe it's easier for a creative person to learn science than for a scientific person to learn to be creative, but I am delighted that we have both. I believe to be a great tester, it is important to have both, whichever way you get there.
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.
Mission Get R Done=My overall mission is to meet any criteria needed to satisfy management which may not be useful for our team once the product is ready to test as soon as possible so that I can focus all of my time in actually testing with a user perspective as efficiently as possible.
Mission No Sucky Automation Drain=Make sure that maintaining and writing automation doesn't conflict with or take time away from the actual testing during the project.
Mission Not a Programmer Don't Wanna Be Thanks=My third goal is to not waste time learning skills that I'll never apply in my job or that I don't have talent for and interest in. I have extreme passion for learning, so why let that go to waste?
1: People Management-Lead Media Validation for (product) to deliver quality media testing in the scheduled time for all (# of) languages. This includes communicating status and escalating issues when needed.
Success will be measured by: Completing Media Validation as agreed upon in test plan on time.
This is a slam dunk and now finished. We finished early, so a big check mark for this one. I learned while doing this project that I can actually handle getting 1000+ emails per day and not cry or hurt anyone, even after working 3 weekends in a row and having little sleep.
2: Individual and People Management- (New Test Case Management Tool)-Enter at least one (list of charters for session based testing) into (Test Case Tool). Lead discussions about levels of granularity and work with the team to pick a consistent way to enter (high level exploratory testing task and collaborative testing sessions) into (Test Case Tool). Explore the possibility of moving other documentation, such as the main (testing charters) for new features into (Test Case Tool). Explore using session based test management practices in (Test Case Tool) for clearer test coverage documentation as ...<< MORE >>