There are probably a lot of misunderstandings about Test Driven Development (TDD) and a general unawareness about what it is so I am hoping you will gain a better understanding after reading this article. I have a nice image on the left which will help to provide better information for TDD. The general thought process is by creating an initial test case which is designed to fail, the developer will design better code which will make the test pass.
The TDD test created will be a simple unit test that will affect a very small piece of code.
Once the unit test has been created it needs to execute and fail.
The developer will then write code to get the test to pass.
The developer will refactor code to make it simpler and more efficient.
The developer will repeat the process and add more tests over a period of time.
In Agile the team normally consists of the BA, Developer, and Tester. It some organizations, the tester is responsible for manual, automated and performance testing activities. That is a lot of responsibility for one person but it does happen in small IT organizations. In larger organizations it gets a little more complicated. I have setup multiple testing departments and I create a shared services model for both automation and performance work. The tester works with those teams and identifies automation and performance testing efforts. I do require that if the test case is going to be automated, it needs to provide the right amount of detail so the automation team will be able to script it properly. I also like the manual tester to execute and pass the test case before it is automated. Input in terms of the stability of the code is also needed, otherwise you can burn a lot of hours having to constantly update changing automated scripts. The beauty of this model is it allows multiple Agile teams to leverage automation and performance skills. As more automation and performance testing is needed, those shared services team will grow creating a model that can scale.
The Agile teams don’t typically need dedicated resources for automation and performance testing, so hours are only used when needed. To keep in line with the Agile methodology, I have both my automation and performance teams create Sprints for the work that is needed so I can closely measure how things are going within a given timeline. Since the effort is shared across the team, they follow standard Agile principles and have their own series of meetings, demos, and retrospectives to ensure communication is flowing across the team. They also may participate in some of the meetings such as daily stand ups for the projects they are supporting.
I have adjusted this model a bit to fit the needs of each organization. It has worked well and I will continue to use it moving forward. The teams like the approach and it has helped to build stronger teams using this approach.
While there is an ever increasing movement for Quality Engineering organizations to “Shift Left” there needs to be more attention placed on “Shift Right”. Here are some reasons why Quality Engineering must pay close attention:
This is especially needed in more traditional industries where there are smaller and smaller UAT teams. There is increasing pressure on the UAT teams to test more and more with fewer and fewer resources.
UAT resources usually have full-time demanding business jobs. UAT is typically given very little attention and focus. If there is a priority, UAT usually loses.
Quality Engineering should work closely with UAT to understand how the business works and create scenarios based upon day in the life scenarios. Those scenarios can then be automated and will greatly improve the quality of the applications before they hit UAT.
While more and more demands are placed on Quality Engineering organizations, they usually are dedicated resources who can focus all their efforts on software quality.
I agree that it is necessary to “Shift Left” but I believe you should actually start by “Shifting Right” in order to cover the backside of the SDLC.
Agile will place greater demands and significantly compress the historically long UAT cycles, the time that used to be available will no longer be available.
“Shift Right” will require interaction with UAT teams. This is often difficult for QE to interact and understand how the business really works. Let’s face it, we are geeks. Once QE has engaged and understood the real world challenges that the business faces, they will be able to identify potential issues before testing gets to UAT.
While this is not an exhaustive list, it will help support the thought that “Shift Right” first is the right way to go.
Quality Engineering is defined as a process that produces the best product possible. It requires substantial effort across the SDLC to ensure that all areas are adequately tested. Here are some core areas of Quality Engineering:
A few objectives that are accomplished through Quality Engineering:
Improve test effectiveness
Leverage quality metrics in order to make better decisions
Find defects earlier
Quality Engineering is a repeatable process that leverages tools to accelerate time to market. It takes Quality Assurance to another level and produces predictable results. Quality Engineering is expanded across development, testing, and release management teams. Organizations that are able to create a collaborative Quality Engineering practice will be the most successful.
The world of software development is drastically changing. In order to get customers what they truly need and want, the Agile methodology is driving how rapid software development is done. Most of my development counterparts believe top notch developers are needed to run strong Agile teams. I naturally respectfully disagree. While many companies have strong developers, is harder to find (and retain) strong Quality Engineers. With the numerous examples of failed software development implementations, C-Level executives are demanding better quality from their IT organizations.
Quality Assurance is no longer reserved for those “people who couldn’t program”. It has evolved into Quality Engineering with resources who can program, perform deep technical analysis, and routinely challenge their development peers. With the increased attention on the Quality Engineering organizations, C-Level executives are willing to spend what is needed to ensure high-quality applications are delivered into production.
Quality Engineers are automation experts. They leverage multiple toolsets and programming language to drive quality within the Agile process. Smoke tests, automated regression tests, automated frameworks, automated code deployments, and performance tests are just a few of the elements that are often required of the Quality Engineer. In addition to their technical skills, Quality Engineers have to be effective communicators and work closely with the Scrum Master, developers, and Product Owner in helping to build a high-quality application.
A few great Quality Engineers can really accelerate the speed of code deployments and can significantly move your organization forward. Without them, your organization will struggle and have difficulty with Agile.