Week 29 in the Office (12-16/09/2022)

Photo by Lucas Clara on Unsplash

Week 29 in the Office (12-16/09/2022)

Quarterly Goal Review: Testing

This week was a relaxed one as the whole organisation recovers mentally and physically after the event. So, meetings and in-person office arrangements were deferred allowing me time to work on some of the backlog tickets we put off due to the event, but also to chip away at a personal project I am trying to transfer from plain HTML, CSS and JS to a Drupal managed site. I have also found time to practice on plain JS (through CodeCademy) which I have got rusty on from doing little development over the past 2 to 3 months.

The focus of this weeks post will be on my first quarterly goal I set for myself back in June / July which was aimed at holding myself more accountable for a technical topic that I found I had little knowledge of. Instead of complaining to my employer about it to try and get them to teach me, I endeavoured to write out SMART goals to plan and progress my learning on the topic of web / software testing independently. I wrote the following 3 months ago and in hindsight, it was a tall order and I didn't achieve what I set out to do. That allows me to narrow down my objectives to more realistic ones for the next quarterly goal (learning about and implementing APIs). Having said that, I'm glad I pursued this as I still came away with useful knowledge now than if I had put off the subject.

What did I want to achieve?

I wanted to gain more knowledge in frontend or backend code testing.

From my learning, it was made apparent that testing is not just a process, rather a philosophy and team effort requiring not only writing the tests, but also employees to come up with the use cases, justify the development time, QA for the tests themselves etc. We do not have the workforce or technical knowledge to perform these key roles within the organisation so the goal was flawed from the start.

The what, why and who?

  • I want to write my own unit / component / integration tests and improve my reading of other peoples test code. I did not manage to achieve this as my knowledge of programming principles is still between beginner and intermediate. As my trainer quite rightly puts it: "You need to know what the code is doing first and getting it to work, before attempting to test it."

  • This goal is important as it shows I can not only write functioning programs, I can problem solve and quality control my code. The skillset is marketable and it emphasises a level of maturity around the work I produce. It will help me save time by catching common bugs and not shipping them to deployment. I am happy I spent time learning about behavioural testing as I think it is a marketable practical skill, it helped me to automate user interactions on website page features which otherwise would be done manually. I can certainly leverage the fact that I thought about the process after writing code and considered returning time / value back to the employer. I took the lead on this task and gained a lot of satisfaction and learning in the process.

  • I am mainly the pursuer of this goal, but I can enlist appropriate support from colleagues and apprenticeship trainers. See above.
  • Limits are my dedication, patience and time commitment. Also, the competency limits listed under Apprentice challenges. These are always going to hold me back but considering my position in the learning journey, I'll take what I've learned as a positive overall.

How will I know when it is accomplished?

  • Produce at least one of each test type for the job codebase ideally. Otherwise, prepare own projects with test code and document them appropriately. I did not manage to produce a range of tests types for the reasons above but I did write some relevant user acceptance tests for our website. I refactored them with help from my trainer and made the source code accessible on GitHub.

  • Pick dedicated online learning resources and complete them. This will lay the groundwork for understanding the syntax and logic behind writing test code. This I did do as there is a plethora of information to read. My main sources of inspiration which I then compiled into a Google Doc include: CodeCademy modules, Testing Automation University, test framework docs, Youtube tutorials.

  • Gain and supplement high level knowledge of testing as part of the SDLC. As some base knowledge has been acquired from the bootcamp, revise this information and commit to memory. I managed to incorporate this task of behavioural testing into my apprenticeship reporting to showcase some understanding of software testing methodologies and frameworks. This was time well spent as the team do not have a need to implement thorough testing beyond that which is provided already in the build process (linting etc.) or provided unit tests as part of the contrib Drupal modules. It would have been difficult to justify this learning had the opportunity not presented itself.

  • Implement A11y testing and fixing and document the process for the apprenticeship portfolio. Didn't get round to this type of testing but certainly worth revisiting as I am sure our website is not as accessible as we would like it to be.

How do I accomplish this?

  • Milestone: produce test code and document. Present as a project on personal portfolio detailing the learning history. Presented as a subtask not full project on my apprenticeship portfolio.

  • Learning cert from online tutorials. Obtained from completing CodeCademy course(s).

  • Examine and understand the boilerplate testing scripts that come bundled with a Drupal site or if the org have implemented their own. This one is beyond me- see the quote from my trainer above.

Is it realistic?

  • Testing stage was not practically trained during the bootcamp. This was because you need to understand the fundamentals of what the code is doing before trying to debug and quality control it. This goal is imperative for career advancement and professional development in software engineering.
  • The goal maybe too premature to set because you need to understand what the code is doing before attempting to test it.
  • It matches my efforts and learning about the field is time well invested in any case.
  • The org do not do a lot of testing apart from what Drupal does automatically. So, this goal could lead to potentially incorporating test code into the CI/CD pipeline. You can document and market this as tangible ROI.

What are the time-constraints?

  • Study and develop for one quarter. If the journey takes longer, then take more time as necessary.
  • I have already setup target practice and review within the apprenticeship training program. Those activities have already been met so I need to explore more learning opportunities that fell out of the Frontend Test Fest Event in June. This process will likely take around 3 months to accomplish.
  • Examine our work codebase for basic examples of PHP testing. Understand what they are trying to achieve.
  • Pick a pet proj (one that takes in user data?) and write test scripts for it.
  • Online learning resources.
  • Implement test fixes in the project codebase.