What Test Managers Should Know About the Software Development Life Cycle

By 1st April 2016 Testing

Why is an awareness of the entire lifecycle essential for test managers?

Without a doubt, testing is one of the most vital parts of the SDLC (software development life cycle) and as a test manager it is important to be able to see the complete lifecycle at a high level rather than just focus on the testing part. To get the best out of your testing efforts it is worth-while spending some time understanding the entire lifecycle. The question that pops up is: ‘why is this so essential?’

Actually, a better question is why is it relevant in this day and age, more than it has been in the past. I’ll take a stab at answering that question below.

The answer is simple. Times have changed and so have software development processes.

Traditionally, testing has always been at the end of the SDLC and the testing team is often kept in the shadows until the last minute. This causes unnecessary waste of time for the testing team while trying to get a basic understanding of what the development team has built and linking it to the requirements created by the requirements team. It can quickly turn into a painful process, at times even creating tension between the development team and testing team.

With the rise in popularity of agile methodologies after the millennium, testing started playing a key role in the early stages of the SDLC. When test managers don’t get their teams involved at the beginning of the lifecycle it can cause waste of money, time and resources.

The orthodox mind-set which says that testers and developers are part of opposing teams is quickly fading away. People have learnt from experience that it is only an illusion that they are in different teams; in fact, they complement each other and are a part of the same unit.

The basics of agile and non-agile Software Development Life cycle (SDLC)

Before getting into the role of a test manager, let’s understand and compare the basic steps in the SDLC, in a traditional versus agile environment.

In a traditional environment, the SDLC begins with the initiation phase where activities such as project kick-off, project vision creation, statement of work, contract creation may happen. Next, the requirements team picks up from where the management leaves off and starts writing requirements. The requirements development phase may involve several whiteboard sessions, business flow creation, value stream creation, and detailed requirements creation.

After the requirements phase is complete, the architects start the solution design at a high level and work with the development team to make a detailed design for them. The development team then starts developing the software per the design and the requirements. The test manager may get involved at this stage. He or she may create a test plan, high level test cases and scenarios. As the development team nears completion of development of their first major release, the testers start creating detailed test cases and start running the tests on the software application.

In an agile environment, the life cycle may also begin with a kick-off, but there may not be a written contract as a result of it. The client and the product team may come to a common understanding on the product vision. The kick-off meeting would ideally include leaders from each functional area. The test manager would be fairly involved in the kick-off process, although he or she may not have the whole testing team involved in it.

Next, the cross-functional leadership will typically agree on a feature list to work from. Small cross-functional teams will be formed to break these features into smaller pieces to sprint on. At the end of every sprint or interval, the cross-functional team would demo and ship the software increment to the client. The client gives feedback to the team and then they take that feedback and start working on it in the next sprint which starts almost immediately. This cycle would repeat until a production release is completed and deployed.

Key points a test manager should know about the SDLC to stay ahead of the game

SDLC terms are often a language of communication

Nothing can be more off-putting than a fellow lead not understanding commonly used terms in a methodology. These terms will soon become the language that leads use for daily communication. As a test manager it’s your responsibility to get educated or certified in the process or methodology being used.

Be it an agile or waterfall methodology, you could get a certification easily these days by searching online for courses available in your area. If getting a certification is too much work for you, you could buy a book on the methodology and educate yourself on it on your own time.

Speak up and get involved early in key SDLC activities

Whatever life cycle methodology you are following in your organization, it is your responsibility as a test manager to make yourself resourceful and get involved in the key project activities. Do not restrict yourself to just being involved in testing activities.

Some examples of key activities you can contribute to include:

  1. project kickoff
  2. release planning
  3. sprint planning
  4. user story grooming
  5. requirements gathering process
  6. retrospective or lessons learnt meetings.

Be proactive about getting involved. You may or may not feel invited, but when you make yourself more useful to the management, they will see that value in your presence and invite you to key meetings.

Avoid SDLC process wars

Different people have different experiences and mindsets. Some may be more suited to a particular process than another. Nevertheless, you will always find common ground between all the differing opinions about SDLC processes.

As a test manager, the last thing you want to do is get into a non-productive process war. You might find that there will always be a few folks who will not be flexible and you might find that annoying, yet it may not be worth getting into heated arguments with them. As difficult as it may seem, try to find something that both parties agree on and go that way if there is no other way to avoid the situation. In the long run, the aforementioned approach will be more beneficial.

Some examples of conflicts can be on how soon the testing team needs to get involved in the lifecycle process. It may be in your interest to get involved as early as possible so find the balance between going too far and too less and then, take your stance. There will always be one or two people in the other teams who may be more agreeable. Use them to your advantage and work with them to come to an agreement sooner.

Versatility and cross-functionality are your friends

As a test manager, you would be in a better position to handle all facets of the SDLC if you have a team of testers with versatile skills and experience in not only testing but development and other subject matters. The most versatile testers are the ones who can write code, just like good developers are the ones who can devise a good test case. Testers who can code may come handy in automating the testing framework by using tools like selenium.

From experience, another advantage could be that the development team may gain more confidence in the testing team by their sheer resourcefulness. In addition to testers who can code, testers with experience in system testing and performance testing will come handy during the stress testing and system testing phases of the product lifecycle. If working in an agile environment, it goes without saying that, testers will have to demonstrate cross-functionality while working in their agile teams.

Prepare for continuous improvement cycle of DevOps

With lot of teams using the DevOps model, tester managers these days need to keep a constant check on their testing team’s performance and metrics, in addition to the product quality analysis metrics. In agile models, the testing teams will have to be part of a team that designs, developers, tests and deploys the product every sprint. Make sure you hold a lessons learnt meeting periodically to evaluate any shortcomings.

Prepare for Operational testing in Production

Have a few testers be involved with the operations and monitoring team if there is one. If there isn’t a separate operations team, then the agile team would probably play this role. Ensure a tester is involved in operational monitoring, so that the quality of the product in production is monitored in real-time by a tester. If any issues are found in production, testers can open bugs in a bug tracker system in addition to the sprint testing bugs.

Recap

  1. With so many projects going agile and testers getting involved early, it has become imperative for test managers to be aware of each aspect of the SDLC.
  2. Traditional SDLC may require testing team’s involvement in only a small phase. In agile lifecycles the testing team is typically involved right from the beginning of the product life cycle.
  3. Some key tips for test managers are – familiarise yourself with SDLC terms, proactively get involved in the SDLC, avoid SDLC process wars, make your team versatile and cross-functional, and prepare for continuous improvement and operational testing.

Test Managers have never been so involved in all aspects of the software development life cycle than the present time.

With a high percentage of software product companies adopting agile principles, it has demanded for the test managers to be influential and involved in the process life cycle right from inception.

As a test manager you would want to encourage your team to be versatile, cross-functional, proactive and resourceful. It is the test manager’s responsibility to enable the testing team in all activities of the SDLC.

Join the discussion 2 Comments

  • Wow. That is so elegant and logical and clearly explained. Keep it up! I follow up your blog for future post.

  • Nice article.

    Thanx for sharing with us valuable information with us. According to me test managers should know everything about the software development lifecycle and they have to interact with the developers in every step of the coding so that bugs can be fixed at the initial stages only without stretching it to the final stage. It will help in decreasing the cost also.

    I must say well done, I have enjoyed reading your article.

Leave a Reply