Wednesday, September 28, 2011

Risk and Different Categories of Risk

What is Risk?

Risk is future unreliable events with a likelihood of occurrence and a potential for loss”
Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work.
Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.

Categories of risks:

Schedule Risk:

Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
  • Wrong time estimation 
  •   Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
  •  Failure to identify complex functionalities and time required to develop those functionalities.
  •  Unexpected project scope expansions.

Budget Risk:

Budget Risk occur due to improper planning of Money
  •  Wrong budget estimation is the Main one in Budget Risk.
  • Cost overruns
  •   Project scope expansion

Operational Risks:

Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:
  •   Failure to address priority conflicts
  •   Failure to resolve the responsibilities
  •  Insufficient resources
  •   No proper subject training
  •   No resource planning
  •  No communication in team.

Technical risks:

Technical risks generally lead to failure of functionality and performance.
Causes of technical risks are:
  •  Continuous changing requirements
  • No advanced technology available or the existing technology is in initial stages.
  •  Product is complex to implement.
  •  Difficult project modules integration.

Programmatic Risks:


These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:

  •   Running out of fund.
  •  Market development
  •   Changing customer product strategy and priority
  •   Government rule changes.

Tuesday, September 27, 2011

Smoke Testing & Sanity Testing

SMOKE TESTING:
  • Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
  • A smoke test is scripted, either using a written set of tests or an automated test
  • A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide.
  • Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification).
  • Smoke testing is normal health check up to a build of an application before taking it to testing in depth.
SANITY TESTING:
  • A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
  • A sanity test is usually unscripted.
  • A Sanity test is used to determine a small section of the application is still working after a minor change.
  • Sanity testing is a cursory testing, it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.
  • Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

Friday, September 23, 2011

What is a Sharepoint?

Microsoft SharePoint is a web application platform developed by Microsoft. Launched in 2001, SharePoint is designed as a centralized replacement for multiple web applications and supports various combinations of enterprise website requirements. It is typically associated with web content management and document management systems.


 SharePoint's multi-purpose platform allows for managing and provisioning of intranet portals, extranets and websites, document management and file management, collaboration spaces, social networking tools, enterprise search, business intelligence tooling, process/information integration, and third-party developed solutions. SharePoint can also be used as a web application development platform.


SharePoint is capable of supporting multiple organizations on a single 'server farm'. Microsoft provides SharePoint Foundation at no cost but sells premium editions with additional functionality, and also provides SharePoint as a cloud computing solution as part of Microsoft's Business Productivity Online Standard Suite (BPOS) and Office 365. The product is also sold as a cloud solution by local third-party vendors. SharePoint provides various methods for customization and configuration of web areas, all of which have granular governance configurations. Beyond basic page-editing, file-storing and custom design ('branding') abilities, one of the more prevalent forms of configuration is the ability to install third-party customizations called 'web parts' (i.e. portlets/widgets/gadgets).


The most common uses of SharePoint include:
Intranet portal

A SharePoint intranet portal is a way to centralize access to enterprise information and applications on a corporate network. It is a tool that helps a company manage its data, applications, and information more easily. This has organizational benefits such as increased employee engagement, centralizing process management, reducing new staff on-boarding costs, and providing tacit knowledge capture. 


Enterprise content and document management


SharePoint is often used to store and track electronic documents or images of paper documents. It is usually also capable of keeping track of the different versions created by different users. In addition to being a platform for digital record management systems that meet government and industry compliance standards, SharePoint also provides the benefit of a central location for storing and working on documents, which can significantly reduce emails and duplicated work in an organization. 


Extranet sites

SharePoint can be used to provide password-protected, web-facing access to people outside an organization. Organizations often use functionality like this to integrate third parties into supply chains or business processes


Internet sites

Using the 'Publishing' feature, SharePoint can be used to manage larger public websites.

Core platform functionality

Sites

SharePoint 2010 Enterprise - 'Create Site' screen


A SharePoint Site is a collection of pages, lists, and libraries configured for the purpose of achieving an express goal. A site may contain sub-sites, and those sites may contain further sub-sites. Typically, sites need to be created from scratch, but sites can also be created according to pre-defined templates that provide packaged functionality. Examples of Site templates in SharePoint include: Blogs, MySites, collaboration (team) sites, document workspaces, groupwork sites, and meeting workspaces.
Sites have navigation, themes/branding, custom permissions, workflows, and have the ability to be configured or customized in a number of ways. In order to achieve a greater degree of maintainability, sites typically inherit site-level settings from their parent sites.

Lists & libraries

Lists and libraries are stored in SharePoint Sites. A List can be thought of as a collection of pieces of information — all of which (typically) have the same properties. For instance, you can have a list of links called "my links", where each item has a URL, a name, and a description.
Lists have many features such as workflows, item-level or list-level permission, version history tracking, multiple content-types, external data sources, and many more features. Some of these features depend on the version of SharePoint that is installed.


A Library is a list where each item in the list refers to a file that is stored in SharePoint. Libraries have all the same behaviors as lists, but because libraries contain files, they have extra features. One of these is the ability to be opened and modified through a compatible WebDAV client (e.g. Windows Explorer).
Microsoft SharePoint comes with some pre-defined list and library definitions. These include: Announcement Lists, Blogs, Contacts, Discussion Boards, Document Libraries, External Content (BCS) lists, Pages, Surveys, and Tasks.
Some of these pre-defined lists have additional integration. For example, lists based on the contact content-type can be synced directly with Microsoft Outlook.

Web-parts

Web-parts are sections that can be inserted into Pages in SharePoint sites. These sections are UI Widgets whose typical uses are
  • Displaying content defined in the web-part's settings (e.g. custom content or an iFrame)
  • Displaying items from Lists/Libraries (this can be customized in SharePoint Designer, using XSLT & CAML)
  • Providing Access to Features in the SharePoint platform (e.g. Search)
Web-parts based on completely custom code can be built in Microsoft Visual Studio 2010 and uploaded by end-users to SharePoint as packaged, sandboxed feature. Due to the prevalence of SharePoint, third-party vendors often provide SharePoint web-parts for intranet sites.
SharePoint Web-parts were formerly implemented separately from ASP.NET Web-parts, but as of SharePoint 2010, SharePoint's Web-parts are now based on it.

Pages

SharePoint has three primary page content-types: Wiki pages, Web-part pages, and Publishing Pages. Unlike prior versions of SharePoint, the default page type is a 'Wiki Page', which enables free-form editing based on the ribbon toolbar. It is possible to insert Web-parts into any page type.

Search

SharePoint Foundation contains a limited search engine. Microsoft produces a free product called Microsoft Search Server Express to complement SharePoint Foundation. Different SharePoint search versions offer different features, but all search engines contain the ability to search within documents and - except in cloud environments: across external data sources (such as file systems).


What is LoadRunner?

HP LoadRunner software is an automated performance and testing product from Hewlett-Packard for examining system behavior and performance, while generating actual load. HP LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc.)

Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, hundreds of ATMs may be open to the public. During peak times — such as 10 a.m. Monday, the start of the work week — the load may be much higher than normal. In order to test such situations, it is not practical to have a testbed of hundreds of ATMs. So, one can use an ATM simulator and a computer system with HP LoadRunner to simulate a large number of users accessing the server simultaneously. Once activities are defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.

HP LoadRunner consists of several different tools: Virtual User Generator (VuGen), Controller, Load Generator, Analysis and the AJAX TruClient

LoadRunner works by creating virtual users who take the place of real users operating client software, such as sending requests using the HTTP protocol to IIS or Apache web servers. Requests from many virtual user clients are generated by Load Generators in order to create a load on various servers under test.These load generator agents are started and stopped by Mercury's Controller program. The Controller controls load test runs based on Scenarios invoking compiled Scripts and associated Run-time Settings.

Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.

With Java clients, VuGen captures calls by hooking within the client JVM. During runs, the status of each machine is monitored by the Controller.
At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.

Each HTML report page generated by Analysis includes a link to results in a text file which Microsoft Excel can open to perform additional analysis.

Errors during each run are stored in a database file which can be read by Microsoft Access.

Tuesday, September 20, 2011

Developers are not good Testers.Why?

Developers testing their own code – what will be the testing output? All happy endings! Yes, the person who develops the code generally sees only happy paths of the product and don’t want to go in much details.
The main concern of developer testing is – misunderstanding of requirements. If requirements are misunderstood by developer then no matter at what depth developer test the application, he will never find the error. The first place where the bug gets introduced will remain till end, as developer will see it as functionality.
Confident developers – Developers wrote the code and they are assured it’s working properly. No need to test this path, no need to test that path, as they know it’s working properly. And right here developers skip the bugs.
Developer vs Tester: Developer always wants to see their code working properly. So they will test it to check if it’s working correctly. But you know why tester will test the application? To make it fail in any way, and tester surely will test how application is not working correctly. This is the main difference in testing done by developers and testers.
Should developers test their own Code?
I personally don’t mind developers testing their own code. After all it’s there baby .They know their code very well. They know what the traps in their codes are. Where it can fail, where to concentrate more, which is important path of the application. Developer can do unit testing very well and can effectively identify boundary cases.
This is all applicable to a developer who is a good tester! But most of the developers consider testing as painful job, even they know the system well, due to their sloppiness they tend to skip many testing paths, as it’s a very painful experience for them. If developers find any errors in their code in unit testing then it’s comparatively easier to fix, as the code is fresh to them, rather than getting the bug from testers after two-three days. But this only possible if the developer is interested in doing that much testing.
Its tester’s responsibility to make sure each and every path is tested or not. Testers should ideally give importance to all small possible details to verify application is not breaking anywhere.
Developers should not review their own code. Generally they will overlook the issues in their code. So give it to testers for review.
Everyone is having specialization in particular subject. Developers generally think how to develop the application on the other hand testers think how the end user is going to use the application.
Conclusion
Finally i like to say that there is no problem if developers are doing the basic unit testing and basic verification testing. Developers can test few exceptional conditions they know are critical and should not be missed. But there are some great testers out there. Through the build to test team. For victory of any project there should be independent testing team validating developer’s applications.

Thursday, September 15, 2011

Five Dimensions of the Risk


Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a schedule etc. could be deterrents to project delivery on time. Unstable communication link can be considered as a probable risk if testing is carried out from a remote location.
Client:
Ambiguous requirements definition, clarifications on issues not being readily available, frequent changes to the requirements etc. could cause chaos during project execution.
Human Resources
: Non-availability of sufficient resources with the skill level expected in the project are not available; Attrition of resources - Appropriate training schedules must be planned for resources to balance the knowledge level to be at par with resources quitting. Underestimating the training effort may have an impact in the project delivery.
System Resources
: Non-availability of /delay in procuring all critical computer resources either hardware and software tools or licenses for software will have an adverse impact.
Quality:
Compound factors like lack of resources along with a tight delivery schedule and frequent changes to requirements will have an impact on the quality of the product tested.

Tuesday, September 6, 2011

Query to find Name of the day


CREATE FUNCTION dbo.udf_DayOfWeek(@dtDate DATETIME)
RETURNS VARCHAR(10)
AS
BEGIN
DECLARE @rtDayofWeek VARCHAR(10)
SELECT @rtDayofWeek = CASE DATEPART(weekday,@dtDate)
WHEN 1 THEN 'Sunday'
WHEN 2 THEN 'Monday'
WHEN 3 THEN 'Tuesday'
WHEN 4 THEN 'Wednesday'
WHEN 5 THEN 'Thursday'
WHEN 6 THEN 'Friday'
WHEN 7 THEN 'Saturday'
END
RETURN (@rtDayofWeek)
END
GO

SELECT dbo.udf_DayOfWeek(GETDATE()) AS DayOfWeek