Tag: Software Development

What is Systems Development Life Cycle

The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. The systems development life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both.http://en.wikipedia.org/wiki/Systems_development_life_cycle

QA Involvement

It is imperative that QA or a representative of QA be present as early in the SDLC as possible. This will allow the QA member or team to begin their process. This includes, but is not limited to:

Resource Planning

Who the tester will be

What the tester will need

What existing test plans can be executed (to include automation)

Release Planning

Given past projects, what is the likelihood of meeting the proposed release date

Can smaller chunks of the User Story be passed to QA sooner

Deployment planning

Smoke tests should be executed on production environments

Resources for Managing SDLC

Gone are the days of being told there is something to test and reporting pass or fail w/ bugs via email or TPS reports. Many systems can be used in conjunction as well. There are benefits to using a mixture of separate systems, mainly cost, but a fragmented system can lead to a waste of man-hours from managing tasks. The big appeal of a unified system, aside from time savings, is tracking. In a application such as TFS or Atlassian, all User Stories, tasks, issues, and hours are logged in a central location.

A QA member can log into these systems to access the work assigned to them. When isssues are found they can be logged and assigned back the the developer and with non-showstopping bugs work can continue. The developer can see the issue assigned to them and submit a fix.

I have worked in a QA department that used FogBugz for the entire life cycle where a single ticket was passed from the Stake Holder to Dev to QA and then back to the Stake Holder. This system was difficult to see where a project was at a given point. We then made a transition to TFS. Tasks were split up and a User Story would be closed after UAT. The sys admin set up a few TVs around the office that would display a KanBan board. This board (also available online) gave an at a glance report of where a project was in development.

At another company, we used a custom WinForms application for story pointing, sprint planning, and hours tracking. We also used BugTracker.net to track issues. In lieu of a KanBan board they used a whiteboard with post it notes. This fragmented system would mean that there were hours wasted in updating a project in multiple systems as well as having to get up and physically move tasks on the white board. Sometimes a developer would set something ‘Ready for QA’ in the WinForms app but not move the post-it note, or vice-versa. Thankfully, this anecdote ends with the transition to TFS.

After each sprint, an analysis can be done using these systems (TFS, Atlassian) to review the development process. Charts and graphs can be populated to show the sucesses and pitfalls of that last sprint.

Incorporating QA into SDLC

Using a system like KanBan it can be easy to flesh out a sprint or release cycle and visualize the work to be done. In KanBan you would have vertical silos for each stage of the development process. You can also add swim lanes to delineate the work needing to be done at each step of the process or split responsibilities by department.

QA will own the QA column and any work “Ready for QA” should have its resources already planned. If a bug is found an issue is attached to the task and either sent back to Dev or work is continued after Dev is notified of the issue. When all tasks are completed and passed acceptance, the task can be moved to the Deployment column. A build should be kicked off and the project deployed to a production environment.

In production, another round of QA is needed as things like a bad code merge could corrupt the project. The QA team should have well established test plans and automation by this point so the time this step takes ought to be minimal.

QA Columns in KanBan

QA testing consist of many subsets, such as; Unit, Path, Security, Integration, Regression, Automation, and UAT. To have a column for each would render the KanBan board too large and require constant moving of tasks by the QA team. Instead, I recommend only three columns: