Monday, January 19, 2015 12:24 PM
One of the surveys which might help us testers understand how the world chose to respond is the State of Testing Survey
. It was conducted in 2013 and the results are here
If you have not participated, here is your chance to participate.
Image Credits: http://electronicvalley.org/derby/surveyb.htm
Thursday, December 04, 2014 04:49 AM
Most challenging course in terms of the content to be skimmed, understood and put in practice.
Add some travelling and festivals in between and the challenges multiply.
Thanks to all the participants, the instructors, my course sponsor Ilari Henrik Aegerter and my family members, I could complete the course on time.
Friday, September 05, 2014 01:35 AM
This blog post is about a topic close to my heart - Software Testing
It is going to be a long post highlighting few key points/myths and what I think about them.
Feel free to comment and we can discuss. Ok, let's start.Case 1: Testing processScenario 1:
You are supposed to test a feature. You receive a requirement document and there is a formal review process. You write test cases based on your understanding of the feature. Add a layer of review process. Start
executing the test cases. File bugs. Measure how many test cases are executed per day per tester. Write a test case for every bug discovered, if they are found outside the test cases. Reject any new feature addition as it was not planned in your scope. You assure the quality of the product and tell when the product is ready for release.Scenario 2:
You are suppose to test a feature. You figure out who is the decision maker, the stakeholders involved and try to understand your role. You seek help, remove traps to get access to the product, interact with the programmers and prepare a light-weight document (checklist/mindmap or on a simple sheet of paper ) which acts as a reference. Based on your interactions with people and products, you update your document. You test the product, file bugs, ask questions, seek help/tips from experts and inform the stakeholders about the status of the product and project.
I will let you pick the scenario you like.
If you are more familiar or in favor of Scenario 1, we will have lots to discuss.Case 2: Manual Testing vs Automation Testing
Have you heard of the word 'Sapience'? Do you use just your hands while testing? Do you think? What happens in your brain when you test? Think for a minute. Yes, THINK.
I feel that the very notion of classifying testing as manual vs automated is wrong. Michael and James have come up with an excellent blog post here highlighting the difference between testing and checking.
Here is the diagram from their post.
Also, check out this blog post by Michael - http://www.developsense.com/blog/2013/02/manual-and-automated-testing/
These two posts talk about Testing and Checking: http://www.satisfice.com/blog/archives/358 http://www.satisfice.com/blog/archives/856What is testing then?
Before reading more on what testing is, do check out the slides from BBST Foundations which describe what a computer program is. The same folks who would define a computer program as a set of instructions would define testing as a process to find bugs or assure quality of the product and testers as the gatekeepers of quality.
Check out an excellent video on the talk between devil and angel of software testing:Testing is an intellectual activity.
If you can think well, you can test well. Every test is a question to the product, sometimes to the project stakeholder. Check out the lessons #16 and #19
Testing is not about test cases or documentation or tools. These were designed to help you test better, support testing. Instead, what do we see testers focusing on?
Learning new tools, writing better user stories, automating tasks and dreaming of days when testing would be fully automated!!!
Pick any resume and check the Skills section: 7 out of 10 would mention some or the other tool names.
Quick Learning is a skill. Tool is a tool. A fool with a tool is still a fool (maybe, a dangerous fool).
So, what am I proposing?
Focus on skills like Observation, Thinking (Critical, Lateral, Forward/Backward, Parallel, Technical), Reasoning, Preparation, Programming basics, Collaboration, Framing, Reporting, Bug Hunting, Social Skills, Knowledge about Psychology, understand and apply oracles and heuristics, quick learning and many more skills. I suggest two books - Lessons Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord) and Testing Computer Software (Cem Kaner, Jack Falk, Hung Q Nguyen)
Watch the videos from BBST courses - Videos
Build your test ideas repository - Test Heuristics Cheat Sheet
, YANDY list300 common software errors
Pick your topic of interest and become a specialist in that. The Ministry of Testing resources page can help you get started. Resources
Case 3: Automation is the future
If you have been hearing of new tools, new languages every week and wondering which one to learn, here is a simple tip:
Your job is safe if you have the skills. There is no single tool which can replace a working human brain. If tools can replace humans, we would have been jobless long back. If you think automation is the future, I am sorry. You are missing a very key element here - EMOTIONS. Check out the ppt file here - Emotions And Test Oracles
by Michael Bolton.
Google for TDD and check how many links highlight why it does not work.
If you think that testers need to learn coding, I am not against it completely. My only question is: How often have we asked programmers to learn testing?
If you think that TDD is the future, remind yourself again that they are good for programmers and do not replace/negate the role of a tester. Read the first comment on this post: http://www.satisfice.com/blog/archives/638
And if you still think that tools can test mobile applications and there will be no need for testers, I will assume that you have no idea about this excellent keynote by Jonathan Kohl.
Saturday, July 26, 2014 08:16 AM
Hope most of you are aware of the awesome software testing competition conducted by Matt Heusser, Maik Nogens and many volunteers across the world. The whole concept of competing for one spot per continent is awesome. You might have participated in contests within your company or a local gathering but can it get bigger than a continent? Software Testing World Cup lets you experience that moment where you compete with close to 250 teams. Yes, 250 and only 1 winner.
Before I begin highlighting our team's experience, I want to thank the lead organizers - Matt Heusser and Maik Nogens and all the volunteer judges, the sponsors and everyone who helped conduct this BIG contest at the highest level. Check out the website for more details: Software Testing World Cup website
The logo is quite good too :)
For the Asia preliminaries, we had started preparing from April. We were a team of four - Pranav, Satish, Sundar and myself. I created a folder on Google Drive and shared it with other teams representing Fiberlink, an IBM company
. Two teams were representing us from the America continent. We had few documents, list of test websites, tutorials on the G Drive. We also scheduled for 30 minute testing sessions till 07th June. Due to our busy schedule, we could manage only 6-7 focused sessions. We tested websites, mobile apps and windows applications too.
Meanwhile, we were brushing up our knowledge on different bugs, patterns, quick tests and checklists. We not only practiced the testing sessions but we also practiced writing the final test reports. We did send a sample test report to few judges for feedback and this exercise helped.
On the day of contest - 07th July, we were all set to test and only after an hour of testing, we realized that many other teams were not able to access the SUT and the contest was called off.
We were worried about the future date as one of us had to fly and we were not sure on how we would manage testing across time zones. The date was announced - 25th July and we had the following conflicting events:
- The day after a hectic office trip where I enjoyed a lot and was tired by end of day
- Pranav had to be part of interview drive for developers
- Protest in Bangalore
- Sundar had to pack for his trip that night
We did not have any practice sessions after the contest was postponed. We were monitoring the other continents' contests closely. We planned to assemble at 8.30 am IST. As Pranav was busy with the drive, we asked Rahul to join us. One interesting observation from my experience is that people find it tough to clear traps till someone else clears similar trap. I reached at 8.30 am and logged in to my Agile Test manager account only to find that the password was incorrect. On attempting Forgot password, it asked for Security Answers which I had no clue of. Immediately, I pinged Michael from HP, Maik and Smita asking them to help me with my login.
Michael solved it immediately and I was able to login to discover that it displayed Europe instance instead of Asia. After confirming that it was an issue on their side, I was waiting for the organizers to announce the SUT. Sundar and Rahul joined me in the meeting room and Satish was stuck in traffic because of the protest.
Sundar tried connecting to mIRC on both the laptops but it kept retrying and connection was timed out. Then, Sundar did something brilliant - connected to VPN and tried connecting via US network and we were placed in the chat room immediately :) Many teams from our company backed out as they were not able to connect to mIRC chat.
I use Unroll.me and found it great to start with. The only disadvantage I face with it is few important emails - like the one from STWC announcing the SUT get moved directly to the Unroll folder. We were informed a day before the contest that there will be two websites and one windows application to choose from. I was asking Sundar on which application to choose - Website or Windows application. He replied NBA.com and I asked him why NBA without realizing that the SUT was already announced.
Immediately, we started our task and we listed out our focus areas for the next 30 minutes. Satish was testing from the cab and sharing files over Skype. We had the Skype group chat going where each one would highlight the bug and send the screenshot. My role was to replicate, file the bug and do some testing when the bug flow was manageable. Sundar was focusing on the different tours, I took up the quick tests with different checkers and Rahul was testing on iPad. Satish was testing on Android smartphone.
We found quite a decent number of critical bugs and in no time, there was just 45 minutes left.
We covered most of the areas planned for testing and I started consolidating the report. Sundar was filing the bugs discovered by Satish and Rahul. He was also helping me with the mind map for additional testing scenarios. At 12.31pm, we were done with testing and finalizing the test report. We emailed it to the mentioned email address and quickly received a confirmation from organizers that they received the report.
- Previous experience of working under severe time pressure helps.
- Getting our test reports reviewed by the judges pointed us to key areas we had overlooked.
- Practice sessions helped us finalize on a convention within the team.
- Do not panic when you face a trouble - think through and take steps to solve it.
That was one contest well planned and executed :)
Now, waiting for the results.
Saturday, March 15, 2014 15:17 PM
I do not subscribe to any testing related blog feeds. Instead, I pay close attention to Joris Meets'
twitter feed and check Ministry of Testing feed
. Both of them do a great job of consolidating important testing related blogs/articles. While browsing through James post on Test Jumper
, I liked what he wrote. It matched with my preferred style of working - help people identify traps, test with them and create an environment conducive to learning and improving testing skills.
There have been instances in my previous and the current organization where I am called upon to help a project which is going nowhere. Most of the times, they face one of the situations:
- Important bugs being identified late
- Testers on unplanned leave
- Unstable product or need for better coverage
- Inexperienced project team
- Important project
I like such challenges. They seem to get the best out of me. I visualize this video and feel good at the additional responsibility given to me.
I started thinking of what gives me the confidence of taking up the role of a Test Jumper
. Can I pass any checklist for someone to use and build on it? I launched XMind
and here is the output.
|My Project Preparation|
This is again a heuristic and not a final plan. It depends on the project, answers to the different questions and other factors like project, team, stakeholders, risks and deadline :)
Monday, March 10, 2014 07:39 AM
Do you test software? Do you test every day? Do you get paid for it?
If you answered yes to any of the two questions, I have one more question for you :)
What percentage of office time do you actually test (interact with the software)?
The answer to 'Testing includes...' might differ from one person to another. I don't want to get into that discussion right now. I am more concerned when people spend very little time interacting with the product and complain of bugs being found by the customer. Consider the following three scenarios:Scenario 1:
A feature has been revamped and will be released to market soon. A tester who has never worked on the feature is called to test the revamp. The tester could:
- Understand the existing feature
- Understand the revamp
- Analyze the XYZ specification
- Write test cases
- Test the feature and file bugs
- Test the system
Your team reaches office at 9am and is available till 6pm.
The total time spent testing the product on an average is 3 hrs. Rest of the time is spent on the following:
- Attending meetings
- Updating KnowledgeBase pages
- Plan for next release
- Taking interviews
- Document the learning
Here is a tester who refuses to follow the rules. She never attends any meeting unless her inputs are a must-have. If she wants to learn anything, she knows the right person who can help her. She is very good at networking and has lots of friends in the whole company. She has one bad habit though, as her colleagues mention. No - not the one about rules, when she is given a feature to test, she spends most of the time interacting with the feature. Her activities can be summed up as follows:
- Understand the mission quickly
- Highlight the traps and risks
- Test the feature, system
- Use information from different sources as a heuristic
- Get help from those who can help her
What is your take on 'How much should you INTERACT with the feature/product/system?'
If you are smart enough, I would expect your answer to start with
'It Depends...' and continue the discussion. At the same time, I am open for new answers.
Thursday, January 09, 2014 09:49 AM
There are usually many paper submissions for a conference. How easy is it for your paper to be selected?
Check out the following tips. Hope they are of use to you - especially if this is your first time.
Abstract / Description
- Let it be as simple and crisp as possible.
- Do not copy paste or explain your company or context or a technology in detail unless it is a new idea. On some of the abstracts, I have seen a lot of details about some well known technology which could have been googled.
- Please get it reviewed by someone who has already presented a paper or presented in a conference.
This is one section which the audience is more interested in, specifically when they need to choose between sessions. Some not-so-good examples of Key Takeaways:
- XYZ Technology or Some terms in ABC Process
- X% improvement in some method
When submitting a paper, please test it.
- Will you as a reviewer, like it?
- Is it really necessary to give you a speaking slot?
- Is it something which needs you or can be found on Internet?
These are three questions which when answered might give you a clear picture of whether your paper is good for a conference submission.
Tuesday, December 31, 2013 13:34 PM
Five more hours before the new year at Bangalore...
Five more lines before I end this blog post.
Thanks for everything that happened in 2013.
Thanks for every experience, I learned from and specially the ones, I couldn't learn from.
Thanks for the good health and wisdom to choose the right words.
Hope to live one more year of experiences, learning, caring and contentment.
Have the courage to give wings to your dreams before its too late.
Tuesday, December 03, 2013 03:54 AM
I support. Do you?Website Link
Please click on the above link and extend your support.
Tuesday, November 19, 2013 18:49 PM
A short post on what happened yesterday in office:
I and my friend Sanket Gagneja were involved in a paired testing session. We had two mobile devices with us. One of the devices had the app which acted as the oracle and the other had the test app.
I was keen on using the test app as I was new to this app. Sanket was testing this app since few days.
He was the note taker and would answer my questions.
I tapped on an icon, typed "test3" and tapped another icon. There appeared a popup with some text. I was reading in my mind and told to Sanket this line "Your development team has really done a good job" and then THE APP CRASHED.
We both looked at each other for a second and emailed the logs. I tried to replicate the issue and once the popup appeared, the app did NOT crash. I immediately pressed another button.
Sanket took over the device and tried the steps. Then, Sanket did something which made me very happy. He not only repeated the steps but went ahead and told the line "Your development team has really done a good job" and THE APP CRASHED.
He was smart enough to not get diverted and actually remembered the exact sentence and repeated it. It is not about remembering the exact sentence. It is more about being aware of what happened, what's happening and is this what is called as "Situational Awareness"?
PS: The app seemed to crash after 10 seconds of inactivity once the popup appeared and we took 10 secs on average to say that sentence.
Sunday, November 17, 2013 13:56 PM
I was very happy to be at Agile Testing Days, 2013
This is how I felt when I was leaving Potsdam, Berlin.
My promise on twitter:
And here are the slides explained. The complete slide deck can be found here
Before I started the session, I showed most of the slides to the audience and a one-liner on what the slide is about. I then gave the option to choose some other session, if the audience did not like what will follow for next 45 minutes. This way, I would have wasted only 2 minutes of someone's time and not 45 minutes.
No one left after the quick overview of all the slides.
This slide was on even before I started the session. I kept this slide to lighten the atmosphere. Most of the talks I have attended have the first slide with the topic name, presenter's name and maybe the company logo.
To ensure that there were no red flags about my understanding of "Agile Testing", I used this slide. I did not read through the contents as it is already known to many. I highlighted that Agile Testing used "Agile Manifesto" as a guideline and customer satisfaction by delivering quickly is more important than following any process. When no one raised any red flag, I moved on to this slide:
With the above slide in background, I explained what Exploratory Testing is, how there are different definitions but highlight one common theme:
If the next test is influenced by learning from the previous test, you are applying exploratory testing approach.
I then- asked the audience on what they feel about Exploratory Testing. The whole group then came up with a list of words/topics. I played the role of note taker. The beauty of this exercise was each word/topic seemed to lead to a new word/topic.
Once we were done with Pros of Exploratory Testing (ET), we also discussed a bit on Cons of ET as per those who complain against ET.
The next slide, we focused on the ET skills, highlighted by Jon Bach.
There are some pre-requisites to do exploratory testing which can stand up to scrutiny. Everyone can test but is your testing valuable? Why do so many people reject ET and force testers to follow a scripted approach?
Good testing requires skill and good testers work on their skills.
As each link explains the myths in detail, I did not spend more time on this slide.
The following slide seems to need more explanation. Let me explain.Skills:
Work on your skills. Do not just restrict to testing related skills. Learn from other disciplines. Spend time practicing the skills. Only those who work on the skills will survive.Experience:
Experience matters a lot. Try to experience
as many different contexts as possible. The varied experiences and the experience in a particular context helps you think of different and useful test ideas which would help you in testing.Customers/Context:
What is the use of any product if it does not solve customers' problems? Do you understand your customers and the context well enough to design your test strategy? I do understand that customers is one of the factors in context.Risks:
My first question to the product owners and the programmers in my company: What is the biggest risk you feel with this feature? What are you worried about the most? The answers help me a lot in understanding the product and the project a bit more in detail.Exploration:
This is related to the "Experience" point. In any aspect of the project, pay additional attention to exploration path. Do not restrict it to just testing. Explore in the true sense - to investigate.Testing:
Finally, a tester with good testing skills and who is skilled at Exploratory testing will be able to help any project and not just Agile testing projects. This tweet sums up the essence of my talk:
Last few slides are self explanatory. And here are some of the photos from twitter:
Finally, I ended my session with a call for questions. Hope this blog post serves the purpose of the session. I enjoyed the session where most of us were involved and shared thoughts.
If you have any questions, feel free to email me at email@example.com
Wednesday, October 30, 2013 08:44 AM
|Day 2: Agile Testing Days|
Monday, October 28, 2013 21:34 PM
Wednesday, October 23, 2013 05:38 AM
Friday, July 26, 2013 02:50 AM
Update: The seats have been filled and registrations have closed. Thanks.
This time, I am conducting this course in collaboration with STeP-IN Forum
and the target audience is testers with experience between 0 - 3 years.Schedule:
Date: August 1st to August 30th
Time: 06.00 am to 07.30 am IST
Link to Register for the course: http://stepinforum.org/software-testing-trainingCourse Overview:
As highlighted in the mind map, this training will focus on the following topics:Basics of Software Testing
We will start with understanding the basic terms like bug - issue - quality - defect. We will definitely NOT go through V-Model, Waterfall and many other such terms which is slowly losing out its importance in today's testing world.Test Ideas
This session will focus on how to generate test ideas, learn from different sources to test any product. We will also know that software testing is not only about testing Functionality.
There is no fun without bugs. So, how do we find them? How is bug investigation different from bug hunting? How to find Sev 1 bugs?
We will definitely be using many tools in our sessions. We will also focus on how to scout for resources and tools in particular.
Once a tester completes the test execution, (s)he should be able to provide a professional test report. We will create different reports and get feedback from the group.
Does your learning stop after a course or workshop? How can one learn about software testing every day? We will go through few important areas for self-learning.
Link to Register for the course: http://stepinforum.org/software-testing-training
Tuesday, July 16, 2013 18:16 PM
July 17th 2013, I complete seven years of testing software.
Sunday, July 07, 2013 04:10 AM
The STeP-IN conference started on 18th June and the closing ceremony was on 21st. I received the Best Speaker award for my hands on tutorial on "Mindmaps: A powerful testing tool to aid testing thought process"
After STeP-IN, its time for World Conference on Next Generation Testing
I am excited to be part of this conference for multiple reasons.
This is the first time, I am conducting a paid workshop on Exploratory Testing. Details about the workshop are here
(Click on the Agenda tab). This is a one-day workshop and you can register here
. The speaker list
is impressive. I have known many of the speakers for quite a few years now.
I take this opportunity to let you know of three reasons why one should attend this conference:Reason 1: The Experience & Knowledge
If you have never attended any conference till date and you are working in software testing industry, I would say that its too late. You need to experience the conference atmosphere. Better late than never. Get started. Once you attend, you will know about different contexts other than the one at your office. You would also know that you can present in next conference too.Reason 2: Build your Network
It is good to know that others share your passion or have interests just like your team. The problems faced by your team are already solved by some other teams. You may never know whom your company might hire in next three months or which domain interests you after six months. The bigger your network, higher your chances.Reason 3: Good Investment
When I started my career in software testing, I paid one-fourth of my salary for a half day workshop. Friends called me crazy but the investment paid off big time. My perspective on software testing changed. And today, I have reached a state where I would conduct a paid workshop. Do not wait for your employer to pay for your learning. Invest in self-learning and reap the benefits soon.
I will be available at Le Méridien
from 10th to 12th July
. See you there.
Sunday, June 09, 2013 08:55 AM
One of the highlights of participating in Weekend Testing
sessions is that you get to see others test, their test reports and thought process to an extent. When I participated in sessions conducted by Europe chapter of Weekend Testing, I noticed that few test reports were in the form of mind maps. Darren McMillan was excellent in reporting with the help of mind maps. When I asked him to help me with mind maps, he wrote this beautiful blog post
which soon became the go-to post for mind maps. I myself would have referenced this over thirty times.
Over the last two years, I have practiced and used mind maps to collect all sorts of information.
Starting from test ideas to book draft to bug investigation, I have gained a lot by using mind maps. I have also conducted workshops at Hyderabad and Chennai on usage of mind maps in testing. It was well-received. So when STeP-IN agreed to my topic of mind maps, I was happy. I see this as an opportunity to help more testers realize the power of mind maps and save a lot of valuable testing time.
Do attend STeP-IN Summit 2013
I am presenting on mind maps on June 18th and there are other valuable presentations and workshops too. Hope to see you there. An overview of my presentation can be found here
Any questions, feel free to ping me.
Thursday, May 30, 2013 19:49 PM
We have a competition at office - a quarterly one. You are free to work on any idea for 24 hours. No meetings, no work, no deadlines. At the end of the day (which is usually a Friday), you get ready to present your idea and its implementation before the judges.
Book 1: Mobile Testing: Ready Reckoner
So, in the event held few days ago, I and my friend Sundaresan Krishnaswami wrote a book on Mobile Testing. We admire Jonathan Kohl's book 'Tap into Mobile Applications' a lot and have learnt a lot from the book. We needed a ready reckoner - a very short book and we created it based on our readings, testing experiences, competition experiences and feedback from other testers.
Each page is designed in such a way that an idea is explained with the help of a screenshot. We have also added the learning and resources link if necessary. As a tester or a mobile enthusiast, you can open any page and apply the idea immediately.
You can print the entire book and have it as a pocket calendar. The book size fits the pocket.
Book 2: UI and UX Testing: Ready Reckoner
This book is also in the ready reckoner format. A screenshot followed by explanation of the idea. Fits into pocket, go-to book before any testing competition or a quick reference when you run out of ideas.
Cost of the books:
Book 1: INR 200 or USD 5
Book 2: INR 130 or USD 3
How can I buy these books?
1. Please transfer INR 200 or 130 or 330 to the following bank account.
Account No: 00531610015960
Bank: HDFC Bank
IFSC Code: HDFC0000053
If you are using Paypal, please transfer USD 5(first book) or 3(second book) or 8(both books) to firstname.lastname@example.org
2. Once I receive the money, I will email you the book.
Any questions, feel free to email me at email@example.com
Saturday, April 13, 2013 17:50 PM
As testers, we ask a lot of questions. Sometimes, we need to answer a lot of questions too. Few days ago, I was asked the question:
"What is smoke and sanity testing and how is it connected with high level test cases?"
I asked why he wanted to know the answer and pasted the link to blog post by Michael Bolton:http://www.developsense.com/blog/2011/11/smoke-testing-vs-sanity-testing/
I told them that it is much more important to practice testing and improve one's testing skills than know answers to such questions. When I mentioned about BBST
, I was asked if BBST meant Behavior Based Software Testing
. I was disappointed and emailed the tester my first book - 'What If... A collection of tips on software testing
'. To my surprise, the tester had already bought this book. I was even more disappointed.
The next day, I received this email from the tester:
Since I have read this book before and at that time, I have just read it like other testing guides and have joined people just to ask my testing queries those were not for testing but was for interview preparations.
But after your advice , I have started reading this book again. This time I am feeling like I have started learning the basics of testing very first time, since the time you have just sent the book to read. You would be amazed sir, that since evening to this time I have just read only 6 pages of it and this time I have not skipped any links or any thing.
Now I am feeling like this book is the best gift given by anyone and once more thing initially i was using it like quick recap but today i feel that it is more like an encyclopedia of testing basics.
Sir, I would request you to just help me in getting to draw the Mindmap and also with basics of drawing these mindmaps (But at least this week i wouldn't get time for this, not because i have a lot of work in office but I have your book to complete it with all its link with better understanding).
I am happy that he has found the book useful. Balaji from ZenQA, Hyderabad also finds the book useful. When I met him last time, he told me that he uses the book as a compulsory reading for the new joinees.
Let us stop worrying about what Sanity or Smoke tests mean. Let us focus on our skills instead!!!
PS: I have titled this post as "What is the difference between Smoke test and Sanity test" to attract more hits. I hope more and more testers read this post and the post by Michael Bolton.
Sunday, March 24, 2013 17:22 PM
We have bug bashes in our company. In every release, the tester invites other testers to test his/her feature. Fresh eyes, different experience usually helps in bringing new test ideas and bugs to the forefront. I usually participate in such bug bashes as it exposes me to different features and test ideas. It is a good opportunity to practice testing and a good break from regular testing too.
In one such testing session, I found a bug where the button was tapped even though I did not tap the button. On further investigation, I realized that the focus of the button was much more than the button area. Let me highlight the issue with the help of the following image.
On the left image, we have a problem.
The button's perimeter is displayed by red color.
But when the user taps or clicks anywhere within the green rectangle, the button is still clicked.
On the right image, the focus of the button is limited to the area highlighted by red color. On tapping or clicking outside the red area, the button is not activated.
How do we usually test such buttons?
- Clicking on the button
- Changing the state of the button - enabled/disabled
- Test the default state of the button
- Combining the button action with other actions
What am I proposing?
I want to include a test to click around the button to check if the focus of the button is restricted to the button area or extends outside the button area. According to me, the name for the test idea: "The Perimeter Test".
Why this bug is important:
a. The user might not know that the click outside the button behaves similar to click on the button.
b. It would be confusing if there is little space between adjacent buttons. The user will not know which button was clicked.
c. The trust on the application's behavior is reduced as the user is not sure of what to expect.
I would like to highlight the Perimeter Test's importance on mobile devices and areas where multiple buttons are placed close by. Try 'Inspect element' on the button and discover the area quickly. Also, the Perimeter Test might not take more time. A quick test to highlight an important bug.
I am happy to give the test idea a name and hope to come up with more such test ideas.
What do you think about 'The Perimeter Test'?
Just to confirm: This is different from "Boundary Testing technique".
Sunday, February 10, 2013 18:35 PM
I was having a Skype discussion on asking the right questions when someone asks us to test a product. We realized that there were many questions and thought of creating a mindmap to build a mnemonic for easy remembering. It is not mandatory that we ask all the questions but it is a good idea to consider all of the categories.
Here is the mindmap and the mnemonic. Thanks to Michael Bolton. http://www.developsense.com/blog/2010/11/context-free-questions-for-testing/
PCM - TRP - DOT - TED - FIAT
Wednesday, February 06, 2013 05:28 AM
I left Bangalore on 1st Feb on a 2-day trip to Hyderabad. The purpose of the visit was to interact with my Hyderabadi tester friends and also take a break. Anurag Raghuvanshi
received me at the Kacheguda station. The train was delayed by half an hour. We took the MMTC train to Hi-Tech city.
Anurag & myself discussed about various testing challenges including
- building awareness about testing
- continuous learning
- relationship with programmers especially when they are not in the same time zone
- counting bugs
Then we freshened up, had our breakfast and started with a testing session. Anurag wanted us to test Junglee
. Last time, we had tested Flipkart
. So, we set a charter to test just the Search bar on Junglee.
|Junglee Search Bar|
The session was restricted to 15 minutes. I created a mindmap and screen recorded my session.
Then we had a pretty long de-brief. It was a two hour long de-brief where we discussed the following:
- Why did I record the session
- How to use Comparable Products heuristic
- What was the test idea behind using script tag attack
- Special cases discovered in the session
- Persistent XSS Attack
- Http codes
- Difference between SupportDetails.com and .net
We went for lunch - Hot butter rotis and lots of paneer. Later we sat down for another testing session. I was happy with the Wi-fi speed and checked the speed on SpeedTest
. It was more than 2Mbps.
He downloaded the application PNotes
and I asked him to highlight his test strategy.
Then, we created a map for Project Planning template.
|Plan for a new project|
After reviewing Anurag's work, I gave him the next task to discover what the files .aff and .dic stood for.
I showed him the power of search terms to gather more information about the files. It was time for a break.
We enjoyed few hot Jalebis, parathas and then headed for Skype Coaching session from 10pm IST.
I had asked folks to create a mindmap and get used to the tool.
Day 2, we had guests to the room. Sudhamshu, Abhinav and Balaji.
- Xenu link checker
- Firefox addon - Extended Status bar
- Article on Cookies
We stopped and then had Hyderabad Biryani for lunch. Balaji came after Abhinav and Sudhamshu left for the day. We went through my article on New Year Resolutions for a tester
Balaji highlighted his experiences of RST workshop with James Bach. He tried 1-2 exercises on us and also told why he was so impressed by Rahul Verma's words. We discussed about why reputation and credibility is so important for a software tester.
Then, it was time for Weekend Testing session. The report can be read here
When I thought that it was leave Hyderabad, I met Bikash who turned out to be a passionate mobile apps tester. We had a good discussion on the tools we use and the challenges we face.
All in all, it was a great two day trip to Hyderabad. My special thanks to Anurag for hosting me.
If you want me to coach you personally or conduct a session in your city, feel free to drop me an email at AJAY184F AT GMAIL DOT COM
Wednesday, January 30, 2013 18:26 PM
Monday, January 28, 2013 18:22 PM
|Skype Training from Jan 31st|