02 Nov

tCognition’s Project Execution Process

tCognition’s Project Execution Process

Project & Program Execution

tCognition delivers all of its Consulting & Professional services solutions following stringent guidelines and rules of client engagement in order to drive project or program success. As such, tCognition ensures that the following professional services and support provided hereunder are in accordance with the following guidelines unless otherwise discussed or negotiated with the Client Stakeholders.

Methodology

tCognition will follow an Agile/Scrum project management process that includes iterative feature development, continuous testing and quality control, weekly status meetings and daily stand-ups with full transparency in the project or program. Our technical background and consulting experience ensure that our customers get high-quality solutions delivered in an effective and efficient manner. Full life-cycle product development services, including project planning, business requirements definition, project implementation, and post-implementation support are provided using proven industry-standard methodologies and best practices.

Agile-Development

Change Control Management

tCognition recommends that every Application change requirement goes through an official change control management process. A Change Control Board (CCB) or Change Advisory Board (CAB) shall be constituted to include representation from the client stakeholders, infrastructure & operations team, change manager for the hosting environment, and tCognition lead. All change requests will be reviewed and discussed in periodic CAB meetings, and only approved change requests will be implemented in the production environment following proper, established procedures. Our resources are familiar with and will follow industry best practices such as ITIL framework while addressing change requests. Emergency changes will be processed through exception handling processes approved by the client. All changes will be tested and approved prior to production deployment.

Knowledge Transfer

All of our resources are coached to provide 100% comprehensive knowledge transfer to our customers on any task that we are involved. The tCognition team also builds several step-by-step training documents for all project areas. We provide these documents to our customers at no additional cost. Depending on client needs and preferences, Knowledge Transfer (KT) could be an ongoing process or a discrete phase of the project lifecycle. 

Contacts

Each of the Parties will provide detailed contact information for all key stakeholders or project managers necessary to interface with the other Party’s management and resources for technical and/or administrative issues, throughout the term or period of the engagement as identified Authorized Contacts.

Activity Disclosure

The Client will inform appropriate tCognition personnel of any delivery schedule changes, activities, or changed requirements that may impact the engagement. tCognition will not be held responsible for any issues or service loss resulting from tasks performed by the Client’s personnel or assigned parties on the contracted environments without prior written notification, and submission of a formal change order through the designated ticketing and tracking systems.

Connectivity

The Client will maintain all necessary connectivity into their systems or environments, providing the necessary security and VPN connectivity between their site(s) and the tCognition network. tCognition will maintain all necessary connectivity into its systems or environments to enable Client’s customers to communicate service issues to tCognition via phone, email and web portal, and to enable tCognition to access Client’s servers.

Monitoring

tCognition will utilize the Client’s monitoring system; as such, the Client will work with tCognition to provide all appropriate and necessary access, information, and training on Client’s monitoring systems. tCognition will also provide the Client with mutually agreed reporting based upon tCognition’s own metrics for measuring its performance hereunder.

Ticketing – Tracking

tCognition will utilize the Client’s ticketing system to track all requests; as such, the Client will work with tCognition to provide all appropriate and necessary access, information, and training on Client’s systems.

06 Jun

QA Testing in an Agile Environment

QA Testing in an Agile Environment

qa_agile_environmentAs a QA Testing Engineer, I have worked on different SDLC models (software development lifecycle models). One of the most recently introduced SDLC models are “Agile Methodologies”. Nowadays, being “agile” is considered more appropriate and is chosen more often over the traditional methods like “waterfall” models.

Creating an agile test environment has developed a cult following. Like most of the QA engineers here at tCognition, I subscribe to the “Agile Manifesto” (from agilemanifesto.org):

 

 

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

QA Testing with Agile Processes – “Sprinting”:

The agile process is followed in software development where requirements are changed frequently and there is need to show the working software at frequent intervals. This is where sprinting comes into play.

All the requirements together in a single project are called product backlogs. The backlogs are divided into multiple iterations, or “sprints”. A single sprint will undergo plan, design and development. Afterwards, the solution to these requirements are tested and reviewed.

A set of requirements that can be implemented independently or on top of the previous sprint work are taken and recorded in documents called user stories. Development is performed on the current sprint’s user story. A typical sprint span lasts about 2-4 weeks. Each sprint is followed by testing activities and any issues / bugs are fixed. After this testing the code is ready to be deployed.

There will be multiple sprints in any given project until all the requirements from the product backlog are covered and the project is completed end-to-end.

Tips on Creating an Agile “Environment”:

Key points to be remembered while working on a project that follows an Agile Framework:

  1. Purpose: Think about what this project is all about and what is needed to implement the solution.
  2. Teamwork is very important. Frequent interactions with your teammates are a must. Consider it like a bunch of mini or micro projects where a single project has to be delivered in a 2-4 week span.
  3. Active participation in all the scrum meetings and holding brainstorm sessions are essential.
  4. Each user story should be discussed and mapped by the QA team and all the requirement gaps should be found as early as possible.
  5. Give feedback: communication promotes agile methodologies.
  6. Testers should always keep an end-to-end approach in mind even though it is one sprint at a time!
  7. Test data preparation needs to be done well in advance. The following points should be considered:
    – What kind of test data is required?
    – Can the test data created be reused in current and future sprints?
  8. A few sprints should be allocated for regression testing and system testing at the end to make sure application is working fine end-to-end.