Development and QA process for Inblox.

We have planned to have 4 separate servers. We will have separate servers for
Development, QA, Staging and Production.

Developers access the Dev server to develop and test the application. Only the
developers have access to the Dev server. Once the development is completed and
build is ready, the QA team will deploy the app in QA server.

The Dev team does not have access to QA server. If the app passes the tests and the
QA signs off then the QA/deployment team will move the build to staging server. The
build in QA server should be moved to staging server. The staging server is accessible
to the product owners and QA. The acceptance tests are run by product owners in
staging server.QA performs a high level testing in staging to ensure the build is correctly
deployed. Finally during the release the build from staging server is moved to the
production server.

QA builds

1. Who is responsible for the QA build?

Developers (front end) are responsible for preparing the QA build. The QA or the
deployment team will deploy the build to the QA server.

2. At what points in the sprint will a build be delivered to QA?

For our project weekly builds are suitable and we can have intermediate builds
occasionaly.
Weekly builds
When the app is unstable it’s favorable to have a weekly release.
Weekly releases let developers build a more stable build. The QA will have enough time
to thoroughly test the features and perform regression. Currently it is suitable to have
weekly builds.

Intermediate build

QA can agree with development to do quick testing on development environment, in order to

identify the early stage defects so developers can fix them during the next round, on priority
basis, and then progressing with further development.

An intermediate build can be tested in the mid of the week. (On each Wednesday)

Daily builds/Nightly builds will be suitable once the app is stable and only minor
changes are done.

QA in agile process

When the scrum begins the combined team, including testing, takes responsibility for
analyzing the business requirements (e.g. user stories). They together define the sprint
goal.

The QA team defines the testing scope (i.e. test plan). That is then validated by the
whole team and the client.

 A test strategy that describes how the system is usually tested.

 QA must define the Test plan:

 Test estimations
 Testing types (functional, integration..)
 Target platforms (both OS and devices which testing has to be performed).
 Entry and Exit criteria.

 Test specifications which contain test scenarios and checklists.

 Test Ideas for exploratory testing and test logs in which the outcome is noted.

Test Ideas

In traditional work, there are often lots of test cases. They also occur in Agile work,
sometimes largely, and sometimes to a lesser extent. The disadvantage of the
traditional test case in an Agile project is that it takes quite a lot of time to plan and write
them. In many cases, checklists or “test ideas” work better.
Make a checklist per area to be tested and in each case describe in 1-2 lines what
should be tested. In the end, your checklist will look like a bunch of one liners. It is also
wise to create a supplementary checklist with general tests. If the need arises in the
future, checklists can be converted to traditional test cases.

Agile stresses on “working software over comprehensive documentation”. Of course,

this does not mean that all documentation is unnecessary. Documentation is a tool to
achieve the goal, and the goal is working software.
Development and QA cycles

In the beginning of the first sprint the team prioritizes and decides which user stories
should be present in the sprint. While the development team starts the implementation
simultaneously the QA team begins work on the test ideas and checklists.

Below is the diagram which explains the Sprint 1:

The QA starts the testing process once the build is deployed. The defects found are
raised. When QA are testing the sprint 1 the Dev team should move forward and start
developing the new features for sprint 2.

After completion of testing the testing team will send out an end of testing report. The
report will explain the outcome of testing in detail. The report will consist of:

1. Tasks accomplished in the sprint

2. User stories tested
3. Tests performed
4. Summary
5. Matrices
6. Plan for next sprint

Once the testing is complete the team determines, along with the client, which defects
are to be fixed in the current sprint. The estimates for each item should be planned
keeping the bug fixes in mind.
Planning and Estimates

In addition to known defects, we must also allocate time for fixing defects which are not
yet known -- that is, the defects which will be found during the upcoming sprint. These
defects may be related to the stories under development in the current sprint. Or they
may be found during system integration or other testing which could only take place
after an earlier sprint had been completed. In any case, each new defect must be
evaluated during our daily triage. Some will likely need to be fixed as part of the current
sprint. Neglecting to allocate time to fix unknown defects makes the sprint plan
inaccurate.

Story Points = Dev Time + Test Time

“Story Points” are units of measure used in Agile to reflect the amount of work needed
to complete a user story. Agile refers to the estimation exercise as “story sizing”. When
teams do story sizing, they often forget to include test time in their overall estimation.
More often overlooked is the test-fix-retest cycle that’s necessary when a critical defect
is found that prevents the story from being accepted. For our sprints to be successful,
it’s critical to include these in our sizing.

Dev process overview

 Ensure that the deployment architecture is documented and implemented.

 Ensure JUnit test cases are written by developers and reviewed by the lead.

 Ensure all tasks are well specified and documented in JIRA. All tasks to be broken

down into sub tasks and specified.

 Ensure all developers update their daily tasks in JIRA.

 Ensure all the deliverables are well tested before pushing them to QA.
Guidelines for Developers

1. Dev should freeze the code after the allocated time is completed and must deploy an
integrated build. QA will not be testing modules.QA will test the integrated build. It is the
responsibility of the developers to perform unit testing and a round of testing before
handing it to QA.

2. Developers should send out a mail when they deploy a build. It is mandatory to
update JIRA and make the items “Ready for QA”.QA team will only take up the defects
in “Ready for QA” status. The deployment mail should clearly mention the below:

1. New features implemented.

2. Version number
3. The bugs that were fixed.
4. Known issues.
5. Impact areas(if any)

3. Developers should take care that they have integrated all the modules in the build. It
is unprofessional to send a new build when QA encounters a bug.

4. Deployment team or QA team should distribute the build in testflight. There build
should be accessible only to QA and Dev. The build should be accessible to product
owners/clients only after QA approval.

5. Testers will reject the build if the app fails the smoke tests or if the mail is not
testable.

6. Version control is mandatory. It helps to keep track of the bugs and their life cycle. A
build should be versioned appropriately (Eg: Inblox 1.0). QA will mention the build in the
bug reports so that bugs can be tracked efficiently. The new features, bugs fixed in
every version should be tracked in a shared folder with the version number.