obsequious

As a tester, your career is filled with projects.  Your response to project challenges define you as a tester on your team, to your managers and project managers, and within your testing community.  Challenges include your analysis of products, requirements, risks, and teammates.  How does the results of your analysis change from project to project?

For your present project, have you grasped the subtle nuance in a product or requirement and let it mentally interact with your bevy of test design techniques?  Have the risks vigorously motivated your imagination in scenarios and testability?  Or, is your response an obsequious plodding of history?

spectrum

A result from an evaluation provides a single piece of evidence.  It may demonstrate behavior, functionality, configuration, or simply existence.  The result by itself rarely provides a conclusion, or enough information on which to base a decision.  More results, that is, more tests, are required to breech a level of understanding sufficient to render learned opinion.
The amount of testing may be important however more important is a diversity of results.  What kinds of tests might you execute to provide a functional profile of the system under test?  What sets of data might you use to define a spectrum of behaviors?  A spectrum of perfection to error recovery?  A spectrum of a few transactions to peak load?  A spectrum of user frustration to user delight?

assumption

An assumption may begin without awareness.  You begin to create plans, structures, or objects based on some premise, observation, personal understanding, or bias.  When you complete your work and have it reviewed, flaws may be discovered.  How I often does this happen and result in someone exclaiming, “I thought it worked a different way” or some other realization that their assumption was inaccurate?

Assumptions help start new solutions to challenging issues but they also help requirements fail, make systems brittle, or cause delivery of the wrong thing.  The tester may test the wrong thing.  As a Tester, help bring clarity to solutions and to your testing by stating early and often, “Here are my assumptions”.

simple

A simple system is more testable and has high transparency.  A simple system’s behavior is easy to observe and observations are easy to report.  A broad and deep evaluation of a simple system is much more possible, much cheaper, and provides more benefits to succeeding integrations of the larger system.

Begin your designs in simplicity and collaborate with your team to evaluate it.  Profile its successes and understand its failures.  Building on small successes gives you the ability to create larger, complex systems with less defects.

acronym

Acronyms speed communication by relieving speakers of saying complete words.  Some acronyms are pronounced one letter at a time, others become their own word, and still others are just a word re-purposed.  Some acronyms come and go to meet the needs of a project.  Others take flight in the enterprise conveying whole groups of people or large business systems.

They become part of the language and culture in the workplace, and often spark stories around their origins for new employees.  They are an opportunity to help the new employee engage their company on an intimate level.  While the SLA on learning TLAs may be ASAP, introduce them purposefully and share your tribal knowledge of their creation.

attitude

Your attitude and your testing are occasionally symbiotic.  Your attitude towards your testing affects your work, and your testing affects your attitude.  Further, your attitude and your tests change throughout the day.  If that isn’t enough, your peers have attitudes all their own which also change throughout the day.  When attitudes become asynchronized, disagreements of various intensities may result.  They further disrupt attitudes and will impact testing.

If you experience disagreement, respond with compassion or an eager ear.  Accept the interaction as you would from a favorite teacher.  Learn what drives the disagreement rather than escalate an emotional reaction.  Give understanding, give ideas, give feedback but save your attitude and improve the testing of you and your peer.

schedule

A schedule can feel like a wall, it can feel like a burden, or it can feel like an opportunity.  If you see a wall, you may be thinking that the amount of work remaining will not get completed by a specified date.  If you are feeling a burden, you may experience stress and that stress increases as the specified date approaches.  Both are valid and can exist simultaneously, or you could toggle between the two.

A schedule can be an opportunity to engage your project team.  A collaboration with the project manager or the business stakeholder or both might illuminate new understanding on testing in the form of priorities.  This conversation discusses the schedule in terms of a budget where just so much work gets completed.  What is the most important work to be completed?  What if other work is not completed?  There are alternatives: more time, more people, and reduced scope.  What change or improvement might you recommend to make the best use of the schedule?

skill

Your position or role requires basic testing skills to evaluate, review, exercise, and observe a product. You may draw upon them from a vast library you have constructed over a period of time. You can apply a functional test, create a spreadsheet, log a defect, lead a team, or report an observation.
With experience, the nuance of applying your skills help you be efficient, creative, expressive, a leader, and possibly clever. You’ve become skillful in your application of your skills. When you reach this point in your career, offer your experience to grow skills in others. And, where possible, work with them to also become skillful.

done

Done is asymptotic to Finished.  The initial effort and investment to create a product follows a familiar development cycle of definition, execution, and release.  There are moments of revelation, conversations of varying intensity, individual epiphanies, team victories, multiple collaborations, and satisfying compromise.

As it goes to release, maybe a feature is not needed immediately, perhaps a defect can be resolved in the next release, and a suggested work around might generate beneficial feedback.  The product is done but it isn’t finished.

rapport

A certain harmony exists in many natural and mechanical systems. Gravity, sunshine, water, planetary motion all contribute to an orderliness of systems where they participate. Inevitable change impacts the system for a brief time as a new harmony establishes. You can witness this harmony in action in cars, the moon, your refrigerator, and your garden.
When you look at the relationships in your project, you may see differing levels of harmony. Where there is collaboration, the harmony is good and the effort to maintain it is minimal. Where there is strife, seek to establish and build rapport and improve the harmony. The project can create better products when it works undistracted by changes or conditions that upset its harmony.