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.
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:
- QA Testing
- Consisting of; Path, Security, Automation Development/Testing, System, Integration
- The stakeholder needs to spend sometime looking at the completed project to ensure it meets the requirements and their expectations of implementation/design
- Production Testing
- Smoke and Automated test execution
- WROX published book written by the Visual Studio evangelist
- The most popular and highest rated book on Amazon for this topic