Shields of Test: Keepers of the Code

SDLC: The Software Development Lifecycle of Testing

“Testing Leads to Failure and Failure Leads to Understanding” — Burt Rutan

Software Testing Engineers, the keepers of the code from getting out without attacking and squashing all the bugs, have an internal SDLC which follows the same outline as any SDLC outline. There is Planning, Analysis, Design, Development, Testing, Implementation, and Maintenance. However, if we bring our focus to SDLC in just the realm of testing these steps take on a synonymous and antonymous meaning. Here’s my chance at taking you through the quest of putting the SDLC of Testing into my own terminology.

**Software Development Testing Lifecycle (SDTLC)

Yes I know the above acronym is not an applicable one but it does save typing and should be. To see an overview of SDLC see my article; Dancing in Dark Mode.

The steps to executing testing and decisions to be made works as follows:

1. Planning
   Create your own framework. Using a Framework such as Cypress.io. Here we find the Tech Stack Decision of the SDTLC. Methodologies and Tools such as Jira or Trello are all part of the planning phase of Testing a Software Application. Should we test in Java, JavaScript, or Python Coding Language. What are the costs of these decisions later down the line. In the realms of old this would be considered gathering a brave adventurer to solve a problem by going on a grand quest.
2. Analysis
   Manual Testing, Formulating Test Cases, Test Plans and filling in all those good things can be considered part of the analysis stage. Just like on a grand adventure you get the backstory of what you should do, you are going to be making documentation and formulating hypothesis on how to deal with the situation you are on the precipice of facing.
3. Design
   Decisions have been made through Analysis. This step in the cycle is the time to start implementing documenting and filing cases and plans for others to see. The design of testing is putting into plain English your plan of attack as you develop. As well as keeping party members or other parts of the development team apprised of your plan. The adventurer has to gather material items for the journey so to do Testing Engineers make sure they are prepared by design to slay the dragon.
4. Development
   Time to build the codebase and get ready to execute the plans thus far. Cucumber, and other Behavior Driven Development tools make this process easier to understand for all those involved in the SDLC but even more understanding of what we do specifically in SDTLC. However, BDD is a specific tool and other methods of testing principles may have been decided in phase 1. If this is the case other types of documentation are applied in phase 2. The battle must be approached with vigor and vigilance by the adventurer.
5. Testing
   The time has come does my code execute without breaking. Yes then it is time to move on to the next phase. This is the campfire kumbaya time of the adventure.
6. Implementation
   Implementation in the SDTLC can include things such as sending back broken code to be fixed. If no code tested is broken then this means it is time to give the okay for the current version to be passed into production. The adventurer has either won the battle or goes home to treat his wounds before trekking out again.
7. Maintenance
   New functionalities can have the tendency to make needs in previous automation testing code change minutely, but it does happen. Young adventurer back to the job board for the next quest.

Just call me a Protector

These steps are now my bible in the workforce. These commandments I shall follow and uphold as my oath allows me to do so. I too am proud to be knighted into the halls of the past Keepers of the Code.