An engineering process for building products on budget, time and scope.
Computools team will assist you at any phase of software engineering to build a quality product and speed up the achievement of your goals.
01BUILD THE TEAM
Making the initial scope based on the specification and estimate.
Сalculating the optimal number of specialists for each role based on expectations for the completion date, taking into account the non-linear productivity increase with a linear hour number increase.
The team’s core consists of professionals who started working on the project from its early stages, i.e. Business Analytic, Architect, Team Lead, Project Manager, UX designer.Ordinary executors are pre-assembled on the project manager's team.
Executors are added according to the following criteria:
level of technical skills
knowledge in the domain
Depending on the project specifics and the number of executors, necessary key roles are involved.
If the required number of executors is higher than the allowable level within the same team, additional teams are included in the project.
An intro meeting.
Carrying out the iterative development phase based on the chosen management framework. It includes iterations based on these next steps:
Specifying the story, including acceptance criteria by the Business Analyst.
Decomposing the story by the Team Lead and Business Analyst. Consult with an Architect if necessary.
Distribution of tasks by the Project Manager and Team Lead.
Preparing the UX\UI design, and if necessary, using these editors:
Consult with the Business Analyst if tasks aren’t detailed enough.
Estimation tasks and approvement by Team Lead.
Task development in accordance with git flow. By default it is feature/branch that includes test development. Possible methodologies are:
Domain driven development (DDD) - used for architecture of logic and code. It is possible to use alternatives in a number of cases.
Test Driven Development (TDD) - used for implementation of the main logic in code.
Creating pull requests with static code analysis using next tools (depending on technology):
JetBrain Products - common
SonarQube - Java
Codesniffer, Mess Detector - PHP
ReSharper - C#
K&R - C++
Golint - go lang
Code review and fixes
identifying logical errors in business rules
identifying potential bugs and unwanted side effects
elimination of complicated implementations
keeping unified system structure
keeping unified system style
detecting errors missed by code analyzers
cross team review – by all participants of the module development including the Team lead. Provides higher performance but takes significantly more time
Team lead review
Bitbucket internal tools
Writing a test case into QA documentation according to task description and design mock-up.
Aspect test and fixes.
Fixing if necessary.
Accept next additions based on selected management framework.
In case of Scrum
Elaborating, decomposing and estimating tasks during the sprint planning. This process allows Product Owner to make changes for each sprint.
Particular attention is paid to grouping tasks in such a way that the Product Owner gets a working project with new functionality at the end of each sprint. Sprints with active development in the new functional and stabilization phases are admissible.
It is acceptable to go with active development and stabilization sprints.
It is possible for the Product Owner to increase the team size. even if it wasn’t planned at the beginning.
In case of Kanban
Elaborating, decomposing and estimating tasks performed right before working on them.
The process' main goal is maximum delivery speed.
The Product Owner sets the task's priority.
It is possible for the Product Owner to increase the team size, even if it wasn’t planned at the beginning.
In case of Waterfall
Elaborating, decomposing and estimating tasks performed during initial phase. Detailed task decomposition and elaboration are highly important from both the Business Analyst and Team Lead sides. If there is no similar experience, this phase may take significantly more time than in Scrum/Kanban based processes. And at the same time it is not completely accurate
It is impossible to make significant changes until the project is finished. And they will require repeating the initial phase.
In order to save time, tasks are grouped according to the development team’s priorities. Thus, feedback during the development is not so important, because it's impossible to make changes.
It is difficult for the Product Owner to increase the team size if it wasn’t planned at the beginning because the work schedule and estimates are already done.
By using basic principles and development approaches such as;
KISS (Keep it short and simple) principles [avoiding over-engineering],
DRY (Don’t repeat yourself) principles,
Clean Code approaches and ideas,
Industry standards, for example, AirBNB/PSR,
OOD principles and methodologies, including SOLID,
Working with next tools to achieve high productivity,
static code analyzer
bug/task tracers - atlassian software firstly
domain specific tools
solved problem is more important than any approach or pattern
Working with specifications and documentation - the sooner a bug is detected, the lower the cost of fixing it:
Development of a testing plan
Development of initial test cases
Working within stories/tasks - identifying bugs in an isolated feature/branch context, allows the development team to quickly determine the cause
task description analysis
analysis of the completeness and clarity of the task
acceptance criteria analysis
discussion of the problem with the Business Analyst and correcting
preparation of test cases and checklists
deployment of the task on dev environment
testing in accordance with a test case
design testing by QA
layout testing by UI designer
if a bug is detected, the task is returned to the developer with a detailed description
information about the environment
in case of success, the task is moved to done
implementation of end to end tests and additional automatic tests in accordance with the requirements based on documentation
UI tests via selenium - main page object design pattern.
API test as part of the development stack.
Load test - is not included in the group of tests launched automatically during the build.
Automatic tests run automatically on build servers and developer local environments. The code can be merged only after passing all tests:
end to end
Regression testing is carried out within the completion of the sprint, or a specific area of work. The main goal is to make sure that there are no hidden bugs, bugs at the junction of the tasks or bugs arising due to side effects of implemented tasks. Facts about regression testing:
performed on QA environment
there is a full manual testing of the build in accordance with documentation
if a bug is detected, it creates an in task tracking system. The task contains the following description:
Name - to describe the essence of the problem concisely.
Code - a unique identifier of the task in the task tracker.
Type: blocker, critical, major, minor, trivial.
Reproducing steps - often are supplemented with screenshots or videos.
link to the environment
current scope - cannot be postponed
to backlog - a build can be released with them. This method is not desirable and is applied only in the case of tight deadlines.
bugs acceptance tests matching expected result and actual result
additionally implementation of automatic tests that track this scenario
repeated regression testing cycle
The choice of working strategy with a release candidate takes place at the stage of writing test plans and depends on the requirements for system reliability and time to market.
Release candidate validation strategy:
Release candidate's testing is an analogue of regression testing, taking into account the definition of done. The result is the admission of the release candidate's uploading to staging.
Staging/demo testing - testing the release candidate which received approval and was uploaded to staging/demo on a specified set of cases that allow to not block efficiency.
Production testing is analogous to staging/demo in a production environment.
strategy of planned Continuous Delivery (CD)
The CD system is an alternative to working with release candidates. In this case, the uploading of operable functional takes place in a semi-automatic mode on schedule. The functional is considered to be operable only if it is passed by regression manual testing. Inoperable functionality is usually excluded from the build and it's not waited to get stabilized at this time.
planned production/staging testing.
Penetration testing - is used to find system security issues
Optional types of testing
Smoke testing is used to check if the build is ready to be tested. This type of testing is rare because the standard development process implies that the build is always ready for testing.
Research tests - can include penetration testing elements, peak load tests, domain specific elements. It is carried out with the help of specialized software in order to identify hidden risks and peak capabilities of the system.
Improvement - all team members can create improvement tasks during their work on the project. After tasks are created, the Business Analyst work with them additionally. This type of task does not block the build but can be done within the scope.
Code stabilization/refactoring - the development team can create tasks. The implementation of which does not provide new functionality, but can increase system stability, reduce the probability of bug emergence and speed up development.