My Mistakes as a Software Tester

Topic sounds like everyday term rite:)..yes it is a daily term..everyday we go on learning new things which makes us differentiate between the fact and conception/idea we have in mind about any particular thing...Few days back i attended a training session where some points regarding automation testing were discussed which actually drove me to write this blog..bcz i cud very well relate to the misconception and the mistakes i did when i joined the software testing industry....
So i would jot down those points for the people like me who dont have much idea of handling things or are new to this industry:)....
1.When i was a fresher i was more keen on learning new things and proving my talent rather than understanding the business perspectives ..Now when i have grown as an individual both personally and intellectually i realize how wrong i was?...Any development or testing is all about adding a business value..Its all about stepping into end user shoes and seeing is it all worth?.....Is it usable?...should i pay for it?....Is automation necessary?...etc....
2.Second mistake which i did was trying to push hard my point thinking it was right,nd feeling disheartened on its nonapproval which forced me to think that nobody understands me and bla bla....actually i have ran into lot of arguments failing to understand the other person views who also may be right from his/her perspective.....So analyze that..
3.One major drawback with me was i was never open to discuss my views and thoughts with my manager or lead which made the situation even worse....
4.Lastly the most major blunder which u can say was handling things on emotional level rather than from business perspective...I lacked what is called crucial conversation which i feel was most imp thing to be done at that moment..though later on this conversation helped me to clear out the misunderstanding and issues but no doubt i was absolutely wrong:(... Here i have put forth all those mistakes for people who are going through some situation like this.....

Now a year later when i think about all that i realize what a blunder i did...i mixed my personal emotions with my professional life....so pls dont do that it blocks ur rational thinking ...nd u run into trouble unnecessarily where finally its a lose-lose situations:(..nd also u lose ur mental peace and balance of life:(....Wishing u all a happy nd peaceful professional life:)

Microsoft Dynamics CRM Analytics Accelerator

Since i have been going through MSCRM accelerators in my free time...i thought of jotting down few important point of MSCRM Analytics accelerator which doesnt match up with the documentation provided by microsoft..I though it could be some help to guys who are going to explore it.. and for me also if i get answers to some of my questions:).. As the word "Analytics" itself makes it clear that its going to generate and display reports that can server your purpose...I found the reports display quite fundoo and cool but there are many things which left me perplexed ..I am going to jot down few important observation of mine ..and also need input from your end to help me configure it...
1. The Analytics was developed using VS2008 and ssr 2008...So though microsoft say the standard rdl provided them would work for both ssr2005 and ssr2008 but ideally it doesnt work in 2005 as many of the properties say like chartcategoryhierarchy are not supported in 2005
2. In Account Executive Dashboard if you notice it considers all the closed deals as won irrespective of the fact whether it is closed as Won or Lost..
3. Similarily if you see the grid displaying open opportunities doesn't fetch the open opportunities even though it exist.....If any one of you can tell me then it would be of great help:)

Extended Sales Forecasting Accelerator

With the thought of utilising my free time i was going through extended sales forecasting accelerator:)...Microsoft video and docs are more than enough to understand how to set it up and what it does..but i am here just penning down few important points to cover it in brief..Installing Extended Sales forecasting accelerator includes following customizations,report and settings
1.Goal and Goal Audit Entity
2.Extended Sales Forecasting Sales Manager And Extended Sales Forecasting SalesPerson security roles
3.MSA-Extended Sales Forecasting: Salesperson Goal Sign-Off,MSA-ExtendedSalesForecasting: Goal Audit Log,MSA-ExtendedSalesForecasting: Notify Goal Change,MSA-ExtendedSalesForecasting: Notify Salesperson of New Goal workflows
4.Two RDLs to be uploaded MSA Goals – Matrix.RDL,MSA Goals – Graph.RDL
To get the setup files and more information on its Installation and setup please go through the link http://www.codeplex.com/crmaccelerators/Release/ProjectReleases.aspx?ReleaseId=18959
Extended Sales forecasting accelerator basically enables the sales department to set goals and tracks the sales performance against them..in graphical or matrix report form....which has further drill down facility to enable viewing the information in more details...In this basically u can set a goal for say VP of Sales and then create subgoal under it for sales manager reporting to VP of Sales.Now the subgoals for VP of sales becomes the goals for sales person.Similarily u can create subgoal for sales person reporting to the sales manager under corresponding Sales manager...When an opportunity is won or cancelled the report would put show the goals versus actual in graph and matrix format...Worflows would send notifications on creation of new sales goals as well on change to existing sales goals....The person receiving the notification can mark it as completed or cancelled depending on whether he accepts the assigned goal or he wants it to be revised.....For more details u can go through the functional overview video as present in the link....Please feel free to get back to me if u need further details on this....

Accessing IFD URL from outside the Server Machine

IFD environment..sounds familiar rite..but it really creates panic when it comes to its installation...a whole list of steps and bla bla...Thanks to microsoft for the IFD tool which really has made IFD installation really cool:)...
So now to get an IFD Environment up and running,u just need to install MSCRM4.0 like a normal on-premise MSCRM and then run the tool..Some dns setting needed ofcourse like adding an alias...and adding an alias or host for each organization in case of multiorg scenarios..In this blog basically i would just tell the setting for accessing your MSCRM4.0 through URL from ur base machine or anywhere outside the main server machine..For that just you need to follow following steps:

1.Go to C:\WINDOWS\system32\drivers\etc
2.Open the hosts file in a notepad
2.Add the key : [IpAddress] [OrgName].[DomainName]

But be very careful guys while you manipulate it because a wrong entry may screw up your machine...
So guys ready to use IFD ....:)

Scrum Overview of Agile

I have been fortunate enough to work with a team where Scrum methodology of Agile was followed religiously...Thanks to my 1st Project:)..Since Agile is too vast a topic to cover i would just cover in brief the phases starting from planning till acceptance....So the various phases which i would cover here are:-

1. Sprint planning
2. Scrum meeting
3. Development+Testing
4. Final acceptance
5. Retrospective

1.SPRINT PLANING MEETING:-In this phases the estimates for all the items scheduled to be covered in the sprint are estimated in Tshirt Sizes or in Story Points

2.SCRUM MEETING:-Everyday we used to have a scrum meeting where basically three point where discussed a.What was done yesterday?b.What we will do today?c.Hindrance if any?
The participant of this meeting will be developers,testers,leads considered as Pigs because they will actually be involved in the completion of work item..Others like managers,Customer etc are considered as Chickens..who can also be part of this meeting but they are not supposed to speak ..

3.DEVELOPMENT+TESTING:In Agile developers and testers go hand in hand.By the time devs are done with coding testers are supposed to be ready with test cases and then the phase of testing and bug fixing goes...Any task in not considered as complete till the QA marks it as closed...And its the responsibility of the dev to make sure his task is completed..

4.FINAL ACCEPTANCE:After the features or the fixed issues are closed it is being sent to the client for his final acceptance.The client tests it and gives his feedback on that...When the client gives a green signal then only the task is finally closed and marked as Accepted.Once it is accepted then only it is considered as successful completion of the iteration else it goes for Spill Over and gets added to Product Backlog

5. RESTROSPECTIVE:After end of every iteration or release there is an retrospective meeting where we discuss basically four points...a.What went good?b.What went wrong?c.Things that can be improved?d.Appreciation - Dont forget its required to boost the moral of your team..Helps a lot and makes people feel important...Nd guys nyways it doesn't cost your pocket so why to be miser in this;)...

Many of the terminology which i have used marked in bold may sound new to you..but if i cover all these in details then trust me you will feel bugged..So you can get back to me for any questions you have and i think i should be able to answer it......I love Agile and I think once you follow even you would love it:)..just try it out....

Microsoft Dynamics Sure Step Methodology

Some days back i got this tool from one of my colleagues and i was going through it....Microsoft Dynamic Sure Step Methodology...i would call it MDSSM here after to avoid typing such a long name:)....MDSSM is an official software process provided by Microsoft which would help you to manage all types of Microsoft Dynamics Projects like MSCRM,Axapta,GP,Navision etc. by defining "WHO shall do WHAT in WHICH ORDER and who is RESPONSIBLE for what".

The different phases of this tool consists of following Phases: Diagnostic,Analysis,Design,Develop,Deploy and Operate.
Corresponding to each phase there are set of documents which needs to be updated by the roles responsible for it.Clicking on a phase,filters out the documents pertaining to it....

But if there are a group of related activities spanning multiple implementation phases then it would be called as cross phase.Cross phase can be divided into three area Organization(Includes Program Management,Training and Business Process Analysis),Solution(Includes Requirement and Configuration,Custom Coding and Quality Testing) and Technology(Includes Infrastructure,Integration and Interfaces and Data Migration).

MDSSM offers five project types i.e.,Standard,Enterprise,Rapid,Major Upgrade and Rapid Upgrade.Depending on the project type selected in the tool your documents section would get updated with the docs related to it......The projects types are detailed below...
-Standard is an approach for implementing Microsoft Dynamics solutions at a single site
-Enterprise is for implementing Microsoft Dynamics solutions in a global/multi-site organization wherein country/site specific unique business needs have to be factored on top of a core solution
-Rapid for implementing with minimal or no customizations
-Major upgrade for factoring additional requirements to the existing Microsoft Dynamic Solutions.
-Rapid Upgrade is an accelerated approach for taking an existing Microsoft Dynamics™ solution to a subsequent release of that solution with minimal or no new requirement.

I didnt find the above tool much usable for my projects but thought of penning down some basic stuff bout it so that it may be of some help to you incase you are planning to go for it.........;)

Highly Effective Seven Habits

Recently i was going through some tools for Managing Software Development Life Cycles when i came across the above article.This article describes the basic seven habits applicable for any role........

1.Be Proactive - Putting the phrase "prevention is better than cure" in software terms "Be Proactive rather than being Reactive".when things are good we always wana take the credit but when things go wrong we look for a person who would take the responsibility for things going wrong.....So instead of finding fault and blaming others when things are not falling in place we can take some preventive measures like getting more clarity on requirements and implementation details,Planning how to move ahead with the project schedule keeping in mind the resources,time,risk factors etc.

2.Begin with the End in Mind - Always define the exit criteria beforehand for a successful release so that you can use it to weigh your deliverable.

3.Put First Things First - Priortize things and define beforehand the alternative path to be taken incase of time,resource or risk constraints so that you know before hand the precedence in which the plan is to be executed when things go wrong

4.Think Win/Win - Always think in the perspective where all the members of the team including the customers are happy about the Software development and Release as we all like HAPPY ENDING;)..

5.Seek First to Understand, Then to be Understood - Many of us have the habit of thinking our own ideas,perspective and thoughts as the best one but it may not be true always.So to come out with the best solution its good to let everybody speak their own views and ideas and then finalize on the most applicable and accepted by all approach.

6.Synergize - Analyze the strength,perspective,experiences of your team members so that you can make the maximum use of the resource to the fullest within the limited time

7.Sharpen the Saw - For continous improvement it is a hard and fast rule to continue honing our skills and learn new techniques, best practices and approaches.Also it is required to survive in software industry:) for whatever reason:D...
Also i would like to mentioned here that sharing knowledge is as much necessary as gaining knowledge.Believe me it saves time and effort:)

We all are aware of the above points but its sad that when it comes to implementing it practically we fail to do so:(.....But lets try our best to follow it religiously for a better SDLC where we(Team and customer) all can be happy.Lets think as "US" rather than "I" and "YOU":)............WISHING U ALL A HAPY ENDING ALWAYS:D..........

Characteristics of a Good Test Framework

Some days back i was analyzing different tools which would help me to automate my tests.Keeping in mind the features which different tools provide and the constraints we had,it was decided to extend some existing free source automation tool to serve our purpose.So i prepared a list of features which i would expect from a test framework.....

The points are mentioned below for your reference.If i have missed some point then please feel free to add to this list:)

1.Should be able to handle controls like lookups,dialog handlers,alerts etc
2.Should be browser(IE6,IE7,mozilla etc) compatible
3.Flexible enough to bring control to parent or child windows
4.Should keep track of results
5.All the control names should be stored in xml or config file or excel file whichever is best suited
6.Should accept input from xls or some other source externally(No need to go ahead and put input parameters in code)
7.Should have generic method to identify controls
8.Should not affect the performance of the application to great extent
9.Should be able to handle exception rather than failing abruptly
10.Should be able to identify controls and look for it depending upon its type e.g.,Identifies a picklist control and searches for control only of picklist type

The above list includes a basic set of features and is common both for website or any specific domain e.g., MSCRM....

Website Requirement Gathering Checklist

Website has become an important part in todays world whether its for online shopping,Booking Tickets,Registering yourself etc.
And we all know that first impression is the last impression same is applicable for your website as well.So here i am jotting down some points which a developer should take care while development and QA should take care while testing...

GENERAL

-Application developed should meet the requirement
-It should return correct result on perform of a action
-It should incorporate all the features and the functions expected
-Application should be easy to learn and use
-Application built should be responsive, helpful, accurate
-It should be accurate and trustworthy
-It should be easy to modify
-Introducing new features should not break the old functionalities
-Application developed should be in compliance with coding standards
-Code should be reusable
-System should be quickly and easily installed on a variety of platforms by a variety of users
-Information should be easily retrievable

USABILITY,INTERFACE AND NAVIGATION

-It should support concurrent users
-Response time should be less
-Instruction for the use of website should be properly documented
-Terminology used should be understandable for all of the site’s intended users
-Navigation bar should be present on every screen and its position should be fixed
-Navigation through text or without mouse should be allowed(depending on requirement)
-Tabbing should work consistently, in a uniform mannerThere should be a link to home on every single page
-Page layout should be consistent across pages
-Images used should add value to page and should not take much of bandwidth
-If Graphics are used then it should make most efficient use of file size
-If the text occupies more space then provided then it should wrap properly
-All referenced web sites or email addresses should be hyperlinked
-Hyperlinks should follow coloring standards
-Site should look the same on different resolutions
-Font should not be too small or too large to read
-Text and messages should be properly aligned
-Printing of page should show all the contents properly as shown in the screen
-All hyperlinks should work(It should not be broken or lead to orphan pages)
-Navigating Back or Forward or postback should not open a new page and should display the desired content
-Desired location should be reachable with 3 or less clicks from the Home Page
-Layout of Form or Table should be correct
-There should not be any broken links or orphan pages
-Contact information for the site owner should be readily visible and available(name, telephone number, email address, mailing address, fax number)
-Bookmarking a page should mark the page with a meaningful name
-Site’s Web address should appear in the History list if the user allows for historical page(depending on requirement)
-Status bar on each Web page should accurately reflect the progress of page loading, information, etc.
-All the pages should have a title
-All the control should have unique id

TABLES

-It should not require much of scrolling
-Printout of table should appear correctly
-Columns should be wide enough so that text doesn’t have to wrap up in every column

FRAMES

-Website should handle browser which do not support frames
-Frames should get resized automatically and appropriately
-Scrollbar should appear if required
-Search engine should be able to find content within the frames(depending on requirement)
-Frame borders should look right
-Refreshing of Frames should not create problems

DATA VERIFICATION

-Privacy Policy should be clearly defined and available for user access
-Stored data accuracy should be sustained
-Data should be verified at workstation, server
-Data entered by the user on the workstation is should yield the right information on the server
-Entering the same information multiple times should be prevented (order forms, free samples, etc.)
-Unique identifier should be assigned to each user entering form data
-Data that is requested of the user should be essential to the process for which it is requested. For example do you need a user’s date of birth in order to process his book order or are you are simply asking for too much user information?
-Numeric fields should not allow text
-User should be able to use wildcard for searches
-Spaces and blank values should not be allowed in fields which are required
-System should accept long string wherever required
-Fields for entering text should have a maximum limit defined
-Initial values of checkboxes and radio buttons should be set depending on requirement
-User should be able to select only one radio button in a group
-Checkboxes should trigger the desired event
-Users should be prevented from entering HTML code in form fields
-Intelligent error handling should be built into your data verification.i.e.,. If Date of Birth is a required field MM/DD/YYYY, it is unlikely that the person entering the data was born in 1857.

EXTERNAL INTERFACES

-System should interface correctly with related external systems
-All supported browsers should be tested
-All error conditions related to external interfaces should be tested when external application is unavailable or server inaccessible
-All external applications that may be launched from within the Web site should be tested

INTERNAL INTERFACES

-Website should support users who cannot perform downloads
-Website should work with firewalls(depending on requirement)
-If the site uses plug-ins, site should be usable even without it. And also it should support plug-in at various modems and PC speeds and browsers
-All versions of plug-ins work together
-All linked documents should be supported/opened on all platforms (i.e. can Microsoft Word be opened on Solaris)
-Site should not lose usability, if Java is not enabled
-Failures should be handled if there are errors in download
-Download of Signed ActiveX Controls and Unsigned ActiveX Controls should be possible depending on requirement
-Initializing and scripting ActiveX controls should be marked as safe depending on requirement
-Can you Script ActiveX controls marked safe for scripting
-Solution should work fine even after cookies is disabled
-Solution should support users across multiple sites/domains
-Copy/paste functionality should be enabled or disabled depending on type of page
-Unencrypted form data should be submitted if it is designed so
-Site should allow paste operations via scripts depending on requirement

BROWSERS – IE, Netscape, AOL, Mac, etc.

-HTML version being used should be compatible with appropriate browser versions
-Java Code/Scripts should be usable by the browsers under test
-Images should get displayed correctly with browsers under test
-Security Settings/Risks should be checked as they relate to each browser
-Digital certificates should be verified across multiple browsers
-Plug-ins should work with the browsers in which testing is performed in the site
-Source code should not be viewable to all users
-Printing site’s content should show same content and format across different browsers
-Content Size on Infrastructure should not have much impact(reliability, consistency)
-Color codes – visual presentation should remain same across browsers
-Mouse vs. Key Strokes should be tested within various browsers
-Disabling of cookies, ActiveX control should be handled properly
-Animated GIFs should be tested across browsers

COOKIES

-Information stored in cookies should be verified
-Cookie information should be encrypted
-Cooking information should get incremented properly
-Cookies should not be editable for the users
-Site functionality should work the same after deletion of cookies
-Cookie information should be correct and valid for the user accessing the site

LOAD/CONCURRENT USAGE

-System should meet its goals for response time, throughput, and availability
-System should be able to handle extreme or stressful loads
-System should be able to continue operating correctly over time without failure
-System should operate in the same way across different computer and network
-configurations, platforms and environments, with different mixes of other applications
-Monitoring of CPU usage, response time, disk space, memory utilization and leaks should be done
-Standards should be defined for response time (i.e. all screens should paint within 10seconds)?
-Firewall, Certificate, Service Provider and Customer Network impact should be verified
-Page loading performance should be acceptable over modems of different speed
-Site should be able to sustain long periods of continuous usage by 1 user or multiple users or short period at high volume
-Site should be able to sustain large transactions without crashing
-Site should allow large orders without locking out inventory if the transaction is invalid

ERROR HANDLING

-Automatic error detection and recovery mechanisms should be built in to try to keep the system operating
-In case of system crash, re-start and recovery mechanisms should be efficient and reliable
-Leaving of the site in the middle of a task should be cancelled or continued depending on requirement
-On losing Internet connection transactions should get cancelled
-Interruptions in file transfer should be handled
-Browser crashes should be handled
-Network failures between Web site and application servers should be handled as desired
-When database server is inaccessible it should not allow operations like retrieval or updating of data into database
-Application should notify the user of transaction status
-Site should include 24 x 7 monitoring of performance
-Email protocol/limitations of monitoring software – MAPI
-Timing – continual, hourly, daily, weekly
-Hardware limitations – does the monitoring software have to run on a dedicated
machine?
-Memory – leaks, cache, issues of resulting from continual running

Network Impacts

-Have you considered 32-bit vs. 64-bit versions of IP?
-Have you tested the impact of Secure Proxy Server?

SECURITY

-System should be Confidentiality/user privacy protected
-Site should perform authentication if required and should ask for username and password at desired pages
-Digital Certificates should be present both at server and client depending on requirement
-If encryption is done then we should verify where the encryption begins and ends
-Concurrent log-on should be permitted depending on requirement
-Time-outs due to inactivity should be handled
-Bookmarking should disabled on secure pages depending on requirement
-Key/lock display on status bar should be displayed for secure pages
-Right Click, View Source should be disabled for secure pages
-Doing direct searches by editing content in the URL should not be allowed if it requires authentication
-While using Digital Certificates, test the browser Cache by enrolling for the Certificate and completing all of the required security information. After completing the application and installation of the certificate, try using the '<--' Backspace key to see if that security information is still residing in Cache. If it is, then any user could walk up to the PC and access highly sensitive Digital Certificate security information.
-Users should know when they are entering or leaving secure portions of your site
-Server should lock out an individual who has tried to access your site multiple times with Invalid login/password information



Hope this post helps you to make your website better:)...

Test Case Writing Best Practices

Recently I gave training on Test Case Writing Best Practices - somewhat surprising rite:)even i feel the same but i did it:D................
Anyways just thought of penning down the discussed points which was useful for me as well...
As a tester i felt these are the some of the most important points to be taken care before you go ahead with writing test cases or implementation..

Details Required Before Writing Test Cases

-Read Specification and Requirements Carefully
-Be clear with the design and the implementation details
-Analyze and Identify all possible scenarios
-Identify the test environments and test types
-Should have detailed information related and affected areas of the requirement
-Should be clear of behavior under failure condition(invalid input, boundary values etc)

Improving Testability (Easy to Test)- Language

-Use Active Case say Do This, Do That
-System Display this, Do That
-Simple Conversational Language
-Exact, consistent names of fields, not generic
-Don’t explain windows basics
-10-15 steps or less. In case of integration test cases try to provide references instead of explaining the functionality again and again
-Always update your test case with the new build
-Follow Naming Convention – Naming Convention helps you to differentiate between function, control, dbname etc . It help in easy identification of different controls, functions, Labels , hyperlink etc.
Note: The naming conventions and practices may vary from project to project.

Naming Conventions

-The scenario/test case for different module should be mentioned in a single worksheet in a single file. The name of the excel file should be TypeofTesting_ModuleName
-Module names should be in Capitals and Bold
-Screen Names should be bold and have camel notation i.e., the first word in capital letters and rest all in small letters.
-All the objects like textbox, listbox,Checkbox,radio buttons etc should be in italics and bold
-The link names should be mentioned in Italics, bold and underline below the word e.g.,' Sign Out’ link should be mentioned as ‘Sign Out’
-Database table name should be in caps e.g.,Emp_Details table name should be EMP_DETAILS

Test Case Attributes

-Test Case Id – Must be Unique across the application
-Test case description - The test case description must be very brief
-Test Case Priority – Priority of the test case
-Test case Type – To identify the type of test case
-Precondition – what should be present in the system, before the test can be executed
-Assumption or Dependencies – (Helps to identify related code or functionalities and features)
-Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system
-Validation Input – step by step instructions on how to carry out the test
-Expected Result– How the system must react based on the test steps
-Actual Result – The actual output
-Post Conditions – State after the test case is executed
-Execution Result(Pass/Fail) – Your actual result based on expected and actual result
-Build Number – To keep track of results

General Guidelines

-Write test cases before implementation of requirement
-Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application.
-Follow a standard template for all test cases
-Use very simple English and general words
-Format followed( Alignment, Naming convention etc) by test cases should be uniform for the entire application
-All the scenario/Test Case should be easily understandable,clear and to the point
-Highlight important points by making text bold or assigning it a color or writing it in different font
-You may add sections to a group of test cases to make it more informative
-You may use double quotes for a particular display text
-Maintain the test cases in a flow so that execution order is maintained and time is saved. Whenever a new scenario/test case is been added between two existing one it should be named after the previous scenario/Test case Id with decimal places ie.,if we have added new scenario between ID ST-SA–BKG-0015,then new scenario ID will be ST-SA-BKG-0015.1
-Use bullet points for different steps
-Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not(Shortage of time etc)
-The prerequisite for the scenario/test case should be mentioned before the test case
-Use a mix of both ‘positive and negative’ tests
-Provide test data(if possible)
-Write in details SQL Queries(it will save time while executing)
-Add reference to bugs or requirement as per your needs
-Defect ID of a Scenario/TestCase should match the Defect ID submitted against the defect in Defect Tracking System
-Add some notes in case you want to convey additional information or explain the test case with example in case the scenario is not much clear
-You can use build number next to your result to keep a track of results or determining defect density

Note:Test case should be such that any person going to execute it or read it gets a clear picture of what needs to be done without needing any explanations


To conclude i would like to tell you that there is no hard and fast rule for writing a good test cases but there are some steps which if followed makes your test cases more readable and informative.........
I hope this post will help you in improving your test cases writing skills.........