Context-Driven Testing

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.

Context-driven testing call it a set of values rather than a process or technique. It revolves around the fact that software users are human beings with diverse preferences, needs, abilities and limitations. A program that works well for one person in a given situation might prove inadequate or inappropriate for another person or situation. For example, a word processor with mathematical symbols and a set of tools for positioning and manipulating them might be ideal for a college professor writing a physics textbook but cumbersome and annoying for a novelist. Conversely, a simple text editor may be preferred by the novelist but be rejected by the professor. Context-driven testing revolves around the fact that there is no single “best solution” that applies to all cases. In addition, it takes into account the fact that complex software projects often evolve in unpredictable ways. Context-driven testing is based on the notion that a computer program should be treated as a solution. It follows that if a program does not resolve the problem or situation it is meant to address, then it cannot be considered a success.

Advantages of context-driven testing include enhanced user-friendliness of the end product, optimized functionality for intended users and adaptability of the product to changing markets and social values. The context-driven methodology does not necessarily work well in all situations. Other approaches might prove better for developers who are under the direct supervision and control of an autocratic “boss” who takes responsibility for the results of work done. Context-driven testing would likely prove superfluous in stable environments where conditions rarely or never change.

Principles

The Seven Basic Principles of the Context-Driven School

  1. The value of any practice depends on its context.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Illustrations of the Principles in Action

  • Testing groups exist to provide testing-related services. They do not run the development project; they serve the project.
  • Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives.
  • It is entirely proper for different test groups to have different missions. A core practice in the service of one mission might be irrelevant or counter-productive in the service of another.
  • Metrics that are not valid are dangerous.
  • The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).
  • All oracles are fallible. Even if the product appears to pass your test, it might well have failed it in ways that you (or the automated test program) were not monitoring.
  • Automated testing is not automatic manual testing: it’s nonsensical to talk about automated tests as if they were automated human testing.
  • Different types of defects will be revealed by different types of tests–tests should become more challenging or should focus on different risks as the program becomes more stable.
  • Test artifacts are worthwhile to the degree that they satisfy their stakeholders’ relevant requirements.

Context-driven techniques?

Context-driven testing is an approach, not a technique. Our task is to do the best testing we can under the circumstances–the more techniques we know, the more options we have available when considering how to cope with a new situation.

The set of techniques–or better put, the body of knowledge–that we need is not just a testing set. In this, we follow in Jerry Weinberg’s footsteps:  Start to finish, we see a software development project as a creative, complex human activity. To know how to serve the project well, we have to understand the project, its stakeholders, and their interests. Many of our core skills come from psychology, economics, ethnography, and the other socials sciences.

Taken from http://context-driven-testing.com/

Types of Testers

I really like the blurb from Jon as below. Its a simple explanation of testing approaches. Currently i am a Tester and i want to develop into an Omega Tester

Taken from blog post from Jon Bach

http://www.satisfice.com/blog/archives/958

What kinds of testers are there?

  • Automated? Manual? There is no such thing as manual or automated testing. It’s all just testing. Testing is often supported by tools that attempt to simulate user interaction with the system. This is what people call “test automation” even though it is only automating a crude approximation of one aspect of testing. If you have the ambition to be a one-man test team, it is extremely valuable to learn how to make your own tools.
  • Exploratory? Scripted? There is no such thing as an exploratory or scripted tester. All good testing is exploratory to some degree and scripted to some degree.
  • Tester. This is a testing generalist who can contribute to any test team. Sometimes called a QA analyst, QA engineer, or test engineer. I prefer the simplicity of “tester.”
  • Omega Tester. The omega tester (which I sometimes call a test jumper, after the analogy of a paratrooper) is one who can do anything. An omega tester is equipped to be the only tester in a project team, if necessary. Omega testers can lead testing, or work with a team of other testers. I am an omega tester. I aspire to be a good one.
  • Performance Tester. The performance tester understands the mathematics and dynamics of the performance of large-scale systems. They use tools that create high loads and measure the performance envelope of systems as they scale up. Performance testers often don’t think of themselves as testers.
  • Usability Tester. The usability tester is a bit mythical. I have met only two dedicated usability testers in my entire career, but I have seen more of them from a distance. A usability tester specializes in studying how users feel about using and learning a product.
  • Security Tester. Security testers also often don’t think of themselves as testers. Security is an exciting, specialized form of testing that requires the mastery of a great many facts about a great many technologies.
  • Testing Toolsmith. A testing toolsmith is a programmer dedicated to writing and maintaining tools that help testers. This is what a lot of people would call an “automated tester” but you better not use that term around me.
  • “SDET” Software Development Engineer in Test. This means a full on programmer who does testing using his programming skills.

Autonomy At work

Article “10 Ways in which software testers can win autonomy and earn respect by Jennifer deJong Lent in TechBacon taken from http://techbeacon.com/10-ways-software-testers-can-win-autonomy-earn-respect

Autonomy has always been important to me. Mostly because i do not enjoy been micro-managed and also because to me, it shows that i am trusted enough to make decisions on my own and do the job. I was lucky enough to have this at my last job, and a lot of the autonomy came from my 1st managers approach to effective team management. My second manager, however, it took a bit more work to get to a stage where it was evident that micro-management was causing disengagement.

So how to get to autonomy?

According to this article and from test guru Jon Bach – “He interacts with his tech and business peers in a thoughtful way. He asks questions. He listens carefully to the answers, welcoming unexpected outcomes. He’s willing to be wrong. He’s keenly aware of how behaviour influences the way he’s received by the people he works with. Self-awareness, he says, is essential when telling developers about potential problems you’ve uncovered in their code. “Your job as a software tester is to reveal problems and vulnerabilities in the application under test,” says Bach, author of the blog Tested: Highlighting the humanity in software testing. “You have to behave in ways that improve the situation.

1. Assume respect from others

There’s only one place to start, says Bach. “Let’s assume we do get respect.” If you’re willing to be bold, rejecting the status quo can result in positive changes. For example, instead of grousing that you weren’t invited to the software requirements meeting, show up and take your place at the table. Bach has done just that and was well received. “Whatever you feared isn’t likely to happen,” he said.

I have gone into meeting as a TA and have always been welcomed as a resource, someone there who is able to answer testing, resourcing, timelines, and workload decisions immediately.

2. Behave in ways that improve the situation

A software tester’s job often requires walking a fine line to not offend while making sure no concern goes unaddressed. “I don’t want to waste anyone’s time. Nor do I want them to not consider my issue,” Bach says. One way to be effective is to approach each issue as a fact-finding mission and remain open to the outcome. 

Instead of saying something doesn’t work, provide data that shows the difference.

3. Aspire to excellence

Establishing and adhering to broader principles that guide your work provides a helpful framework for dealing with difficult conversations. As a software tester, “I am vigilant about improving the culture, improving the process,” Bach says. He recommends that all software testers define their own standards of excellence and act accordingly. “What makes you excellent? What does excellence mean?” This doesn’t happen overnight, but it’s useful to understand the answers to these questions, he adds.

Do the best that you can and keep trying to be better at it

4. Ask the dumb question

Here’s a scenario common to all professions, not just software testing. You’re in a meeting. A question or comment occurs to you, but you keep silent. “Nine out of 10 people don’t speak up,” Bach says. But hiding what you don’t know—or failing to weigh in with a concern—is a mistake. Bach once asked: “What’s a bug?” Some peers may have given him funny looks at first, but a meaningful conversation followed. “It was almost Zen-like,” he says. “I don’t mind being the one who asks the dumb question.” How does Bach define a bug? “Every bug is a story. I wanted something to happen and I got this instead.”

There is seriously no such thing as a dumb question, Ask away at anything, you will be surprised.

5. Provoke a conversation that has to happen

Software testers can earn respect by taking the lead when problems arise. “I go to the whiteboard and draw my understanding [of the issue under discussion],” says Bach. Participants weigh in with their feedback: “Yes, ‘that’s the model,’ or ‘do we need this piece?'” they might say. “A good software tester doesn’t mind playing agent provocateur. It’s about provoking a conversation that has to happen.”

6. Go meta

Another leadership tactic Bach employs is to focus on the big picture—beyond the project and the company. “A good software tester can go meta,” he says. As a way of determining acceptable page load times, Bach once asked: ” ‘How does Amazon do it?’ It was a way of seeing how our own product was doing.”

What is the big picture? What are you hoping to achieve? How does a bug affect the whole thing?

7. Expect scrutiny, and be prepared

Software testers who do their homework get respect. “When you go in with a bug, expect questions, and make sure you know the answers,” Bach says. For example, if the bug occurred in the Chrome browser, a developer is likely to ask, “Does it happen in Safari? Did you clear your cookies?” There’s going to be scrutiny, Bach says. “You want to be able to say, ‘Yes, I checked that.’ “

Sure you found a bug. But what else. Where else? How? Check, check and recheck

8. Save face by using safety language

The most effective way to describe a problem found in testing is to use what Bach calls “safety language.” Phrases like “It seems as if” or “It could be” or “according to what I saw on my machine, at this time, under these conditions” show respect for others. What’s more, they let you save face when, for example, a developer tells you, “You didn’t configure your environment correctly. You didn’t set the flag,” Bach says, recounting a situation that actually happened to him.

Don’t assume its broken because you found something.  Check

9. Just say “Got it”

Software testers are vigilant about finding and fixing vulnerabilities in code. But you have to know when to stop. A developer once told Bach: “Jon, relax, this is a just a beta. It went to three customers.” When that happens, stop talking, and don’t explain. Just say, “Got it!”

There has to be an end point. As a tester testing never stops, you should know when to stop

10. Prepare to be tested

To maintain the respect of others, software testers should be ready to work in a hostile environment. That way, you won’t lose your cool when things get tough. “Keep your center; don’t get excited; don’t get defensive,” even when people speak harshly, Bach says. “Prepare to be tested yourself. Be prepared to be wrong. Keep an even keel.”

Keep your heard screwed on, and prepare to be asked the hard questions

What drives Bach’s approach as a software tester is simple common sense, and yet his tips for succeeding—and being received with respect—are notoriously difficult to implement. But they work for him: focus on your humanity. Be honest, do your homework, stay self aware, be open to all outcomes, define and follow your own code of excellence, know when to stop, and be willing to be wrong. “It is simplistic,” he says, “but not simple.”

Great Resources

Found this @ http://www.huibschoots.nl/wordpress/?page_id=441


What is testing -.- Becoming a (great) tester -.- Hiring (testers) -.- Test Design -.-Testing Skills -.- Context-Driven Testing -.- Rapid Software Testing -.-Exploratory Testing -.- What exploratory Testing is NOT -.- Session Based Test Management -.- Agile & agile testing -.- Heuristics -.- Test Strategy -.- Test Ideas-.- Oracles -.- Testability -.- Regression testing -.- Test Estimation -.- Reporting -.-Standards & certification -.- (Social) Science -.- Learning -.- Visualisation -.-Automation -.- Learn to code -.- Speaking tips -.- Magazines -.- Videos/podcasts-.- Forums/communities -.- Tools -.- More link collections -.- Uncategorized beauties


Testing & What is Testing:


Becoming a (great) tester:



Hiring (testers):


Test Design:


Testing Skills:


Context-Driven Testing:


Rapid Software Testing:


(Exploratory) Testing:


What exploratory Testing is NOT:


Session Based Test Management:



Agile & Agile testing:


Heuristics:


Test Strategy:


Test Ideas:


Oracles:


Testability:


Regression testing:


Test Estimation:



Reporting:


Standards and certification:


(Social) Science:


Learning:


Visualisation:



Automation & Tool aided testing:


Learn to code:


Speaker tips:


Magazines:


Videos/podcasts:



Forums/communities:


Tools:


More link collections:


Uncategorized beauties:

It Works!

Taken from blog post by Michael Bolton It Works on March 31st, 2014

http://www.developsense.com/blog/2014/03/

What does it mean it works? I have heard this terminology used in the work space, and then heard someone else come back and pretty much reduced it to nothing. IT says it works, Care or Sales etc. will have a very different view point..

According to Michael, “To me, when people say “it works”, they really mean

Some aspect
of some feature
or some function
appeared
to meet some requirement
to some degree
based on some theory
and based on some observation
that some agent made
under some conditions
once
or maybe more.”

Just because someone says it works, a tester does still need to “question the statement “it works”, to investigate the claim, and to elaborate on it such that important people in the product know what it really means.”

FUNNY-FUNNYSHIRTIMAGEFOUR_1

Testing Trapeze

As per article on testing trapeze website

http://www.testingcircus.com/testing-trapeze-faqs/

A new bi-monthly testing magazine to feature testers from Australia and New Zealand.

Why are we creating another testing magazine?
We want to see a small, simple, quality magazine that amplifies the voices of testers from Australia and New Zealand, presenting a clear, consistent message of good testing practice from existing and emerging leaders. We want to demonstrate the caliber of our community and encourage new testers to join us by engaging in their work at a different level. We want to create a publication that we feel proud of, that truly represents Australia and New Zealand on the international stage; a magazine that you want to read, share and contribute to.