"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 >>
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.
The following things happened in a 12 month span of time my 3rd year as a perm employee with a software testing job:
1. I was in intense chronic pain, and going to the doctor often, with no cure AND no definative diagnosis in sight. I'm not talking a little bit of discomfort. I'm talking about laying on the floor and crying, trying not to panic type pain. I was very worried that I was going to become fully disabled as it kept getting worse.
2. My marriage was totally falling apart and soon I was getting divorced, and 2 months after the divorce, my ex-husband remarried to someone I knew. I would go into more detail, but then it would seem even more like Jerry Springer, so I'll stop right there. Ultimately, it was the best thing that could have happened in life, but at the time it was rough.
3. My grandmother passed away.
4. My mentor, the first person to teach me how to test, who I credit with the fact I ended up staying in test and actually HAVE passion for it, died suddenly.
5. Major layoffs. I've survived 5 layoffs at my job. I have no doubt that part of this is luck. I understand that in software I am far more likely to be laid off than to retire from the industry.
So, in the face of all of these issues, I made it through that year and managed to do a decent job of taking care of myself, healing, and getting work done. I'm proud of the testing work I did during that time.
Things that helped:
a) Tell your manager if you are facing a very difficult problem.
b) Do NOT cry in your office. Go into the bathroom. I'm sure some of the people at my work thought I was developing IBS or something during this period of time, but really, if you can't leave your drama at the door, at least try to set up some sort of no crying zone.I'll add to this, carry eye drops, take some time to calm down, get it together, and come out once you are calm. If you are female (such as me), some under eye concealer in the purse is always a plus. You are testing, and can't do a good job if you are hysterical emotionally, so you might have to work later if you aren't able to focus for part of the day.
c) Work early or late if you need some alone time. This is one of the perks of testing at some companies, so use it when you can.
d) I set up a meditation area ...<< 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.
Top 3
1. Adobe Photoshop-My love of this product is so insane, and NO, it isn't just because I participated in the Photoshop 5 bug hunt and won an Ikea gift card, although, Swedish furniture doesn't hurt. Before I totally show my age, here are the reasons I love Photoshop.
a) The uses are limited to your imagination. It doesn't TRY to guess exactly what you are doing.
b) Plays well with others. Saves in many formats.
c) Truely one of the most innovative products ever, and remains a true origional by continually adding new things such as "align layers by content" and the new "selection" tools.
d) Is simple or complicated, depends on what you are doing.
e) If I take your pictures you'll never have acne, wrinkles, or bad undereye circles again (unless you want them). Trust me, if I take your picture, it is my job to make you look hot. I've been told that if the software thing doesn't work out, I should go do photos for Playboy. One side effect of this is that I picked up my boyfriends Maxim magazine and couldn't stop pointing out the Photoshop work that wasn't very good, and which tool they used. I was so engrossed in what post processing they did that I forgot to be at all jealous. Well, with Photoshop, I TOO can be a Maxim girl on print anytime I want. Did you know, I'm a software tester AND bikini model? Ok, maybe not in real life.
2. Google Mail (gmail)-While this has been beta since Orville Rednebacher was a boy, I LOVE this email program. There are a few things I'd like improved, such as notification software for the Mac, but all in all, I've never used better email anywhere at any price.
a) Free (well, ad supported).
b) Web Based.
c) Archive and free space. I no longer have to use work arounds to manage my mail. This is a huge timesaver. Microsoft Outlook is even more of a clown due to gmail putting it to shame on efficiency alone, and for free.
d) Easy to search.
e) Handles threads nicely.
f) Doesn't have fancy features, because it did the simple ones right. So, do you really need rules if you can instead manage your email most reasonably with just archive? They fixed a problem for 80% of users correctly instead of spending all the time on the 20% extreme users.
3. StumbleUpon plug-in for Firefox-This is a plug-in where ...<< MORE >>
Thanks to Matt Stratton, I found out that I do have an RSS feed if you'd rather read that. It is http://blog.testyredhead.com
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.
I'm putting the plan together with the following new ideas.
1. All of the automation time IN will be tracked. Just as we are using Session Based Test Management for our thoughtful hand crafted tests, we will also be using this for Automated tests. This means while creating them, investigating problems with them, sifting through results, and maintaining them, that time investment will be tracked and reported. The fact that almost all automated test plans are missing this makes me cry into my pillow at night. Representing an accurate picture of the automation costs is a vital part of making a good logical decision about the value of automating certain tests. This is going to take some evaluation on my part, and as a new process I'm sure it will be refined as we go along.
2. Protecting areas which really NEED thoughtful hand crafted testing. This is like a wildlife preserve. I get to set aside a "no drill zone" for those areas I feel would be destroyed if left to the robots.
3. Using automation to make session based test management easier for all tests. I have an idea for making this sexy, and no, I'm not talking about perl and text files my friends. I'm talking about some lipgloss on that pig. This is something I can get excited about. I'm a big believer in experimenting with the visual presentation of data, and I have some tinkering to do in this area.
4. Pimping out automation other people already made. I call this, maybe we can create a sexier wheel, but that doesn't mean it's cost effective. Now,..everyone into the shopping cart and we're headed for the Hawaii! Wish us luck! (glub glub). I kid, I kid. We will try to at least provide a hearty rubber raft with patches when we go out in the open ocean.
That reminds me of a story. On our 3rd date my boyfriend and I went to the lovely Ballard Locks here in Seattle. If you haven't been, you really should go. He noticed some ...<< MORE >>