"The PMP experience"

First time I thought about PMP exam in 2013 (When I heard a software tester passing the exam). Finally, registered for exam in Nov 2017 and passed on 22 Feb 2018.I followed almost a disciplined study schedule for over 2 months. DEC & JAN are the best months to go out and enjoy the weather but I chose to stay in house most of the time and make my dream come true!

When I started preparation, I used to score 60% in test papers. This gradually kept on increasing and in the last paper that I attempted, I scored 85%. I used to study 2-3 hours on weekdays and 5-6 hours on weekend. I had the plus point of working with CMMI level 5 companies in a defined process setup. So, I could understand most items defined in the books and tests.

Prior to starting my study schedule, I did little research on internet on how much study time is sufficient, what books to read, where to get the test papers etc. Then, based on my capability I got to know that approx. 2.2 months would be sufficient for me to attempt the final PMP exam. I read 2 books, "PMP Head Start" & PMP book of 'Rita Mulcahy'. First I completed Head start book and attempted all exercises. I did not attempt the final test paper after completing this book. I then read 'Rita Mulcahy' PMP book (along with PMI Guide) and it took little longer than planned to finish this book. I did all the exercises. I attempted my first full PMP test at this point.

I re-read entire 'Rita Mulcahy' PMP book and re-done the exercises as well. I attempted my 2nd full PMP test. Happy to score 75%+. I re-read the chapters but faster this time. Most focus on areas where I was not scoring well. I attempted my 3rd full PMP test, just 2 days before exam date. Happy to score 85%. I was ready to attempt the exam.

I scheduled the exam for the first available slot early morning. Test center was walking distance from my place. I kept myself cool though the entire period of 4 hours of the exam. Sometime 4-5 questions in continuation made me feel not very sure about the correct answer. I marked them to be looked later and kept moving forward. I took 2 breaks during the exam. I had enough time to review the questions that I did not answer early. Later, I answered all of them. Then, I clicked on End Test with full courage. I Passed!!

"Show Stopper"

Let's accept the fact, "You can not find all bugs just by going through requirements document".

I wrote all the test cases based on requirements document and added some more based on my experience. I got bugs, wherever system did not meet the requirements.

One day, when I Was showing the demo to a business user, He asked me to navigate to another module which was not in the scope of requirements document for customization. He asked me to check some data values and perform a workflow transaction. He was happy to see that data that he is
looking for is there.

I realized that this data is fine but it is showing duplicate records (for thousands of records). Business user did not see the duplicate record. He was just happy to see the data.

I drilled down the bug and found that the solution provided missed of doing customization in this module as this was not provided in the requirement documents. This bug turned out to be a "Show Stopper" and sent to a top ERP selling organization. They accepted the bug and are working to fix it in their product.

It is very important to have full understanding of business user's expectations. You should not stop the requirements gathering, when your requirements document is ready. Whenever you have the opportunity, discuss with business user about the product which is under development/testing/UAT
or at any stage.

In most of the cases, you have to agree to the business user's demand and your go live plan will get delayed. So, it's better to have courage and discuss the implementation with them. Else, you will have overruns in Revenue, Cost, Quality, Schedule, Resources. All !!! 

Most Powerful word - "TEST"!

Delivery Manager : Make sure you #TEST all customization done in product prior to release!

Change Manager: #TEST report must be attached with all the Releases!

DBA: Are all SQL queries #TESTED?

Project Manager: When can we send this to #TEST? Why so many failures from #TEST?

Development Lead: Guys, make sure we #TEST our code and then release!

Developers: I must #TEST for all input and output parameters!

Deployment Teams: Let's make the #TEST instance ready!

Customer: When can we #TEST?

The list is endless. Make sure you #Test!

You have to think and run your test scenarios like a real user/customer!

I wanted to buy a book on Amazon. I was not sure about the cost and time of delivery but i needed asap and in my budget. I browsed the similar books and compared prices and popularity of the author. The price was on higher side as these were printed books and delivery time was also around a week. Then i checked digital editions of these books which were not expensive and were also available on all my devices immediately. I browsed some of the eBooks and purchased one of them. I paid using my credit card and the book was available for me to read on my laptop.

Check the above scenario created by a real time user while making a purchase on a online store. check the amount of time spent by the user for executing this scenario. Amazon worked fine and there were no errors. I was a happy customer. Can you cover this scenario while writing test cases/scripts? May be, No.

My point is, while going through the requirements documents, make sure to understand the real use of the software. How this is going to be used? How different functionalities/modules are going to interact? If you can cover these in your test scripts, nothing better than that. However, you need to be creative, focused, and use software tester's brain to get closer to the expected scenarios that can be created by the real user.

As you can not ask for unlimited amount of test time, You need to make sure that type of test execution done by you is measurable and metrics can be produced.