Government Digital Service
WP1455: End to end tests for GOV.UK Publishing applications
6 Incomplete applications
5 SME, 1 large
4 Completed applications
4 SME, 0 large
Important dates
- Published
- Wednesday 23 August 2017
- Deadline for asking questions
- Wednesday 30 August 2017 at 11:59pm GMT
- Closing date for applications
- Wednesday 6 September 2017 at 11:59pm GMT
Overview
- Summary of the work
- Testers and developers needed to understand the behaviours of our publishing applications and write new automated functional tests for them. The team would perform some exploratory testing and automate the tests to fit in with our Rspec and Capybara-based testing framework. Appropriate training and instruction will be provided
- Latest start date
- Monday 23 October 2017
- Expected contract length
- Approximately five months. Not beyond 31/03/2018
- Location
- No specific location, eg they can work remotely
- Organisation the work is for
- Government Digital Service
- Budget range
- £100,000 - £115,920
About the work
- Why the work is being done
- In order to support and fulfil the vision for GOV.UK, we need to iterate our publishing applications and workflow rapidly and with confidence. Having good end-to-end functional test coverage for critical paths will enable us to deploy changes with confidence that they won't negatively impact publishers and citizens
- Problem to be solved
- GOV.UK is a platform of microservices. These are all well tested internally, but few publishing user journeys have end to end test coverage that exercises each component in the system. This lowers our deployment confidence. We need end to end tests written for common publisher journeys across 6 publishing applications: Travel Advice, Mainstream, Manuals, Collections, Contacts and Policies. We expect the work to be completed within 9 working weeks. There will weekly meetings with the supplier to ensure that the work remains on track.
- Who the users are and what they need to do
-
"As a developer on GOV.UK
I want to test how my changes affect the entire publishing journey
So I can have confidence in the code I am writing and move more quickly." - Early market engagement
- none
- Any work that’s already been done
- We have a Docker-powered end to end test framework that runs the applications required for testing. An Rspec and Capybara-based framework then runs tests against the Specialist Publisher application and exercises that application, our publishing platform, routing layer and front end application.
- Existing team
- The existing team of GOV.UK developers will be available to review Pull Requests and answer questions on any undocumented application behaviour. The work will be coordinated by a GOV.UK Delivery Manager and overseen by a GOV.UK Senior Technologist. There will be a session with our in-house trainer on our publishing tools in order to understand the user journeys.
- Current phase
- Live
Work setup
- Address where the work will take place
- GDS, The White Chapel Building, 10 Whitechapel High Street, London, E1 8QS
- Working arrangements
- The team should work in the GDS office for an initial period to gain context, but are encouraged to remotely afterwards. Fortnightly check in meetings on progress are required.
- Security clearance
- SC
Additional information
- Additional terms and conditions
- Cabinet Office (CO) Travel and Subsistence policy will apply. All expenses must be pre-agreed with between the parties and must comply with the CO T&S policy.
Skills and experience
Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.
- Essential skills and experience
-
- 3+ years experience testing Rails applications
- 2+ years experience working with Rspec and Capybara
- 2+ years experience with Continuous Integration
- Experience working with Git
- Must be able to work independently of developers
- Must be able to consult documentation and read code to understand application behaviour
- Nice-to-have skills and experience
-
- Evidence of working with Docker
- Evidence of experience testing a system composed of microservices
- Evidence of exploratory testing capability
- Evidence of knowledge of PostgreSQL and Mongo databases
- Evidence of testing Rails applications that use APIs instead of a database
How suppliers will be evaluated
- How many suppliers to evaluate
- 3
- Proposal criteria
-
- Technical solution
- Approach and methodology
- How the approach or solution improves the stability of GOV.UK applications
- Estimated timeframes for the work
- How they’ve identified risks and dependencies and offered approaches to manage them
- Team structure
- Value for money
- How the approach works to minimise the need for similar work in the future
- Plan for understanding application behaviour
- Strategy for determining what requires testing
- Cultural fit criteria
-
- Evidence of experience working in an Agile environment with Kanban
- Evidence of experience reporting progress to Senior Management on a regular basis
- Experience communicating with other developers via Slack or similar tools
- Demonstrated understanding of the need to ask well defined questions of other developers
- Examples of sharing learnings with other developers
- Experience of pair or mob programming and understanding of the benefits
- Payment approach
- Time and materials
- Assessment methods
-
- Written proposal
- Work history
- Presentation
- Evaluation weighting
-
Technical competence
70%Cultural fit
10%Price
20%
Questions asked by suppliers
No questions have been answered yet