Software testing

Process

First of all, the process of software testing is never ending, because the product always need to be improved and every time you do it you need to test it again. Now lets talk about the steps of the software testing process.

  1. Planning
  2. Creation of scenarios
  3. Preparation of test environment and data creation
  4. Run the scenarios
  5. Reporting results

Software testing is an iterative process and continues after the software is completed.

Types and levels

When we say testing, we see that there are different types of tests. Test types have a per-category in terms of levels, types and processes. Each type of test can be an article in its own right or even a book

Activities and roles

Test lead/manager: A test lead is responsible for:

  • Defining the testing activities for subordinates – testers or test engineers.
  • All responsibilities of test planning.
  • To check if the team has all the necessary resources to execute the testing activities.
  • To check if testing is going hand in hand with the software development in all phases.
  • Prepare the status report of testing activities.
  • Required Interactions with customers.
  • Updating project manager regularly about the progress of testing activities.

Test engineers/QA testers/QC testers are responsible for:

  • To read all the documents and understand what needs to be tested.
  • Based on the information procured in the above step decide how it is to be tested.
  • Inform the test lead about what all resources will be required for software testing.
  • Develop test cases and prioritize testing activities.
  • Execute all the test case and report defects, define severity and priority for each defect.
  • Carry out regression testing every time when changes are made to the code to fix defects.

Testing environments

A testing environment is a setup of software and hardware for the testing teams to execute test cases. In other words, it supports test execution with hardware, software and network configured.

Key areas to set up in Test Environment:

  • System and applications
  • Test data
  • Database server
  • Front-end running environment
  • Client operating system
  • Browser
  • Hardware includes Server Operating system
  • Network
  • Documentation required like reference documents/configuration guides/installation guides/ user manuals

Specification-Based or Black-Box techniques: create tests, primarly, by analysis of the test basis and tracing the bugs in order to know how the system behaves.

Structure-Based or White-Box techniques: code coverage, statement and decision coverage, and control flow test design technique.

Experience-Based techniques: based on the testers skill, perception, experience with similar applications, and experience with similar technologies.

Process for control and management of defects in artifacts

  1. Defect prevention
  2. Deliverable baseline
  3. Defect discovery
  4. Defect resolution
  5. Process improvement

Tools for V&V

Automation is used by the supporting language, commonly used a script language computer to automated the software application. There are varios tools to write automation scripts. Allows us to identify the process that can be used to automate the testing process. Tools for version control GithubGitkrakenGitpod Tools for testing HP Quick Test ProfessionalSeleniumIBM Rational Functional... Continue Reading →

Software Testing

Software testing is one of the most important activities in the life cycle of any software, since with it we can detect easily if the software works or if it doesn’t. Software Testing is a process in which you perform evaluations of the software and the system to check if it follows the requirements, works as expected and is bug-free.

Types of Software Testing

To understand the way software testing works you need to know that there are many different types of testing and each one with its own subtypes. In this blog we will mainly talk about the software testing approaches and the software testing levels.

Software Testing Approaches

  • White Box Testing.- This type of testing is done by via looking at the structure of the code, you test the internal part of it, designing test cases for it.
  • Black Box Testing.– This type of testing is done mainly by looking at the inputs and outputs of the system or the program. You design test cases which only look at the input and the output, and see if the expected output matches the real output of the program.
  • Grey Box Testing.- In this type of testing you perform a mixture of Black box and a mixture of White Box testing, you choose tests that align with what you want out of the program.

Software Testing Levels

  • Unit Testing.- This level of testing is done via testing each module of the program as separate units, ensuring that each function and every unit of the application works correctly as expected by its own.
  • Integration Testing.- In this type of testing you check if the connections or transfer of data within the units works as expected.
  • System Testing.- In this type, you check the system as a whole, ensuring that the whole system works as is expected when all the units work together as one.
  • Acceptance Testing.- In this type of testing you mainly check if the system follows the requirements of the client. Checking if it has met the criteria for delivery.

You could also divide software testing into functional and non functional, where in one you test the functional requirements of the program and in the other you test the non functional ones.

Roles of Software Testing

  • QA Manager.- The one who manages the whole team related to testing, ensuring they are all working as a team and following the guidelines of the company and of the client.
  • QA Analyst.- The one whose main job is analyzing the results of the tests, looking for where the bugs are, what is happening, and the one who also designs the tests.
  • Tester.- The person whose in charge of testing the system using the test cases.
  • Other jobs.- Sometimes in software testing you get other roles like the one in charge of the automation of the tests or the one who tests the performance of the system.

Test Case Design

Since Test Cases are the base of testing, you need to ensure that they are good and are well designed. To do that there are different techniques which you can use to design them. These techniques are defined into 3 categories:

  • Designing test cases using the requirements specification and black box testing.- Examples: Use Case Testing, Decision Table Testing.
  • Designing test cases from the structure of the system or its components. Examples: Branch coverage, path coverage.
  • Designing test cases based on the tester’s experience or intuition. Examples: Error guessing, Exploratory Testing.

Testing Environments

One of the main ways to test is using a testing environment, which is an environment designed solely for testing before launching to the live server. It allows to deploy application and ensure it is bug free before pushing to the product.

Software Testing

 

This time were talking about software testing, one of the most important processes in software quality assurance, which I might say a lot, but NOW I’m really meaning it (Not that I didn´t meant it before, it just really important this time).  The definition of software quality is “an investigation done with the purpose of informing stakeholders about the software’s quality of the service or product. It pretty much means that the tester checks that the product is behaving as it should, and if they find errors, they solve them. Software testing has a defined process which is divided in 5 steps:

1. Planning

In this step we determine the scope of the test and the risks of it, we also define the materials to be used, the sources the test needs and we give an estimate of the test dates.

2. Creation of scenarios

In this step we define the expected outputs of our test, and the scenarios of the test are written. The scenarios of the test should range between simple and diverse, so that the test itself can achieve a validity.

3. Preparation of test environment and data creation

In this step the preparation of the test are administered, the project should be installed in the test environment, the data to be used in the project should also be provided and prepared with accordance of the project reach.

And the test environment itself is tested so it doesn’t generate a problem during the test itself.

4. Run the Scenarios.

Simplest step, the scenarios previously created are applied and the tests are run. All the scenarios should be applied successfully but time constrains may make this a little too tough.

5 Report the results

A report of the result is created so that the stakeholders concerned are communicated, it should be noted that this report should use a basic language as possible, and it can present some videos or photo to help illustrate the results.

After all this explaining it should be clear what the general process of software testing is, but this process is applied even further as there are different types of software testing:

  • Unit Testing
  • Integration testing
  • System Testing
  • Acceptance testing

Unit testing, which is usually done by developers test whether a piece or block of code is doing its purpose. In this case we want to test a piece of code that calls another one and to isolate that piece so that we can verify its functionality.

Integration testing is done by testers, this one checks the combination of various parts in conjunction and their functionality as a whole. For example, if in a user interface test a button isn’t working, all the part that compose that user interface are considered as faulty. So, in integration testing we test the operation of two or more code blocks.

System testing is a test of the system as a whole (Shocking I know). If the previous tests are done in one or a group of code block, this test is done on the whole system, and it’s performed by QA testers. For example, testing an application and making sure that all of the functions are being processed as it was designed, if a bug is found during this test it usually means that the previous test were incomplete.

Acceptance tests are performed by end users, and its purpose is to confirm that the product is considered successful by a group of users.

Now in every software quality test there is usually a team or group of persons behind it, and these people have defined tasks and roles, so let’s do a breakdown of these. A group of quality testers is made up of, usually these roles:

·        Software tester:

o   Responsible for designing testing scenarios for usability testing.

o   Responsible for conducting the testing, thereafter, analyze the results and then submit his observations to the development team.

o   He may have to interact with the clients to better understand the product requirements or in case the design requires any kind of modifications.

o   Software Testers are often responsible for creating test-product documentation and must participate in testing related walk through.

 

·        Software test manager:

o   Responsible for all interdepartmental meetings.

o   Interaction with the customers whenever required.

o   Responsible for recruiting software testing staff.

o   Schedule testing activities create budget for testing and prepare test effort estimations.

o   Carry out continuous test process improvement with the help of metrics.

o   Check the quality of requirements, how well they are defined.

o   Trace test procedures with the help of test traceability matrix.

 

·        Software test Automator:

o   Be able to understand the requirement and design test procedures and test cases for automated software testing.

o   Design automated test scripts that are reusable.

o   Ensure that all automated testing related activities are carried out as per the standards defined by the company.

Another important aspect of software testing is the environment of your tests, while you could have all your tests in one environment it is recommended that for some types of tests your environment is prepared for the specific situation. We have four different types of testing environments, which are:

Integration Testing Environment

For this type of environment you don’t need a specific need of your environment, given that the tests that are applied are integration test, with an environment that can support these and has access to the basics and has the configuration and management of application servers, web servers, databases, and all the infrastructure needs of the application, you’re good.

Performance testing environment

Int this case the tests that is going to be applied is the system test, but you’re probably want to check how your product performs, so in this case you’re going to need multiple environments that has different kinds of configuration and characteristics, like: number of CPU cores, size of RAM,  concurrent users, Volume of data, etc.

Security Testing Environment

For this case of testing we need an environment which is devoid of security flaws (kind of impossible, I know) because these test are the ones with online services integrated, so when you’re running your system test you need to do a security test. Some of the rules for these tests are:

  • Have an isolated test environment.
  • Have non-disclosure agreements in place.
  • Don’t leave the system in a worse state.
  • Don’t touch production data
Chaos Testing Environment

This is one is a bit complicates, so according to chaos theory: “Chaos engineering is the discipline of experimenting on a system to build confidence in the system’s capability to withstand turbulent conditions in production.” So, we need an environment that has the ability to test the high-availability, disaster recovery, and business continuity provisions configured in each service crucial to improving the reliability of your whole system.

The next part to discuss is the test case design techniques, but this part is so long that it would take a dedicate blog entry for me to finish explaining all of them so we will just catalog them:

We can group the techniques depending on the test case itself, for the techniques that derive from a requirement specification or a black box test design are:

  • Boundary Value Analysis (BVA)
  • Equivalence Partitioning (EP)
  • Decision Table Testing
  • State Transition Diagrams
  • Use Case Testing

The next set of techniques derivates directly from the structure of a system:

  • Statement Coverage
  • Branch Coverage
  • Path Coverage
  • LCSAJ Testing

And the last set derivates from the developer previous experience:

  • Error Guessing
  • Exploratory Testing

And that’s all for today, writing this blog has been a bit tougher than expected, but it has been more fun too, the next blog might be the last one, so see you then!

Tools for V&V

Welcome to another of this interesting posts, I hope you’re excellent. In this time I will be talking about the existing tools for V&V.

Tools for version control

git image

Version control systems are software tools that helps a team manage changes to source code. They keeps track of every modification to the code in a special kind of database. They are especially useful for DevOps teams since they help them to reduce development time and increase successful deployments.

The top 5 tools for version control are the following:

To know more about each one, click on the name.

Automated Software Testing Tools

Test automation is an essential part for delivering quality software faster, it requires solutions in Agile, continous integration and DevOps methodologies. All of this cannor be realized without good tools.

Here is a list of the most trending software testing automation tools. To get to know more about each one, click on each title.

Tools for process administration of V&V

Ansible logo

Knowing the right tool to the right job can save us hours of extra work. Here are some tools for process administrarion of V&V.

Well i hope you’ve enjoy some of the useful tool i have provided you in this post. Thank you for taking the time to read this.

Work smarter, not harder

Quick recap before we begin this:

  • Verification answers the question “are we building the product right?”
  • Validation answers the question “are we building the right product?”

End of recap.

Now that we know what V&V stands for, we can focus on the tools to aid the V&V process. You see, you can’t just go off and do whatever you feel like doing. Even when software development is often a somewhat chaotic process, there’s a bit of organization going on. We’ll talk a little bit about the tools that we use to turn this seemingly chaotic process into something a little more organized.

Version Control Systems

First, there’s Version Control Systems. These help us make sure that we’re building the product right, and if we screw up, this tool allows us to go back in time and pretend that never happened. If you’re a programmer, you’re most likely familiar with Version Control already. If not, or if you’re new, let me explain it to ya. Version Control Systems record changes to a file or set of files over time to make it easier for you if you ever need to go back to a specific version later in the project lifetime.

  • Local Version Control System: This is what I like to call a self-managed version control, because it’s basically just you creating a bunch of copies in different directories. If you’re somewhat organized, you might even include a timestamp to identify them faster. Problem is, they’re really, really error prone. If you ever modify a file in the wrong directory, you just lost a version, and if you’re like me, who just lets VSCode auto-open the folder you’re working on, this is a real problem. Also, this only works if you’re a one-man-team. If you’re part of a team, this is absolutely impossible to implement unless everyone works on the same computer.
Local Version Control System. Screenshot owned by me, taken for demonstrative purposes.
  • Centralized Version Control System: So, in order to deal with the whole issue of working in teams, CVCSs became a thing. These systems have a single “central” working copy of the project in a centralized server, and programmers grab a version, modify it, and commit the changes back to the central copy. If another programmer modified the files while you were working on them yourself, you can pull their changes and merge them before committing them back to the server. As you can probably imagine, this made it a lot easier and faster to deal with multiple people working on the same file at the same time.
Centralized Version Control System. Image taken from: https://miro.medium.com/max/700/1*GgaGcwh5L246YcU5NVDA5A.png
  • Distributed Version Control System: This is like an iterative upgrade over CVSs. With DVCSs, you don’t only have a working copy of the project, but a copy of the whole repository (a “clone”) in your storage drive with the whole metadata of the original. This means copying the project is heavier, but not so much as to call it wasteful (we’re mostly working with text files after all), and it brings a bunch of benefits with it. You can easily go back to a different version of a file locally instead of contacting the central server each time you need to roll back, and you can more confidently commit changes to your local copy without worrying about breaking the main copy. If changes were pushed to the central copy, you “pull” all the repository changes and history, and if you want to commit to the central copy, you “push” your changes to make them visible and accessible to everyone in your team.
Distributed Version Control System. Image taken from: https://miro.medium.com/max/700/1*CEyiDu_mQ5u9NI0Fr2pSdA.png

By now, you can probably see how useful Version Control Systems are. They help us keep track of all the changes and modifications we’ve made to each file inside a project, and they allow us to go back if we ever screw up (which we often do), so if you’re not already using a Version Control System, you should probably consider starting to do so. I personally prefer Git, but you could prefer something else.

Tools for testing

What are computers for, if not to make our lives easier? I mean, we’re programmers, so we’re technically in charge of making computers useful for everyone, but that doesn’t mean that we can’t spoil ourselves every once in a while by making tools for ourselves.

Testing, no one likes it (unless maybe if you’re a video game tester, since you get to play the game before anyone else, but even then you have to deal with early bugs and glitches). The solution to this? automation. Why are you still testing your software manually, when a computer can make your life easier? You’re a programmer, you should know better. The less time you have to spend making sure that your code is correct, the more time you can spend stressing about your code not working the way you want it to. That’s why testing automation tools became a thing. Again, these tools help us make sure that we’re building the product right by making sure that everything’s working as it should.

There’s a bunch of test automation tools available. Now, I won’t go into too much detail on these because I’ve never actually used them myself (except for Postman, I heavily depend on Postman when creating web-based applications to test my endpoints. Postman is great, I heavily recommend it). Now, even if I haven’t used them myself, I still recommend that you check them out and try to find one that suits your needs. Test automation is especially useful once a project gets bigger and you can’t manually keep track of everything that’s going on. You can find more information on these tools here, here, and here.

Process administration tools

Process administration is arguably the second most important part of software development (after version control, which is a lifesaver). Process administration is how you keep track of who is doing which task, and how fast they’re working, so they help us make sure that we’re building the right product. It’s not only useful for managers who are looking to keep track of what everyone’s doing, but also for developers who might need help from someone who’s working on another piece of the project. These tools make it easier to know what everyone’s up to without having to explicitly ask them what they’re doing, and if you’re an introvert like me, the less social interactions the better.

Again, there’s a bunch of tools available, and we won’t talk about them all here. The main idea of this blog post is to let you know that they exist, and that they’re actually pretty useful.

Jira is arguably the most popular tool for this. It’s a software management tool that is used by a lot of big companies. It’s very, very robust, and it’s easy to implement in a workspace. Deep integration into the development process, compatibility with other management tools, and a bunch of features that aid the management process are some of the features that attract companies to Jira over their competitors.

Jira dashboard. Image taken from: https://www.atlassian.com/es/software/jira

Notion is another popular tool that serves more as an AIO workspace. Additional to management features, it can also help with design and productivity, and it supports Markdown Language, which is nice, since most developers are already used to Markdown.

Personally, when I just need a basic tool for managing tasks and tracking progress, I usually go for Trello. It doesn’t have a lot of features, but it gets the job done. If you don’t need anything fancy or deep integration with other tools, you can always opt for this, especially when you don’t have money to pay for new tools.

Remember, always try to find new ways to aid your work process. The less manual work you have to do, the more you can focus on actually being productive. Thinking and coming up with ideas takes time, and we can never take time for granted. Always remember that in order to be more productive, you have to learn how to work smarter, not harder.

Software Testing

El proceso de prueba de software, aunque no es exactamente el mismo para todas las metodologías, puede generalizarse para contener los puntos principales y más importantes que nos ayudan a tener una experiencia de prueba efectiva.

Primero necesitamos definir la estrategia de prueba y el plan de prueba. Algunas de las cosas que puede utilizar para describir el alcance de prueba de su proyecto son:

Sistemas que deben probarse
Características y funciones específicas del proyecto
requerimientos no funcionales
Herramientas
Y muchos más


Sin estrategia y plan, cada proyecto tendrá dificultades para ser productivo. Esto le ayudará a definir sus criterios de entrada y salida para las pruebas, que son importantes como control para su equipo. Si los requisitos carecen de especificidad, no entrarán en prueba. Si el código probado no cumple con los estándares de calidad específicos, el código nunca pasará a la siguiente fase.

En segundo lugar, necesita el diseño de prueba. Aquí tendrá una colección de casos de prueba necesarios para validar el sistema. El diseño de la prueba se basa en la experiencia de la prueba, el conocimiento de los probadores del sistema que se está probando y las prácticas de prueba predominantes. Se centra en descubrir y corregir errores importantes, en lugar de otros aspectos o defectos superficiales.

La tercera fase es la ejecución de la prueba. Hay muchas formas en las que puede ejecutar pruebas, para este paso tendrá que adaptar sus pruebas a la cantidad adecuada de pruebas hasta que esté seguro de que su sistema es completamente funcional y en su mayoría libre de errores. Comprender los requisitos de su entorno de prueba es clave para poder decidir su estrategia de prueba.

Finalmente, tenemos el cierre de la prueba. Aquí es donde entran en juego sus criterios de salida porque indican la finalización del ciclo de prueba y la preparación para el lanzamiento de su producto. Para garantizar el cierre de la prueba, se deben cumplir todos sus requisitos, tanto técnicos como comerciales. Debe haber aprobado un porcentaje mínimo de aprobación, la mejor práctica es apuntar al 90% de las pruebas aprobadas. Cada defecto crítico debe arreglarse.

Estos pasos son solo una vista general de cómo debería ser su proceso de prueba.

Hay cuatro niveles de prueba de software que debe tener en cuenta. Estos son:

Prueba unitaria: el programa se somete a evaluaciones que se centran en componentes específicos del software para ver si son completamente funcionales. El propósito de esta ronda de pruebas es determinar si el software funciona según lo diseñado. Una unidad puede referirse a una función, un programa individual o un procedimiento.


Prueba de integración: esto permite a las personas la oportunidad de combinar todas las unidades en un programa y probarlas juntas. Está diseñado para encontrar defectos de interfaz entre cada módulo o función.


Prueba del sistema: el nivel de prueba del sistema es el primero en el que se prueba la aplicación como un todo. Su objetivo es evaluar si el sistema ha cumplido con todos los requisitos y ver si cumple con los estándares de calidad.


Prueba de aceptación: este es el nivel final de prueba y se utiliza para determinar si un sistema está listo para su lanzamiento o no. Los requisitos pueden cambiar durante el ciclo de desarrollo, por lo que debe realizar una prueba para ver si el proceso satisface las necesidades de la empresa. Una vez superado este nivel, el software se puede entregar a producción.

Hay varios roles y actividades que se deben realizar en las pruebas, cada uno de los cuales tiene ciertas responsabilidades que deben realizarse. Los roles principales son:

Administrador de pruebas: el administrador de pruebas generalmente se contrata cuando hay muchos grupos de prueba. Algunas de las funciones principales de un administrador de pruebas son: preparar la estrategia de prueba, preparar el presupuesto de prueba, definir los niveles y ciclos de prueba, desarrollar la estrategia para la documentación de prueba, métricas e informes, y muchos más.


Líder de prueba: cada grupo de prueba debe estar dirigido por un líder de prueba. El líder de la prueba desempeña los roles de administrador de la prueba cuando está ausente y tiene sus propias responsabilidades, que incluyen: preparar el plan de prueba en cada nivel de prueba, definir los objetivos, asignar roles y proporcionar horarios a los probadores, etc.


Probadores: El grupo de probadores puede tener diferentes niveles de probadores y roles como probadores de rendimiento, probadores de automatización, etc.

Algunas de sus responsabilidades son: recopilar los requisitos de prueba, configurar y verificar el entorno de prueba, automatizar las pruebas y muchas más.

Y para qué sirve el testing? – Educacion IT

Software Review (Peer Review and/or Code Inspection)

On today´s topic, we are going to talk about Software Review and we are going to talk about: Definition and characteristicsActivities and rolesReviewing key work products (plans, requirements, design and code) Definition and characteristics Software Review is a part of the Software Development Life Cycle (for more info about Life Cycles you can take a... Continue Reading →