In this blog we have seen many different processes that help us ensure that our software is a quality software. But performing all of those processes manually without the help of any tool would end up being an enormous task. Thankfully there are multiple tools that help us perform those processes and we will talk about them today.
Tools for Version Control
For version control there are many different tools, but I will mainly be talking about Git and Github, which is the most popular one and the most used in the industry.
Before starting to talk about Git, let’s dive deeper into what is Version Control. Version control is the management of the code development process. It’s a way to manage the changes to the source code over time. It records each change and allows you to revert back to previous states that were recorded. As you can see this is very useful when developing, since if you made a mistake or prefer the way it was before you can easily just revert the changes. Version control also allows teams to work on a same program at once, since they can be working on the source code and the version control tools allow you to upload the changes and pull the changes if needed, and if there is conflict between what one member of the team did and another, then the version control tools allows you to choose between the two versions or to create a new one.
Git is a software tool that allows easy version control. It uses repositories as folders for the source code which can be divided into branch which can later be merged into a main one, that is the one deployed, while you can make experimental changes on other branches to later unite them with the main one or discard them.
One of the main advantages of Git is that since you can manage repositories locally even within a team, you can still have version control even if you don’t have a network connection at a time, and once you have it all the commits will be made after you have worked normally.
Another advantage is how since it’s so popular it’s really simple to implement and most people already know how to work with it, instead of other tools of version control. Also Git allows people to make pull requests, so you can kind of put changes on a waiting list until they are checked and if they are fine they merge into the main branch.
Tools for Testing
Selenium.- Selenium is one of the most popular tools for testing, which is a free open source automated testing framework. It’s mainly used to test web applications. It can use different languages like Java or C# to create Selenium Test Scripts which are ways to automate testing.
JUnit.- JUnit is another popular tool, it is a Java automation tool for unit tests mainly. It has been important for the evolution of TDD. JUnit allows to run tests continously and tells if they are succesful or not, also allowing to test multiple things at once. It’s a simple but effective tool which provides immediate feedback.
Tools for process administration
Trello. Trello is one of the most widely used in the industry, since it allows you to have a Kan Ban board for the development team, which is the basis for Agile Development, that way everyone is in the same page and can easily see in a visual way which tasks are immediate priority, which tasks are already done, who is working on which thing, etc. It’s a very useful tool that every software team should use.
Notion. Notion is a great tool that allows teams to have their own “wiki”, that way they can have the same notes, divide the information as needed, and have the resources at hand for everyone to use. It’s a way to have the information in a neat way about the software which is easy to access and modify.
What is “version control”, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
Local Version Control Systems
Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
Centralized Version Control Systems
The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
Git is one of the best version control tools that is available in the present market.
Provides strong support for non-linear development.
Distributed repository model.
Compatible with existing systems and protocols like HTTP, FTP, ssh.
Capable of efficiently handling small to large sized projects.
Cryptographic authentication of history.
Pluggable merge strategies.
Periodic explicit object packing.
Garbage accumulates until collected.
It is yet another most popular revision control system. CVS has been the tool of choice for a long time.
Client-server repository model.
Multiple developers might work on the same project parallelly.
CVS client will keep the working copy of the file up-to-date and requires manual intervention only when an edit conflict occurs
Keeps a historical snapshot of the project.
Anonymous read access.
‘Update’ command to keep local copies up to date.
Can uphold different branches of a project.
Excludes symbolic links to avoid a security risk.
Uses delta compression technique for efficient storage.
Tools for testing
Selenium is a testing framework to perform web application testing across various browsers and platforms like Windows, Mac, and Linux. Selenium helps the testers to write tests in various programming languages like Java, PHP, C#, Python, Groovy, Ruby, and Perl. It offers record and playback features to write tests without learning Selenium IDE.
Selenium proudly supports some of the largest, yet well known browser vendors who make sure they have Selenium as a native part of their browser. Selenium is undoubtedly the base for most of the other software testing tools in general.
TestingWhiz is a test automation tool with the code-less scripting by Cignet Infotech, a CMMi Level 3 IT solutions provider. TestingWhiz tool’s Enterprise edition offers a complete package of various automated testing solutions like web testing, software testing, database testing, API testing, mobile app testing, regression test suite maintenance, optimization, and automation, and cross-browser testing.
TestingWhiz offers various important features like:
Keyword-driven, data-driven testing, and distributed testing
Browser Extension Testing
Object Eye Internal Recorder
Integration with bug tracking tools like Jira, Mantis, TFS and FogBugz
Integration with test management tools like HP Quality Center, Zephyr, TestRail, and Microsoft VSTS
HP QuickTest Professional was renamed to HPE Unified Functional Testing. HPE UFT offers testing automation for functional and regression testing for software applications.
Visual Basic Scripting Edition scripting language is used by this tool to register the test processes and operates the various objects and controls in testing the applications.
QTP offers various features like:
Integration with Mercury Business Process Testing and Mercury Quality Center
Unique Smart Object Recognition
Error handling mechanism
Creation of parameters for objects, checkpoints, and data-driven tables
Process administration of V&V
Jira is a great software management tool that is widely used in many companies. It is very robust and offers many features that help the management of tasks and processes, and it can be integrated with other tools.
A very innovative tool that serves as a all-in-one workspace. It supports many features, for productivity, design, and of course, task management. An alternative to Jira, and great for managing the status of processes. It also supports markdown.
Only two more posts to go! So, here we go with the 5th one:
Software testing process
Types and levels of testing
Activities and roles in testing
Test Case Design techniques (open and closed views)
Process for control and management of defects in artifacts
#1: Test Strategy and Test Plan:
These artefacts describe the scope for testing for a project:
The systems that need to be tested, and any specific configurations
Features and functions that are the focus of the project
Test approach—traditional, exploratory, automation, etc.—or a mix
Key processes to follow – for defects resolution, defects triage
Tools—for logging defects, for test case scripting, for traceability
Documentation to refer, and to produce as output
Test environment requirements and setup
Risks, dependencies and contingencies
#2: Test Design
Test design as a process is an amalgamation of the Test Manager’s experience of similar projects over the years, testers’ knowledge of the system/functionality being tested and prevailing practices in testing at any given point. For instance, if you work for a company in the early stages of a new product development, your focus will be on uncovering major bugs with the alpha/beta versions of your software, and less on making the software completely bug-proof.
#3: Test Execution
You can execute tests in many different ways—as single, waterfall SIT (System Integration Test) and UAT (User Acceptance Test) phases; as part of Agile sprints; supplemented with exploratory tests; or with test-driven development. Ultimately, you need to do adequate amount of software testing to ensure your system is (relatively) bug-free.
#4: Test Closure
Right—so you have done the planning necessary, executed tests and now want to green-light your product for release. You need to consider the exit criteria for signalling completion of the test cycle and readiness for a release. Let’s look at the components of exit criteria in general:
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.
QA Leader is the most important member of the testing team. While it is extremely crucial for him/her to have a clear understanding of the testing process or methodology. It is also essential for him/her to be familiar with the varied test-program concerns such as test environment and data management, trouble reporting and resolution, etc.
2. Test Lead
With a clear understanding about the applications business area and its requirements, a test lead is a person who is also familiar with the varied test-program issues such as test data management, test design, and test development.
3. Test Engineer
The role of a test engineer is to determine the best way to create a process that can enable one to test a particular product in the best possible manner. Test engineers can have different expertise based on which they are assigned a role in a company. Some of these are: – Usability Test Engineer – Manual Test Engineer – Automated Test Engineer
4. Network Test Engineer
With a high level of proficiency and expertise in a variety of technical skills such as programming languages, database technologies, and computer operating systems, network test engineers are good at product evaluation and integration skills.
5. Test Library and Configuration Specialist:
This job role requires one to have a network, database, and system administration skills along with expertise in technical skills including programming languages, database technologies, and computer operating systems.
Having a sound knowledge about various concepts involved in test designing and execution methodologies, a software tester is the one who is able to interact efficiently with the development team.
Test Case Design techniques
1. Specification-Based or Black-Box techniques
This technique leverages the external description of the software such as technical specifications, design, and client’s requirements to design test cases. The technique enables testers to develop test cases that provide full test coverage.
2. Structure-Based or White-Box techniques
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.
3. Experience-Based techniques
These techniques are highly dependent on tester’s experience to understand the most important areas of the software. The outcomes of these techniques are based on the skills, knowledge, and expertise of the people involved. The types of experience-based techniques are as follows:
In this technique, the testers anticipate errors based on their experience, availability of data and their knowledge of product failure. Error guessing is dependent on the skills, intuition, and experience of the testers.
This technique is used to test the application without any formal documentation. There is minimum time available for testing and maximum for test execution. In exploratory testing, the test design and test execution are performed concurrently.
Process for control and management of defects in artifacts
Defect Management Life Cycle
When a system gives a different output other than the actual business requirement i.e. when there is a deviation from the actual or original business requirement then we can say that there is a defect in the system/software.
When the testing team executes the test cases, they come across a situation where the actual test result is different from the expected result. This variation is termed as a Defect.
Basically, a Software Defect is a condition which does not meet the software requirement. The defect is an error or a flaw which produces an unexpected or incorrect behavior in the system.
In order to handle the projects appropriately, you need to know how to deal with the development and release, but along with that you also need to know how to handle defects.
#1) Defect Prevention:
Defect prevention is the best method to eliminate the defects in the early stage of testing instead of finding the defects in the later stage and then fixing it. This method is also cost effective as the cost required for fixing the defects found in the early stages of testing is very low.
However, it is not possible to remove all the defects but at least you can minimize the impact of the defect and cost to fix the same.
The major steps involved in Defect Prevention are as follow:
Identify Critical Risk: Identify the critical risks in the system which will impact more if occurred during testing or in the later stage.
Estimate Expected Impact: For each critical risk, calculate how much would be the financial impact if the risk actually encountered.
Minimize expected impact: Once you identify all critical risks, take the topmost risks which may be harmful to the system if encountered and try to minimize or eliminate the risk. For risks which cannot be eliminated, it reduces the probability of occurrence and its financial impact.
#2) Deliverable Baseline:
When a deliverable (system, product or document) reaches its pre-defined milestone then you can say a deliverable is a baseline. In this process, the product or the deliverable moves from one stage to another and as the deliverable moves from one stage to another, the existing defects in the system also gets carried forward to the next milestone or stage.
#3) Defect Discovery:
It is almost impossible to remove all the defects from the system and make a system as a defect-free one. But you can identify the defects early before they become costlier to the project. We can say that the defect discovered means it is formally brought to the attention of the development team and after analysis of that the defect development team also accepted it as a defect.
Steps involved in Defect Discovery are as follows:
Find a Defect: Identify defects before they become a major problem to the system.
Report Defect: As soon as the testing team finds a defect, their responsibility is to make the development team aware that there is an issue identified which needs to be analyzed and fixed.
Acknowledge Defect: Once the testing team assigns the defect to the development team, its the development team’s responsibility to acknowledge the defect and continue further to fix it if it is a valid defect.
#4) Defect Resolution:
In the above process, the testing team has identified the defect and reported to the development team. Now here the development team needs to proceed for the resolution of the defect.
The steps involved in the defect resolution are as follows:
Prioritize the risk: Development team analyzes the defect and prioritizes the fixing of the defect. If a defect has more impact on the system then they make the fixing of the defect on a high priority.
Fix the defect: Based on the priority, the development team fixes the defect, higher priority defects are resolved first and lower priority defects are fixed at the end.
Report the Resolution: Its the development team’s responsibility to ensure that the testing team is aware when the defects are going for a fix and how the defect has been fixed i.e. by changing one of the configuration files or making some code changes. This will be helpful for the testing team to understand the cause of the defect.
#5) Process Improvement:
Though in the defect resolution process the defects are prioritized and fixed, from a process perspective, it does not mean that lower priority defects are not important and are not impacting much to the system. From process improvement point of view, all defects identified are same as a critical defect.
Even these minor defects give an opportunity to learn how to improve the process and prevent the occurrences of any defect which may impact system failure in the future. Identification of a defect having a lower impact on the system may not be a big deal but the occurrences of such defect in the system itself is a big deal.
For process improvement, everyone in the project needs to look back and check from where the defect was originated. Based on that you can make changes in the validation process, base-lining document, review process which may catch the defects early in the process which are less expensive.
CMMI CMMI has focuses on 3 specific areas: Product and Service Development, Service Establishment and Management and Product and Service Acquisition. TSP/PSP PSP stands for Personal Software Process, and it´s a work model that will help developers define their own processes, plan an give follow up to their own work, and administrate the quality of their product! TSP stands for Team Software Process, it enfasizes on teamwork, how to form teams undestanding each members strenghts and weaknesses. Common goals are formed, and plans are made using appropriate leadership :). ISO-15504 ISO-15504 is a reference model used to assess a team´s […]
Performing a software review, something vital in the life of any programmer. Something we do often, maybe to help a friend or even to review our own code. Reviewing is vital to ensure that we don’t have unexpected bugs due to typos or stuff we missed. In the industry, they also perform software review but in a more organized way, with certain activities and roles that I will be talking about in the following paragraphs.
What is a Software Review?
The main characteristic of a software review is that it helps us detects errors, bugs and defects in our code, and not just that we also ensure that it follows good practices. We can perform it simply by reading our own code or someone else’s a code, it’s a matter of examining it deeply so we can detect which lines are wrong in the code and quickly fix them. That’s one main advatange that it has over testing, since on testing you can detect that your code is wrong in many different ways, but to know where it is wrong you have to debug it, meanwhile in software review you quickly fix it, so you save a lot of time that would be spent on debugging.
There are many different types and subtypes of Software Review: Mainly Peer Review, Software Management Review and Software Audit Review. But we will be talking just about Peer Review and Code Inspection which are the most used in the industry.
This type of review is the one used in pair programming and is one of the most common types of software review. There are two main roles: The driver and the observer or navigator. The driver is the one who is writing the code, while the observer is the one reviewing it. These two persons are always switching roles continously, so the driver is never the driver for the whole Pair Programming Session. The navigator is continously reviewing each line, and ensuring that it’s following good practices, detecting bugs or problems that may arise and considering how it may function as a whole. This allows the driver to focus completely on the task of writing the code and making sure that it works, without worrying about stuff that the navigator is looking for.
Software Inspection is one of the most rigorous proccess of software review. It has two roles: The developer and the Reviewers. The process starts by the developer explaining the product created by the code, the requirements its trying to solve, and any questions that the reviewers may have. The developer then exits the room and the reviewers start to carefully examine it to detect any defect the product may have, after that they put all the data they collected in the inspection on a document and tell the defects detected to the developer along with ways to fix it. The one that tells this information to the developer is called the reporter which is chosen by a moderator which is the one that mediates everything between the reviewers and the developers. One main advantage of this process is that it can be performed even if the code isn’t over, because since the ones performing the review are humans coders they have the experience needed to detect common bugs or mistakes in the code without having specific tests.
There are three main metrics that must be carefully examined while performing a software inspection:
Defects; Detecting the amount of defects, and why they arised is important to ensure that they don’t happen in the future.
Effort: It’s important that the inspections are time effective, so they don’t end up bigger than the time spent on developing. To achieve this is important that the developers comment their code and use good practices like naming the variables relevant names and not using magic numbers.
Deliverable size: Inspections must be done every certain time, but in that time the deliverable that will be examined must not be too large or else we will fail on the effort metric since it will take a long time to carefully examine it.
Software review is always important, and it doesn’t even have to be hard. Just by performing good practices, doing good comments in your work and making sure that you understand how your code work will make it easier for the ones reviewing it and performing inspections on it, which on a larger scale will make your whole code team much more productive!
Al paso del tiempo en este mundo del Software podemos ver que empezamos programando un simple Hola Mundo!, de ahí pasamos a las variables, ciclos, y paso a paso hemos subido a cosas mas complicadas con el paso del tiempo, por lo que las cosas o elementos que tenemos que tener a consideración ha ido en aumento. Es por ello que hoy vengo a escribirles un poco acerca de la Calidad de Software.
¿Que es la calidad de Software?
En pocas palabras la Calidad de Software es el campo de estudio y practica que describe los atributos deseados o esperados del producto que se esta construyendo. Hay 2 panoramas que podemos observar: El manejo de defectos y la calidad de los atributos.
El manejo de los defectos
Un defecto del software puede ser identificado como la falla de no abordar los requisitos del usuario final.
Los defectos que podemos observar aquí incluye desde los requerimientos que se perdieron o los mal entendidos que se tiene con estos, un error de diseño, lógico, de datos, tiempo de procesamiento, validaciones o simplemente errores de código.
El manejo de los defectos es basado en el conteo y administración de los errores, estos errores comúnmente se dividen en severidad, por lo que esto nos sirve para darles un numero y así usarlos para la planificación. En un nivel más avanzado se usan herramientas para el manejo de estos, como la implementan de fases de detección, tablas de control o la capacidad de procesamiento.
Calidad de los atributos
Este enfoque de la calidad del software se ejemplifica mejor con modelos de calidad fija, como ISO / IEC 25010: 2011. Esta norma describe una jerarquía de ocho características de calidad, cada una compuesta de subcaracterísticas:
Asegurar la calidad del Software
Asegurar la calidad de software se confunde a menudo con la calidad del proceso con la calidad del producto, lo que conlleva a tener falsas expectativas a momento de desarrollar el software, de hecho muchas empresas hoy en día no tienen una organización o mentalidad de calidad del producto.
Un plan estrategico que deberian de establecer para el control de la calidad de manera atuomatizada:
Producto vs Proyecto. Calidad de Proceso, Producto y Servicio. Proceso del SQAP y la familia Squire. Continuous Integration. Grupo de QA: Certificación de Productos. Continuous Delivery: time to market.