Software Product Development & Quality Testing
Entrance’s software development services team utilizes a tailored version of the Microsoft Solution Framework (MSF) Agile methodology to manage and deliver projects. The Agile process enables Entrance to focus on delivering working software that provides the highest business value at all times. Customer engagement and collaboration is key and, employing Agile allows our Clients to see and touch the software at the end of each iteration, typically 2-3 weeks long, which allows us to be highly responsive to our client’s changing needs.
To ensure the solution delivered meets our high standards, all solutions are delivered with our quality testing services.
We have team members solely focused on the following areas to delivery better software for our customers:
This model defines five distinct phases for a project. These phases overlap, define what needs to be accomplished and define a goal for quality. When used in combination with Entrance’s Agile methodology, these stages are small in scope and performed quickly.
Brainstorm with team about what ultimately needs to be accomplished, identify road blocks and determine how success will be defined.
Architect and design a solution that meets the requirements
Development of the actual software solution
Quality testing services, validation that the solution meets the acceptance criteria associated with specific product backlog items approved by the customer
Change management and go-live support associated with taking a software solution live
Agile Software Development Methodology
The Agile process works well when not all requirements are known at the onset of the project, and there is a need to be flexible to accommodate changes in requirements as the Client learns more about what they need or want in a technology solution. This process allows for changes to requirements to be made throughout the lifecycle of development. Changes are then incorporated at the beginning of each sprint where there is a deliberate and purposeful discussion about the relevant and most current requirements; as long as the Client is willing to make trade-offs regarding priority and scope of requirements, this change process will easily accommodate a need to iteratively develop a working technology solution in a phased approach, continually focusing on the highest priority features.
MANAGING THE WORK
Agile processes, by definition, employ short, time-boxed iterations called Sprints to define the scope of work that will be completed, and to then complete that work. Each Sprint is 2-3 weeks long and starts with a Spring Planning meeting and ends with a Demonstration of working software, the “Shippable Increment.”
The Product Planning process is a pre-cursor to any development activity. Depending on the scope of the problem and solution this process can take from one to five days of effort. This typically involves all of the members of the team, but can be limited to the Product Owner, Scrum Master, and Team Members who specialize in Business Analysis and Architecture.
The Product Planning process is a pre-cursor to any development and produces the following outcomes and artifacts:
- Understanding and documenting the business problem and processes
- Problems/limitations of the current solution or process
- A vision for the end state
- Developing an initial Product Backlog consisting of User Stories that detail the functionality required by each type of user based on role
- If possible each User Story should be assigned a Business Value to help determine the priority for the follow-on Sprint Planning
- Each user story should have clear acceptance criteria that will drive both developer testing and our software testing service
The Sprint Planning process allows Entrance and our Client to work together to prioritize and schedule User Stories in the Product Backlog for development. This is accomplished at the beginning of each Sprint by pulling items from the Product Backlog into the Sprint Backlog. As the User Stories are placed into the Sprint Backlog, Acceptance Criteria are written against the User Story to ensure that developers, testers, and users have a shared understanding of the definition of “Done” for a given User Story. The end result of Sprint Planning is a Sprint Backlog that contains User Stories and Bugs the team will work on until the end of the Sprint.
Throughout the Sprint the Team is continuously updating the User Stories in the Sprint Backlog with effort expended and remaining effort. This provides the information needed for reporting on Sprint progress and the metrics Entrance uses to manage its projects.
At the end of the Sprint, a Demo is conducted to show the Client the capability that was built and to get feedback on the implementation.
This provides the Client the opportunity to see and touch the solution.
The team will continuously be looking for improvement opportunities, and will set aside a period at the end of each sprint to reflect on lessons learned. This period is called the Sprint Retrospective.
Entrance approaches this meeting after the demo as a start-stop-continue meeting. Each team member is asked to identify specific things that the team should start doing, stop doing, continue doing With specific items identified the team will decide which items to focus on during the next sprint.
This process involves using tools and Agile development practices to turn the User Stories into functional software. This is driven by the order and priority of the User Stories contained in the Sprint Backlog. Throughout the Sprint, as the User Stories are turned into functional software, the software is tested and evaluated by our developers, Quality Assurance (QA) team, and the Client against the Acceptance Criteria in the User Stories to ensure we are building the right solution. The Team will meet at the Daily Stand-up to discuss yesterday’s accomplishments, today’s planned work and any impediments to getting the work done.
To increase quality and productivity, the Entrance team leverages market-leading tools and Agile practices:
Static code analysis tools
Automated UI Testing
Kanban boards for Work Item Management
Source Code Management via TFS
Database Source Code Management via Redgate
Entrance incorporates quality into all aspects of project delivery tailored to the type of software product development we are engaged in delivering. Document-based deliverables go through internal review for content accuracy, style, and voice. Additionally, Entrance incorporates input from Client via draft reviews throughout the delivery cycle.
Software based deliverables are put through a rigorous independent software testing and quality assurance testing process that involves the following steps when appropriate:
- Definition of Acceptance Criteria for software based functionality
- Unit testing done at the developer level
- Functional testing done by Quality Assurance resources
- Automated regression testing intended to streamline the development and deployment process as software based solutions evolve
- Software Code Reviews when appropriate
User Acceptance Testing Eliminating all defects from non-trivial software can be cost prohibitive, therefore, Entrance monitors the costs and effort associated with resolving defects to keep those costs within acceptable tolerances and Entrance company standards.
Related Case Studies
Get Pricing Information or Ask Us a Question