Showing posts with label Shmuel Gershon. Show all posts
Showing posts with label Shmuel Gershon. Show all posts

Sunday, January 12, 2014

Professional meeting? JeST DO IT

This post is about my experience of organizing Tester’s meeting. It is true  as well for any other meeting, be it Software Developers, Social workers or a meeting of Puppeteers.

The 3rd meeting of JeST – the Jerusalem workshop on SW Testing is just over. Such a meeting is a great opportunity to meet fellow testers, and share experiences and ideas.
I am the proud founder of JeST, together with Shmuel Gershon, Asher Samuels and Alon Waisbard (look in Twitter for @sgershon, @absamuels  and @awaisbard ). I am telling you that because less than a year ago, organizing such a meeting, looked to me as a distant vision, something that will happen in the far future when I will develop the complex skills necessary to organize such an event.
But it doesn’t.
A moment during JeST2


Organizing a meeting is so easy, that I must share how easy it is, with you. The main issue to overcome is the mental block and just do it. To help you overcome this block, I prepared a list of the things that you don’t need, in order to hold such a meeting:
1)      A budget
You will be able to find a place to host a short meeting. You don’t need to rent a conference hall. It can be the room in the company of one of the meeting participants, or one’s home living room. Refreshments can be brought by the host or by the participants.  If it works for you and the potential participants, you can schedule a meeting in a quiet restaurant and address the need for both the location and refreshments.
2)      Sponsors
Since you don’t need a heavy budget, you don’t need an organization to support your meeting. Although I welcome cooperation and networking, which naturally happens in such meetings, I prefer to remain independent and stay away from organizations that try to use the meeting for their own promotion.
A thank you note should be enough as a return of the hosts good will.
3)      Heavy logistics
You don’t need a full-time administrator to organize such a meeting. Split the tasks between a few friends and it will not consume too much time. Use social networks to spread the word. Meetup service can simplify the process even more, in return for a payment of a few bucks.

(Late note: there are many Meetup groups which are allready dedicated to promote events like yours. See for example: ILTechTalks group. All you need is to suggest your event in such group, free of charge)
4)      Professional presenters and presentations
Not everyone who has interesting things to say is a professional presenter and the length of a
JeST3 agenda
presentation does not make it better (most times it’s the opposite). For our meetings, we chose a format of lightning talks followed by a discussion.  One time, we had a “regular” presentation, which was great too, but the most significant part for most of the participants was the discussions that we held.
5)      A large number of participants
Rating is overrated. While it is nice to see many people come to “your” meeting, a large audience has its drawbacks too – the atmosphere is less intimate, it’s harder to facilitate the discussion, and not every participant feels free to express his opinion. When I started to organize the first JeST meeting, I was worried that the meeting would not  draw a “respectful” number of participants.  I did the “Worst case scenario” drill and came to conclusion that if only me and the other 3 folks that shared the idea of organizing the meeting would come, it would not be a waste of time.  At the end the meeting turned out to be a success, also by the number of participants.
All the above are not a “must have” in order to organize your testers meeting. All you need is Testers and a love of testing.






Thursday, February 23, 2012

DOWNTIME NOTIFICATION

If you will it, it is no dream.
One day, the test engineers in the Testing lab came to work and went through their inbox. Among the mail was a short message from the Testing lab manager:
To: All testers
Subject: QC DOWNTIME NOTIFICATION: unlimited period
Dear testers, in order to try new ways of work, our test management system, Quality Center (AKA “QC”), will be down until further notice. There is no change in your task definitions, roles and responsibilities.
P.S. I will be out of office on vacation for the next two weeks.
At first glance, the testers were shocked, they re-read the message and moved their eyes to the message date, but it wasn’t April 1st. They looked at the Hebrew calendar, but the month of Adar hadn’t started yet. As seasoned testers, they didn’t take the message as a fact and tried to enter the Quality Center site, without success. 
The coffee corner was crowded. Continuous humming of testers and team managers shaking their head from side to side in disbelief. Managers tried to reach the test lab manager via cell phone, SMS, email, Facebook, and twitter, but got no response. They approached the manager’s manager who told them: “Please talk with your test lab manager. I believe that it is important, but in order to change his decision you must contact him. Till then I will back his decision and won’t interfere.”
The most concerned was the project testing leadership team. They realized that they would not be able to query progress indicators and track whether they had reached coverage expectations for each work week: ww25 10%; ww26 20%; ww27 40%; ww28 60%; ww29 80%; ww30 90% and so on.
The Security team manager gave his team clear instructions: “Perform any legal or semi-legal operation to hack and bring up the system”. But even the efforts of the best white hat hackers team in the industry were not enough to bring up a system that was shutdown, power unplugged, behind a locked door.
Team leaders sat in the labs perplexed. Some asked their team members to perform some bug verifications and handle other minor issues, but didn’t have an idea as to what to do next. One of the leads had an idea: Shmuel, from the Sustaining product test team, told him once that he does not work with QC. As he knew Shmuel managed to perform testing, they could ask him for advice.
An expedition of several people approached Shmuel. The following dialogue took place:
Crowd: “Please help us. We need to run our cycle, but QC is down. How can we do it? Do we need some kind of magic?”
Shmuel: "Does QC run the cycle for you?"
Crowd: “No! But how will we know what tests to run?”
Shmuel: "Oh, knowing what tests to run is important, as we will want to look for information about what we don't know, and get a feeling for areas we consider at risk. Is that what you want from your tests too?"
Crowd: “Yes”
Shmuel: "So let's see: How do you decide what tests to run?"
Sara: "I go to QC and pull the list of tests that are not 'done'."
Shmuel: "We said we are looking for risk and new info – is that what you have in the not-’done’ list?"
Herzl: "Not exactly, it is a list of tests for old info."
Shmuel: "But your team does find new bugs using them, Herzl, how do you do that?"
Herzl: “I guess we find them because when we run the list of tests, we somehow know where things can show problems.”
Josh: “During test execution sometimes I see something behaves suspiciously. I investigate it and find a bug.”
Shmuel: "Josh, this is what happens in my team, too! But you said 'somehow', Herzl... how do you think you knew?"
Herzl: "I don't know... we've seen similar problems in the past?"
Shmuel: "Ah, so you use your experience as part of the secret. Do you have seasoned testers in your team?"
Herzl: “Yes."
Sara: "We also have new testers, they sometimes tests things we hadn't written or thought of."
Shmuel: "It looks like we let our teams think about risk and new information (what we said we were looking for) everyday! Is that so? Sara?"
Sara: "Well, yes... in a sense... for bugs."
Shmuel: "So what do you need QC for?"
Herzl: "How will they start if we don't give them a cycle?"
Shmuel: "How about you just tell them to start? You can ask them to list what they want to test without another list distracting them.”
Herzl: If you will it, it is no dream
Sara: “How would we make sure that teams distribute the work correctly and focus on the risk areas?”
Shmuel: “You do talk with your team members, don’t you? “
Sara (a bit offended): ”Sure, constantly!”
Shmuel: “When talking with your team you learn about what they tested, so you can take the opportunity to discuss focus areas and distribute the work.”
Sara: ”I guess this can be more meaningful than when I just hand them the test cycle and ask about progress.”
Josh: ”Without a list of test cases, how do you make sure that you will not forget to check important things or some details? Our product is pretty big and you can easily forget a part.”
Sara: ”I agree with Josh and want to add that sometimes we do find a bug when a test case fails.”
Shmuel: “Sara and Josh, this is a good question, and hard to answer. It seems that there’s an assumption that the central test list will solve the problem for you.
Testers work is solving this problem, and they have a wealth of tools for that – the test case repository is one of them. Renewing the test case list is another, which can be done by interviewing managers and programmers. Now you don’t have the central repository, but you can organize your own checklists and areas of coverage.”
Herzl: “Sound great, but are you able to report coverage and test results without having numbers of test cases and pass/fail results?”
Shmuel: “Let’s take a closer look at these results and see if we’ll miss them. Are found problems lost, unless there’s a failed test? We use a bug repository to log and study them, which is reviewed by the project managers.”
Herzl: “But without the pass results, do you suggest providing our message about coverage without supporting numbers?”
Shmuel: “Not at all! If you have supportive numbers you should provide them. But in your cycle case... if the receiver does not know what the tests are, there’s little support by counting them.“
Sara: “Well, all they ask is whether we will complete our work in time. And I think we will.“
The test team leaders start to disperse, each to his own team, to discuss the work without the test management database. In a few hours the whole testing department was back at work. Issues were raised, bugs were opened, and short meaningful coverage reports were provided.
Two weeks later. A short message appeared in the tester’s inbox:
To: All testers
Subject: COMPLETED: QC DOWNTIME NOTIFICATION:  server is up again
No one bothered to read the rest of the message.
Special thank to Shmuel Gershon for participating as a guest author in this post 

=====================================================================
Further reading:


Tuesday, April 27, 2010

Celebrating 10 years of testing - the Milestones and the People


This month marks 10 years since I moved from the I.T. support field into SW testing. Celebrations often find you very busy with other activities like I am now these days, in a middle of a validation project, but nevertheless I would like to give some thought to important milestones during this testing decade.

I will follow the context driven school of testing, which emphasizes the people as the most important part of the Testing project and I will celebrate each milestone and mention the related people who helped me reach it.

Milestone: First mistake
Person: Myself (who else could I blame…?)
Bad decision – bad result – when I let development close a non-reproducible bug, it was a mistake - since such bugs tend to reproduce at a later stage... Fortunately, failure reproduced again before the product went out to certification, during the pre-certification process, but that caused a lot of noise. Believe me - learning this lesson made me a much better tester.

Milestone: Leading a team of really great testers
People: Jose & Itzik
Jose, a new student (now a firmware architect) and Itzik, a tester with some experience (now a SW developer) joined my team. Together we built a team of passionate testers who challenged the tested SW. Without knowledge of too many methodologies and processes we explored and invented new methods and tools. We did a great job for our stakeholders.
I discovered my skill as a team leader – not intimidated by the talents of others – but helping the team express their abilities.

Milestone: My really great bug
Person: Jose
When I wondered “what would happen if…” and did the extra action that exposed a major failure in the product, I did not recognize how great a bug it was. Only when Jose (appearing in this post for the 2nd time), pointed out the thought process and mindset that led me to find this bug did I understand the significance of this occasion. Since then, a framed hard copy of the bug entry hangs in my cubicle and I refer to it as my own Tester Certification.

Milestone: Redefining myself as a Tester
Person: James Marcus Bach
When I was sent to his “How to be an expert tester” session, I did not anticipate its impact. Perhaps I was ready after 5 years of experimenting and perhaps it was James’ style, but this session made me start a journey of reading, talking and thinking about testing, exposing myself to different approaches, finding my preferences and defining my approach to different aspects of our profession.

Milestone: Participating in the Methodologies workgroup
People: The workgroup members
Participating and contributing to the methodologies workgroup of my testing department was not only an honor, but a challenge. Besides reviewing the work of others, I contributed two of the chapters of our methodology document. I had to explore, define, write and discuss the methodology of bug submission and test case authoring, exposing myself to criticism and debate.

Milestone: Starting to blog
People: Shmuel Gershon, Pradeep Soundararajan, Parimala Shankaraiah
During the last year, I started blogging. The inspiration came from my friend Shmuel Gershon who has been blogging about testing for a few years. I started blogging with a first post that reviewed Test books and magazines. Then I read Pradeep Soundararajan’s post “Why good software testers should come out of the well?”, and started blogging my own ideas too. I had been thinking about it for a long time, but his last post gave me the final push after a few months of an idle blog. Parimala Shankaraiah with her refreshing blog “Curious Tester” inspired me by showing how simple ideas turn into brilliant and refreshing posts.

All of these people and milestones have made me the Tester that I am today, and made for a thoroughly enjoyable decade. Thank you, And have a great next decade.

Tuesday, September 22, 2009

Create your tester portfolio

The following presentation that I have created with my friend Shmuel Gershon, suggest ways for novice testers to gain experience by doing open source and crowd source testing and. We did not invent the wheel here, but we discuss and give some guiding that could be useful for novice testers.
This presentation was a result of a request that we got from few Tech career SQA course graduates, for some training that will increase their value in the eyes of potential employers. they suggested that we will teach them the ITCQB certification exam. however, we thought that we could do something more meaningful by giving them this workshop.

link to our work:


and as a shared document in scribd