As we know Verification and Validation consists in exploring the current design against properties expressed as part of the requirements. There exists some tools for monitoring and controlling the process of verification and validation of software.
Tools for version control
What is version control? version control allows you to manage changes to files over time. Version control is important to keep track of changes and keep every team member working off the latest version
The ones that I have used are:
And from those I am really starting to enjoy GitHub is kind of a necessity in the world of software.
Tools for testing
Tools from a software testing context can be defined as a product that supports one or more test activities right from planning, requirements, creating a build, test execution, defect logging and test analysis.
For testing I don’t really have experience but I read about some and this are the ones that I liked the most.
Tools for process administration of V&V
I don’t know much about this, but I found this tool
The IBM® Rational® Rhapsody® product line is a collaborative design and development environment for systems engineers and software developers to create, test, and document real-time or embedded systems and software.
GDPro is a Visual OO Designing Tool, which gives the code developers the ability to create object-oriented software designs
This where the ones that I found and I notice that I really need to learn more and more,
Testing is a really important part on every aspect during the life cycle of software, you should test everything and since the begging.
Software Testing Process
Even testing has its own process you can’t just clic a button and run your test and that’s it… well actually yes you can with automatization but to get to that part you need to plan.
Creating test scenarios
Preparation of environments
You design your test strategy and test plan, this plan includes:
The systems that need to be tested, and any specific configurations
Features and functions that are the focus of the project
Key processes to follow
Documentation to refer, and to produce as output
Test environment requirements and setup
Risks, dependencies and contingencies
CREATING TEST SCENARIOS
You prepare what you want as an output, what your test should show or give as a result. The scenarios mean if I give this input … what should be the answer…
We are creating in this step what is called as a test suite. A test suite is a collection of test cases that are necessary to validate the system being built, against its original requirements.
PREPARATION OF ENVIRONMENTS
Here you get the resources that you listed during the planning step, what you need to run these test, it could be specific hardware or even some people to help, all of these aspects need to be covered.
You can execute test in different ways, like software, you can apply waterfall model or agile model. During this stage you need to do adequate amount of software testing to ensure your system is (relatively) bug-free
Every mayor detail is important for future maintenance of the software, you need to remember that you are not writing code for the computer, you are writing code for future developers that are going to review it.
In order to release the test and declare it done you need:
100% requirements coverage: all business and technical requirements have to be covered by testing.
Minimum % pass rate: targeting 90% of all test cases to be passed is best practice.
All critical defects to be fixed: self-explanatory. They are critical for a reason.
Polish things off with feedback: providing stats about testing – how many high/medium/low defects, which functions/features were affected, where were defects concentrated the most, approaches used to resolve defects (defer vs fix).
Types and levels of testing
Unit Testing is done to check whether the individual modules of the source code are working properly. i.e. testing each and every unit of the application separately.
Done by -> Developers
Is defined as the testing of combined parts of an application to determine if they function correctly. Integration testing can be done in two ways: Bottom-up integration testing and Top-down integration testing.
Done by -> Testers
Tests the system as a whole. Once all the components are integrated, the application as a whole is tested rigorously to see that it meets the specified Quality Standards
Done by -> Specialized testing team
Is like the final testing, here you are making sure that the whole system works as required
Done by -> End users
Is when the tester writes scripts and uses another software to test the product. This process involves automation of a manual process. Automation Testing is used to re-run the test scenarios that were performed manually, quickly, and repeatedly.
testing includes testing a software manually, i.e., without using any automated tool or any script. In this type, the tester takes over the role of an end-user and tests the software to identify any unexpected behavior or bug.
A test environment is a server that allows you to run the test cases you have defined.
A test environment provides accurate feedback about the quality and behavior of the application under test.
The testing environments recommended by Ricardo Avalos are:
Prometheus with Graphana and Kibana go to the link to start
Test Case Design techniques (open and closed views)
The main purpose of test case design techniques is to test the functionalities and features of the software with the help of effective test cases
Specification-Based or Black-Box techniques
Talks about external description of the software such as technical specifications, design, and client’s requirements to design test cases.
Here we have:
Boundary Value Analysis (BVA)
Equivalence Partitioning (EP)
Decision Table Testing
State Transition Diagrams
Use Case Testing
The structure-based or white-box technique design test cases based on the internal structure of the software. This technique exhaustively tests the developed code. Developers who have complete information of the software code, its internal structure, and design help to design the test cases.
Here we have:
Statement Testing & Coverage
Decision Testing Coverage
Multiple Condition Testing
All Path Testing
The outcomes of these techniques are based on the skills, knowledge, and expertise of the people involved.
Here we have:
Process for control & management of defects
Defect Management is a systematic process to identify and fix bugs.
A defect management cycle contains the following stages
Discovery of Defect -> the project teams have to discover as many defects as possible
Defect Categorization -> prioritize their tasks
Fixing of Defect by developers -> starts with assigning defects to developers, developers schedule the defect, fixed and send a report of resolution to the test manager
Verification by Testers -> the testing team verifies that the defects are actually resolved.
Defect Closure -> Once a defect has been resolved and verified, the defect is changed status as closed.
Defect Reports at the end of project -> n software testing is a process in which test managers prepare and send the defect report to the management team for feedback on defect management process and defects’ status.
Doing the GitHub part was really easy, as a Computer Science student I already had a GitHub account, personally I don’t use it a lot while working on self projects (BUT I REALLY SHOULD) but when I have to do some homework or task in teams, well thats a whole different story.
So that part was done, doing the SSH KEY that was new to me, apparently is a whole security topic, I learned that SSH improves or adds another layer of security while working on some repository. As personal computer for this semester I used a MAC, so as many things on MAC the installation was pretty easy, but if you want to take a look just click the image.
Cron was a WHOLE different story.
So the cron daemon on Linux runs tasks in the background at specific times, Crontab files can be used to automate backups, system maintenance and other repetitive tasks, meaning that instead of every time you start working on some repo, instead of writing the commands:
>git pull origin branch
You simply start working because Cron already did some fetch and pull by its own several times or the time you indicate, which is awesome since I had forgotten to do that and end up with some merge conflicts and hated every human being in this world and beyond.
So back at Cron. It seams pretty simple
Open your terminal
Get inside your repository by the -> cd Desktop… commands
Once you are there (git status should work) you type crontab -e
And thats it!
Well it didn’t work for me.
I did everything I could and nothing.
I found these instructions on some repo on git. AND LITERALLY IS JUST 2 LINES OF CODE!, click on the button to see!
If you want to move inside the editor you need to press the letter “i” as INSERT and you will be in editing mode, then for saving you write :wq. I did this and the whole thing looked great but it didn’t do anything.
I even followed every post from the next link, (click on image) but still any luck.
If it worked to you please leave some commend bellow to help me!.
Is an inspection of a software by one or more individuals it can be the ones in charge of the software or other people somehow involved, with the objective of finding and resolving errors and defects in the software during the early stages of Software Development Life Cycle (SDLC).
Software review helps software engineers in validating the quality, functionality and other vital features and components of the software.
It includes testing the software product and it makes sure that it meets the requirements stated by the client.
Objectives of Software Review:
To improve the productivity of the development team.
To facilitate the code reading and interpretation in the future.
To make the testing process time and cost effective.
Detect on early stages errors.
To make the final software with fewer defects.
Make sure everyone on the team understand every part of the software.
Frequent check of samples of work can lead to low error rate.
To eliminate the inadequacies.
This diagram explains how the review should be done in every part where is needed. As in every process of the life cycle of software you need to plan and the review is not the exception, why is this? because you need to establish what parts are going to be reviewed, how is in charge, in what stages of the software should be done, the outcome expected. Then you start by some inputs, reading the code and analyzing the outputs while you document everything, remember that this is precisely one of the advantages of doing code review.
After all the errors or details that need to be corrected are target, you need to do a meeting in order to discuss how the changes are going to be applied and the responsibilities of each team member. You work on the issues and then meet again to see if everything is okey. And you start over.
I know this may seem a pretty hard or sometimes even unnecessary work but believe is not, this reviewing time can help you understand the code, make progress on documentation, etc. Some time that you could be spending later on bug fixing and where correcting something can lead to crash more things, so what you prefer? spend your time on bug fixing at the end or spend your time doing some documentation and correcting small issues?
Types of Software Reviews:
Software Peer Review: The process of checking the technical content and quality of the product. Usually done by the author of the work product along with some other developers. Peer Review has following types:
Code Review: Computer source code is examined.
Pair Programming: It is a code review where two developers develop code together.
Walkthrough: Members of the development team are guided by author who asks questions and make comments about defects.
Technical Review: A team of highly qualified individuals examines the software product for errors on specifications or standards.
Inspection: The reviewers follow a well-defined process to find defects.
Software Management Review: Evaluates the work status.
Software Audit Review: People who are not a part of the development team, organize an independent inspection of the software product.
So yup a lot of work but well oriented work that can save you a lot of time when you finish your software.
How to review the key work products? As I mentioned before there are some stages that you need to follow on each key work product but here I will mention what you should focus.
Plans -> what I have learned is that here you need to review dates, thats the critical part, how are you organizing, what are you doing in time, what is out of schedule. So when you are reviewing your plans focus on delivery dates and make sure they are accurate with the amount of work. It should be reviewed by the project manager.
Requirements -> here you should review clearness, every work on the requirements document should be clear and understood by everything, check that there aren’t any gray scales. It should be reviewed by all the team members.
Design -> make sure that every corner is on the hand with the requirements list and that the customer is satisfied with it, make some appointments and ask your customer to give its opinion.
Code -> don’t just look for bugs or errors, here look also for making readable and clear code. Review by developers in charge of it and also by other developers that are not part of the project. Remember you are not writing code just for a machine but also for other people that are going to maintain the software.
Software is built in order to satisfy the needs of a specific market or organization, but with technology increasing everyday, the customers expectations grows as well, to the point that now delivering a product that does what is asked is not enough. Quality of software is essential, here enters the Verification and Validation of Software, a process oriented to maintain software quality. It can also be referee as Software Quality Control.
Verification: Are we building the product right?
Validation: Are we building the right product?
V&V in the life cycle of software development
This model is based on the association of a testing phase for each corresponding development stage. In the life cycle of software development is a highly-disciplined model and the next phase starts only after completion of the previous phase and is a sequential model type.
This model is a kind of cousin from the Waterfall model, meaning that you have to be very careful on each part because going back when you make a mistake can be catastrophic, in personal I don’t like this model since you are not seeing like little advances as the prototype model, but it depends on the type of project, your customer your team work, etc.
The requirements are collected, analyzed and studied. How the system is implemented is not important here, but what the system is supposed to do.
It involves detailed communication with the customer to understand and document his/her expectations and exact requirements. This would serve as the guideline for the system designers in the system design phase.
Determine verification approach
Determine adequacy of requirements
Generate functional test data
Determine consistency of design with requirements
USER ACCEPTANCE TEST PLAN
User Acceptance Test Plans are developed during this stage as business requirements can be used as an input. It involves testing the product in user environment, meaning that the user should give some expected outputs from the program, as an example could be the error margins accepted by the user.
This part is extremely important, even the little details could cause big issues. For example the case of a missile that because a little margin error, killed 28 soldiers. If you want to learn more click on the gif.
USER ACCEPTANCE TESTING
Performed in a user environment that resembles the production environment, using realistic data. UAT verifies that delivered system meets user’s requirement and system is ready for use in real time.
The testing of a single program, module or unit of code. Usually performed by the developer of the software performs as designed.
Performed by -> Developers
Systems design is the phase where system engineers analyze and understand the business requirements and figure out possibilities and techniques by which the user requirements can be implemented. Once this is established you can create the software specification document which serves as a blueprint for the development phase is generated, like a cook book.
Determine adequacy of design
Generate structural and functional test data
Determine consistency with design
SYSTEM TEST PLAN
During the realization of the system test plan is discussed the kind of testing that is going to be applied, which can include functional and structural testing, such as stress testing. Also what parts from the code are going to be tested, what inputs are going to be tested and the outputs expected.
System Test ensures that expectations from application developed are met. The whole application is tested for its functionality, inter-dependency and communication. System Testing verifies that functional and non-functional requirements have been met. Load and performance testing, stress testing, regression testing, etc., are subsets of system testing.
Performed by -> Independent Test Team
HIGH LEVEL DESIGN
Architectural specifications are understood and designed in this phase. The system design is broken down further into modules taking up different functionality. The baseline in selecting the architecture is that it should realize all functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc.
The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage.
INTEGRATED TEST PLAN
Integration Test Plans can be designed and documented during this stage. Here you decide what types of testing you can implement that involves hardware parts, and what parts of the hardware are going to be tested
Integration tests are performed to test the coexistence and communication of the internal modules within the system. These tests verify that units created and tested independently can coexist and communicate among themselves.
Performed by -> Developers with support from an independent test team
The detailed internal design for all the system modules is specified so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo-code.
It is important that the design is compatible with the other modules in the system architecture and the other external systems.
UNIT TEST PLAN
Here you need to divide what parts of the code are critic or soft. Also how are you going to test each individual part, and what to do in case something crashes.
A unit is the smallest entity which can independently exist, e.g. a program module.
Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/units. It helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.
Performed by -> Development team.
International standards for V&V of Software
IEEE Std 1986
2. IEEE Std 1012-1998
For these 2 there ir a HUGE document, if you want to learn even more click on the button
IEEE standards focuses on verification & validation (V&V) processes and applies to systems, software, and hardware being developed, maintained, or reused.
The purpose of the standard is to perform the following: – Establish a common framework of the V&V processes, activities, and tasks in support of all system, software, and hardware life cycle processes.
Actually each part of the verification testing has its own IEEE standard, I will only mention them, and if you want to learn more you can check this information, is from wikipedia but it works for this perfectly fine, at least to have some understanding.
This activity involves the initiation, preparation of response, contract, planning, execution and control, review and evaluation, and delivery and completion activities, integrity levels, etc.
I dare say this is the most important part, since your plan is how are you going to execute everything and the different parts of your work. It can also help you visualize if its the right model for your project or it you need a different approach. Doing this part correctly can save you a lot of time or could be your doom, so you need to be extremely careful.
Administration of a V&VPlan
The administration process involves -> Software reports, documentation, policies, tasks, dates. As in a debate there must be a moderator, also the V&V Plan needs some administration, some plan to follow with dates and people in charge, backup plans in case you miss some dead line. I read that this part depends more on the type of project you are developing and your user requirements, so it depends totally on what you are doing.
Originally created for the U.S. Department of Defense to assess the quality and capability of their software contractors. CMMI best practices focus on what needs to be done to improve performance and align operations to business goals. It is interesting that it was created by the U.S department, also I read that the CMMI is used not only by software development, but also other areas or companies use them as well.
Evaluates three areas:
process and service development
service establishment and management
product and service acquisition
Level 1 – Initial.
Level 2 – Managed. Configuration Management.
Level 3 – Defined. Decision Analysis and Resolution.
Level 4 – Quantitatively Managed.
Level 5 – Optimizing.
The CMMI principal is that “the quality of a system or product is highly influenced by the process used to develop and maintain it”
Team Software Process and Personal Software Process
Is a structured software development process designed to increase the quality of software products through a high level organized team.
This model is really eye catching since it is first oriented to improve yourself and them improve the team work. This is perfect because first you need how to work alone and then you can learn how to work on a team without going in the way of others or the more talented getting all mean.
The PSP is implemented on a personal level, and then the activities are integrated into the TSP work team
The PSP follows the premise that when people make mistakes, their errors are usually predictable, so PSP developers can personalize their checklists to target their own common errors. This when merged with the team is a powerful tool to get a high quality software.
Establishes requirements for an evaluation of processes and evaluation models, pretending that these requirements can be applied in any evaluation model, this means that as the first model, it can be applied to not only software products.
It contains a reference model. The reference model defines a process dimension and a capability dimension. This process is divided into 5 categories:
For me this model is the most formal of all of them, since is backed up from the TR, IEEE and so many “formal” organizations, and also for me is one of the most complicated or high level from the whole models described here. The good of this is that it can be modified in order to apply it to scrum model.
Is a process reference model developed in Mexico, this standard is composed of four parts:
Part 01 Concepts and products definition
Part 02 Process requirements (MoProSoft)
Part 03 Process implementation guidelines
Part 04 Evaluation principles (EvalProSoft)
The MoProSoft process model consists of three layers or categories:
High Management: contains the Business Management process.
Management: composed of the Process Management, Projects Management and Resources Management processes.
Operation: includes the Specific Project Management process (SPM), Software Development and Maintenance process (SDM).
It is nice to know that a standard model was created in Mexico, sometimes I have the wrong idea that all these standards come from only one place, but this is totally wrong. Also from what I have read, is interesting that this model MoProSoft considers the development and maintenance software processes as one, I would dare to say that separating the process like an organization level could bring some communication barrer, but it depends where is applied.
Is an organizational improvement model which serves as a kind of roadmap for initiating, planning, and implementing process improvement actions for defect reductions.
The IDEAL model is named for the five phases an organization runs through in performing a change initiative: Initiating, Diagnosing, Establishing, Acting, Learning
At first I thought this was an iterative model, but no. The contrary is like the waterfall method, you first detect your problems or weakness, then you prepare a plan of action and then you follow it. From all the method this for me seemed the most straight forward method.
The field of study and PRACTICE that describes and ensures the desirable attributes fo software products, it measures how well software is designed -> quality of design, and how well the code molds from that design -> quality of conformance.
This means that the Software Quality ensures that our program, code, system, meets our client expectations.
Some of the key aspects that SO takes on account (additional of course to our requirements) are:
Good design: easy and friendly to the user design, everything under 3 clicks from distance.
Reliability: perform the functionality without any issues.
Durability: software should be able to work during long periods of time without crashing.
Consistency: it should be able to work as well in different devices
Maintainability: bugs should be able to capture and fix quickly
Purpose-> Ensure Quality
Definition by IEEE
The degree to which a system, component, or process meets customer or user needs or expectations and specified requirements
Software Quality search for explicit and implicit requirements and expectations. Where explicit means, clearly defined and documented by our customer and implicit means not defined or documented but more like a suggestion
If you want to learn more you should check this video, its pretty good
Defining Software Quality
Software Quality Assurance (SQA) ensures how we handle the quality in the processes of a software product, establishing and evaluating all of these in a “process-focused action”, so that in the end, we end up having a product completely functional, with the basic minimum quality being accomplished in all cases, and a happy user in most cases.
My experience installing and using a Virtual Machine with linux as Operative System…was painful.
I know is pretty useful having a virtual machine for different purposes, even on my diferente classes I have used many times different virtual machines, for example my Networks class 1 and 2, Advanced Programming and so on.
If you need to install a Virtual Machine with linux and you don’t know how, you should check this video, is actually pretty helpful.
Finally one of my biggest mistake was not studying or doing Linux research before using it, I am pretty aware that some people are experts at Linux, but I certainly was not, I was used to Mac and Windows, so I couldn’t install like Sublime Text for example on my Linux Virtual Machine…because I was trying to do it like downloading it from the browser and expecting to just with some clicks install it…
Well after hours of looking up at those files were I couldn’t find the .exe I understood that everything works from TERMINAL!!!!!, and with just a few lines of commands all my apps were installed.
So…always do some research before jumping on deeper and new waters.