Beginner S.R.S testing section writing advice

Question

I'm writing the Testing section for a SRS for a group project. We started out with the IEEE std 830-1993 SRS template but have kinda moulded it around our project to suit our needs.

We are taking an Agile approach but firstly we have to write the SRS and I am writing the testing section and it is quite difficult. I've never worked as a Engineer/Developer so I was looking for some guidance. From what I understand about the SRS is that it is meant for the Product Owner to see what we have understood and agreed to design, and how we are going to do it and why we are doing it this way, so this should not be too technical and is meant to be readable by most people?

BTW, Are iterations always 1 week long (We only have a few weeks, we would have made it longer but there is not much time left).

So far the section on testing I have broken down to the following subsections:

Testing Overview
Here I just put a summary of what the following sub sections will explain about 4/5 lines

Approach to Testing
Here I implement an answer to 'Why' we are doing this, the reasons for testing and how testing benefits the development and progress of the code.

Testing Stratergy
Here I implement a 'How' we are going to achieve this comparing and contrasting unit testing, BDD, TDD and describing other forms of testing like acceptance testing and whitebox/black box testing and justifying why we need to use it and why we didn't use methods like sub-system testing and module testing etc.

I also go into validating and verifying data and the importance of testing not just about testing the code but about test data as well.

Testing Methods
Here I go into the 'meat' The most technical/detailed part about testing describing what unit tests are and what they look like and why they are needed, I also give a description of what a test cases is and what they look like and how we use them to ensure code completion and security when developers have already developed the code.

Testing Schedual/Plan
Here, the final section. I go through How often we test, what happens if a test fails/passes and how this working in regards to the agile development cycle. A table that shows roughly when the testing stage will happen so 7 day long iterations maybe on a Friday/Saturday. Also explain when we plan to meet key testing milestones and put this in bullet point? Or should I use table format or plain text?

Anyways, That is what I got so far, What is your critique? What would be better placed? and are the sections in a good order? You can see I've used this {Why, How, Meat} order to try and build up the knowledge and reasons of testing before explaining it in depth at the end, and finishing with scheduling.

Btw, sorry for my bad spelling/grammar.

Thanks

Answer 1

BTW, Are iterations always 1 week long (We only have a few weeks, we would have made it longer but there is not much time left).

• No, an iteration does not have to be 1 week long. It is flexible based on your development context and company culture. 1 week or 2 weeks are fairly common for an iteration.

Testing Stratergy Here I implement a 'How' we are going to achieve this comparing and contrasting unit testing, BDD, TDD and describing other forms of testing like acceptance testing and whitebox/black box testing and justifying why we need to use it and why we didn't use methods like sub-system testing and module testing etc. I also go into validating and verifying data and the importance of testing not just about testing the code but about test data as well.

• Are you going to use all of the testing techniques you mentioned above? You do not have much time left, you should only talk about the test techniques you are using instead of providing a Wikipedia style paragraph.

Testing Strategy and Testing method:

• What are the differences between those two sections? I am a bit confused.

Testing Schedual/Plan Here, the final section. I go through How often we test, what happens if a test fails/passes and how this working in regards to the agile development cycle.

• What happens if a test fails/passes, in my personal opinion, it should be included under Test Strategy. What do we do if a test fails is more related to testing approach then scheduling.

I would include a section to present risks involved as well,

• what happens if there is not enough time to do software testing
• what happens if we miss a milestone