Software Development Process

When a new development team is created, managers insist on creating a “Ways of Working” which essentially comes down to describing the software development and testing process in the ideal way.

Then after a few weeks, you end up just resorting to the default way of working.

The “ideal” way assumes that the Testers can provide ideas and inspiration to the Developer, and when the Developer writes the fix, the solution won’t deviate from their original perception. Therefore, all the Test Cases are written up front, and none are needed to be written after.

Here is an example that one of my former teams came up with:

Before fixing the defect

Analyse together 

• Make sure you pair up as a developer and tester to work on the defect.
• Review the problem together
• Understand how to replicate the fault
• Understand the extent of the problem (all regions, all set-ups, all environments?)
• Do the initial debugging to understand where the problem lies

Fixing the defect

The developer MUST 

• Make sure there are unit tests to support the current functionality
• If there aren’t unit tests then implement a simple refactor which will allow appropriate unit tests to be added
• Add unit tests that prove the defect (which will fail)
• Fix the defect
• Get it code reviewed
• If you are working on code you are not familiar with, get 2 reviews, one of which must be from an expert
• Run all the unit tests and prove the fix

The tester MUST 

        • Write test cases with steps and expected results for the initial test cases. They must

                ○ Be clear and unambiguous

                ○ Cover the different scenarios/circumstances/options

                ○ Not test things that are irrelevant

        • Once written, set the state to “Review” and assign to the reviewer

        • The reviewer

                ○ Adds comments as appropriate

                ○ Set the state to “Ready” if Ok, or back to “Design” if it needs changes

                ○ Assign it back the test author

        • Only use Given, When, Then if you are using Specflow to automate your tests

        • Only use exploratory testing

                ○ If you have passed a Rapid Testing course

                ○ And you have a clear understanding of testing heuristics

                ○ And you plan and classify sessions, keep session logs, run debriefs

                ○ And all the specific test cases and all regression test cases have been executed

        • Create regression tests of the functionality

        • Create test case(s) to prove the defect

        • Get the tests reviewed

        • If you are working on functionality you are not familiar with, get 2 reviews, one must be from an expert

Assure the Quality

• Review the actual changes together
• Understand the logic
• Understand the scope
  • Minor/contained (inside a method that’s inside a class that doesn’t affect anything that’s outside it)
  • Medium/impacting (a change that impacts outside it’s own class or is called from elsewhere in the system
  • Major/widespread (a complete refactoring of existing code or large changes to core features)
  • If they don’t understand the logic or can’t establish the scope, escalate to the Technical Manager
• Execute the tests
• Attach and link all work items and evidence together