Week 5 software testing plan | BSA385 Intro To Software Engineering | University of Phoenix
Wk 5 – Software Testing Plan [due Mon]
o “Software Testing Plan” document
Continue your work using the scenario presented in Week One.
The Director of Software Engineering would like to have you create a new Software Testing Plan.
Using the Software Testing Plan document provided, develop a 3- to 4-page software testing plan. The plan will include the following:
o Design and Develop: Software testing goals, assumptions, and deliverables:
o Testing Goal
o Test Assumptions
o Quality Attributes
o Schedule in the Life Cycle
o Required Artifacts
o Test: Data: generation and automation tools:
o Test Data Generation Methods
o Test Automation
o Acceptance Test
o Deploy: Versioning, maintenance, and environment:
o Version Control
o Maintenance Plan
o Testing Environment
Scenario in week 1:
The company you work for is a programming services contractor that consults with businesses in the United States requiring assistance in creating software in compliance with the Health Insurance Portability and Accountability Act (HIPAA). Your company advertises a proven track record in providing secure code that meets regulatory and compliance recommendations that include the protection of all Personally Identifiable Information (PII).
Your client is a small hospital and surgery center that requires a program that will calculate the bill for a patient’s hospital stay, including charges for the surgery, daily hospital fees, and pharmacy. The hospital only performs five types of surgeries, limits the patient stay to three days, and has a limited pharmacy offering of ten prescription drugs. The hospital employees who will use the program should be able to enter the patient information, including name, hospital ID number, diagnosis, surgery type, length of stay, and prescriptions. The program will then produce a final billing statement. The client would like the program completed in six months.
Using the file provided and referencing the scenario above, complete the 2- to 3-page System Development Life Cycle Table. The table is designed to help you see how to apply the SDLC to an actual program.
SDLC Phases Phase Description Questions/Engineering Principles Reference:
Typical Documents or Artifacts used in this phase
The planning and analysis phase is likely the most vital phase in the software development process. In these phases, one needs to define the scope of the problem and determine possible solutions, and if they will fit the needs of the organization. From here one must analyze the needs of the end users to ensure the new system meets their expectations of the system. What are the most useful and convenient features you use in the current system, and what are their benefits?
What features would you liked to see change?
Is there any change you would make in the appearance of your current system?
If there were no constraints on the project, how would you like the program to work and what features would you like to see in it?
Is there any particular feature you would like to emphasize (Smart Bear, n.d.). Requirements Document
Software Requirements Specifications (SRS)
This phase will describe, in detail, the needed hardware and software specs and feature set that will be developed for the project requirements of the new system. Evaluate Design Alternatives, are there any other ways to design the system and how would that be better than the current system’s design?
Make Quality Number 1, quality of the software being developed and the team behind it are essential
Use an appropriate process model, during
the design phase, it is important to use an appropriate development model for the project in development.(Grist Project Management, n.d.). Software Development Plan (SDP)
Data flow diagram (DFD) or entity-relationship diagram (ERD)
User Interface Prototype
This is the phase where the majority of the work is performed. The actual development of the software is done here based of the design documents from the previous phase. Get It Right Before You Make It Faster, ensure the system developed works as intended by the end users before any optimizations.
People are the KEY to success, be sure the bring the right people for the right jobs during the development of the project.
Inspect Code, comb through and evaluate your code for any bugs or ways to simplify the code (Grist Project Management, n.d.). Implementation Strategy
Programming Conventions and Libraries Specification
Testing This phase involves systems integration and testing to be completed by a quality assurance professional. This phase makes sure the product does actually meet the business and project goals originally sought out with. Establish and change management environment. This principle implies that the development team needs to be prepared both physically and mentally for the significant amount of changes to be made to the project.
Instrument the process for objective quality control and progress assessment with an independent team. This will ensure the development team creates and QC process to go through whenever and change is performed.
Establish an iterative life cycle process to confront risks early in the development process (Royce, n.d.).
The final phases are actually deploying the newly developed system to the client and maintenance of the system by performing required updates to comply with current policy. In this phase end users can now fine tune the new system and figure out any additional user requirements. Establish an economically scalable configurable process.
Use a demonstration bases approach to assess intermediate artifacts.
Plan intermediate release in groups of usage scenarios with evolving levels of detail (Royce, n.d.). Installation Guide
Note: An artifact is typically referred to as a by-product that is produced during the software development life cycle. Examples of architects are requirements, use cases, class diagrams, designs, project plans, test plans, etc.
Documentation in software development typically refers to user guide, training manuals, installation guide, online help, etc. Users need documentation to run the system successfully.
Artifacts can be considered as documentation that is an output from a phase in SDLC into another phase of the SDLC. For example, a requirements artifact is created by a Business Analysist during the requirements gathering phase and then passed to the Systems Analysts and the Architects to create the systems architecture and design. The same requirements artifact can also be passed to testers to create their test plans and test scenarios, as well as technical writers to create documentation outlines.
Documentation is always part of deliverables. However, artifacts may not be unless it is stated in the contract as part of custom solutions development
Grist Project Management. (n.d.). The Principles Of Conventional Software Engineering. Retrieved from https://www.gristprojectmanagement.us/software-3/the-principles-of-conventional-software-engineering.html
Innvovative Architects. (n.d.). The Seven Phases of the System-Development Life Cycle. Retrieved from https://www.innovativearchitects.com/KnowledgeCenter/basic-IT-systems/system-development-life-cycle.aspx
Royce, W. (n.d.). Software Management Renaissance. Retrieved from https://www.nasa.gov/pdf/293180main_56571main_wroyce_east_west_0301.pdf
Smart Bear. (n.d.). How to Interview Users to Find Out What They Really Want. Retrieved from https://blog.smartbear.com/software-quality/how-to-interview-users-to-find-out-what-they-really-want/