Testers and Independence

by - jonathankohl 
I'm a big fan of collaboration within software development groups. I like to work closely with developers and other team members (particularly documentation writers and customers who can be great bug finders), because we get great results by working closely together. Here are some concerns I hear from people who aren't used to this:
How do testers (and other critical thinkers) express critical ideas?
How can testers integrated into development teams still be independent thinkers?
How can testers provide critiques of product development?
Here's how I do it:

1) I try very hard to be congruent. Read Virginia Satir's work, or Weinberg's Quality Software Management series for more on congruence. I work on being congruent by asking myself these questions:
"Am I trying to manipulate someone (or the rest of the team) by what I'm saying?"
"Am I not communicating what I really think?"
"Am I putting the process above people?"

Sounds simple, but it goes a long way.

We can be manipulative on agile teams as well. If I want a certain bug to be fixed that isn't being addressed, I can subtly alter my status at a daily standup to give it more attention (which will eventually backfire), or I can be congruent, and just say: "I really want us to focus on this bug."

Whenever I vocalize a small concern even when the rest of the team is going another direction, it is worthwhile. Whenever I don't, we end up with problems. It helps me retain my independence as an individual working in a team. If everyone does it, we get diverse opinions, and hopefully diverse views on potential risks instead of getting wrapped up in groupthink. Read Brenner's Appreciate Differences for more on this.

Read more at:
https://www.kohl.ca/blog/archives/000137.html

Test your Software Testing Knowledge before giving the ISTQB exams (Foundation/Advanced)

You can test your knowledge of Software Testing by taking the following quizzes. There is one for each ISEB/ISTQB certificated software testing course and the answers will be revealed at the end to tell you how you got on and to see if you are ready to take the real exam.

Please choose a test:

ISEB Intermediate level

 

ISEB/ISTQB Foundation level

 

ISTQB Advanced Test Analyst level

 

ISTQB Advanced Technical Test Analyst level

 

ISTQB Advanced Test Manager level

Effective Test status reports

By - Anuj Magazine
Here i am sharing some tips based on my experience on how the status reports can be made more effective.

Identify the audience of status report: 
Knowing the audience who will read the report is an important exercise. More often, i have seen that the Test status reports are sent to distribution lists containing large number of people without a thought to who the recipients are. Having knowledge does not mean to know the people personally, which may not always be possible if you are working in an organization distributed world wide but it means to understand their role in the project. This always helps to anticipate the expectations people have from the status report.
It is always preferable to list the role of people receiving the status report which may be as diverse as the following-
- Product Manager
- Project Manager
- Development Manager
- Development Director
- Test Team
- Development team
- Vice President etc.

If the status reports are sent without knowing who is receiving it, then it often leads to majority of recipients ignoring the report upon receiving it and you take the blame of unnecessarily spamming their inboxes.


Read More at: https://goo.gl/nziAM

Globalization Testing Myths

By - Anuj Magazine

I think i havent contributed to the Myths about Globalization Testing Series in a while. I do intend to write more about this and soon. In the meantime, i thought to just go back in time a little and list all myths that i have worked to uncover in the previous blogs. Here's the list-

Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated

Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.

Read More at: https://goo.gl/zHaKV

Best Practices in Context Driven testing

By - Debasis - The Bug Hunter

What a context-driven tester like me might do when allotted to a testing assignment?1. A context-driven tester might start by asking a bunch of context-based/context-related questions in an attempt to know the context better and deduce information about the mission, aims and objectives of the testing assignment! As it is said, proper questioning has the capability of solving half of the problem; and a context-driven tester knows this fact clearly from his experience and practice!


2. Once somebody said - The only thing that does not change in this world is “the word change” itself! This applies to software development too. Projects keep changing shapes as the development phase continues. A smart context-driven tester knows and understands that it is wise to be flexible and change the testing strategy as the context changes during a development phase. He can change mind and change the way he thinks once he realizes that the context has changed and is not the same as it was before!


3. A context-driven tester understands that the testing practices/approaches/procedures that had worked in his earlier testing project might or might not work in the current assignment simply because the context of both these projects might not be the same! A context-driven tester clearly knows that what looked like the “best practice” (so called!) in the earlier project might suddenly loose its value and become a “bad practice” once the context is different!





Read More at: https://goo.gl/iAlmC

Who is responsible when testing team missed the bugs?

A common problem in Software Testing - Who is responsible when testing team missed the bugs in early stages and find major bugs near the release date?

Answer by Andreea Dolete: I actually think that such an approach would be a big mistake, at least at that specific moment. Your main concern should be how to correct this with minimum negative impact on all levels.
In general , after a release, there are the so called Lesson learned session. That is the perfect space where you can raise the topic on how to PREVENT such situations and identify posible gaps in project's processes.

RESPONSABILITY lies with a lot of different actors in your project, as they all contribute with pieces. Communication, updated processes & proper engagement of all contributing parties within the project is the mix you need.

To give some hints to your question, if such situation occurs then it's most likely due to:
1. current process gap - development is never released to testing without a proper hand over session highlighting the fulfilled business requirements
2. solution concept documentation not clear enough OR not structured enough (usecase, realization concept, technical design).
3. developers do not just code on their own. They align to process/approach/strategy both on their team level as well as on project level. SO if they miss features then it's a clear internal team management issue as well.
4. communication issues

Reference: https://goo.gl/H7WZ9

Biggest Risk in software testing - The risk of ignoring the risks

Typical risks in Software Testing Cycle-

• Incomplete evaluation of labor on the project
• Partly estimated labor costs for testing
• Test plan is not tied to the project plan
• The testing strategy is absent or failing the development team or customer

and the Biggest one -

• The risk of ignoring the risks - One of the risks, which applies to all levels of risk management.

Refusing to take into account the fact that there are risks that the process (even the most well-established, verified, formalized and controlled) can lead to inefficiencies, usually leads to overly optimistic plans to conflicts with their non-compliance, the need to reschedule a "fire mode" ( that usually leads to miscalculations, and more violates the normal rhythm of work) and as a result of failures.

What to do: to start working with the risks (however hackneyed and trite not sounded this conclusion, but there is no other recommendation). In testing the specific risks a bit. Most of the risks the project level, may be solved by joint efforts of the testing, development and project management.

Now, hopefully, it will be easier..

Reference - https://goo.gl/SQ0f4