Some Limitations of sharepoint online

1. My site

·         Mysite collection master page (root.master) cannot be edited using SharePoint Designer, it actually can be changed but the change is not supported by Microsoft and might cause the site to break. http://community.office365.com/en-us/forums/153/p/58396/213704.aspx#213704

·         Feature stapling is not supported as of yet as it is a Farm level feature??? Not sure if this is true but Microsoft do not seem to want to confirm or refute this. It is only available in dedicated online Implementations, not on multi tenancy.

·         It is possible to brand the My Site Host and Individual user My Sites with Custom Sandbox Solutions, but this is not supported by Microsoft. It is important to note that when a user provisions their My Site for the first time, it would take default branding based on the OOTB My Site template. The user must then upload Sandbox solutions to apply branding to their already created My Sites. Individual end-users can use SharePoint Designer to update branding on case by case basis as well. This should be avoided as it is not supported http://community.office365.com/en-us/forums/153/p/46010/223145.aspx

·         The Microsoft supported way is to use SharePoint Designer to make branding changes or accept the standard themes available. 

2. IIS Limitations

·         No access to web.config file or any other IIS changeable element. To   make changes    in IIS you need to have full access to SharePoint’s web site directory in IIS as well as the full SharePoint object model on the server. This level of access is not available in SharePoint Online. Currently the only ways around this are to use a client-side calls in JavaScript/ JQuery (ECMAScript) or Silverlight, or wrap it in an Azure-hosted WCF endpoint and call it using SharePoint Online’s Business Connectivity Services. 

3. Branding

·         Branding can be done directly via SharePoint Designer or packaged using a Visual Studio project. You start with an empty SharePoint project and add the relevant elements including a feature receiver to apply branding during a feature activated event and retract it during the feature deactivated event. http://msdn.microsoft.com/en-us/Office365TrainingCourse_8V_4

·         The master page of a public facing website cannot be changed using SharePoint Designer. Editing of the public website cannot be done using SPD either. All customisations must be done using the site designer tool.

·         Master pages for SharePoint online are not set up for fixed width sites or layouts.

Tester Tested !: The negatives of "negative testing"

Tester Tested !: The negatives of "negative testing": Before you proceed reading this post, please take a piece of paper or a notepad and write down what you mean by "negative testing". Are you...

Tester Tested !: Your search for Bug Free Software ends here

Tester Tested !: Your search for Bug Free Software ends here: Test 2008 was a scintillating software testing conference. I never slept before 2 AM every night around the conference dates. I had great di...

Error Guessing

In software testing, error guessing is a test method in which test cases used to find bugs in programs are established based on experience in prior testing. The scope of test cases usually rely on the software tester involved, who uses past experience and intuition to determine what situations commonly cause software failure, or may cause errors to appear. Typical errors include divide by zero, null pointers, or invalid parameters.

Error guessing has no explicit rules for testing test cases can be designed depending on the situation, either drawing from functional documents or when an unexpected/undocumented error is found while testing operations.

Error Guessing is the ability to find errors or defects in the AUT by what appears to be intuition. In fact, testers who are effective at error guessing actually use a range of techniques, including:

* Knowledge about the AUT, such as the design method or implementation technology
* Knowledge of the results of any earlier testing phases (particularly important in Regression Testing)
* Experience of testing similar or related systems (and knowing where defects have arisen previously in those systems)
* Knowledge of typical implementation errors (such as division by zero errors)
* General testing rules of thumb of heuristics.

Error guessing is a skill that is well worth cultivating since it can make testing much more effective and efficient - two extremely important goals in the testing process. Typically, the skill of Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation: Either when reading the functional documents or when you are testing and find an error that you have not documented.

Importance and Consequences of bugs

IMPORTANCE OF BUGS: 

 The importance of bugs depends on frequency, correction cost, installation cost, and consequences.

1. Frequency: How often does that kind of bug occur? Pay more attention to the more frequent bug types.
2. Correction Cost: What does it cost to correct the bug after it is found? The cost is the sum of 2 factors: (1) the cost of discovery (2) the cost of correction. These costs go up dramatically later in the development cycle when the bug is discovered. Correction cost also depends on system size.
3. Installation Cost: Installation cost depends on the number of installations: small for a single user program but more for distributed systems. Fixing one bug and distributing the fix could exceed the entire system's development cost.
4. Consequences: What are the consequences of the bug? Bug consequences can range from mild to catastrophic.

A reasonable metric for bug importance is

Importance= ($) = Frequence * (Correction cost + Installation cost + Consequential cost)

• CONSEQUENCES OF BUGS: The consequences of a bug can be measure in terms of human rather than machine. Some consequences of a bug on a scale of one to ten are:
  1. Mild: The symptoms of the bug offend us aesthetically (gently); a misspelled output or a misaligned printout.
  2. Moderate: Outputs are misleading or redundant. The bug impacts the system's performance.
  3. Annoying: The system's behaviour because of the bug is dehumanizing. E.g. Names are truncated orarbitarily modified.
  4. Disturbing: It refuses to handle legitimate (authorized / legal) transactions. The ATM wont give you money. My credit card is declared invalid.
  5. Serious: It loses track of its transactions. Not just the transaction itself but the fact that the transaction occurred. Accountability is lost.
  6. Very Serious: The bug causes the system to do the wrong transactions. Instead of losing your paycheck, the system credits it to another account or converts deposits to withdrawals.
  7. Extreme: The problems aren't limited to a few users or to few transaction types. They are frequent and arbitrary instead of sporadic infrequent) or for unusual cases.
  8. Intolerable: Long term unrecoverable corruption of the database occurs and the corruption is not easily discovered. Serious consideration is given to shutting the system down.
  9. Catastrophic: The decision to shut down is taken out of our hands because the system fails.
  10. Infectious: What can be worse than a failed system? One that corrupt other systems even though it doesnot fall in itself ; that erodes the social physical environment; that melts nuclear reactors and starts war.

"Cannot connect to Configuration database " error in sharepoint 2010

This behavior occurs if one of the following conditions is true:

• The SQL database is not running.
• Internet Information Services (IIS) is configured to run in IIS 5.0 isolation mode.
• The account that is used by application pool does not have the required permissions to the SQL Server database.
• Network connectivity has been lost between the Windows SharePoint Services server and the Microsoft SQL Server server.

Method 1: Verify that the SQL database is running

1. Click Start, point to Programs, point to Administrative Tools, and then click Services.
2. In the list of services, locate the MSSQLSERVER service. This service may also be listed as MSSQL$SHAREPOINT.
3. Note the value of the Status column. If the Status column lists Started, the database server is running. If the Status column is empty, the database server is not running.
   
   To start the database server, right-click the MSSQLSERVER service, and then click Start.

Method 2: Verify that IIS is not running in IIS 5.0 isolation mode

1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. In the left pane, right-click your server name, and then expand the local computer.
3. Right click Web Sites, and then click Properties.
4. Click the Service tab.
5. Click to clear the Run WWW service in IIS 5.0 isolation mode check box.
6. Click OK
7. To start the WWW service, click Yes.

Method 3: Make sure that the account that is used by the application pool is the account that has the required permissions to the SQL Server database

First, you must first determine the application pool identity. To do this, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. Double-click the Web Sites folder.
3. Right-click the virtual server that is running Windows SharePoint Services 2.0, and then click Properties.
4. Click Home Directory.
5. Note the information that is in the Application name box (this is the application pool name), and then click Cancel.
6. In the left pane, right-click Application Pools, and then click Properties.
7. Click the Identity tab.
8. Note the information that is in the Application pool identitypane, and then click Cancel.

Next, you must verify that this account has the required permission the SQL Server database. To do this, follow these steps:

1. Click Start, point to Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
2. In the left pane, double-click Microsoft SQL Servers, and then double-click your SQL server group.
3. Double-click your server.
4. Double-click Security.
5. In the left pane, click Logins.
6. In the right pane, double-click the user who you noted step 8 of the previous procedure.
7. In the SQL Server Login Properties dialog box, click Server Roles.
8. Click to select both the Security Administrators and the Database Creators check boxes, and then click Database Access.
9. Under the Permit column, click to select the Windows SharePoint Services database.
10. Click OK.

Method 4: Make sure that you have network connectivity and correct name resolution between the servers

To do this, follow these steps:

1. Verify that the Windows SharePoint Services server is using the correct IP address for the SQL server. To do this, run the ping command on the Windows SharePoint Services server.
2. Verify that the Windows SharePoint Services server is obtaining the correct IP address for the SQL server from DNS. To do this, run the nslookup command from the Windows SharePoint Services server.
3. Make sure that there are no incorrect entries for the SQL server. To do this, examine the Hosts file on the Windows SharePoint Services server. This file is in the following location:
   %systemroot%\system32\drivers\etc\Hosts
4. On the Windows SharePoint Services server, look for SQL client aliases. To do this, follow these steps:
   1. Click Start, click Run, and then type cliconfg in the Open box.
   2. Click the Alias tab.
   By default, there are no SQL client aliases. If you have any aliases for the SQL server, verify that they are correct, or remove them.

Selenium

Introduction: 

Selenium is a suite of tools for browser automation. It is composed of 
"IDE", a recording and playback mechanism, "WebDriver" and Remote 
Control "RC" which provide APIs for browser automation in a wide variety
 of languages, and "Grid", which allows many tests using the APIs to be 
run in parallel. QA Tester should not forget to mention during interview
 that with the release of Selenium 2, Selenium RC has been officially 
deprecated in favor of Selenium WebDriver. It works with most browsers, 
including Firefox from 3.0 up to 8, Internet Explorer 8, Google Chrome, 
Safari and Opera 11.5.

 Selenium could be used for the functional, regression, load testing of 
the web based applications. 

 Advantages & Features of Selenium 

1.Intelligent field selection will use IDs, names, or XPath as needed 
2. It is a record & playback tool and the script format can be written in
various languages including : C#, Java, PERL, Python, PHP, HTML 
3. Auto complete for all common Selenium commands 
4. Debug and set breakpoints 
5. Option to automatically assert the title of every page 
6. Support for Selenium user-extensions.js file

Selenium Limitations 

 Selenium IDE has many great features and is a fruitful and 
well-organized test automation tool for developing test cases, in the 
same time Selenium IDE is missing certain vital features of a testing 
tool: conditional statements, loops, logging functionality, exception 
handling, reporting functionality, database testing, re-execution of 
failed tests and screenshots taking capability. Selenium IDE doesn't for
 IE, Safari and Opera browsers.  

Why Testing is Recommended During Design Phase?

Testing during the design phase can prevent defects later on. I recommend we verify three things...  

1.Verify the design is good,efficient,compact,Testable and Maintainable.

 2.Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module). 

3.Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product

Tester Tested !: Why good software testers should come out of the w...

Tester Tested !: Why good software testers should come out of the w...: One problem that I constantly spot whenever I meet a good tester in India - they don't blog and publicly write or speak. That''s why some p...

12 Practical Tips for Building Bug Free Software

1. Code Reviews

Four eyes see more than two. That’s why you should let other developers review your source code on a regular basis. Pair programming on the other hand, a technique where two developers write code together for longer periods, isn’t for everyone and is often not needed. But complicated, important or security related code greatly benefits from code reviews and will improve your code quality a lot.

2. Beta Tests

Beta tests play an important role with keeping your software’s quality high. But most times, it doesn’t make sense to release beta versions of your software for minor updates. Major releases on the other hand, should be tested by end-users and customers before going gold. You can test your software as much as you want, if you cannot control the execution environment, the chance is high that end-users will find bugs and problems with all the different computer configurations out there. Also make sure that your software reached a high quality standard before giving it to beta testers. You don’t want to waste the testers’ time by letting them find and report bugs that you already know about.

3. Automated Tests

Automated tests like unit tests or automated GUI tests can be used to guarantee the functionality of application modules, application programming interfaces (APIs) and user interfaces. You don’t have to be a test-driven development wizard to make good use of automated tests. Using unit tests for key parts of your application can go a long way towards building more reliable software. There are tons of unit testing frameworks, web and GUI testing tools out there that you can utilize.

4. Logging

Using log files or live logging during development and production usage is an important and useful technique to identify bugs, find concurrency problems and to analyze and find out why an application crashed. Advanced logging tools are also able to log complete objects, trace threads and distributed systems and offer rich viewer tools to monitor your application. Instead of writing your own basic logging framework, you should use proven and advanced libraries and tools. Many open-source and even some commercial offerings have been released over the years, including our own .NET, Java and Delphi logging tool SmartInspect.

5. Error Reporting

To find and resolve errors and exceptions, you first have to know what kind of errors your users and customers are experiencing. Many users of trial software won’t get in touch with you to report any errors. Instead, they will just uninstall your application and test a competing product. To make error reporting for end-users easier and more useful to you, you should use automated error and exception reporting techniques. When an unhandled exception occurs, your application should show a friendly dialog offering the user to send an error report back to the developer. Error reports should contain all kind of information to help you identify the problem, including error messages, call stacks, version numbers and log files.

6. Customer Feedback

Similar to error reporting, you should make giving feedback as easy as possible for your users and customers. In SmartInspect, for example, we have buttons in the menu and toolbars to send feedback and questions. You can also use a short (optional) survey when a user uninstalls your application. This survey should only have a few questions and besides other things ask why the user uninstalled your software. If a lot of users report that they uninstalled your software because of stability problems, you will know that your application isn’t as high-quality as you have thought.

7. Use Proven Code

You should build the core functionality and main features of your applications yourself, because only then are you able to easily and quickly modify and improve it. But for many other parts you can reuse existing and proven code. It will take you years to build a stable, easy-to-use and feature complete reporting engine or setup builder, for example. Often times it’s better to use proven existing code, either from internal libraries, third-party companies or open source solutions if the license permits this.

8. Dedicated Testers

If possible, you should have dedicated testers in your organization for quality assurance. In fact, you should have lots of them. For simple standard applications, one tester per developer is a good rule of thumb. For applications that are complicated and time-consuming to test, two or more testers per developer are needed. Many small organizations cannot afford dedicated testers. If this is the case, developers should test each others’ code. It’s important that others test your code and functionality, because general wisdom says that developers do a really bad job testing software that they wrote themselves.

9. Virtual Machines

To test your software on as many different environments and operating systems as possible, you should use virtual machines with tools like VMware, Virtual PC or other available virtualization software. Besides allowing you to test your software on all kinds of configurations, you will save tons of time because you can easily copy, share and reset the virtual machines. It’s a good idea to create many different standard images for all the operating systems you regular test on and put them on a file server. When you need a specific configuration to test something, you can then start with one of your base images without installing the operating system, drivers and required software and so on.

10. Write a Specification

Many bugs are caused by badly designed class hierarchies, inaccurate interfaces, wrongly understood requirements and the therefore required workarounds. That’s why an experienced developer or architect should write a specification with all the collected requirements and technical implementation details before writing the first line of code. But as always, requirements change during the lifetime of a software application. That’s why it’s important to keep the specification up-to-date and plan the architecture changes for any new or altered requirements.

11. Use a Good Debugger

If you use an IDE like Visual Studio, Eclipse or Delphi, you already have access to a powerful debugger that you should use. But with many development environments and development platforms like PHP, Windows Scripting, Python and Ruby, many developers aren’t using a debugger. In those scripting environments, developers often try to squish bugs by try and error, changing code parts, adding a few print statements and so on. This is not only a very cumbersome and time-consuming way of identifying and solving bugs, it’s also very dangerous if you don’t fully understand your code and are able to step through it with a debugger. Do yourself a favor and get a good debugger for your development platform (and there are debuggers for almost everything).

12. Debug and Strict Options

Many development environments allow you to enable special debugging options like range checking, overflow checking and memory corruption checking. Such options should be enabled during development and sometimes even during quality assurance to identify hard to find bugs. Many script languages like Perl or PHP on the other hand allow you to enable certain rules and warnings that will force you to declare variables before using them. This is especially useful if a script language is case-sensitive and it’s easy to make typos.

As I already said, these tips won’t make your software magically bug-free, but they allow you to make your software much more stable, reliable and usable if you put the work into it. And on top of it, it will make you a better developer, too.

Gray Box Testing

Gray Box Testing

It is just a combination of both Black box & white box testing.

It is platform independent and language independent.

Used to test embedded systems.

Functionality and behavioral parts are tested.

Tester should have the knowledge of both the internals and externals of the function.

If you know something about how the product works on the inside, you can test it better from the outside.

Gray box testing is especially important with Web and Internet applications, because the Internet is built around loosely integrated components that connect via relatively well-defined interfaces. Unless you understand the architecture of the Net, your testing will be skin deep.

SQL query to find the size of a database

SELECT DB_NAME(database_id) AS DatabaseName,
Name AS Logical_Name,
Physical_Name, (size*8)/1024 SizeMB
FROM sys.master_files
WHERE DB_NAME(database_id) = 'Sample'
GO

Here Sample is the name of the database.If you remove the WHERE condition you will find the result for all the databases.

Accessibility testing

Accessibility testing  for web sites is a service that can provide much more than the standard point-by-point testing techniques of most automated services.Accessibility testing is the technique of making sure that your product is accessibility compliant. There could be many reasons why your product needs to be accessibility compliant as stated above.

It provides a more detailed analysis of the content and layout of the page elements, yielding optimization procedures for a variety of circumstances that can be used during the development process of a site, site remodeling, or ongoing evaluation and monitoring of an existing site.

Typical accessibility problems can be classified into following four groups, each of them with different access difficulties and issues:

Visual impairments

Such as blindness, low or restricted vision, or color blindness. User with visual impairments uses assistive technology software that reads content loud. User with weak vision can also make text larger with browser setting or magnificent setting of operating system.

Motor skills

Such as the inability to use a keyboard or mouse, or to make fine movements.

Hearing impairments

Such as reduced or total loss of hearing

Cognitive abilities

Such as reading difficulties, dyslexia or memory loss.

Development team can make sure that their product is partially accessibility compliant by code inspection and Unit testing. Test team needs to certify that product is accessibility compliant during the functional testing phase. In most cases, accessibility checklist is used to certify the accessibility compliance. This checklist can have information on what should be tested, how it should be tested and status of product for different access related problems. 

For accessibility testing to succeed, test team should plan a separate cycle for accessibility testing. Management should make sure that test team have information on what to test and all the tools that they need to test accessibility are available to them.

Typical test cases for accessibility might look similar to the following examples -

• Make sure that all functions are available via keyboard only (do not use mouse)
• Make sure that information is visible when display setting is changed to High Contrast modes.
• Make sure that screen reading tools can read all the text available and every picture/Image have corresponding alternate text associated with it.
• Make sure that product defined keyboard actions do not affect accessibility keyboard shortcuts.

There are many tools in the market to assist you in your accessibility testing. Any single tool cannot certify that your product is accessibility compliant. You will always need more than one tool to check accessibility compliance of your product. Broadly, tools related to accessibility can be divided into two categories. Inspectors or web checkers

This category of tool allows developer or tester to know exactly what information is being provided to an assistive technology. For example, tools like Inspect Object can be used to get information on what all information is given to the assistive technology.

This category of tools is what a person with disability will use. To make sure that product is accessibility compliant, tools like screen readers, screen magnifiers etc. are used. Testing with an assistive technology has to be performed manually to understand how the AT will interact with the product and documentation. More information on the tools is present in tool section of this website for you to explore.

Some tips that can be used for Accessibility testing .

• When using a screen reader, be sure to include tests for everything the user would be doing, such as install and un-install of the product.
• If a function cannot be performed using an Assistive Technology, then it may be considered accessible if it has a command line interface to perform that function.

Most of the time on windows platform, accessibility is built in your product using Microsoft Active Accessibility (MSAA). You can get more information about MSAA on this page.