Software examination
Checking software, websites, mobile applications, modules, APIs and source code against the contract, technical specifications and stated functions. Fees from RUB 90,000. Moscow and the Moscow Region.
Software examination compares a specific version of the development deliverable with the agreed requirements. Missing functions, reproducible defects and failures caused by the environment or an external integration must be distinguished.
Subject of examination
- Software build, source code and configuration
- Contract, technical and detailed technical specifications, and acceptance criteria
- Test scenarios, logs and version history
Sample questions for the expert
- Which requirements are implemented in the version examined?
- Which shortcomings are reproducible under the specified conditions?
- Are the limitations related to code, settings or external dependencies?
- Are the materials sufficient to check the scope and result of the work?
The final questions are formulated according to the objects and circumstances of the particular task.
What to prepare
- Agreed requirements with all versions
- The build to be examined and its version details
- Code and documentation within the agreed scope
- Environment description, test data, logs and acceptance certificates
How the examination is conducted
A “requirement — verification method — result” mapping is prepared. The environment and reproduction conditions are stated. Code analysis is used as needed and does not replace checking the program's actual behavior.
Scope and limitations
Interface-only access may limit conclusions about the server side. Technical testing does not automatically establish ownership rights, the amount of losses or a breach of contract.
What the deliverable records
The result contains verified requirements, reproducible scenarios, identified nonconformities and limitations of the source materials.
What makes a verification scenario reproducible
A report that “the button does not work” becomes a verifiable technical task when it describes the initial system state, user role, input data and action sequence. The record also needs the expected result and actual observation. A repeat check must establish whether the same conditions were met, rather than merely show a similar screen.
- For a report, preserve selection parameters, period, source records and the generated file.
- For an integration, preserve a sample request and response, operation time, result code and relevant logs.
- For an access error, record the role, permission settings and action the user attempted.
- For an intermittent defect, preserve several observations with occurrence conditions and details of successful runs of the same scenario.
Distinguish the outcomes: requirement checked and met; checked and a nonconformity found; check limited by missing data or access. The last situation does not by itself mean the function is absent. For example, an unavailable external service may prevent completion of a scenario even though the corresponding software module exists.
Choose test data that preserve the operation's meaning, including boundary cases and known disputed examples. Confidential information can be anonymized if replacement does not change the conditions causing the error. An agreed set of scenarios and annexes helps verify conclusions without repeating the entire development history.
Tell us
about your task.
Describe the situation and attach the materials. After reviewing your request, we will agree on the examination format, questions, timeframe and cost.