Always QA your outputs
Especially when you feel extra confident about your results.
🇪🇸 Este post está escrito en inglés y español. Puedes encontrar el texto en español más abajo.
🇺🇸 If there’s one thing I’ve learned by working with software engineers is that you need to QA the outputs of your workflow. QA stands for Quality Assurance. In plain English, it means making sure that your workflow results in the outputs you expect. If you are working on a dashboard that includes a table with numbers that change every time to click on a button, you need to QA it to make sure that the button actually does what you expect it to do.
In my social science training, I was never taught about workflow, including the idea that you need to QA several aspects of your work before you make things public. For example, as a social scientist, you should QA your data cleaning outputs to make sure that the data included in analyses described in published journal articles are the right data. Even though this sounds very obvious and people do it informally, I’ve never seen formal training on how to QA the work of a social scientist.
The basics
Now that you have designed a clean workflow, you can establish routines and protocols to review the outputs of every step in a workflow.
Work with others
It’s really easy to make mistakes when you are the only person reviewing a script or a data set. Find a partner who can at least review outputs with you. Together, you can discuss whether the dataset includes the variables you expected it to include, whether the number of rows is close to what you expected, and whether the data is in the right format for the next step (for example, analysis or visualization).
Schedule your QA
Setting a timeframe for your QA can have several benefits. First, you can let everyone in your team know about the QA date(s). This will help you align expectations and will focus attention on reviewing workflow steps and outputs. Second, scheduling serves as a goal-setting strategy. You can plan your work around finishing the current version of your code by the QA date. That way, you establish a time-bound result. Otherwise, it’s really hard to have clarity (and align expectations with others) around when the code is done. Obviously, you can always keep improving code; the goal of a QA stage is to prepare you to release something that works, not something perfect.
Use test data
Create a test data set by using a subset of your real data or making up fake data. Then, use the test data set to make sure that your workflow results in the outputs you expected. For example, you can test whether the data cleaning routine results in the clean data you had in mind. Or, you can test whether the variables are in the right format to create the plot you envisioned.
Document issues and results
You will likely learn many things every time you QA your workflow. And because you want to build on your learning moving forward, you should be writing about the issues and errors that came up, as well as the things that worked. Documenting your learning is the only way to make sure that you and others will be able to reuse code in the future. If you are working with a versioning system (Git), you do this by default. If you aren’t, taking notes on a shared document is all you need to get started.
Even if you have a great QA, you may miss stuff. For example, an academic may send a paper to a journal and the reviewers may catch a mistake in the analyses based on the tables included in the article. This is what engineers call “bugs”. You can’t avoid bugs all the time. Yet a good QA can save you from encountering many bugs down the road.
🇪🇸 Si hay algo que he aprendido al trabajar con ingenieros de software es que necesitas controlar la calidad de los resultados de tu flujo de trabajo. QA significa Quality Assurance (Aseguramiento de Calidad). En términos simples, significa asegurarte de que tu flujo de trabajo resulte en los resultados que esperas. Si estás trabajando en un dashboard que incluye una tabla con números que cambian cada vez que haces clic en un botón, necesitas hacerle QA para asegurarte de que el botón realmente haga lo que esperas que haga.
En mi formación en ciencias sociales, nunca me enseñaron sobre flujos de trabajo, incluyendo la idea de que necesitas hacer QA a varios aspectos de tu trabajo antes de hacer público. Por ejemplo, deberías hacer QA de tus resultados de limpieza de datos para asegurarte de que los datos incluidos en los análisis descritos en los artículos de revistas publicados son los datos correctos. Aunque esto suena muy obvio y la gente lo hace informalmente, nunca he visto un curso o taller formal sobre cómo hacer QA al trabajo de un científico social.
Los conceptos básicos
Ahora que has diseñado un flujo de trabajo limpio, puedes establecer rutinas y protocolos para revisar los resultados de cada paso en un flujo de trabajo.
Trabaja con otros
Es muy fácil cometer errores cuando eres la única persona revisando un script o un conjunto de datos. Encuentra un compañero que al menos pueda revisar los resultados contigo. Juntos, pueden discutir si el conjunto de datos incluye las variables que esperabas que incluyera, si el número de filas está cerca de lo que esperabas, y si los datos están en el formato correcto para el siguiente paso (por ejemplo, análisis o visualización).
Programa tu QA
Establecer un marco de tiempo para tu QA puede tener varios beneficios. Primero, puedes hacer saber a todos en tu equipo sobre la fecha(s) de QA. Esto te ayudará a alinear expectativas y centrará la atención en revisar los pasos y los resultados del flujo de trabajo. En segundo lugar, programar sirve como una estrategia de establecimiento de metas. Puedes planificar tu trabajo en torno a terminar la versión actual de tu código para la fecha de QA. De esa manera, estableces un resultado con límite de tiempo. De lo contrario, es realmente difícil tener claridad (y alinear las expectativas con los demás) acerca de cuándo el código está terminado. Obviamente, siempre puedes seguir mejorando el código; el objetivo de una etapa de QA es prepararte para lanzar algo que funcione, no algo perfecto.
Usa datos de prueba
Crea un conjunto de datos de prueba utilizando un subconjunto de tus datos reales o inventando datos falsos. Luego, usa el conjunto de datos de prueba para asegurarte de que tu flujo de trabajo resulta en los resultados que esperabas. Por ejemplo, puedes probar si la rutina de limpieza de datos da como resultado los datos limpios que tenías en mente. O, puedes probar si las variables están en el formato correcto para crear la trama que imaginaste.
Documenta problemas y resultados
Es probable que aprendas muchas cosas cada vez que hagas QA a tu flujo de trabajo. Y porque quieres construir sobre tu aprendizaje en el futuro, deberías estar escribiendo sobre los problemas y errores que surgieron, así como sobre las cosas que funcionaron. Documentar tu aprendizaje es la única forma de asegurarte de que tú y otros podrán reutilizar el código en el futuro. Si estás trabajando con un sistema de versionado (Git), haces esto por defecto. Si no lo estás, tomar notas en un documento compartido es todo lo que necesitas para empezar.
Incluso si tienes un gran QA, puedes pasar por alto cosas. Por ejemplo, un académico puede enviar un artículo a una revista y los revisores pueden encontrar un error en los análisis basados en las tablas incluidas en el artículo. Esto es lo que los ingenieros llaman "bugs". No puedes evitar los bugs todo el tiempo. Sin embargo, un buen QA puede salvarte de encontrar muchos bugs en el futuro.