Mission: You are asked to test Digg Reader. Write a test plan for testing the www.digg.com.

Testing Context: Time available for testing is one week and one tester will be testing entire product. Tester: Ravisuriya Date: 16th Sep 2013 Time: 11:00 PM IST to 12:11 AM IST

Session Notes: Looks like the mission and context is demanding huge from a tester. Not sure what the Test Plan mean here. One week means 5 days or 7 days? Test Plan is also viewed just as logistic details of test project. But in this context, it appears like the stakeholder does not mean logistic plan. Instead, the test strategy is expected in the test plan. Few of us practice combining Test Logistics and Test Strategy and call it as Test Plan. In this case, I consider this perspective for word 'Test Plan'. And, this is first assumption I'm making. I need to test entire product. What is available in the product? What is the testability factor of product? Where can I find this information before hand, starting the hands on testing? I see, Digg has got multiple products web app, Android app, iOS app. My test plan should be for which product? I cannot have one test plan for all these products. Should I be testing all three products in one week? It is possible, if stakeholder comprises on values. So, I make the second assumption now, I will be testing the web app. The third assumption, I'm making is the stakeholder wants the Digg Reader should be usable for first. That is the purpose (functionality) has the higher priority than any other quality criteria though other quality criteria information are expected from testing. The fourth assumption is, the features released in the product are those which are demanded by users and which are very much needed to hold the Google Reader users. With these detail, I study how the product is built and maintained. Digg is configured over AWS for hosting and infrastructure. Database: Amazon's NoSQL Queuing services: Amazon's SQS Network DNS handling: Amazon Route 53 Load Traffic Controller: AWS Elastic Load Balancer Storage Space: Amazon's S3 and CDN. Language: Python Content Caching: Momcached, redis, twomproxy. Additional data storage system: MongoDB. Network connection handling: Tornado framework. Process Handler: Beanstalkd Front end: jQuery, Backbone.js, Require.js, Uglify.js, Lo-Dash, Node.js, LESS.

Challenges for Digg Team to solve Reader experience is fast and responsible as possible. Data size: 8 million feeds to be processed. User should be able to scroll through pages for looking at feeds and feel the super coolness in viewing the feed content. Pagination and scrolling needs to be pleasant experience for user. Should be able to import data of Google Reader and any other news feed reader. Ability to unsave saved items Export feeds from Digg Reader OPML file import and export Option to show or hide a news feed. Refresh of page should be auto. Default hyper text protocol connection on secured wire. Indicate the news feed coming in on auto refresh. Support on mobile browsers. Count of feed coming in and sitting as unread. Should be able to mark all as read in pleasing experience. Should be able to pick unread news feed for the respective directory level. Listing the unread feeds count next to the feed name prominently. Should be able to mark the feed as read or unread. Above are demand list which I should be testing. As per the 3rd assumption, I test only for functionality assuming performance and load balance are handled well. This becomes my 5th assumption.

Master Test Strategy 1. Test for functionality of Digg Reader (DR) on all major browsers and release candidates. 2. Study the problems that can arise with the technology being used. Look for the compatibility problem which blocks the product on a browser. 3. Test for the API's integrated with Digg Reader (DR). Ex: Twitter, FB, Google. 4. Basic tests for fundamental functionality. 5. Identify the actions which can be automated. Build simple scripts to test the front end operations. 6. Test for the features released into web version. 7. Identify what is critical for stakeholder and business. Evaluate it with this strategy and refine the approach of testing based on context needs. Keep the session notes maintained.

Logistic: Tester: 1 Browser: IE 7,8,9,10; FF Nightly, Aurora, Release Build; Chrome: Nightly, Release Build; Safari Release Build; Opera Release Build. OS: Windows 2007, Windows 8, Mac 10.7, Linux Distributions. Duration: 1 week [ 10 hrs per day] end of test plan

Coverage Identification of product environment. Identification of priority features being released. Identification of test environment details. Identifying the initial Master Test Strategy Identification of risks what the product is trying to know.

Session Conclusion I focused on learning the product's current context and what they are trying to achieve by solving what kind of problems. For studying what kind of problems and benefits user gets for using this product, I brought an initial draft of Master Test Strategy. The test strategy will evolve and undergoes changes for making the testing valuable as testing progresses. I have accomplished the mission of this session.

** End ** --