Hi folks of the testing community,
Through this first blog of mine I (Sriram) am stepping in to the world of blogging as a baby learning to walk on the highway called the Software testing. Testing as a career huh!!!. I never thought of testing till I found myself searching for a platform to set my foot upon to start off as a career. Until then, all I tested was my dad’s patience and a little bit of testing my speeding capability on the bikes - in reality I was actually doing a performance testing. lol. I started my career as a tester some 18 months back and as I continue to grow, I believe this forum would serve as a learning platform for many. And as always please do feed in your comments and criticism and I would love to see your credits and appreciations.
In my first write up, I am going to discuss about an interesting concept in testing called Session Based Testing. This idea of SBT brewed up in one of the stopovers at the local tea stall during the nights with my dearest friend, Ragavendhran I call him Raga. :P
You would also find him talk about his experience in SBT underneath. I found SBT very interesting because I am a guy who is always very passionate about testing functionalities without any boundaries. I always believed that the script based testing creates a boundary in our mind and would bring a mind set that testing is all done once test scripts are executed. This is how I feel and I have felt many times, don’t know about how others would feel on this. I believe in Ad-Hoc testing, exploratory testing and that’s why I find SBT very interesting.
SBT – Basically called as a testing package which should be un-interruptible and reviewable. Following are the components of SBT:
1. Charter
2. Session Timeframes
3. Results review of each session
4. Debrief
1. Charter: - Can be called as the agenda or the mission of the session. To be very specific and to put in simple words What to test and How to test.
2. Session Timeframes:- Time that would require for the test effort for each sessions. Basically a short session would require 60 minutes, and a normal session would require 90 minutes and a long session would require 2 hours. Buffer time of 15 minutes is always permissible. The timeframes are basically setup upon analyzing the complexity of the functionalities that are planned to be tested in a session.
3. Results review of each session:- A session report is prepared after each sessions which consist of the following headers namely charter items, Areas, Start time of the session, Tester Name, Task Breakdown, Duration, Test Design and Execution, Bug Investigation and Reporting, Session setup, Charter vs Opportunity, Data Files (if used), Test Notes.
If you look at the contents of the session sheet you can find a header named Charter vs Opportunity. As we have discussed about charter, now lets get into the opportunity concept. The main advantage of exploratory testing is "Opportunity of finding bugs" is more. In the same way Opportunities are those which are not listed in the charter as test items but still due to the intuition of us (We Testers) we normally intend to deviate from the agenda to find more bugs. The time utilized for the opportunity testing is not included in the session time estimate but later documented in the session report. Bugs found by charter and opportunities are documented separately. An opportunity today hits the charter tomorrow which helps in optimizing the future sessions.
4. Debrief: Every Session testing is followed by the Debrief session where the testing team actively participates and discusses about the experience of the testing session. Discussions about the next session also can or will be a part of Debrief session. This is my general understanding about Debrief session.
Usually Test Managers follow the PROOF concept to validate the session testing.
1. Past – what happened?
2. Results – What we achieved?
3. Obstacles – Difficulties
4. Outlook – What has to be done to overcome the difficulties?
5. Feelings – What each team member felt?
Tester's Role:- Each test session comprise of three vital tasks namely Test design and execution, Bug investigation and Reporting and Session setup, shortly called as TBS metrics. Its tester's responsibility to report the effort spent on each task to analyze the happenings of the session. In addition to this they also report the time spent on identifying bugs through Charter vs Opportunity.
My experience in implementing SBTM:-
Pradeep Soundararajan said.
@Rag (That’s how I call you)
Thanks for your comment. After having worked with you, I think every team needs a person like you who can set a cool atmosphere, make testing look like awesome fun and help colleagues working hard.
You should consider writing, too.This was the trigger for me to blog:
To give a brief introduction about me according to my assessment (Self assessment), currently i am Mr. 'poor writer, a moderate decent reader, and wannabe passionate tester' Ragavendhran (Any pet names welcome).
I was working for XXX company for about 7 months in YYY project. Last 5 months gave me the true essence of testing as I was working with my thala and got to know the different perception of testing which was ahead of the conventional method. Now I realise that my true experience in testing is 5 months and the rest 2.2 yrs of experience as fake or for sake.
Its been 4 months I am working with Pradeep, I came to know that there is another ABC project where UAT testing is going on in the same XXX Company, and got a chance to take a look at that project and felt that there is an opportunity for me to explore.
I approached my thala for this, I explained about my need and he suggested me to get in touch with
Santosh Tuppad (This is how you get contacts & I was lucky enough that I came to know him). Later I approached him and discussed about my need which was wandering in my mind. Then he suggested me to go through Session Based Testing Methodology and asked me to implement the same in my path of exploration.
Since It was my penultimate day @ xxx company, I was giving KT and other stuffs to my team members, and parallely testing of Reports has to be done, the report 'X' was so huge, imagine it takes value from 8 to 9 different database, which involves 21 different formulas and there were about 84 test cases. Testing was supposed to be completed by EOD, and it was post lunch time (you know how sleepy we would be) and nothing was kicked off.
I immediately felt that this was the moment where i can really help out my project, i decided, for the next 5 hours we are not going to move anywhere and within this time frame what is that i can do. I dint document it but i communicated to my peer who was also willing to join me for this session of 5 hours. Then i discussed with him about the approach that we are going to follow for the next 5 hours in order to accomplish our target which we have set for ourselves. We of course took help from the test cases which we have prepared, but still we were adding some adhoc test cases which would help us to find the bug quickly, since we were happy about the progress after some 2 – 3 hours. We were very excited about the way we carried out our testing in that session of 2 – 3 hours, during the process i noticed that we were finding defects, but i was keenly observing that more than finding the bugs, the opportunity of finding it was more.
I don't know what was the reason behind it :
Since 2 testers were involved could be a reason,
Perhaps we were working continuously without any interruption could be a reason,
Might be whatever the doubts we had was clarified by each other,
Could be the adhoc testing which we did during the session,
End of the 5th hour we were done with the testing( and the mission was accomplished successfully with in a given time frame) which we had set before 5 hours, we ended up with several defects(more than the defects which we identified, we found more opportunity of finding it) which was valid & we prepared a detailed report on what we set as a target before 5 hours, what all we carried out, necessary documents , what all the problems and observations which we have faced during the 5 hours & all defect details with ID's and other attachments and sent that to the project team by EOD.
I then realized this would be probably a variety of session based testing which we have carried out for 5 hours and i was sharing the concept with my peer tester who was new to this, he was also happy that he had done something for this day & i was really proud about myself because i realized 1st time, what learning would help anyone and what speaking to others who has great knowledge would benefit you.
This is my first blog which i am writing, thanks 'Thala' for the trigger & thanks santosh, looking forward a lot of support from you.
We hope this article on SBT has opened the eyes of a few chota testers like us on the emerging trends and practices on software testing. Do feel free to share your thoughts and experiences on SBT, also i encourage my fellow testers to write in and discuss interesting topics anything on testing which the Testing community as a whole would benefit from.
We personally welcome your comments and appreciations. We believe your comments and your suggestion would take us to new heights.
